AIで実装は速くなったのに、なぜプロジェクトは終わらないのか？
生成AIの活用でコードを書く速度は確実に上がりました。それなのに、プロジェクト全体で見ると「思ったほど速く終わっていない」と感じたことはないでしょうか。複数チーム・複数プロジェクトを横断して開発者兼スクラムマスターとして働く中で見えてきた、生成AI時代の新しいボトルネックについて整理します。
実装は速くなった。でも、プロジェクトは速くなっていない
生成AIによって、開発者の仕事は確実に速くなりました。
- 以前は数時間かかっていた実装が、数十分で終わることも珍しくない
- エラーメッセージを検索してStack Overflowを巡回し、公式ドキュメントを読む…といったデバッグの時間も大幅に減った
- 設計の壁打ちやドキュメント作成のスピードも上がった
一方で、プロジェクト全体を見渡すと、なんとなく「速くなった実感がない」というのが正直なところです。仕様の整理、レビュー、動作確認、顧客との調整、Slackでの相談。実装自体は1時間で終わるのに、「本当にこの仕様でいいんだっけ」という確認に数時間かかる。コードを書く時間よりも、誰かの返事を待つ時間の方が長い。そんな場面が現場ではよく起きています。
生成AIによって実装のコストは下がったものの、仕事が減ったわけではなく、時間を使う場所が変わっただけなのではないか。ここに一つの仮説が生まれます。
ボトルネックは、「実装」から「意思決定」へ移動したのではないか。
開発現場はこれまでも「意思決定の効率化」に取り組んできた
生成AIが登場するずっと前から、開発現場は意思決定を効率化するための工夫を積み重ねてきました。整理すると、大きく3つのアプローチに分けられます。
① 意思決定を減らす
コーディング規約、テンプレート、ガードレールの設計、ハーネスなど。毎回ゼロから判断しなくて済むようにする、つまり人間が判断する必要そのものを減らすアプローチです。生成AIとの相性も良く、比較的うまく機能しています。ただし対象になるのは、主に「どう実装するか」「どんなコードを書くか」といった技術的な意思決定です。
② 意思決定を履歴化する
ADR（Architecture Decision Record）や設計書がこれにあたります。なぜその設計にしたのか、なぜその選択をしたのか。未来の自分や後から参画したメンバーのための情報として、意思決定を組織の知識として残すアプローチです。これも比較的うまくいっている一方で、扱われているのはやはり技術的な意思決定が中心です。
③ 意思決定を分散する
権限委譲や、現場で判断できる範囲を広げるアプローチです。アジャイル開発の思想にも通じます。ただ、3つの中でこれが一番難しいと感じています。技術的な判断であればある程度ルール化できますが、「この機能を本当に作るべきか」「速度と品質のどちらを優先するか」「顧客の要望をどこまで受け入れるか」といった判断になると、途端に難しくなります。ベテランは判断できるけれど、その基準をうまく言語化できない。権限を移譲したつもりでも、結局は元の担当者に聞かないと決められない。こうしたことが現場ではよく起きています。
技術的な意思決定については、開発現場は長年改善を積み重ねてきました。一方で「何を作るのか」「なぜ作るのか」「どの課題を優先するのか」といったビジネス側の意思決定は、構造化や自動化がまだまだ難しい領域です。実装は速くなったのに、プロジェクト全体のスピードが思ったほど上がらない理由は、ここにあるのではないでしょうか。
AIに意思決定を任せられるか
では、実装をAIで効率化してきたように、意思決定もAIで効率化できないか。結論から言うと、部分的には可能だと考えています。
情報収集、複数ある選択肢の整理、それぞれのリスク分析、過去事例の検索。こうした部分はAIが得意とするところです。
ただし、大きな壁があります。AIは提案できますし、選択肢も出せますし、比較もできます。でも、「決めて、責任を取る」ことまではしてくれません。それはこれからも変わらず人間の役割です。むしろ、そこまでAIが担うようになったら、人間が働く意味自体を問い直す必要が出てくるだろうとも思っています。
AIに渡すべきは「答え」ではなく「判断基準」
では、AIに意思決定を支援してもらうには何を渡せばいいのでしょうか。それは答えそのものではなく、判断基準だと考えています。
意思決定には、必ずその責任者がいます。同じ課題であっても、立場が変われば判断は変わります。プロダクト責任者であれば顧客価値を重視するかもしれませんし、開発責任者であれば技術的負債を気にするでしょう。経営層であれば売上や利益、リスクを見るはずです。つまり、同じ課題に対する「正解」は一つではありません。
だからこそ、AIに渡すべきなのは「特定の誰か」の判断ではなく、「プロダクト責任者としてならどう判断するか」「経営者としてならどう判断するか」という、ロールごとの判断基準・判断フローです。意思決定者が複数いるなら、その全ロール分を言語化しておく必要があります。
そしてこれは、AI活用のためだけの話にとどまりません。人間同士の仕事でも同じです。誰が、何を重視して、どんな順番で判断するのか。それが言語化・共有されていないからこそ属人化が起こり、権限委譲が進まず、意思決定が特定の人に集中してしまう。AI活用のために必要な取り組みは、そのまま組織改善にもつながるテーマだと感じています。
現場からの気づき：開発者とPMのあいだで広がるギャップ
この考えを社内で議論した際、gaipack 本部長の鈴木からは、次のような指摘がありました。
エンジニアはAIの恩恵を受けやすく、実装が速くなることで生まれた余裕を、そのまま自分の担当範囲の品質向上に振り向けやすい立場にあります。一方でPM側の仕事は対人的な業務が中心のため、AIの恩恵を受けにくく、品質がそれほど上がりにくい。結果として、開発側とPM側の相対的なパフォーマンスの差が、以前よりも目立ちやすくなっているのではないか、という仮説です。
もしこの仮説が正しいとすれば、対応の方向性は「余裕が生まれた開発側が、PM側の業務の一部を引き取る、あるいは一緒にやる」形でギャップを埋めていくことかもしれません。実際、単なる開発者・作業者としてだけ動いていても、これから先は価値が上がりにくいのではないか、という感覚もあります。技術的な視点はもちろん、ビジネスの視点からも「こう開発した方がいい」と提案できるようになること。役割を広げていくことが、これからの開発者に求められる価値なのだと思います。
もっとも、これは「今までの開発者はここまで」という暗黙のスコープを、AIのない時代の前提のまま引きずっているだけなのかもしれません。AIによって前提が変わった以上、役割の境界線そのものを見直すタイミングに来ているのだと思います。まだ誰も「正解」を持っていない領域だからこそ、現場での試行錯誤を積み重ねながら、少しずつベストプラクティスを作っていく必要があると感じています。
まとめ
生成AIによって、「作る」コストは大きく下がりました。その結果、ボトルネックは「実装」から「意思決定」へと移動しています。だとすれば、次に効率化すべき対象も意思決定です。
- AIは情報収集・選択肢整理・リスク分析を支援できるが、決定と責任は人間が担う
- AIに渡すべきは答えではなく、ロールごとの判断基準
- 判断基準・判断フローの言語化は、AI活用だけでなく組織の属人化解消にもつながる
- 開発者に求められる役割も、技術的な意思決定だけでなくビジネス的な意思決定へと広がりつつある
「AI活用」の話をしているつもりが、最後は「人間の意思決定をどう構造化するか」という組織づくりの話になりました。でも、それこそがAI時代の面白さなのだと思います。
KDDIアイレットでは、実装の高速化にとどまらず、意思決定プロセスも含めた生成AI駆動開発を「gaipack」ブランドで支援を行っています。開発生産性の壁を感じている方は、お気軽にお問い合わせください。