AI駆動開発時代でも、「小さくはじめて大きく育てる」は変わらない
こんにちは。ライジングサン・システムコンサルティングの岩佐です。
これまで当社ブログでは、DXが停滞する背景を「IT経営」や「組織学習」の観点から整理し、「小さくはじめて大きく育てる」ことの重要性を述べてきました。
では、AI駆動開発によってソフトウェアを圧倒的に速く作れるようになった今、この原則はどうなるのでしょうか。
結論から言えば、この原則は古くなるどころか、むしろ重要性を増していると考えています。とくに、社内システムの内製化を検討している・進めている企業の担当者の方には、AI時代でもこの原則がなぜ有効かを知っておいていただきたいと考えています。
本記事では、その理由を3つに整理します。
- 人と組織は、大きな変化を一気には受け止められない
- 丸投げでは学習が残らず、「理解負債」が膨らむ
- 無秩序に作ると、野良アプリがはびこる
以下、順に説明します。
1. 人と組織は、大きな変化を一気には受け止められない
1-1. AIで大規模なシステムを短時間で作れるようになった
生成AIやAI駆動開発の進化で、ソフトウェア開発の風景は変わってきました。UIモックアップ、CRUD、帳票、API連携、テストコード、ドキュメントまで、従来は人手で積み上げていたものを、かなり短い時間で形にできるようになっています。業務システムの初期構築や検証フェーズでは、以前は「要件を固めてから」「予算を確保してから」と段階を踏まなければ進まなかったものが、今では仮説段階でもUIやバックエンドプロセスを簡易実装し、実物を見ながら質の高い議論ができるようになりました。
これは大きな前進です。
ですがその一方で、短時間で形にできるからこそ、「一気にまとめてリリースしよう」という発想も生まれやすくなっています。社内システムの内製化を進めるなかでも、AIで短期間に形にできるからと、一気にリリースしたくなる場面はあるかもしれません。
1-2. エンドユーザが変化を受け止める速度は変わっていない
しかし、エンドユーザが新しい仕組みを理解し、受け入れ、日々の業務の中で使いこなし、さらに改善に参加できるようになるまでの速度は変わっていません。社内システムであれば、エンドユーザは自社の現場の皆さんです。大規模なシステムを一気にビッグバンリリースすると、これまでの業務フローや承認プロセスを大きく変える必要が出てくることがほとんどです。このような大きな変化を、日常業務をこなしながら受け入れるのは、その皆さんにとても大きな負担を強いることになります。
こうした泥臭いことを一つひとつ整理し、関係者で合意し、現場で回る形にしていく必要があります。この部分は、今もなお人間の仕事です。前記事「DXが止まる本当の理由は、ITではなく”IT経営”にある」の通り、DXが本格化すると問題は技術より組織の論点（意思決定、責任分担、標準化、予算、経営関与）に移ります。いくらAIが優秀になってもこの論点は消えません。
1-3. ビッグバンリリースは、現場の負担が大きすぎる
したがって、いくらAIで早くつくれるようになったからといっても、自社の現場に大きな変化を強いるビッグバンリリースは、現場の負担が大きすぎることが多いのです。開発スピードが上がったことと、導入の成功確率が上がったことは、必ずしも同じではありません。作れることが大きな価値なのは確かですが、それだけで人と組織が変わるわけではありません。大規模なシステムを短時間でつくっても、人や組織はそんな大きな変化を一気には受け止められないのです。
1-4. だから、小さな変化を素早く積み上げて育てる
だから、大きな変化を一気に強いるのではなく、小さな変化を素早く積み上げ、人間にとって自然な変化量に調整しながら大きく育てる。「小さくはじめて大きく育てる」は、その意味で現実的な選択であると同時に、理想のアプローチでもあります。AIで作る速度が上がったいま、その速度を「一気に大きく出す」ではなく、「小さな変化を素早く積み上げる」側に振り向ける。そう考えると、この原則は、AI時代にこそフィットするアプローチです。内製化では、現場に寄り添いながら社内に理解を蓄積していくことが重要です。だからこそ、現場が受け止められる変化量に合わせて小さく始め、素早く積み上げていくアプローチが有効になります。
2. AIに丸投げするだけでは「理解負債」が膨らむ
2-1. AIに一気に作らせる進め方が注目されている
最近、AIエージェントに要件を渡し、一気にアプリや業務システムを作らせるスタイルが注目されています。短期間で形になるインパクトは大きいです。ただ、この進め方には注意が必要です。流行している進め方のなかには、構造として「一括請負で丸投げする開発」とよく似た落とし穴を持つものがあります。ただし、社内システムの内製化を目指すのであれば、AIに一気に作らせるだけでは、後述するように社内に必要な学習が残りません。
2-2. 過程を飛ばすと、学習が残らず「理解負債」が膨らむ
内製化では、社内に「何を作るか・どう指示すれば望むものができるか」という判断力や学習を蓄積することが目的の一端です。要件をAIに渡し、完成した成果物を受け取る——そのやり方だと、発注側であるユーザ企業に、「どんな指示を出せば望むソフトウェアができ、どんな指示だと役に立たないものができたか」という学びが十分残りません。これは、相手が受託開発会社でもAIでも、その本質は変わりません。
更に業務システムを長く使い続けるためには、「何が動くか」だけでなく、「なぜこう作られているのか」を説明できる必要があります。ある入力項目が必要な理由。ある承認ステップを残した理由。ある例外処理をあえて自動化しなかった理由。こうした判断の積み重ねこそが、後から改善し、保守し、引き継ぐための土台になります。
現場の困りごとを聞き、仕様に言語化し、優先順位をつけ、実装と運用に落とし込んでいく過程そのものに、ユーザ企業側の学習があります。この過程を精緻に記録し、いつでも参照できるようにしておくことは、社内システム内製化という文脈でも極めて重要です。
2-3. AIは丸投げ先ではなく、パートナーとして使う
AIがコードを書くことと、人が業務を理解し、意思決定し、責任を持つことは別の仕事です。AIが前者を強力に支援する時代だからこそ、後者をユーザ企業側で誰が担うか、どう残すかを、意識的に考える必要があります。つまり、AIを「文句を言わない、安上がりな丸投げ先」ではなく、人と組織の学習を共に進めるパートナーとして付き合うことが肝要です。
3. 無秩序に作ると、野良アプリがはびこる
3-1. 作れるからこそ、あちこちに仕組みを次々つくりたくなる
生成AIがより進化し、人間の意図をより正確に汲み取り、より早く質の高いソフトウェアを実装できるようになると、現場の困りごとへの対応がさらに手軽になります。あちこちの課題に、その場で小さな仕組みを次々につくりたくなる。これは一見すると良いことのように見えます。実際、小さな改善を素早く形にできるのはAI時代の強みです。
ノーコード・ローコードが注目された頃、「シチズンデベロッパー」という言葉とともに「誰でもアプリがつくれる時代」が喧伝されました。実際に開発のハードルは下がりましたが、無秩序にエンドユーザに開発を解放した場合の弊害も知られています。
たとえば、「もっと簡単な開発ツールを導入し、みんながアプリ開発できるようにすれば、さらに業務効率化が進むのでは」という目論見でDXを進めた場合です。
しかし蓋を開けてみると…
- 部門ごとに似て非なるアプリがつくられる
- マスターデータが統一されていないため、統合したくても統合できない
- 結果、野良アプリ同士のあいだで手作業での転記が発生する
など、DXとは真逆の事態に陥る事があります。この構図は、生成AIで作れる量が増えたときにもそのまま当てはまる可能性があります。
3-2. 全体設計がないまま増えると、野良アプリと同じ問題に
このように、全体設計や運用ルール、データのつながりを持たないまま社内アプリが増えると、やがて「野良Excel」と同じ問題が起きます。局所的な便利さの積み重ねが、全体では管理不能な複雑さに変わっていきます。この構図は新しいものではありません。なので、AI時代のリスクは「作れないこと」ではなく「作りすぎること」かもしれません。
正確には、作ったものが社内の学習や全体設計につながらないまま増殖していくことです。
3-3. 無秩序な生成AI開発に潜むセキュリティリスク
さらに、LLMによる開発では、ローコード・ノーコード開発ではあまり意識しなくてよかったリスクも顕在化します。それがセキュリティです。ローコード・ノーコードでは、開発プラットフォームが許した範囲でしかつくれない「制限されたもの」だったため、エンドユーザに開発を解放しても、開発者だけが担うような高度なセキュリティ考慮を求める場面は相対的に少なく、リスクは比較的抑えられていました。
一方、LLMでコードや仕様を自由に生成できるようになると、アクセス制御やデータの扱い、本番環境への反映など、これまで開発者だけが担ってきたセキュリティ考慮を、組織として設計・運用しないと、野良アプリ的な開発がそのままセキュリティ上の穴になりかねません。
3-4. 「小さく」は、設計された範囲で始めること
ここで重要なのは、「小さく始める」が無計画にたくさん作ることではない、という点です。
将来の成長を見据え、どの順番で広げるか、何を標準化するか、どこに学習を残すかを考えたうえで、無理なく広げられるように設計する。その意味での「小さく」であれば、野良化を防ぎながら、段階的に価値を積み上げていけます。
4. だから「小さくはじめて大きく育てる」
以上、3つの理由を述べてきました。
- 人・組織は大きな変化を一気には受け止められない（柱1）
- 丸投げでは学習が残らず、理解負債が膨らむ（柱2）
- 無秩序に作ると野良アプリがはびこる（柱3）
いずれも、「大きく一気に」「丸投げで」「無秩序に」進めたときに起きるリスクです。社内システムの内製化であればなおさら、これらは避け、小さく始めて学びながら育てる進め方が有効です。逆に言えば、受け止められる単位で段階的に出し、学習が残るようにプロセスにAIを組み込み、設計された範囲で広げる——つまり「小さくはじめて大きく育てる」——ことで、これらのリスクを抑えられます。
私たちは、生成AI駆動開発の時代を、小さく始める必要がなくなったのではなく、そのサイクルをこれまでより速く・低コストで回せるようになった時代だと捉えています。
小さく始めることは妥協ではありません。
成功確率を上げるための戦略です。
AIは、その戦略をより強力に支える道具になり得ます。設計思想の中心に「育てること」を置く。完成形を最初から定義しきらず、分割できる単位で導入し、フィードバックを仕様や運用に戻せるようにする。現場や運用担当者が改善に参加できる余地を残す。AIを、安い下請けではなく人と組織の学習を加速するパートナーとして位置づける。その前提に立つほうが、人にも組織にもソフトウェアにも無理がかかりません。AI時代だからこそ、この原則を守る必要があります。
まとめ
結局、AI時代に変わったものと、変わっていないもの
生成AIによって、ソフトウェアを形にするスピードは大きく上がりました。これは間違いなく大きな変化です。
しかし一方で、現場が新しい仕組みを理解し、運用し、改善し続けるには、相変わらず時間と対話が必要です。
私たちは、AI時代だからこそ「最初から全部入り」を目指すのではなく、この原則をより大切にしたいと考えています。
理由は3つです。（1）人・組織は大きな変化を一気には受け止められない。（2）丸投げでは学習が残らず理解負債が膨らむ。（3）無秩序に作ると野良アプリがはびこる。社内システムの内製化を検討している・進めている企業の担当者の方には、AIで作る速度が上がったいまでも、この原則を前提に進めていただくことをお勧めします。
生成AIも、便利な丸投げ先ではなく人と組織の学習を共に進めるパートナーとして使うほうが、大きな成果につながると、私たちは考えています。