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