2026/01/31

生成AI時代の開発組織の変化への考察

はじめに

生成AIの普及によって、設計・実装・テスト・ドキュメント作成まで、開発の「手を動かす」部分、いわゆるプロセス自体は明確に速くなりました。

一方で、リリース頻度が上がっているはずなのに、事業としての成果が比例してこないといった「加速しているのに進んでいない」という違和感を持つ場面も増えた気がします。
この記事は、具体的な手法を断定するのではなく、**「AIが効き始めた今、どこが詰まりやすくなっているのか」**を言語化するための整理です。

少しポエム寄りな部分もありますが、現場の会話を前に進めるための材料になればと思います。

対象読者

生成AIを開発に取り入れ、実装速度の向上を実感し始めている方
スクラムなどのアジャイルを回しているが、成果につながりにくい違和感がある方
見積もりや計画の会話が噛み合わず、疲弊しているエンジニアやPdM、マネージャー

参考資料

今回の記事は多くの参考資料の内容を踏まえて構成しています。個人の見解と参考資料の内容を混ぜつつ、私なりに解釈した内容であることをご了承ください。

速く作れるのに、なぜ事業は進まないのか？

生成AIで「作る」のは速くなりました。これは誰もが認める変化です。しかし、現場では次のような「詰まり」が目立つようになっています。

作業は早くこなせるようになっているはずなのに、優先順位がいつまでも決まらない
レビュー・承認・会議待ちといった「待機時間」の比重が増えた
「成果」の定義が、チケットの消化（アウトプット）なのか、事業への寄与（価値）なのか曖昧なまま走り続けている

AIによって「実装の遅さ」という開発組織の抱える課題が解消に向かいつつある一方、それ以外の場所にある摩擦が、組織のボトルネックとして浮かび上がってきました。

1. AIは「増幅器」

生成AIは増幅器であるという言説を聞いたことがないでしょうか？シニアエンジニアはより良いコードを素早く量産できるようになった一方で、元々いいコードが書けないエンジニアは高速で負債を量産してしまう現状を指しています。組織においても同様で、生成AIは、組織の弱点を自動で直してくれるツールではなく、むしろ 増幅器 として働きます。

もともと判断が速い組織は、実装の加速がそのまま事業の前進につながる
もともと合意形成が重い組織は、実装が速くなるほど決定の遅さが際立ち、実装に取りかかれない

個人の生産性が上がっても、組織全体のリードタイムが短縮されないのは、この増幅器が組織の構造的な歪みを解消できていないからです。

従来は仕様が決まるまでの間、開発チームは他にも実装したり、リファクタリングしたりといった作業が大量にあったため、決定の遅さが目立ちにくい面がありました。しかし、AIによって「作る」部分が高速化されると、決定の遅さがそのままリードタイムに直結します。

2. スクラムが「コンフォートゾーン」化する

次に、プロダクトチームで取り組むスクラムについて考えてみます。
スクラムは本来、不確実性の中で「学習」を繰り返すための枠組みです。
AI関係なく、スクラムにおいては運用が慣習化するほど、「枠組みを回していること」自体が目的化しがちです。

レトロスペクティブが「単なる会話の場」になる話してスッキリして終わり、というパターンです。本来は次のスプリントで「試し」、その結果を「更新」することで学習が進みますが、アクションが継続されないと学びは蓄積されません。
スプリントゴールが「バックログの詰め合わせ」になる「今週やるチケット一覧」がゴールになると、プロダクトをどうしたいかという狙いが消えます。スプリントが学習の単位ではなく、単なる作業処理のサイクルになってしまいます。

これらの課題は、生成AIが登場する以前から存在していましたが、AIで実装が加速するほど、この課題によるダメージは大きくなります。速く回っているのに、何も学べていない状態は顕在化しやすくなりました。

3. ボトルネックは意思決定の構造ではないか

開発のスループットが上がったとき、次に詰まるのは「技術」ではなく「組織構造」です。

具体的には、以下のような課題がある開発そしきをよく見かけます。

権限と責任の不一致：誰が決めるのか曖昧で、会議を繰り返さないと何も進まない。
役割の壁：「それはPMの仕事」「それはエンジニアの領分」という境界線でボールが止まり、リードタイムが伸びる。
評価制度のラグ：評価が「アウトプット（作った量）」に寄っていると、誰も「価値（効いた結果）」に責任を持たなくなる。

ボトルネックが技術的な部分にない場合、エンジニアが次に解消するべき課題は技術の外側にあることを認識する必要があります。

4. 詰まりを解消するための具体策

では構造的な詰まりに対し、私たちはどのような視点を持つべきでしょうか。

小さな単位で動く：人月の神話などで言われている通り、人数が増えるほど合意コストは指数関数的に増えます。生成AIによって労働集約部分が解消されると次は意思決定の摩擦を最小化する小さい単位のチーム編成が重要になります。
役割の境界を無くしていく：「誰の仕事か」で止まる時間を減らす。責務分担は必要ですが、境界が硬すぎると待ち時間が増えてしまい、生成AIによって他工程のリードタイムが短縮されているため、致命的なボトルネックになります。
マネジメントの再定義：マネージャーの役割が「進捗管理」だった時代は生成AIによって終わります。進捗は生成AIによって加速され、管理するメリットが薄れ、不確実性の増加によってコストだけが膨らみます。マネージャーは権限の整理、責任の設計といったボトルネックの除去へシフトしていく必要があります。

5. 計画は「当てない」。更新し続ける

ソフトウェア開発は、原因と結果が事後にしか見えない「複雑（Complex）」な問題領域です。この前提に立つと、そもそも「完璧な計画を立て、それを守る」というモデルは破綻しています。。

計画は「当てるもの」ではなく、経験と学びによって「更新し続ける活動」そのものである。

実務では、計画を分離して考えることが重要です。

計画の意味について考えてみましょう。何のために計画を立てて守るんでしょうか？

ビジネスの意思決定を支援するため?リリースに伴う作業の整理などビジネスを成り立たせるため?様々な理由があると思いますが、本当にそれらを実現するために、どの作業がいつ開始して、いつ完了するかといった詳細なスケジュールが必要でしょうか？

多くの場合、詳細なスケジュールは不要です。必要なのは、いつまでに何を達成したいのかという大まかな方向性と、そのために何を検証し、学び、更新していくのかというプロセスです。

そのため、計画は3つのレベルに分けて考えてみましょう。

長期ゴール： 6ヶ月〜1年先に達成したい大きな目標
中期マイルストーン： 1〜3ヶ月先に達成したい
短期の詳細： 1〜2週間のスプリントで達成したい具体的なタスク

これらの計画を立てた上で「わからないことリスト」を管理するのも有効です。ソフトウェア開発はよく不確実性があると言われますが、チーム内で何が不確実で、いつまでに、どうすれば検証できるのか。これを言語化しチーム内で認識を揃えることで、不確実性を管理することができます。

6. 見積もりは未来予測ではなく「交渉の道具」

そもそも見積もり通りに進まないことを問題視している人もよく見かけます。

これは前提から間違えていて、見積もりというのはそもそも「未来予測」ではなく、「交渉の道具」です。

令和になった現在でさえ、一週間、一ヶ月先の天気予報すら外れることがあるのに、我々エンジニアが半年、一年先のプロジェクトの状況を正確に当てることなど不可能で、あくまでも現時点での予測に過ぎません。

見積もりは占いではないということをまずは関係者で認識を持ちましょう。

組織が見積もりを求める真の理由は、技術的な予測が欲しいからではなく、**「意思決定の材料」**が欲しいからです。

例えば、以下のような判断をビジネスサイドとしてはしたいために技術的な見積もりを求めています。

どこに投資すべきか
何を優先し、何を捨てるべきか

そのためにエンジニアが提示できる内容は決して占いの結果ではないはずです。例えば、以下のような情報を提示できるとどうでしょうか。

前提: 仕様、リソース、スコープ
リスク: 技術的な不確実性
選択肢: 実現しうる範囲
トレードオフ: 将来を見据えたコストとメリットの比較

見積もりを通して何を合意できたかこそが重要です。

これらの認識をビジネスサイドを含めて合わせていくことで、見積もりを有効な判断材料として活用できるだけでなく、見積もりに対する不毛な議論も減らせるはずです。

ここでいう不毛な議論とは、例えば以下のようなものです。

技術的な見積もりが外れたことを責める
見積もりを絶対視し、変更を拒む
ビジネスサイドが過剰な要求をし、技術サイドが防御的すぎる見積もりを出す
技術サイドが無理な目標としての計画を立てざるを得ない
技術サイドが建前のスケジュールと本音のスケジュールを二重管理する

本当に自分たちがやりたいことは見積もりを100%当てることなのか、プロダクトを通してユーザーに価値を提供することなのか、改めて考えてみることをお勧めします。

7. 「アウトプット脳」と「価値脳」の衝突

本当に重要なことはユーザーに価値を提供することだとわかっていながら、なぜ組織はいつも「アウトプット」ばかり追ってしまうのでしょうか。

理由はシンプルで、アウトプットは測定しやすく、価値は測定しにくいからです。

リリースした事実は即座にカウントできますが、それがユーザーにどう効いたかは遅れて現れます。この時間差が、組織を測定可能な確かなもの、つまりアウトプット重視へと引き戻してしまいます。この断絶を個人の熱量で埋めるのには限界があります。

8. 断絶を埋める3つの仕組み

価値志向の文化を定着させるには、精神論ではなく仕組みが必要です。

8.1 実験の設計：全てのリリースを「機能追加」ではなく「ユーザーの行動変容に関する仮説検証」と定義し直す。
8.2 会話の設計：定例の報告順序を、「何を作ったか」ではなく「ユーザーにどんな変化があったか（あるいはまだ起きていないか）」から始めるよう強制的に固定する。
8.3 KPIの設計： KPIを単なるノルマではなく、先行指標、つまり兆しから事業指標までを繋ぐ仮説の連鎖（KPIチェーン）として扱う。

9. エンジニアが仕様設計に積極的に関与し、当事者になる

AI時代、エンジニアが決まった仕様を実装するだけ、といった分業モデルは機能しません。
なぜなら、将来にわたって発生する複雑性のコスト、いわゆる本来の意味での 技術的負債 を最も解像度高く理解しているのは、コードを書くエンジニア自身だからです。

これは、仕様実現によるメリットと複雑性によるコストのトレードオフ関係を最も理解しているのはエンジニアであるということを意味します。

つまりエンジニアは仕様の段階から対話に関与し、「仕様と設計の往復」を自ら回す必要があります。

じゃあマネージャーは必要ないか、というとそうではないと考えています。

PMの領域を奪うことではありません。PMはプロダクトに対して何を実現するべきか、といったアイデアを出して最終的な意思決定をします。エンジニアはプロダクトが持つ「複雑性」を管理し、持続可能な価値を守るためのプロとしてトレードオフの説明責任を果たし、意思決定を支援します。

10. まとめ

生成AIによっていわゆる作るプロセス全体がが加速したことで、私たちは否応なしに次の課題に向き合わされています。

私たちは何を「成果」と呼ぶのか
誰が、何を、どの速度で決めるのか
不確実性とどう対話し、組織としてどう学習するのか

これまで複雑性、不確実性に向き合うためのフレームワークであったスクラムでさえも、形式的な運用では効果が発揮しづらくなっており、組織の構造的な課題を解消しない限り、AIの恩恵を最大化できないことが明らかになってきました。

AI導入の成否は、結局のところ「組織が学習能力を取り戻せるか」にかかっています。速く作れる時代であればあるほど、小さく、早く学べない組織は、凄まじいスピードで「間違った場所」へと向かってしまうからです。