GitHub CopilotやClaude Codeなどのコーディング支援AIを導入したのに「思ったより開発が速くならない」——そんな声が現場から増えている。ソフトウェアエンジニアのFrederick Van Brabantは、その原因を鋭く指摘する。開発の真のボトルネックはコーディング速度ではなく、上流に潜む要件の曖昧さだ、と。
「長い＝問題の発生源」ではない
AIの文脈で頻繁に語られるのは、コーディングフェーズの自動化だ。「開発に70日かかっているならAIで3日に縮められる」——こういった期待をよく耳にする。ガントチャートを見れば確かに開発フェーズが最も長く見えるが、そこに集中するのは「見えやすいボトルネックに飛びつく」典型的な過ちだ。
トヨタ生産方式（TPS）や制約理論の古典的名著『ザ・ゴール』が教えるのは、プロセスの真のボトルネックを正確に特定し、そこだけに集中することの重要性だ。「時間がかかっているフェーズ」と「問題の発生源」は必ずしも一致しない。
本当のボトルネック：要件の曖昧さ
ソフトウェア開発がなぜ時間がかかるのかを考えてほしい。タイピングが遅いから、ではない。問題を定義し、仕様に落とし込み、コンピュータが解釈できる形に変換するプロセスに時間がかかるのだ。
たとえば「売上完了時にユーザーへメールを送る」という機能要件があったとする。これだけでは開発は始められない。
- メールの内容は何を含むのか？
- 売上処理にエラーがあった場合もメールを送るのか？
- 「売上完了」とはどの時点を指すのか？
こうした問いかけを繰り返し、ドメインエキスパートと協力して曖昧さを解消する作業こそが、ソフトウェア開発の実質的な工数の大半を占めている。
AIに「丸投げ」すると何が起きるか
「AIに投げれば早い」という期待は根強い。確かにAIはコードを素早く生成できる。だが問題は「正しいコードを生成しているか」だ。
人間vsAIの開発比較では、AIが自律的に動いているように見えるが、実際には大量のハンドホールディング（手取り足取りの誘導）が必要だ。曖昧な要件をAIに投げると、AIは「それらしいコード」を生成する。しかし、それが意図した動作をするかどうかは別問題だ。上流の問題（要件の曖昧さ）はそのまま残り、修正のためのやりとりが後ろに積み上がっていく。
プロセスの時間短縮に見えて、実際には「何が正しいか」を定義する作業が後ろにずれただけかもしれない。
実務への影響：日本のエンジニア・IT管理者へ
1. 上流プロセスへの投資を怠らない AIツールを入れる前に、要件定義・仕様書作成のプロセスを見直す。曖昧な仕様でAIにコードを書かせても、手直しに時間がかかるだけだ。「AIを入れる前に仕様を固める」は当たり前のようで、意外と実践できていない組織が多い。
2. AIへの指示を「仕様」として扱う AIへのプロンプトは仕様書と同じだ。「ざっくりした指示でいい感じにやってくれる」という期待は幻想だ。コンテキストを精緻に渡すスキルが、AIを活用する上での真の差別化要因になる。
3. 削れた時間をどこに使うかを先に設計する AIがコーディング工数を削減したとして、その時間で何をするかを先に決めておく。要件定義の精度を上げる、テストを充実させる、ユーザーインタビューを増やす——こういった上流・下流への投資が最終的なアウトカムを改善する。
筆者の見解
この記事の主張は、現場感覚として非常に腑に落ちる。
「AIを使えばすぐに成果が出る」という期待は、ツールに責任を押し付けている側面がある。何かが遅いとき、すぐに「開発が遅い、だからAIだ」という結論に飛ぶ組織は多い。だが問題の本質は、そのずっと前段にある。
実際にAIコーディングツールを日常的に使っていると痛感するのは「曖昧に指示すると曖昧な答えが返ってくる」という事実だ。これはAIの欠陥ではない。入力の質が出力の質を決める、という当たり前の原則がAIにも適用されるだけだ。
一方で、上流プロセスにこそAIを活用する余地がある。要件の構造化、矛盾の検出、ユーザーストーリーの精緻化——こういった作業にAIが介在すれば、本当の意味でのプロセス改善が起きる可能性がある。「AIはコードを書く道具」という枠を超え、「要件を一緒に考えるパートナー」として使いこなすフェーズが次のステップだろう。
「AIを入れれば速くなる」ではなく、「AIを正しく使うために何を変えるか」を問うことが、今のIT組織に最も求められている問いかけだと思う。ボトルネックを正確に特定してから打ち手を決める——これはAI以前の、プロセス改善の基本だ。
出典: この記事は I don’t think AI will make your processes go faster の内容をもとに、筆者の見解を加えて独自に執筆したものです。