生成AIに関する最新の調査結果をもとに、ソフトウェアプロダクト組織とエンジニアの変化を整理する。本稿では、その現状と動向を明らかにしたい。
対象とするのは、数年先の未来ではなく、現在およびその少し先くらいの範囲である。技術進化が速すぎて予想がつかないからだ。あまり先のことを考えても的外れな内容になってしまう。
参照するデータは、2025年以降に公開されたものに限定した。執筆時点が2025年10月であること、そしてAIエージェントの本格的な活用が始まったのも2025年であることが理由である。
なお、ここに記す内容には私自身のバイアスが少なからず含まれる点をあらかじめご承知おきいただきたい。
🎧 本記事の音声概要をポッドキャストで公開中
この記事の主要なポイントをGoogleのAIツールNotebookLMで音声概要化し、Spotifyにて実験的に配信中。
【ご視聴時の注意点】AI生成概要のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。
開発ワークフローの変化
Human-AIオーケストレーション化
ChatGPTやGeminiのような生成AIツールが対話型である理由は、Human-in-the-loopをUIとして形にする意図もあったのではないか。その真偽はともかく、私はそのように捉えている。
生成AIから期待する出力を得るために、人間とAIが対話を繰り返すことは珍しくない。人間がAIに指示を出し、出力を評価し、さらに完成度を高めるための指示を与える。
こうして人間を介したループの果てに最終成果物を得る。対話型UIは、このワークフローに最適だ。
これは、人間とAIによる協働──いわば「Human-AIオーケストレーション」である。
人間がオーケストレーターとして全体を指揮し、AIが実行を担う。とりわけ「AIエージェント」との協働では、人間は目的や戦略設計により集中できる。AIが自律的にタスクを計画し、必要に応じて外部ツールを活用するからだ。
こうしたオーケストレーション型の協働スタイルは、開発ワークフローにも浸透しつつある。開発プロセスへのAIツールの導入が進んでいるからだ。
Stack Overflowによる2025年の調査では、回答者の84%がAIツールを開発プロセスに利用していた*1。前年度の76%から8ポイント増加している*2。
一方で興味深いのは、51%のプロの開発者がAIエージェントをまだ利用していない点である。内訳を見ると、14%はコード補完のみに留まり、37%はAIエージェントの導入予定はないと回答している。*3
この結果は、調査期間が2025年5月29日から6月23日だったことに起因する可能性が高い。本格的なAIコーディングエージェントツールの登場がその前後であり、まだ十分に浸透していなかったのだろう。たとえばClaude Codeがリリースされたのが5月22日である。
2025年10月現在、実際には、開発ワークフローでのAIエージェント利用は定着しつつあると感るところだ。
一方で、AIを導入しても効果が出ない、かえって手間が増えて疲れるといった声もある。
たとえば、より多くのプルリクエスト（PR）が投げられるようになった結果、PRの自ビュー時間が91%増加したという調査結果もある*4。人間が大量のコードレビューに追われるようになったのだ。
その結果として、開発生産性やビジネス成果に目立った変化がみられないという。いわゆる「AI生産性パラドックス」と呼ばれる問題である。
そういった問題や課題は、技術の進化やプラクティスの登場で、いずれ軽減されていくはずだ。OpenAI DevDay 2025（現地10月6日）でのCodexの実演でも、それを感じられる。
全開発チームへのAI導入状況の均一化
開発ワークフローのAI化は、チーム間での浸透状況にバラツキが無いほうがよい。そうでなければ、導入効果を相殺する要因となり得るからだ*5。
複数チームが関わるソフトウェア開発プロジェクトを想定すると、その理由は明確だ。AI導入の遅れているチームが足を引っ張り、先行しているチームのスピードを打ち消してしまう可能性がある。
これも、AI生産性パラドックスを引き起こす一因である。
生産性向上のボトルネックは、AIモデルそのものではなくシステム──すなわち組織構造と運用にある。
したがって、こうした非対称な状況が見られる場合には、開発チーム間でのAI導入を段階的に均一化していく取り組みが求められるだろう。
PDLC（Product Development Life Cycle）の変化
開発ワークフロー以外へのAI導入
生成AIの活用は、開発だけにとどまらず、最終的にPDLC全体へと広げることになる。これも、AI生産性パラドックスがその背景だ。
AI導入が最も進んでいるコーディング作業に要する時間は、PDLCの中で25%から35%に過ぎない*6。言うまでもなく、AIを導入したからといって、その時間がゼロになるわけでもない。だから、市場投入までの時間への影響は軽微になる。
そもそも、一部のフェーズやプロセス、ステージのみを高速化しても、下流で詰まればそこがボトルネックとなり改善効果は取り消される。仮にそこにAIを導入してボトルネックを解消しても、別の箇所が新たなボトルネックとなるかもしれない。
だからこそ、PDLC全体を対象にしたAI導入が求められていく。部分最適ではなく、全体最適化を進めることが、AI活用の次の焦点となる。
プロダクトディスカバリのクロスファンクショナル化
プロダクトディスカバリプロセスは、プロトタイピングを通じてクロスファンクショナル化が従来より進むだろう。もちろんそこには開発者も含まれる。
「プロダクトディスカバリ」とは、「顧客とビジネスにとって価値があり、実現可能なものは何か」を継続的に探り、学ぶプロセスである。ソフトウェアデリバリーの前に実施され、「何を作るべきか」という不確実性を減らすことを目的とする。
従来、プロトタイピングのコストが高かった時代は、検証対象のアイデアを厳選せざるを得なかった。そのため、アイデアを検討・選定するフェーズと、プロトタイプを作成して検証するフェーズは明確に分かれていた。
しかしマッキンゼーは、AIネイティブなPDLCではこの二つのフェーズが統合されると指摘している*7。それはなぜか。
生成AIによってプロトタイプ作成に要する時間が大幅に削減されるためだ。アイデアが浮かべばすぐに形にし、実際に動くソフトウェアで検証できる。たとえばVibe Codingは、そのプラクティスに最適なワークフローだろう。
こうしてプロダクトディスカバリのサイクルが高速化すれば、職能を越えた緊密な連携がこれまで以上に求められる。職能が分断された状態では、全体のスピードが損なわれるうえ、後工程になるほど目的意識（Why）が薄れて検証の精度も落ちてしまう。
書籍『INSPIRED』では、プロダクトディスカバリ（製品発見）が次のように説明されている。
発見は、プロダクトマネジメント、ユーザーエクスペリエンスデザイン、エンジニアリングの緊密な協力によるところが大きい。製品の発見においては、製品のプログラムの１行目を書く前に、さまざまなリスクに取り組んでいる。
製品発見の目的は、良いアイデアと悪いアイデアをすぐに判別することだ。だから製品発見が生むものは有効なプロダクトバックログである。
引用: マーティ・ケーガン 著／佐藤 真治, 関 満徳 監修／神月 謙一 訳『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』日本能率協会マネジメントセンター, 2019年, CHAPTER8（文章内の強調は筆者によるもの）
AIによってこの「発見」の速度が加速するなら、チームの在り方そのものも変わらざるを得ない。クロスファンクショナル化は、AI時代のプロダクトディスカバリにおける必然的な帰結なのだと考えている。
ディスカバリとデリバリーのデュアルトラック化
プロダクトディスカバリとソフトウェアデリバリーをクロスファンクショナルに進めるなら、そのアプローチとして「デュアルトラックアジャイル」が適合する。
デュアルトラックアジャイルとは、プロダクトディスカバリとデリバリーを1つのプロセスに統合するモデルです。
引用: Jeff Gothelf, Josh Seiden 著／坂田 一倫 監訳／児島 修 訳／Eric Ries シリーズエディタ『Lean UX 第3版─アジャイルなチームによるプロダクト開発』オライリー・ジャパン, 2022年, 16.1.3（文章内の強調は筆者によるもの）
前掲の『INSPIRED』で述べられているとおり、プロダクトディスカバリの成果物は「有効なプロダクトバックログ」である。
自著『チームの力で組織を動かす』でも、プロダクトバックログを介してディスカバリとデリバリーが循環する様子を次のように記している。
企画を進める方をディスカバリトラック（discovery track）と呼び、開発を進める方をデリバリートラック（delivery track）と呼びます。ディスカバリトラックで詳細化したり検証して生き残った企画は、プロダクトバックログにデリバリートラック向けのアイテムとして追加されます。そして、デリバリートラックで開発し、リリースして得たフィードバックからの学びは、ディスカバリトラックに返されるのです。
もちろん、チームメンバー全員がどちらのトラックにも参加します。ディスカバリトラックにエンジニアが参加すると、開発時間が減ってデリバリートラックのアウトプットは小さくなるでしょう。ベロシティも下がります。しかし、それは問題ではありません。チームが担っているのは、単なるソフトウェア開発ではなく、プロダクト開発なのです。コードを書くことだけに集中することが、プロダクトの価値を高めるわけではありません。
引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年, 6-6-2（文章内の強調は筆者によるもの）
デュアルトラックアジャイルを採用しなくとも、ディスカバリとデリバリーのクロスファンクショナル化と連携が重要であることは変わらない。
たとえばHatchWorksのAIネイティブ手法は、両トラックで継続的なコラボレーションと適応を設計原則として掲げる*8。マッキンゼーも、AIネイティブなPDLCにおけるディスカバリ/デリバリー連動の重要性を強調している*9。
チームと組織の変化
あらゆるロール/職種の「Agentic ∗」化
AIエージェントを活用し、能動的に価値を生み出す働き方への変化、それをここでは「Agentic ∗（Agenticスター）」化と呼ぶことにしよう。たとえばエンジニアなら「Agenticエンジニア」である。この言葉は、HatchWorksによるものだ*10。
今後は、エンジニアだけでなく様々なロールや職種がこの方向に進むだろう。
Human-AIオーケストレーションによるコーディングを「Agentic Coding」と呼ぶことがある。この言葉は、Anthropic社が2025年4月にClaude Code利用者に向け「Agentic Codingのためのベストプラクティス」と称した文書を公開したことから注目を集めた*11。
Agentic Codingはプログラミング手法とみなせるが、それをエンジニアリングへと昇華させようとするのが、Zedの提唱する「Agentic Engineering」である*12。
そう、プログラミングとエンジニアリングは違うのだ。
Google社内では、「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」と言われる*13。「一度作ったら終わり」ではなく、継続的な開発・保守・運用を通して価値を更新していく営み、これがエンジニアリングだ。
だから、Agentic Codingを駆使してエンジニアリングを担うエンジニアは「Agenticエンジニア」なのだ。もちろん、コーディングだけを担っているわけではない。彼らは従来の開発知識や経験にAIオーケストレーションスキルを融合して様々な職務を遂行する。
「従来の知識や経験」が必要となる理由は、AIエージェントによるタスク実行に人間が介在するからだ。そこに、従来の知識や経験が活かされる。人間がまったく介さずともAIエージェントだけですべてをこなせる時代はまだ到来していない。
人間の知識や経験が必要であるということは、専門性の異なる人が集まる必要性にもつながる。一人でカバーできる仕事量やドメインにも限界がある。プロダクトの規模や性質にもよるが、こういった理由から、一人でPDLCすべてを完結することはまだ難しい。
したがって、これまでのように様々な知識や経験を持った人たちがチームを組んで、仕事を進めることになる。
そして今後は、エンジニア以外のロールや職種もAgentic化する。Human-AIオーケストレーションを前提としたワークフローでは、それぞれの専門知識と経験が活かされる。
たとえばHatchWorksではAgenticエンジニアのほかに、「Agenticプロダクトストラテジスト*14」「Agentic QAエンジニア*15」「Agenticデザイナー*16」なども定義されている。
AI時代のチームとは、専門性とオーケストレーション能力を兼ね備えたAgenticな集合体へと進化していく。
チームメンバー数の削減
AI導入によってチームの少人数化がさらに進む可能性がある。しかし、どこまで下がるかは定かではない。
ある文献では、生成AIの導入によって生産性が20から30%向上するため、人員を同程度削減しても成果は維持できると述べている。つまり、これまで10人で達成していた成果を、7人から8人で出せるという理屈だ。
一見、筋が通っているように思える。しかし、本当にそうだろうか。
この違和感の正体は、これが仕事量だけで計算されたものであり、仕事の領域や専門性が考慮されていない点だ。
メンバー数を減らしすぎると、適切な品質でアウトプットできる仕事の領域や専門性が狭くなる。マルチスキル化を進めようとも、一人の人間がカバーできる範囲には限界があるからだ。
Human-AIオーケストレーション型のワークフローでは、人間の知識や経験が依然として欠かせない。生成AIの支援があっても、専門外の領域では品質が落ちざるを得ない。
チームの少人数化は確実に進むだろう。しかしそれは、チームが扱える領域・専門性と品質の間のバランスが取れる地点で収束していくと考えられる。
チーム数の削減
チームの数も、限定的な削減になるだろう。理由はチームメンバー数の議論と同じである。
チーム数を決める根拠は、結局のところチームが扱える「認知負荷」の総量にある。この観点から、書籍『チームトポロジー』はチーム設計を展開していた*17。チーム単位で認知負荷を抑えることで、過剰な責任範囲や業務領域の拡大を防ぐという考え方だ。
認知負荷を考慮しないと、チームの責任範囲と担当領域は広がりすぎることになる。自分の仕事に熟達するだけの余裕がなくなり、担当業務のコンテキストスイッチに悩まされる。
引用: マシュー・スケルトン, マニュエル・パイス 著／原田 騎郎, 永瀬 美穂, 吉羽 龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセンター, 2021年, Chapter1
チームの認知負荷を担うのは、メンバーひとりひとりだ。つまり、チームが対応できる領域と品質のバランスによって、最適なチーム数が決まる。もし対応できる領域が変わらないなら、チーム数も大きく変化しない。
エンジニアに求められるスキルやコンピテンシー
生成された成果物の品質に対するアカウンタビリティ
AIによる成果物の品質は、指示した人間が責任を負っている。この自覚を欠いたAI活用は、チームや組織の生産性をかえって損ねるおそれがある。
業務で生成AIを利用すると、多くの人が直面するのが「AIワークスロップ」だ。これは、見かけは立派でも実質的な価値に欠けた成果物を指す。
こうしたワークスロップを成果物として提出すれば、受け手に余分な負担を与えることになる。ある調査では、ワークスロップ1件あたり平均2時間弱の追加作業が発生すると報告されている*18。たとえば品質の悪いPRを投げると、レビュアーの負荷は高くなる。
しかし、こういったことは現実にはよくあるようだ。同調査によると、40%の人が過去1か月間にワークスロップを受け取ったと回答している。また、受け取った仕事の15%をワークスロップが占めていた。*19
忘れてはならないのは、エンジニアリングとは「時間で積分したプログラミングである」ということだ。
その成果物は、ソフトウェアを継続的に開発し、保守・運用できるものでなければならない。人間によるものであれ、AIによるものであれ、この原則は変わらない。
AIが出力した成果物であっても、その品質のアカウンタビリティは、それを指示した人間にあるのだ。
ラーニングアジリティ
AI時代に活躍する人材は、「ラーニングアジリティ」を実践しているはずだ。
ラーニングアジリティとは、新しい状況や初めての経験から素早く学び、それを次の状況で柔軟に活かす能力を指す。単なる知識の吸収力ではなく、未知の環境に適応し、学びを実践へと変えられる力である。
AIの進化は極めて速く、今日の常識が明日には通用しなくなる。不確実性の高い環境下で、ソフトウェアエンジニアリングの変化もこれまで以上に加速している。
だからこそ、新しい技術や経験に臆することなく踏み出す姿勢が求められる。
プロンプト/コンテキストエンジニアリングスキル
生成AIを扱うエンジニアには、プロンプトエンジニアリングとコンテキストエンジニアリングの力が不可欠だ。これらを磨かなければ、意図を正確に伝え、AIの膨大な知識から期待する出力を引き出すことはできない。
さらに、LLMの特性を深く理解すれば、より適切なプロンプトを組み立てることも可能となる。目的に応じてLLMを使い分けることだってあるだろう。
また、チームのパフォーマンスを高めるために、コンテキストの整備も欠かせない。そこにはドキュメントを揃えるだけでなく、AIエージェントのツールチェーン（MCP）を整備することも含まれる。
フルスタック化によるエンドツーエンドでの開発スキル
マッキンゼーによれば、生成AIによって開発者はフルスタック化していくという*20。AIを活用することで、専門外の技術領域や技術スタックを扱うハードルが下がるからだろう。
フロントエンドからバックエンドまでエンドツーエンドで開発できることには、確かに合理性がある。
とはいえ、AIの有無にかかわらず、実際にフルスタック開発を行うと、技術領域ごとにIDEなどの開発環境を切り替えなければならず、作業は煩雑になりやすい。開発環境の統合が伴わなければ、効率は上がらないだろう。
加えて、AIを前提とした環境設計も重要になる。たとえば、マルチリポよりもモノリポの方が、AIを活用したエンドツーエンドでのフルスタック開発に適しているかもしれない。
設計やアーキテクチャ技術
システム全体を俯瞰するアーキテクチャ設計は、依然として人間の役割が大きい。Stanfordの2025年の研究によれば、生成AIは多くのライブラリや関数呼び出しが絡む複雑なコーディングを苦手としている*21。
一方で、シンプルな設計の多くは、AIに委ねた方が効率的だ。
もちろん、今後も人間とAIの役割の境界は変わり続ける。各社のLLMの性能が日々向上しているからだ。
それでも、人間がシステム全体の構造と品質を見通し、どの領域をAIに任せるかを判断する役割は変わらない。この統合的な視点こそ、AI時代におけるエンジニアの設計力と創造性の核心ではないだろうか。
クラフトマンシップ
経験豊富なエンジニアが持つ暗黙知は、AIに置き換えられにくい領域だ。生成AIは定型的な形式知を学習できても、文脈依存の判断や経験則のような暗黙知を再現することは難しい。
Stanfordの雇用データ分析では、AIに置き換えられやすいのは主に定型業務であり、熟練者が持つ暗黙知こそが今後も価値を持ち続けると指摘されている*22。
こうした熟練の技術や判断力は、Human-AIオーケストレーションにおいて、人間が品質を統制する要として機能する。AIの出力を評価し、改善へと導く知見が求められるからだ。
AI時代においても、ロバート・C・マーチンが説く「クラフトマンシップ*23」の精神は生き続ける。高い品質を追求し、技術的卓越性を磨き続ける姿勢こそ、変化の時代におけるプロフェッショナルの証といえる。
最後に
AIエージェントにより、公開されるアプリケーションの数は爆発的に増えると考えられる。エンジニアでなくてもアプリケーションを作れるようになるためだ。そこには、SNSのコンテンツがそうであるように、良質なものとそうでないものが入り混じるだろう。
私たちはその中で他との差別化を模索することになる。品質を高めるのか、速さや量で勝負するのか──AIの活用戦略そのものが競争軸となる。そこでは新たな課題も多く抱えることになるはずだ。
マーティン・ファウラーは、生成AIの特徴である「非決定性」とどう向き合うかをエンジニアは学ぶべきだと説いている*24。同じプロンプトを使っても、毎回異なる結果が返るためである。
しかし、私たちはすでに “非決定的な存在” と長く向き合ってきた。人間がそうだ。同じ指示を出しても、実行する人によって成果物は異なるし、同じ人でも状況によって結果は変わる。
つまり、生成AIの時代においては、マネジメントの知識やスキルをエンジニアリングに応用できるということだ。『チームの力で組織を動かす』を読まれた方ならお気づきかもしれないが、私は逆に、エンジニアリングの知識やスキルをマネジメントに応用している。だからこそ、この変化は非常に興味深い。
本稿を執筆してみて感じたことは、AIがどれほど進化しても、人間を介在させる限り組織設計の原則は大きくは変わらないという点である。AI中心の組織を設計しようとしても、結局は人間の特性を考慮せざるを得ないのだ。
最後に、本稿のテーマとも関わる自身の取り組みを紹介したい。
2025年8月25日に拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された。AIについてはほとんど触れていないが、AI時代の組織設計を考えるうえでの基礎となる内容だと考えている。
