mtx2s’s blog

エンジニアリングをエンジニアリングする。

RPI/SDD/AI-DLCによるAI-native開発──AI-assisted, AI-firstのさらにその先へ

gooseに代表される「RPI」、KiroやSpec Kitなどの「SDD（仕様駆動開発）」、そしてAWSの「AI-DLC」。これら次世代のアプローチは、AI-nativeな開発プロセスを、単なる概念から具体的な実装へと押し上げつつある。

いずれもAI-drivenという点では共通しており、広義にはAI-DLC（AI駆動開発ライフサイクル）の実践手法と捉えられるが、その内実は三者三様だ。複雑なコードの改修に焦点をあてるRPI, よく練られた仕様に基づいてコードを組み上げるSDD, そして組織全体のプロセス変革を目指すAWSのAI-DLC。課題解決の主眼も成果物の位置づけも大きく異なる。

本稿ではまず、“AI-native” な手法と “非AI-native” な手法の違いを明らかにする。そのうえで、前者の最新アプローチであるRPI/SDD/AI-DLCが持つ思想の違いを整理していく。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

AIネイティブ（AI-native）と非AIネイティブ（AI-assisted, AI-first）

現状のAI活用状況は、まだまだLiftの域を越えず、Shiftに至っていない、というのが私の印象だ。

この「Lift」と「Shift」という言葉は、ソフトウェアシステムのクラウド化が進み始めた2010年代によく使われた。オンプレミスのシステムをそのままクラウドに移行するのがLift、アーキテクチャや構成をクラウド前提で最適化する方式がShiftである。

クラウドのポテンシャルを最大限に引き出すには、Liftだけでは不十分であり、Shiftしなければならなかった。そうすることで、システムがはじめて “クラウドネイティブ” と呼ばれるものになった。

AIを活用したSDLC/PDLCも同様であり、現状はまだLiftであってShiftに至っていない。すなわち、AIネイティブ化されておらず、AIエージェントのポテンシャルを完全には引き出せていないということだ。

AI導入によるワークフローの変化には、次の3段階がある。なお、これらの用語に統一化された明確な定義があるわけではなさそうなので、多分に私の解釈に基づいていることに留意してほしい。

  1. AI-assisted: 既存のワークフローをそのままに、部分的な作業をAIで効率化するアプローチ
  2. AI-first: 既存のワークフローの中で、AIの活用を最優先に置くアプローチ
  3. AI-native: ワークフローそのものを、AIエージェント前提に構築するアプローチ

つまり、“組織を動かすシステム” の最適化を “既存のワークフローの延長線上” で実現するか（1や2）、“AIエージェントを基盤として” 再構築するか（3）で、AIネイティブかどうかが分かれる。無論、後者がAIネイティブである。DORAレポート2025では前者を「Augmenting」, 後者を「Evolving」と呼んでいる*1。

GitHub Copilotを振り返れば、コード補完は典型的なAI-assistedであり、Chatもまた、その延長線上に位置づけられる。いずれも、従来のままのワークフローを前提とした支援にとどまっている。

しかし、2025年5月から6月にかけて、Claude Codeの正式リリースやGitHub Copilot ChatへのAgent modeの搭載などが進んだことで状況は変わり始めた。これにより、AI-firstな運用が現実的な選択肢となり、さらにAI-nativeへと向かう可能性も視野に入った。

とはいえ、実際の現場では、多くがAI-firstの段階にとどまっていたのではないだろうか。その背景には、AIエージェントの活用が、依然として個人単位のワークフローに閉じており、組織やプロセス全体の再設計にまでは踏み込めていない、という構造的な要因がある。

「個人の生産性は高まったが、チーム・組織の生産性は大きく変わらない」という声を耳にすることがある。これこそ、“個人単位のワークフローに閉じた現状” を、端的に言い表している。

AI-firstが限界を迎える3つの構造的理由

AI-firstという言葉自体には、大きな解釈の幅が存在する。本節ではその中でも、明示的なプロセス設計を伴わず、アドホックにプロンプトを与えながら、AIエージェントと協働で成果物を作り上げていく開発スタイルをAI-firstとして扱う。

そのうえで、このスタイルには本質的な限界がある。いくつかの問題を抱えているからだ。

そのなかでも特に次の3点が大きい。これらに共通しているのは、“人間が頭の中で管理しているコンテキスト” を、そのままAIエージェントに丸投げする点にある。

  1. コードが複雑になりやすい / 複雑なコード相手ではうまく機能しない:
    • AIは「シンプル」化より「簡単」に実現する方法*2を好む。結果として複雑化が進行する。
  2. スペックドリフトが生じやすい:
    • 仕様の漏れや曖昧さをAIが勝手に “それっぽく” 補完してしまう。人間がそれに気づけない。
  3. チーム・組織の生産性が、個人のAI活用スキルに大きく依存する:
    • AIを使いこなす技術が「個人の職人技」に留まり、チーム・組織全体を底上げする仕組みが欠如している。

1について補足すると、こうなる理由の1つは、AIエージェントが、本質的複雑性と偶有的複雑性を区別できないことで生じる*3。コードベース上でこれらが絡み合って存在するからだ。

ソフトウェアには、解決すべき問題そのものに起因する「本質的複雑性」と、過去の回避策や古いフレームワークによる「偶有的複雑性」を内在している*4。後者は技術的負債にもなり得る。

AIはこの二つが絡み合った状態から「どこでビジネスロジックが終わり、どこからが古い仕組みなのか」という境界線を見出すことができず、単に古いロジックの上に新しい層を重ねてしまう。つまり、“簡単に実現する方法” を選択しがちだ。結果、コード設計はシンプルにならず、より複雑化する。

これが、AIエージェントに「リファクタリングして」と投げても、うまくいかないことがある理由の1つなのだろう。

AIで加速した世界では、こうして複雑化したコードの蓄積も加速する。あっという間に、追加開発や保守が困難な状況に陥ってしまうのだ。

1の複雑性の話だけでなく、2や3についても、対策として採用されやすいのは、人間の介入を増やす方向性だろう。つまり、AIによる最終成果物を、人間が “後から” 丹念に “レビュー” することでカバーするアプローチである。

しかし、これでは時間もかかる上に、手戻りも大きい。これが、AI導入効果の制約となる。AIによる加速が、そのままレビューという “人間のボトルネック” を肥大化させる結果となり、組織としての真の導入効果を損なってしまうのだ。

AI-nativeなフロー: ワーク&ハンドオフからインタラクティブAIフローへ

AI-nativeな手法の特徴は、最終的な実装（コード生成）の前に、コンテキストを構造化し、実行の指針となる中間成果物を段階的に確定させる開発プロセスにある。これらを、“AIエージェントが駆動” して、人間と協働でフローを進める。

こうすることで、AIの非決定性の削減に注力し、期待する成果物を得ようとする。つまり、後ではなく、先に手間をかけるのだ。そこで作成された中間成果物が、AIエージェントに対する制約となる。

一見するとウォーターフォールモデルへの回帰のようでもあるが、そうではない。フィードバックサイクルの長さが違う*5。AI-nativeなワークフロー/プロセスのサイクルは、数時間から数日レベルだ。これは、アジャイル手法による数週間レベルよりもはるかに短い。

また、工程単位での分業ではない点も異なる。特に、SDDや、AWSのAI-DLCは、クロスファンクショナルやペア・モブで全工程を進めることを想定されたものだ。

従来のような、“ワーク&ハンドオフ” の連続によるフローは、AI時代には適さない。着手した個々のワーク（WIP）がAIで加速するほど、ハンドオフでの待ち時間が最大のボトルネックとなるからだ。

そのうえ、工程をまたぐたびに生じる「引き継ぎのムダ*6」によって情報劣化が生じる。すなわち、コンテキストが欠落することでAIによる “勝手な推論” が混入し、スペックドリフトなどを誘発する。

だからこそ、全工程をクロスファンクショナルに進め、コンテキストをシームレスに繋ぎ、共有し続けることが合理的となる。

その最適解が、AIエージェントが情報の構造化をリードし、人間がその場で判断を下す「インタラクティブAIフロー」とでも言うべきスタイルだ。これは、Human-in-the-loopのもとで、人間が高速にOODAループを回し続けるプロセス*7に他ならない。

人間はパイロットであり、AIエージェントは航空機の制御システムだとイメージするとよいだろう。

RPI/SDD/AI-DLCの実践がもたらすAI-native化

RPI, SDD, そしてAWSのAI-DLC。これらは呼称こそ異なるが、いずれもインタラクティブAIフローを体現する、紛れもないAI-nativeな開発アプローチである。

少々ややこしいのは、RPIをSDDと呼ぶこともでき*8、SDDをAI-DLCの一形態として定義する見方もある*9という点だ。これらを包括的に捉えるならば、すべては AI-DLC（AI-Driven Development Life Cycle, AI駆動開発ライフサイクル） という大きな概念に集約される。

では、なぜ複数のモデル名が存在するのか。

それは、それぞれが解決しようとする “課題の重点” が異なっているからだ。本節では、そこに焦点をあてる。

RPI（Research, Plan, Implement）

RPIが目指すのは、“複雑なコードベースに対する適切な変更を可能にする” ことだ。AIによる技術的負債予備軍の大量生産を防ぐため、人間がリサーチ結果をレビューし、アーキテクチャ上の決定を計画に固定するプロセスである。

このモデルは、オープンソースのAIエージェントであるgooseで用いられていることでも知られており、ドキュメントにはこう記されている。

多くの人は、AIエージェントを「このコードをリファクタリングする」、「この機能を削除する」、「この新機能を追加する」といった形で直接実行に移します。これは、特に小さな変更やコードベースではうまく機能する場合もありますが、複雑な変更ではうまくいかないことがよくあります。

引用: 「Research → Plan → Implement Pattern | goose」ページ内の文章をGoogle翻訳

gooseでは、複雑なコードベースの変更を体系的に処理するために、レシピを用いた構造化されたRPIワークフローを採​​用しています。

引用: 「Research → Plan → Implement Pattern | goose」ページ内の文章をGoogle翻訳

ワークフローは、その名が示す通りだ。

Research（調査） → Plan（実装計画） → Implement（実装実行）

gooseのRPIでは、このPlanによる成果物を「Source of Truth」としている。徹底的なResearchに基づき、Planが精緻に組み上がれば、AIによるImplementの再現性と成功率は飛躍的に高まる。

RPIは、コンテキストウィンドウを適切に活用するための戦略である点にも注目したい。

AIエージェントは、巨大すぎるコードベースや大量のドキュメントといった膨大な情報を前にすると、推論精度が著しく低下する傾向がある。そのため、人間がアドホックなプロンプトで直接的にImplementを命じるのは迷走を招くおそれがある。だからこそ、事前にResearch, Planという段階を経て、情報の絞り込みを行う。

実際、gooseのRPIレシピでは、Research工程においてサブエージェントを活用し、メインのコンテキストウィンドウをノイズで圧迫させない工夫も見られる。

AIにとってのコンテキストウィンドウは、人間の脳で言うところの「ワーキングメモリ」だ。それはすなわち、AIにとっての「認知負荷」を考慮に作業を進める必要性を示している。たとえ巨大なコンテキストウィンドウを持っていても、溢れてしまうこともあれば、迷子（Lost in the Middle）になることもある。

つまりRPIとは、AIエージェントの “認知負荷” を適切に管理する設計プロセスなのだ。情報の海から必要なコンテキストだけをすくい上げ、純度の高い “Plan” に昇華させることで、最終的な “Implement” の成功確率を決定論的なレベルへと近づけるための戦略なのだ。

SDD（Spec-Driven Development）

RPIが「手順の合意」に重点を置くのに対し、SDDは “振る舞いの合意” に重点を置く。仕様書の中に “期待される入出力” や “満たすべき制約” を明文化し、それを人間とAIの間での “検証可能な契約” へと昇華させるのが、その本質的な狙いである。

これにより、AIが実装時に行う恣意的な補完（スペックドリフト）を抑止し、成果物が要件を満たしているかを客観的に評価可能な状態にする。

ワークフローは、各フレームワークの実装に準じるが、概ね次の3ステップで構成される。

Specify（仕様策定） → Plan（実装計画） → Implement（実装実行）

Kiroのモデルに寄せたcc-sddでのスラッシュコマンド*10では、次のようになる。

  • Specify: /spec-init, /spec-requirements
  • Plan: /spec-design, /spec-tasks
  • Implement: /spec-impl

GitHubのSpac Kitではこうだ。

  • Specify: /specify
  • Plan: /plan, /tasks
  • Implement: /implement

RPIでは、Planの成果物を「Source of Truth（SoT）」としていたが、SDDではその位置づけにおいて思想が分かれる。

ひとつは、Specifyによる成果物を永続的なSoTとする思想だ。従来の開発ではコードをSoTとしていた。しかしこの思想では、コードを一種の副産物とみなす*11。従って、エンジニアがコードを直接変更することはなく、仕様を変更し、AIに再生成させることでコードを追随させる。

もうひとつは、Specifyによる成果物を「コードを正しく生成するためのガイド」と位置づける思想だ。ここでのSoTは、従来通りあくまでもコードである。仕様書はAIとの合意形成を加速させ、実装の精度を高めるための中間成果物として機能する。

これらのことから、SDDには3つのレベルがあるとされる*12。

  1. Spec-first: 熟考された仕様を最初に書き、それをガイドとしてAIが開発を行う。あくまでその場のタスクを完結させるための手法。
  2. Spec-anchored: タスク完了後も仕様を保持し続ける。機能の拡張やメンテナンスの際にも常にその仕様を起点とし、継続的に活用する。
  3. Spec-as-source: 仕様をSoTとする究極の形。人間は仕様のみを編集し、コードには一切触れない。コードは仕様から生成される副産物。

先に挙げたcc-sddやSpec Kitは、1のSpec-firstに位置づけられるだろう。2のSpec-anchoredを目指している可能性もある。

いずれにしても、実装根拠となるドキュメントがコードと共にリポジトリに管理されることで、コンテキストの完全なトレーサビリティが確保される点は、極めて大きな恩恵だ。これにより、将来の拡張時においても、AIは過去の意図を正確に踏まえた推論が可能になる。

また、SDDはこれらのワークフローをペアやモブで実施することも意識している。AIが構造化を駆動し、人間がその場で判断を下す。この同期的な協働こそが、従来の「ワーク＆ハンドオフ」型のフローから脱却し、待機時間をゼロに抑え、情報の劣化を最小化する解なのである。

AWSのAI-DLC（AI-Driven Development Life Cycle）:

AWSが定義するAI-DLCは、AIの自律性とスピードを最大限に引き出すためのプロセス・体制を定義し、組織全体をAIネイティブ化するための方法論（メソドロジー）である。

ここで重視されるのは、AIとの共生を前提に再構築された「儀式」そのものだ。特に、AIがファシリテーターとして人間に問いを投げかけ、作業を誘導する「会話の方向の逆転（Reverse the Conversation Direction）」を基本原則とする。

ワークフローは以下の3段階で構成される（日本語訳はAWSドキュメント*13に準拠）。

Inception（開始） → Construction（構築） → Operations（運用）

Inception: ビジネス上の「Intent（意図）」を、開発可能な最小単位である「Unit」へと分解するフェーズ。AIが「モブ・エラボレーション」の進行役となり、ユーザーストーリーや非機能要件、テスト基準を提案。チーム全員がその場で検証・修正を行うことで、認識の齟齬を瞬時に解消する。これはRPIやSDDにおけるResearch/Specifyを、より組織レベルへ昇華させたものといえる。

Construction: Unitをデプロイ可能な成果物へと変換するフェーズ。AIがモデリングからコード生成、ユニットテストまでを連続的に実行する。人間は「モブ・プログラミング」や「モブ・テスティング」を通じて成果物を即座に評価し、品質とビジネス目標への整合性をリアルタイムで担保する。

Operations: システムのデプロイ、監視、および保守を行うフェーズ。AIがテレメトリデータを分析して異常検知やSLA違反の予測を自動化し、解決アクションを提案する。人間は提案の検証と承認に専念することで、運用の圧倒的な効率化を実現する。

“DLC” と名乗るだけあって、Operationsまでカバーしている点が、RPIやSDDとは大きく異なる。

AWSのAI-DLCもまた、SDDと同様に実装根拠のトレーサビリティ確保を意図している。AIが生成したすべてのUnitと決定プロセスが記録されることで、ブラックボックス化を防ぐ設計となっている。

ホワイトペーパーのAppendix Aとして付属されたプロンプトを試すことで、その片鱗に触れることができる。また、AWS LabsのGitHubに、aidlc-workflowsというリポジトリもあるので、こちらを試してみるのもよいだろう。これらはKiroやAmazon Q Developerへの導入が可能だ。

どれを導入するかより、どう使い分けるか

AI-nativeなアプローチ（RPI, SDD, AI-DLC）と、非AI-nativeなアプローチ（AI-assisted / AI-first）は、択一問題ではない。いずれも銀の弾丸ではなく、少なくとも現時点では、解決すべき課題の性質に応じて戦略的に使い分けることこそが肝要だろう。

まず、RPI, SDD, AI-DLCは、先述した次の3つの問題を解消・軽減する対策として位置づけられる。ここから、選択の基準が見えてくる。

  1. コードが複雑になりやすい / 複雑なコード相手ではうまく機能しない → RPI
  2. スペックドリフトが生じやすい → SDD
  3. チーム・組織の生産性が、個人のAI活用スキルに大きく依存する → AI-DLC（SDD）

これを踏まえたうえで検討するなら、それぞれの用途を以下のように基準化できる。

小規模なバグ修正、定型的なリファクタリング

  • アプローチ: 非AI-native
  • 判断基準: 前提知識が限定的で、AIが迷走するリスクが低いとき。ドキュメントを生成・レビューするオーバーヘッドを避け、AIへの直接的な指示で手軽さと速度を優先するシーン。

影響範囲が不明瞭、技術的に複雑性の高い既存コードの変更

  • アプローチ: RPI
  • 判断基準: 巨大なコードベースや古い負債に手を入れる際、いきなりコードを書かせるとAIが破壊的な変更を行うリスクがあるとき。事前の調査と計画によって、AIの認知負荷を制御する必要があるシーン。
  • 補足: 現時点で言えば、非常に複雑なものについては、非AI-nativeなアプローチや人手に頼る手法が効果的な場合もある。

単機能の開発

  • アプローチ: SDD
  • 判断基準: リファインメントによって既に最小単位に分割されたプロダクトバックログアイテムを扱うとき。実装前に「振る舞いの契約」を交わし、スペックドリフトを抑止したいシーン。

抽象度が高く、分割・詳細化前の開発

  • アプローチ: AI-DLC（InceptionからConstructionまで）
  • 判断基準: ビジネス上の意図がまだ抽象的で、それを開発可能な単位（Unit）へ分解する段階からAIを介入させたいとき。AIをファシリテーターとして、チーム全体の合意形成を加速させたいシーン。

おわりに: 成熟を待つより、まずやってみる

AIエージェントによるSDLC/PDLCの変容は未だ過渡期の真っ只中にあり、今後も変化が続くだろう。今日採用した技術や方法論が明日には別のものに置き換わっている、といった事態も珍しくはない。

こうした状況下では、新しいツールや手法への着手を億劫に感じるのも無理はない。導入に要した労力が、技術の陳腐化によって無駄になることを避けたいという心理は、合理的ですらある。

これは、RPIやSDD, AWSのAI-DLCも例外ではない。実際、SDDは、Technology Radarにおいて未だ「Assess」のフェーズにある（2026年1月時点）。

しかし、成熟を待っていては、その間に個人や組織の成長は止まってしまう。たとえ成熟期が訪れたとしても、そこに至るまでの試行錯誤や変遷を知らぬままでは、技術の “本質” を見抜き、使いこなすことは困難だろう。

変化の激しい今だからこそ、あえて荒削りな技術に触れ、その違いや進化の経緯を肌で感じるべきだ。その実戦的な理解の積み重ねこそが、次の新しい波を最大限に活用する力を養い、ひいては個人としても組織としても、競争優位を生む源泉になるのではないだろうか。

参考文献

*1:2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P82-P83

*2:Rich Hickey「Simple Made Easy」InfoQ, 2011年10月20日

*3:Jake Nations（Netflix）「The Infinite Software Crisis」AI Engineer, 2025年12月21日, 「Simple vs. Easy (Rich Hickey’s Definition) 」07:40~

*4:フレデリック・P・ブルックス,Jr. 著, 滝沢 徹, 牧野 祐子, 富澤 昇 訳『人月の神話【新装版】』丸善出版, 2014年, 第16章

*5:Liu Shangqi「Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices」Thoughtworks United States, 2025年12月4日, 「Is spec-driven development just a return to waterfall?」

*6:メアリー・ポッペンディーク, トム・ポッペンディーク 著／平鍋健児 監訳／高嶋優子, 天野勝 訳『リーン開発の本質 ソフトウエア開発に活かす7つの原則』日経BP, 2008年, 第4章

*7:mtx2s「AI導入により生じる“自動化のパラドックス”と“デスキリング”に打ち勝つ」mtx2s on note, 2025年12月1日

*8:Jake Nations（Netflix）「The Infinite Software Crisis」AI Engineer, 2025年12月21日, 「Simple vs. Easy (Rich Hickey’s Definition) 」11:08~

*9:「GitHub - gotalab/cc-sdd: Spec-driven development (SDD) for your team's workflow. Kiro style commands that enforce structured requirements→design→tasks workflow and steering, transforming how you build with AI. Support Claude Code, Codex, Cursor, Github Copilot, Gemini CLI and Windsurf.」

*10:「cc-sdd/docs/guides/ja/command-reference.md at main · gotalab/cc-sdd · GitHub」

*11:Liu Shangqi「Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices」Thoughtworks United States, 2025年12月4日, 「Defining spec-driven development and competing interpretations of it」

*12:Birgitta Böckeler「Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl」martinfowler.com, 2025年10月15日

*13:Masao Kanamori 訳「AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築」Amazon Web Services ブログ, 2025年8月8日

ソフトウェアエンジニアの本質は“課題解決”なのか？

「エンジニアの本質は課題解決である」というよく聞く台詞に対し、ずっと、軽い違和感があった。いや、決して強い反論があるわけではない。しかし、なぜかこの言葉が響いてこない。

この感覚がはっきりと表出したのは、実は最近だ。以前から感じてはいたものの、強く意識することはなかった。突き詰める対象になるほど、問題として捉えてこなかったのだろう。

だが、ソフトウェアエンジニアリングの現場にAIエージェントが入り込んだ今こそ、この違和感を言語化すべきだと思い至った。エンジニアが多くの時間を割いてきたコーディングは、AIが代替しつつある。その精度は高まり、担える領域も、確実に広がっている。

だからこそ、エンジニアという職種の本質を、あらためて問い直す必要があるのではないか。「エンジニアの本質は課題解決である」という言葉は、そのためのよい切り口になる。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

「エンジニアの本質は課題解決である」という言葉には限定性と多義性がある

違和感をもう少し掘り下げてみると、この言葉が持つ「限定性」と「多義性」という性質に気づく。つまり、範囲を絞り込み、同時に意味を広げてしまう──その二つの性質が、同時に含まれている。

この言葉は、次のような構造を持っている。

  1. 「エンジニアの」という限定性
  2. 「課題解決」という言葉の多義性
  3. 「課題解決である」という限定性

「エンジニアの」と限定する不自然さ

そもそも「課題解決」という営みは、エンジニア職に固有のものだろうか。

ビジネスに関わる多くの職種にとって、程度の差はあっても、その本質は課題解決にあるはずだ。企業のミッションは、抽象度をあげれば課題解決に行き着く。そこに参加する限り、いずれの職種の本質も、課題解決と言える。

したがって、特定の職種を指して、その本質が「課題解決にある」と語ることに不自然さがある。

おそらくこの限定性の背景には、「手段が目的化しやすい」という、エンジニアという専門職特有の事情があるのではないか。

専門職には、その専門技術を追求する面白さがある。そこに没頭するがあまり、何のために技術を行使しているのかを忘れやすい。これは、デザイナーがデザイン性にばかり気を取られ、機能性を見失ってしまう構造とよく似ている。

それを戒（いまし）める言葉として、「エンジニアの本質は課題解決だ」という表現が使われるのだ。つまり、「コードを書くこと」そのものを、エンジニアの仕事だと捉えすぎることへの “批判” も少なからず含まれているのだろう。

「課題解決」という言葉への解像度の低さ

「課題解決」という言葉は、響きがビジネス的で格好良いが、便利に使われすぎる側面もある。何を指しているのか、分かったようで分からない。

「エンジニアの本質は課題解決」と言ったとき、どこからどこまでを指しているのだろうか。一般に「課題解決」と呼ばれる営みは、少なくとも次のようなプロセスを含んでいる。

  1. 現状把握: 今、何が起きているか
  2. あるべき姿の設定: 本来どうなっているのが理想か
  3. 問題の特定: 現状と理想のギャップは何か
  4. 原因分析: なぜそのギャップが生じているのか
  5. 課題の設定: ギャップを埋めるために、具体的に何を解決すべきか
  6. 解決策（ソリューション）の実行: 具体的な手段を講じる

では、この一連のプロセス全体が「エンジニアの本質」なのか。それとも、最後の6だけを指して「課題解決」と呼んでいるのだろうか。ここが誤解を受けやすい。

本来ここで言われているのは、よく知られた「三人の石切り工」の話に近いのだろう。たとえ6だけを担っていたとしても、1から6全体を通して課題を解決している、という認識を持てということだ。

しかし、「課題解決」という言葉は、文脈によっては受託開発の構造を想起させやすい。そこではウォーターフォール型の工程分離が前提となり、1から5はいわゆる「上流」、6の実行は「下流」として、異なる役割が割り当てられることが多い。

その結果、「課題解決」という言葉が、エンジニアが主に担う6の役割を指す責務の話として受け取られてしまう場合がある。

さらに、このような「あるべき姿と現状のギャップ」を対象とする課題解決だけが、エンジニアリングの営みではない。

新しい価値を生み出すことや、既にある価値を維持し、将来へ継承していくことは、必ずしも明確な「問題」から始まるわけではない。それでも、エンジニアリングの重要な役割であることに変わりはない。

こうした営みもまた、抽象度を上げれば「課題解決」という枠組みの中に含めて捉えることができる。そして、その広がりこそが、この言葉を分かりにくくしている理由でもあるのではないだろうか。

「課題解決である」との断定によって否定される多義性

「である」という限定的な言い回しは、「課題解決」が持つ多義性を包み込む余地を、かえって狭めてはいないだろうか。

その結果、課題解決が狭義の意味に閉じてしまうような印象を与えかねない。聞き手の意識が、価値創造や維持・継承へと向かう余地を、あらかじめ狭めてしまっているようにも感じられる。

いや、むしろ話し手自身も、狭義の課題解決という枠組みの中でしか、物事を捉えられていないのではないか。それは、ソフトウェアエンジニアという職能の可能性を、静かに狭めてしまう行為にもなり得る。

私はそこに、危うさを感じるのだ。

エンジニアリングの提供価値とは何か？

エンジニアの本質とは、つまりエンジニアリングの生み出す価値そのものと言える。そこには、少なくとも次の三つの観点がある。

  • 複雑性を秩序に変換する
  • 再現性と効率性を創出する
  • 持続可能性を維持する

複雑性を秩序に変換する

ソフトウェア開発とは、そもそも不確実なものを扱う営みである。

エンジニアリングの本質は、「不確実性の削減」と述べられることもある*1。「不確実性コーン」が示すように、ソフトウェア開発は、不確実な状態から確実な状態へと変えていく活動だ。

言い換えれば、絶え間ない探索と論理を手がかりとして、複雑性に秩序をもたらす営みである。

再現性と効率性を創出する

ソフトウェアは、同じことを、同じように、何度でもできる。再配布可能な知識やスキルのパッケージでもある。

ビジネス向けの業務アプリケーションや、コンシューマー向けの便利ツールは、その典型例だ。ソフトウェアゲームもまた、同じ構造を持っている。

さらに、ソフトウェアで処理される知識やスキル、手続きは、人間が処理するよりも速く、そして安定している。その結果として、人間の能力は拡張される。

持続可能性を維持する

ソフトウェアは、完成した瞬間から “変わり続けること” を宿命付けられた成果物だ。変更が容易でなければ、もはや “ソフト” とは言えず、その価値が失われていく。

ソフトウェアの稼働期間が長いほど、その “振る舞い” に変更が入る。そこに耐えうる “構造” を維持し進化させ続けること。それが、単なるプログラミングとエンジニアリングを分ける*2*3。

こうした持続可能性の維持は、設計や実装の巧拙（こうせつ）だけで決まるものではない。むしろ、変更を前提にした意思決定や、構造への投資の積み重ねによって形作られる。

エンジニアの本質とは？

ここまでの議論を踏まえ、定義の言語化をGeminiやChatGPTと繰り返した。そのうえで導き出されたエンジニアの本質は、次のとおりだ。

──論理の力で、混沌とした現実に再現性のある秩序を与えることで、価値を持続的に創出し、人間の可能性を拡張し続けること──

一言で言い切れる定義にはならなかった。だが、これまで見てきたエンジニアリングの価値を、無理なく包含している。あえて短縮するなら、「再現性ある価値の継続的な創出」といったところか。

企業で働くエンジニアの価値は、自社のミッションのもと、目の前のユーザーや顧客、ビジネス、あるいは社会に向き合い、この役割定義を実行することで具現化される。

さいごに: AI時代でもエンジニアの本質は変わらない

AIがコーディングを代替するようになっても、エンジニアのアイデンティティが崩壊するわけではない。なぜなら、その本質は変わっていないからだ。今後、AIが担う領域がさらに広がっても同じだろう。

コードを書く機会が減ることに喪失感をおぼえる人もいる。だが、コーディングエージェントとの協働は、新しい知的な楽しさももたらしている。ケント・ベックが「50年に及ぶプログラミング経験の中で、今が一番楽しい」と述べているのも、その一例だ*4。

手段が目的化しやすいのは、専門職種の宿命でもある。だがそれは、対象に深く没頭している証であり、知的好奇心の表れでもある。その追求は、個人の満足にとどまらず、組織に新たな可能性や能力の飛躍をもたらすこともある。

つまり、夢中になることは、エンジニアリングの原動力でもある。AIとの協働で形は変わっても、技術への探究心は持ち続けるべきだ。

その探究の先で、混沌とした現実に秩序を与え、再現性ある価値として社会に残していく。そこにこそ、AI時代においても変わらないエンジニアの本質がある。

なお、年末にこのテーマに向き合ったのは、先日登壇したパネルディスカッションで、「エンジニアの本質は課題解決である」という言葉への違和感を表明してしまったことがきっかけだった。それをあらためて整理し、言葉にしてみようとしたのが、本記事の試みである。

findy.connpass.com

余談ではあるが、AI時代においても本質が変わらないという点では、ソフトウェア開発組織の設計原理についても同様だ。AIによって開発が加速するほど、組織構造に由来する摩擦は無視できなくなる。チームや組織として、持続的に価値を生み出すための考え方については、拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』で詳しく扱っている。

gihyo.jp

参考文献

*1:広木大地 著『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』技術評論社, 2018年, 1-2

*2:Robert C. Martin 著／角 征典, 高木 正弘 翻訳『Clean Architecture 達人に学ぶソフトウェアの構造と設計』KADOKAWA, 2018年, 第2章

*3:Titus Winters, Tom Manshreck, Hyrum Wright 編／竹辺 靖昭 監訳／久富木 隆一 訳『Googleのソフトウェアエンジニアリング─持続可能なプログラミングを支える技術、文化、プロセス』オライリー・ジャパン, 2021年, 1章

*4:「TDD, AI agents and coding with Kent Beck」The Pragmatic Engineer, 2025年6月, 03:05-03:10参照

AIで加速する個人、伸びないデリバリー──2025 DORAレポートが示すフローと摩擦の真実

AIツールを導入した結果、コーディングなど個人の作業スピードは上がった。けれど、チームや組織レベルのパフォーマンスはほとんど変わらない。むしろ、問題や混乱を招いている──そんな経験はないだろうか。

このギャップこそ、AI導入を進めた多くの組織が直面しているミステリーだ。

AI導入に関する2025年版のDORAレポートは、その原因が個人のスキルではなく、組織全体を動かす「システム」にあると指摘している。AIの真価を引き出せるかどうかは、ツールの性能や個人のスキル以上に、それらを組み込む組織構造やプロセスに左右される。

本稿では、ソフトウェアデリバリーにおけるAIの力を最大限に引き出すための二つの鍵、「フロー」と「摩擦」に焦点を当てる。組織の流れをどう整え、どのように摩擦を取り除くべきか。その核心を探っていこう。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

主な参考文献

今回取り上げる文献は、2025年9月24日に公開された「2025 DORA State of AI-assisted Software Development Report」である。Google CloudのDORA（ドーラ）チームが、AI支援がソフトウェアデリバリーにもたらす影響を体系的に調査した最新レポートだ。

cloud.google.com

特徴的なのは、調査の焦点が「AIを導入すべきか」ではなく、「導入後に組織がどう変化したのか」に置かれている点である。約5,000名の開発実務者の回答と100時間超の定性調査から、生産性や品質、チームパフォーマンスへの影響が多面的に整理されている。

本稿では、このレポートが示す実態を入り口に、AI導入後の組織で生じている問題の構造を明らかにしていく。その第一歩となるのが、冒頭で触れた “ミステリー”──すなわち昨年の「2024 DORAアノマリー」である。

前回2024年度の調査で発覚した「DORAアノマリー」という現象

まず押さえておきたいのは、昨年の調査で発生した “異変” である。

DORAによる2024年の調査では、AIを積極的に導入した組織ほど、ソフトウェアデリバリーの「スループット（throughput）」が落ち、「不安定性（instability）」が増した*1。

AIを入れたのにパフォーマンスが悪化する──これが「2024 DORAアノマリー（異常事態）」と呼ばれる現象だ*2。本来の目的である生産性向上とは逆の結果を招いた。

なぜそんなことが起きたのか。そして、2025年度の結果はどう変化したのか──。

2025年度の調査の核心は、AIによる “増幅” とシステムによる “相乗効果”

2025年度のレポートが強調する核心は、次の2点である。

  • AIは、鏡であり力を増幅する存在（amplifier）である*3
  • システムは、その力の相乗効果を生み出す存在（force multiplier）である*4

ここで言う「システム」とは、ソフトウェアデリバリーを支える組織構造・プロセス・技術・文化といった環境全体を指す。いわゆるソフトウェアシステムのことではない。

AIは、システムの “良い部分” だけでなく “悪い部分” までも映し出し、増幅する。システムに非効率やボトルネックがあれば、その弱点もAIのスピードによって一気に表面化する。

こうした状況の中で、2024年時点では、多くの組織がAI導入を始めたばかりであり、システム側の準備が追いついていなかった。

そう、2024年のアノマリーは、この構造によって起きていたのである。

実際、2025年度の調査では、システム側をAIのスピードに適応させた組織ほどスループットが回復している*5。

この結果は、W・エドワーズ・デミングによる1993年の言葉を思い起こさせる。

悪いシステムは、良い人をいつも打ち負かす。

引用: John Hunter「A Bad System Will Beat a Good Person Every Time」The W. Edwards Deming Institute, 2015年, 記事内の文を筆者が翻訳

30年以上経ったAI時代でもなお、この原則は変わらない。AIの効果を引き出せるかどうかは、ツールや個人の能力だけでなく、それを支えるシステムの成熟度に大きく依存する。

次節では、システムの成熟度を高めるために何が必要なのか、レポートの示唆を見ていく。

AI導入による個人への効果を組織の成果に “変換” するためのシステム強化

AI導入の効果がもっとも顕著に現れるのは、「個人の生産性（individual effectiveness）」である*6。これは多くの開発者が実感しているだろう。

しかし、それで満足していては、組織パフォーマンスは向上しない。

個人レベルで増幅された効果を、チームや組織の成果へと変換するためには、システム側で相乗効果を生み出す必要がある。どれだけシステムを強化できるかが、その成否を決める。

DORAが有効性を確認した取り組みは次の2つである。

  • バリューストリームマネジメント（VSM）*7
  • プラットフォームエンジニアリング*8

「VSM」は、ソフトウェアがアイデアから顧客に届くまでのフローを可視化し、滞留たいりゅう箇所を特定・改善するための手法である。どこか一工程でもスループットが下がれば、そこがボトルネックとなり全体の性能を押し下げる。それを解消しなければ、AIがもたらした個人レベルの生産性向上も組織全体へ波及しない。

一方「プラットフォーム」は、DevOpsの観点（DORAの “D” は DevOps の “D” である）では、社内開発者向けのCI/CDやセルフサービス型インフラなどを指す*9。これらが整備されていれば、フローは速く、かつ安定する。結果として、VSMの成果にも寄与する。

いずれにせよ、焦点となるのは「フロー」である。

AI時代こそ “フロー” に注意を傾ける

VSMの実践とは、端的に言えばフローに目を向けることだ。これまでのソフトウェア開発では、人員配置や工数といった “リソース” に比べ、システム全体の “フロー” は意識されにくかった。

バリューストリームは、複数のプロセスが連なるパイプラインのように捉えると理解しやすい。その中をいくつものジョブが流れていく。このジョブの単位がフロー（フローユニット）だ。

VSMとは、この流れの中でボトルネックを特定し、取り除く実践である。これはソフトウェアシステムのパフォーマンスチューニングに近い。

バリューストリームやフローは、組織づくりを考えるうえで欠かせないテーマであり、拙著『チームの力で組織を動かす』でも基礎概念として整理している。そこで用いている説明の一部を、下記に引用する。

　たとえば、バリューストリーム内に、A, B, Cという3つのプロセスがあったとしましょう。これらのスループット上限がそれぞれ5, 3, 4である時、バリューストリーム全体のスループットは3です。Bのスループット上限である3がボトルネックになっているからです。

　ここで、Cのスループット上限を5に高めたとしても、やはりバリューストリーム全体のスループットは3のままです。Cのスループットがいくら高くても、BからCへのフローユニットの引き渡しは、Bのスループット上限である3でしか行われないからです。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年, 2-2-3

AI導入によって一部工程（プロセスやステージ）のスループットがいくら増幅されても、下流工程がそれを受け止められなければ、全体のスループットは変わらない。

次に、開発者にとってもっと身近な具体例を考えてみたい。

よくある例: AI導入でコーディングが速くなった代償としてコードレビューで詰まる

AIの導入によってコーディング速度が上がり、プルリクエスト数が一気に増えた──そんな経験を持つ組織は少なくないだろう。

典型的な開発プロセスを示すカンバンボードは、次の4ステージで構成される*10。

  1. To Do
  2. 進行中（設計や実装）
  3. コードレビュー
  4. 完了

「進行中」のスループットだけが上がると、「コードレビュー」に多くのチケットが滞留たいりゅうする。レビューさえ通れば、あとは自動化されたCIが流れを進めてくれるため、ボトルネックは明らかにレビュー工程にある。

つまり、この状態でのAI導入は「設計・実装」工程における “個人の生産性” を高めただけで、システム全体の流れは変わっていない。

レビュー工程に長い待ち行列ができる光景は、AI以前から珍しくない。それを放置したままAI導入を進めれば、その待ち行列は拡大するだけだ。これこそ、AIが鏡となってシステムの “悪い部分” を増幅した典型例である。

ここで多くの組織は、ボトルネックの解消に向けて対策を検討しはじめる。たとえば次のような手段だ。

  • 「WIP制限」を導入する
  • ペアプロの導入によって、レビュー自体を不要にする
  • コードレビューにもAIを活用し、負荷を軽減する
  • 一部のプルリクエストをAIレビューのみで通過させる

これらの施策でレビュー工程の詰まりが解消されれば、ボトルネックは別の場所に変わる。それをまた解消する。パフォーマンスチューニング同様、VSMもこの繰り返しである。

しかし、なぜレビュー工程は詰まるのか。たとえば開発者が期限に追われ、自分の作業を優先し、レビューを後回しにしているのかもしれない。

こうした構造的な原因を取り除かない限り、システムは本質的に強化されない。表面の問題は解消されても、流れの奥底に潜む “詰まりやすさ” は残ったままだ。

その構造的な問題こそが、次に述べる「摩擦」である。

フローを詰まらせる見えない “摩擦” の正体

フローを阻害する本質的な要因として、DORAレポートは「摩擦（friction）*11」を挙げている*12。摩擦とは、個人の作業を妨げたり、遅らせたりする要因の総称だ。これが少ないほどフローは滑らかになり、組織全体のスピードが上がる。

しかしレポートは、AI導入が「個人の生産性」や「コード品質（code quality）」を高める一方で、「摩擦」や「燃え尽き症候群（burnout）」にはほとんど影響を与えない、という興味深い結果を示した。これは “stubborn results（動かない結果）” と表現されている*13。

なぜこれらはAIでは解消されないのか。その中でもフローを直接阻害する「摩擦」による “見えにくい抵抗” に焦点を当てて考えていく。

気づかぬうちに効率を失ってしまう、現実のフローの複雑さ

現実のフローは想像以上に複雑で、さまざまな経路が絡み合う中で効率を失いやすい。その経路は、バリューストリームやカンバンボードでは捉えきれない領域や粒度にまで広がる。結果として、個々の集中力を奪い、チーム全体の流れを鈍らせてしまう。

たとえば──

  • 集中してコーディングしたいのに、頻繁にミーティングや割り込みタスクで中断される
  • ちょっとした変更でも、複数チームでの確認や誰かの承認が必要になる
  • 必要な情報がすぐに見つからない
  • ツールが使いにくい

これらはすべて、フローを阻害する摩擦である。DORAレポートが紹介する2019年のマイクロソフトの調査でも、開発者の一日を妨げる要因として同様の問題が指摘されている*14*15。

こうした摩擦による停滞は、少なからず、組織設計に起因する。組織構造に歪ひずみがあるとバリューストリームは複雑になり、フローはすぐに効率性を失う。さらにコミュニケーションの経路も入り組み、コストが増大する。

その帰結として、コンウェイの法則*16が示す通り、システム構造──すなわち内部品質──にまで悪影響が及ぶ。

とはいえ、こうした組織設計上の問題は、AI導入だけでは解決しにくい。そもそも問題の存在に気づくことすら難しい。では、どう取り組めばよいのか。

フローを詰まらせる組織設計アンチパターン

どのような設計が、組織にどのような影響を与えるのか。それがわかれば、組織設計者は現状に合わない設計を避け、より適した構造を選びやすくなる。

そこで役立つのが、組織設計に関する「アンチパターン」である。『チームの力で組織を動かす』では、16のアンチパターンを収録しており、そのうち8つはフロー（およびコミュニケーション）の効率を悪化させるパターンだ。

その簡易版としてまとめたのが、資料「内部品質・フロー効率・コミュニケーションコストを悪化させ、現場を苦しめかねない16の組織設計アンチパターン［超簡易版］」である。

P15からP24までが、その8つのアンチパターン集となっており、下に貼り付けたスライドが、その1つめのパターン「スパゲッティ組織」だ（P17）。

mtx2s「内部品質・フロー効率・コミュニケーションコストを悪化させ現場を苦しめかねない16の組織設計アンチパターン［超簡易版］」SpeakerDeck, 2025年, P15-P24

AIによる音声解説はこちら。

open.spotify.com

こうしたアンチパターンによってプロセスが非効率化している組織は、DORAレポートの7類型のひとつである「クラスター3: プロセスに制約される（constrained by process）*17」に当てはまりやすい。

クラスター3のチームは、技術的には安定したシステム基盤を持ちながらも、煩雑はんざつなプロセスがメンバーの努力を消耗させている。その結果として、「摩擦」や「燃え尽き症候群」が生じやすくなり、ワークフローは過度に負荷の高いものとなる。いくら基盤が整っていても、その状態では顧客価値やビジネス価値を十分に高めることは難しい。

言い換えれば、組織設計上の問題が解決されない限り、技術的な安定性だけではフローは守れない、ということだ。組織構造自体が、自体が過酷で持続不可能な環境を生み出している。

DORAレポートも次のように指摘している。

Treat your AI adoption as an organizational transformation.

（AI導入を組織変革として捉えよ）

引用: 「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P17（日本語訳は筆者によるもの）

AIの導入は、組織構造そのものを見直す契機と捉えるべきである。その際の設計思想として重要になるのが、次に述べる「ストリームアラインド」というアプローチだ。

“ストリームアラインド” での継続的なフロー改善

レポートでも述べられているように、VSMによるフロー改善は “単発” で終わる取り組みではない*18。

したがって、改善の主体となる組織体制も “継続的” であることが望ましい。プロジェクトごとに都度チームを組み替えるような体制では、バリューストリームが安定せず、改善した効果も蓄積されにくい。

継続的な体制を構築するうえでは、チームを「ストリームアラインド（Stream-aligned）」として編成するアプローチが有効だ。『チームの力で組織を動かす』でも、この考え方を指針として整理している。

プロジェクトに対してチームを編成するのではなく、バリューストリームに対してチームを編成します。チームをストリームに専属配備するということです。それは、開発チームであっても企画チームであっても、スクラムチームのような機能横断型のチームであっても同様です。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年, 6-1

バリューストリームに専属するチームは、メンバー構成も責務も安定し、継続的な改善に取り組むことができる。日々の業務を通して実験し、学び、適応を積み重ねることで、摩擦が削減され、フローの効率性は確実に向上する。

このようなチームを「ストリームアラインドチーム*19」と名付けた『チームトポロジー』はDevOpsを基盤としており、同じくDevOpsの体系に立脚したDORAレポートとも高い親和性がある。AI導入を組織変革として進めるのであれば、ストリームアラインド型の体制はその基盤になりうる。

摩擦を軽減する “AIケイパビリティ”

摩擦の軽減に向けては、組織設計の改善だけでなく、日々の働き方そのものを変えるアプローチも有効である。

DORAレポートでは、AI導入と組み合わせた際に摩擦の減少が確認された二つのケイパビリティが紹介されている。

  1. 明確に伝達されたAIスタンス（Clear and communicated AI stance）
  2. 小さなバッチでの作業（Working in small batches）

明確に伝達されたAIスタンス

組織がAI利用に関する明確な方針を持ち、それが現場まで徹底的に共有されている状態を指す*20。

方針が不明瞭であれば、開発者は「使ってよいのか」「どこまで任せてよいのか」といった不安を抱えやすい。こうした迷い自体が摩擦となり、AI活用の速度を落とす。

明確なスタンスは、開発者を余計な不安から解放し、“創ること” に集中できる環境を生む。その結果、「摩擦」の減少だけでなく、「個人の生産性」「スループット」「組織パフォーマンス」の向上にも寄与する。

小さなバッチサイズでの作業

短時間で完了可能な作業単位に分割し、コード変更行数を抑え、1回のデプロイに含まれる変更数を小さく保つプラクティスである*21。AI以前からDevOpsやリーンソフトウェア開発で推奨されるプラクティスでもある。

しかし、AI導入が進むと逆にバッチが肥大化しやすい。するとどうなるだろうか。

たとえばプルリクエストのサイズが大きくなれば、レビューが重くなり品質担保も難しくなる。これは典型的な摩擦の発生である。

一方で、小さなバッチは「個人の生産性」を下げる側面もある。AIは大量の変更を一気に進める場面で特に強力だが、このケイパビリティはその伸び代を意図的に抑えるからだ。

とはいえ、「個人の生産性」は手段であり目的ではない。それよりも、このケイパビリティの効果である「摩擦」の軽減と「プロダクトパフォーマンス（product performance）」の向上を増幅させたい。部分最適より全体最適だ。

最後に

ここまで見てきたように、AIの効果を最大化するために重要なのは、個人の高速化ではなく、システム全体の「フローを整え、摩擦を減らすこと」である。

AI導入によって個々のアウトプットが増えても、組織のシステムがそのスピードに対応していなければ、本来の効果は相殺されてしまう。これは、デミングが述べた原則の現代的な再確認でもある。

では、私たちはどこを測り、どう改善すべきか。

個人レベルの「活動量」だけに着目するのではなく、システムレベルの「パフォーマンス」や「効率とフロー」の観点でモニタリングし、改善を続ける必要がある*22。

DORAのクラスター分析が示す通り、スループットが高いチームは、不安定性が低いチームでもある*23。高速でありながら安定している──そこが目指すべき姿だ。

そのための重要なAIケイパビリティが「ユーザー中心主義（User-centric focus）」である*24。ユーザー価値に結びつかないアウトプットを高速に生成しても意味はない。フロー改善と価値創出は常にセットで取り組む必要がある。

本稿では、DORAレポートを軸にフローと摩擦の視点から解説した。バリューストリームやフローの改善に関心があれば、拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』も手にとってみて欲しい。組織構造とフローの関係について、体系的に整理している。

gihyo.jp

*1:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P35

*2:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P9

*3:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P87

*4:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P70およびP74

*5:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P42

*6:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P38 Figure 28

*7:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P73

*8:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P65

*9:「プラットフォーム エンジニアリングとは」Google Cloud

*10:Dan Radigan「カンバン」Atlassian,, ボトルネックの減少

*11:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P37

*12:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P77の "You’re no longer just optimizing a small step; you’re removing friction from the system’s biggest constraint." など（constraintとは、TOCでは「ボトルネック」を指す）

*13:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P39

*14:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P40

*15:Meyer, André N., Earl T. Barr, Christian Bird, and Thomas Zimmermann「Today was a good day: The daily life of software developers」IEEE Transactions on Software Engineering, 2019, 47, no. 5. (2019): 863–-880

*16:Melvin E. Conway「How Do Committees Invent?」Mel Conway’s Home Page, 1968年

*17:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P17

*18:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P76

*19:マシュー・スケルトン, マニュエル・パイス 著／原田 騎郎, 永瀬 美穂, 吉羽 龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセンター, 2021年, CHAPTER5

*20:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P51-P53

*21:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P58

*22:Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler「The SPACE of Developer Productivity: There's more to it than you think.」『ACM Queue』2021年

*23:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P19 Figure 10

*24:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P95

エンジニアのキャリアパスと組織戦略をつなぐ地図を描く — 『ITエンジニアの転職学』を読んで

ITエンジニアのキャリアをどう考えればよいのか。それは、エンジニア本人のみならず、彼らのキャリアを共に考えるエンジニアリングマネージャーにとっても難しい問いである。

人は、難しい問題にぶち当たったとき、その緊急度が低ければ後回しにしがちだ。だから、いざ答えを求められたときに、場当たり的な言動・行動をとってしまうことがある。マネージャーとしてこれは避けたい状況だ。

メンバーのキャリアを真剣に考えるとき、マネージャーの視野は自然と組織全体へ広がる。個人の成長支援だけでなく、組織戦略やチーム設計との整合が欠かせない。

つまり、キャリアの問題は組織の問題でもあるのだ。

書籍『ITエンジニアの転職学』は、エンジニア個人の転職にとどまらず、そうしたマネージャーの思考を整理する手がかりを与えてくれる。

本記事では、エンジニアリングマネジメントの視点から、エンジニアのキャリアと組織戦略の関係性を軸に本書を読み解く。したがって、タイトルにある「転職」というテーマからは少し離れ、組織論的な読み方になる。その点はあらかじめご了承いただきたい。

参考書籍の紹介

2025年10月24日に講談社から出版された『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』を、著者の赤川朗氏からご恵贈いただいた。

www.kspub.co.jp

本書は、2万人のITエンジニアのデータを分析し、転職を成功に導く知見を体系化し、指南している。その内容も網羅的だ。転職市場における読者自身の立ち位置の分析方法から、職務経歴書の作成、選考プロセスの対策、さらには転職後のマインドにまで至る。

何より素晴らしいのは、その視点が「転職」という単一イベントにとどまらず、それをITエンジニアのキャリア設計の一部として組み込んでいる点にある。転職を考えている人だけでなく、考えていない人も、自身のキャリア設計の参考書として何度も読み返して欲しい一冊だ。

エンジニアリングマネジメントの視点からメンバーのキャリア設計を見る

マネージャーがメンバーのキャリアを考えるとき、注視すべきは “個人” と “組織” の2つの側面である。どれほど優秀な個人であっても、その成長方向が組織戦略と交わらなければ十分に力を発揮できない。結果として組織も力を失う。これは、どちらにとっても不幸だ。

マネージャーにとってのキャリア支援とは、個人と組織の接点を見つける営みなのだ。そのため、マネージャーは次の三つの課題を同時に見据える必要がある。

  1. 個人の成長支援
  2. 組織戦略
  3. 組織設計の最適化

これら三つは独立して存在するのではなく、連動している。組織戦略が目指す方向を定め、組織設計がその実行体制を形にする。そして、個人の成長支援がそれを可能にする力を育てる。現場での成長の結果は、設計や戦略の見直しにもつながる。

こうした複雑な関係性を整理するうえで、『ITエンジニアの転職学』の枠組みは有効だ。同書で定義されているエンジニアの「役割」と「能力」は、キャリアを個人視点だけでなく、組織の構成要素として捉えるための共通言語になる。まずは、この二つの概念を簡潔に紹介する。

エンジニアの役割を8つの分類と2つの軸で捉える

『ITエンジニアの転職学』では、エンジニアの役割を次の8つに整理している。詳細はぜひ書籍を手に取ってほしい。

  • はじまりの開発者
  • テックリード
  • 横串組織（SRE, セキュリティ、CTO室など）
  • スクラムマスター/プロジェクトマネージャー
  • エンジニアリングマネージャー
  • プロダクトマネージャー
  • 専門家（エキスパート）
  • 他職種との融合（技術広報、CRE, FDE, ITコンサルなど）

本書では「役割」という言葉を「キャリアパス」の段階として扱っている。つまり、「はじまりの開発者」から始まり、そこから他の7つの役割へとキャリアを歩んでいくという考え方だ。

さらに秀逸なのは、これらの役割を2つの軸で整理している点である。この図により、エンジニアとしてどの方向で成果を発揮していくのかを俯瞰できる。

  • 縦軸:
    • 上方向: ユーザー・事業・組織課題を解く力
    • 下方向: 技術課題を解く力
  • 横軸:
    • 左方向: 個の力
    • 右方向: 組織の力

出展: 赤川 朗 著『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』講談社, 2025年, 図2-1を参考に筆者が作成

軸のラベルは「力」と表現されているが、これは、その力を用いて発揮する「成果」の方向性だととらえるとよい。たとえば、「はじまりの開発者」は中央に位置し、「EM」は右上、「専門家」は左下にプロットされる。このマップを使えば、自分の立ち位置や次に伸ばすべき力を具体的に考えられる。

余談であるが、「はじまりの開発者」というネーミングがロールプレイングゲームの職業名っぽくて気に入った。エンジニアとしての冒険が、今まさにはじまるようだ。

エンジニアの能力を6つのカテゴリと5つのレベルで捉える

エンジニアの能力については、6つのカテゴリと5つのレベルで整理されている。この枠組みによって、個々のスキルを俯瞰的に捉えることができる。

  • カテゴリ:

    • 設計力・実装力
    • 専門性の深さと広さ
    • 推進力・プロジェクト貢献
    • 組織貢献
    • 事業・顧客貢献
    • 情報発信・プレゼンス

  • レベル:

    1. 要支援
    2. 自立
    3. 主力
    4. リーダー
    5. 社内第一人者・業界リード

本書では、これらをもとに各役割をレーダーチャートで可視化している。しかも、役割ごとに年収データと連動したチャートが描かれており、極めて実践的だ。この枠組みを活用すれば、自社内の評価に閉じず、客観的な役割・能力定義に基づいてキャリア設計や組織設計を進めることができる（できれば、毎年このチャートを更新して公開して欲しいところだ）。

出展: 赤川 朗 著『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』講談社, 2025年, 図2-2から図2-8までを参考に筆者が作成

個人の成長を支援する

役割定義と能力定義は、マネージャーがメンバー本人とキャリア支援を対話で合意し、行動に落とし込むための共通言語になる。

たとえば、次の順で対話を進める。

  1. 役割: どんな役割を担いたい/担ってほしいか
  2. 方向: その役割は2軸上でどこに位置し、どんな力と成果が求められるのか
  3. 適合性: 役割に対して各能力カテゴリのレベルがどれだけ充足/不足しているか
  4. 計画化: どの能力カテゴリを、どのように伸ばしていくか

注意したいのは、すべての能力を一様に上げようとしないことだ。現実的には、強化すべき能力を絞り、そのための機会設計（任せる仕事やレビュー観点、伴走の仕方など）まで具体化することが重要である。

また、キャリアの方向は後述する組織戦略と接続して考える必要がある。もちろん、本人の意向を無視してはならない。両者が交わる領域を見いだし、そこに成長機会を設計することが肝要だ。

「スタッフプラス」と「エンジニアリングマネジメント」という2つの方向性

エンジニアのキャリアパスを、大きく「スタッフプラス」と「エンジニアリングマネジメント」という2つの方向性に分けて捉えると、キャリア設計に関する対話が格段に整理しやすくなる。

書籍『スタッフエンジニア　マネジメントを超えるリーダーシップ』では、キャリアラダーを「シニア」を起点にこの2つへと分岐させている。

出展: Will Larson 著, 増井 雄一郎 解説, 長谷川 圭 翻訳『スタッフエンジニア　マネジメントを超えるリーダーシップ』日経BP, 2023年, 第1章の図「エンジニアリングのキャリアラダーにおける２本の路線」を参考に筆者が作成

この考え方は、『ITエンジニアの転職学』で示された二軸のキャリアマップにも対応づけられる。左上から右下に一本の対角線を引くと、左下がスタッフプラス、右上がエンジニアリングマネジメントの領域となる。中央付近の領域は、キャリアラダー上の「シニア」以下のポジションにあたる。

（注釈：素直に縦軸で両者を分けるべきか悩んだが、『ITエンジニアの転職学』図2-1との適合性を考える中で対角線で分けることを選んだ）

スタッフプラスの4つのアーキタイプ──「テックリード」「アーキテクト」「ソルバー（解決者）」「右腕（ライトハンド）」──は、この左下の領域に位置づけられる。実際、『ITエンジニアの転職学』でも、テックリードが下段中央に描かれており、整合が取れる。

この整理により、マネジメント方向に進むか、IC（Individual Contributor, 個人貢献者）として専門性を深めるかというキャリアの方向性を、マネージャーとメンバーの双方で明確に話し合いやすくなるだろう。

個人のキャリア戦略と組織戦略を接続する

エンジニアリングマネージャーが向き合うべきは、個人のキャリアと組織戦略の接続点である。メンバーの成長を支援することは、同時に組織の進化を設計することでもある。

組織戦略とは、目指す組織（ToBe）と現在の組織（AsIs）とのギャップを、どの軸で埋めていくかを定める方針だ。ToBe像は決して固定された形ではなく、環境変化やビジネス戦略に合わせて絶えず変化する。

そして、その方針を具体の構造に落とし込むのが組織設計である。どのようにチームを分け、どんな人材をどこに配置するかがここで決まる。

では、それをどう構造的に捉えればよいか。ここでもまた、『ITエンジニアの転職学』のキャリアマップは有効なフレームワークとなる。

たとえば、2軸マップ上に、ToBeとAsIsの人材分布を重ねて描くことができれば、どんな人材や役割を強化すべきかが見えてくる。「テックリードや（特定領域の）専門家を増やさなければならない」といった具体的な課題が見えてくるだろう。そのギャップを埋める戦術として、採用や異動を選択することもあれば、育成を選択することもある。

重要なのは、個人のキャリアを独立したものと見なさず、組織の設計要素として扱う視点を持つことだ。

こうしたアプローチをとることで、キャリア定義という “個人の道具” が、“組織を設計するための地図” にもなり得る。『ITエンジニアの転職学』は、エンジニア一人ひとりのキャリアを見つめるための書であると同時に、マネージャーが組織を設計するための座標軸を与えてくれる本でもあるのだ。

進化し続けるAI時代だからこそキャリアも組織も経験主義で適応を繰り返す

エンジニアリング領域におけるAIの進化の速さが、組織戦略と個人のキャリア戦略のあいだに “ずれ” を生んでいる。組織戦略からトップダウンで導き出したキャリアパスが、AIによる現場の変化に追いつけていないのだ。

この状況が、キャリアに対するメンバーらの漠然とした不安を呼び起こしている。「自分の役割がこの先どうなるのか」「このスキルはもう古いのでは」といった不安は、このずれの中で生じるものだ。

『ITエンジニアの転職学』で赤川氏は、AIの得意領域が2軸のキャリアマップの中心から同心円状に外へと広がっていくと予測している。現在のAIは、主に定型的な形式知を扱うことを得意とするからだ。

だが、読者であるエンジニアやマネージャーが、そこから短絡的に次の図式へ飛ぶのは危うい。

  1. キャリアマップの中心に位置するジュニアエンジニア（はじまりの開発者）の活躍と経験の場が失われる
  2. より外側に位置するシニア以上のエンジニアの活躍と経験の機会が増える

実際のダイナミズムはもっと複雑だ。ジュニアが経験を積めなければ将来のシニアは育たず、シニアばかり残れば組織は硬直化する。さらにAIの得意領域が外側まで広がれば、シニアさえ代替される。

だが、きっとそうはならない。

AIの進化によって、否応なく構造的変化が始まるはずだ。エンジニアに求められる役割も能力も、変化が強制されるのだ。もし組織がその変化に受け身でいたなら、エンジニアの努力は旧来の枠組みに閉じ込められ、力を発揮できなくなる。

だからこそ、変化によって生じる “ずれ” を早く検知し、素早く更新する仕組みを持つことが重要だ。AIによって変わる現場の実態に、組織構造を合わせていく。それが、組織を進化させ続け、キャリア不安を和らげる有効な方法である。

私たち人間はまだ、AIとの協働に関する知識と経験を十分に持っていない。それらが不足すれば、組織設計に関する意思決定も最適にはならない。

だからこそ、経験主義による意思決定が力を発揮する。小さく試し、学び、修正を重ねる。その探索プロセスを回し続けるのだ。プロダクト開発と同様に、組織設計も仮説検証を繰り返す学習システムとして捉えるべきである。

余談であるが、AI時代に変わりゆくエンジニア、チーム、組織については、こちらの記事も参考にして欲しい。

mtx2s.hatenablog.com

最後に

『ITエンジニアの転職学』を読んで感じたのは、著者である赤川氏のエンジニアへの深い愛情だ。ひとりでも多くのエンジニアが後悔なくキャリアを歩めるように――その願いが全編を通して貫かれている。

本書は転職の指南書であると同時に、「エンジニアの人生をどう設計するか」を問う一冊でもある。エンジニアのキャリアがAIによって大きく変わり始めた今だからこそ、手に取ってほしい。

あわせて、本稿のテーマにも関わる自身の取り組みを紹介したい。

2025年8月25日に拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された。

エンジニアのキャリアそのものには触れていないが、チームや組織の設計について詳しく解説している。両書を併せて読むことで、キャリアと組織を結ぶ全体像がより明確に見えてくるだろう。

gihyo.jp

AI時代のソフトウェアプロダクト開発──変わるエンジニア、チーム、組織

生成AIに関する最新の調査結果をもとに、ソフトウェアプロダクト組織とエンジニアの変化を整理する。本稿では、その現状と動向を明らかにしたい。

対象とするのは、数年先の未来ではなく、現在およびその少し先くらいの範囲である。技術進化が速すぎて予想がつかないからだ。あまり先のことを考えても的外れな内容になってしまう。

参照するデータは、2025年以降に公開されたものに限定した。執筆時点が2025年10月であること、そしてAIエージェントの本格的な活用が始まったのも2025年であることが理由である。

なお、ここに記す内容には私自身のバイアスが少なからず含まれる点をあらかじめご承知おきいただきたい。

🎧 本記事の音声概要をポッドキャストで公開中
この記事の主要なポイントをGoogleのAIツールNotebookLMで音声概要化し、Spotifyにて実験的に配信中。

open.spotify.com

【ご視聴時の注意点】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の実演でも、それを感じられる。

www.youtube.com

全開発チームへの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時代の組織設計を考えるうえでの基礎となる内容だと考えている。

gihyo.jp

参考文献

*1:「2025 Stack Overflow Developer Survey」Stack Overflow, 2025年, AI tools in the development process

*2:「2024 Stack Overflow Developer Survey」Stack Overflow, 2024年, AI tools in the development process

*3:「2025 Stack Overflow Developer Survey」Stack Overflow, 2025年, AI Agents（Professional Developers）

*4:「The AI Productivity Paradox Research Report」Faros AI, 2025年7月23日, #1 Individual throughput soars, review queues balloon

*5:「The AI Productivity Paradox Research Report」Faros AI, 2025年7月23日, Four AI adoption patterns help explain the plateau

*6:Purna Doddapaneni, Bill Radzevych, Steven Breeden, Bharat Bansal, and Tanvee Rao「From Pilots to Payoff: Generative AI in Software Development」Bain & Company, 2025年9月23日, Beyond code completion: Generative AI for the entire life cycle

*7:「AI-enabled software development fuels innovation」McKinsey, 2025年2月10日, Exhibit1およびExhibit2

*8:Melissa Malec「The AI Development Team of the Future: Skills, Roles & Structure」HatchWorks, 2025年7月16日, Core Roles in the AI Development Team of the Future

*9:「AI-enabled software development fuels innovation」McKinsey, 2025年2月10日, Exhibit2

*10:Melissa Malec「The AI Development Team of the Future: Skills, Roles & Structure」HatchWorks, 2025年7月16日, The Agentic Engineer

*11:「Claude Code: Best Practices for agentic coding」Anthropic, 2025年4月18日

*12:「Agentic Engineering」Zed

*13:Titus Winters, Tom Manshreck, Hyrum Wright 編／竹辺 靖昭 監訳／久富木 隆一 訳『Googleのソフトウェアエンジニアリング　──持続可能なプログラミングを支える技術、文化、プロセス』オライリー・ジャパン, 2021年, 1章

*14:Melissa Malec「The AI Development Team of the Future: Skills, Roles & Structure」HatchWorks, 2025年7月16日, The Agentic Product Strategist

*15:Melissa Malec「The AI Development Team of the Future: Skills, Roles & Structure」HatchWorks, 2025年7月16日, The Agentic QA Engineer

*16:Melissa Malec「The AI Development Team of the Future: Skills, Roles & Structure」HatchWorks, 2025年7月16日, The Agentic Designer

*17:マシュー・スケルトン, マニュエル・パイス 著／原田 騎郎, 永瀬 美穂, 吉羽 龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセンター, 2021年, Chapter1

*18:Kate Niederhoffer, Gabriella Rosen Kellerman, Angela Lee, Alex Liebscher, Kristina Rapuano and Jeffrey T. Hancock「AI-Generated “Workslop” Is Destroying Productivity」Harvard Business Review, 2025年9月22日, The Workslop Tax

*19:Kate Niederhoffer, Gabriella Rosen Kellerman, Angela Lee, Alex Liebscher, Kristina Rapuano and Jeffrey T. Hancock「AI-Generated “Workslop” Is Destroying Productivity」Harvard Business Review, 2025年9月22日, 冒頭の文章

*20:「AI-enabled software development fuels innovation」McKinsey, 2025年2月10日, Talent and organizational structure

*21:「Artificial Intelligence Index Report 2025」Stanford University Human-Centered Artificial Intelligence, 2025年, P131

*22:Erik Brynjolfsson, Bharat Chandar, Ruyu Chen「Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence」Stanford University Human-Centered Artificial Intelligence, 2025年8月26日, P4

*23:Robert C.Martin 著, 角 征典 訳『Clean Craftsmanship 規律、基準、倫理』KADOKAWA, 2022年

*24:Martin Fowler「LLMs bring new nature of abstraction」martinfowler.com, 2025年6月24日

チームの自律性を重んじるだけでは組織がうまく回らない / 「Spotify’s Failed #SquadGoals」を読み解く

「Spotifyは "Spotifyモデル" を使っていないし、あなたも使うべきではない」という一文からはじまる文書「Spotify’s Failed #SquadGoals」が公開されたのは、2020年4月だ。Spotifyモデルを紹介する書籍『ユニコーン企業のひみつ』の日本語版発売が2021年4月。そこから1年も前の出来事である。

今となっては古い話題ではあるが、Spotifyモデルが失敗したとされる原因について改めて掘り下げようと思い、「Failed #SquadGoals」をあらためて読み直してみた。その内容を本稿に整理する。

もちろん、Spotifyモデルを批判する意図は微塵もなく、失敗したと断定する気もない。純粋に、当該文書に記された失敗理由の数々が、多くの組織にとっても考慮すべき示唆を含んでいると感じただけだ。言い換えれば、一般化できる知見が豊富に含まれているのではないか、ということである。

だからこそ、ここから学べることは大いにある。特に、大規模アジャイルでソフトウェアプロダクトを開発する組織を設計する際の洞察を養ううえで役立つだろう。

なお、私自身はSpotifyモデルを試した経験はない。知識として知っているだけだ。文書に書かれていることの真偽を確認したわけでもない。その後の最新情報も追ってはいない。実際、Spotify組織は、その後もどんどん変化していったと言う。きっと、本当に問題を抱えていたとしても、解決していったのだろう。

参考にした主な文献

本稿で主に参考にした文献は次のとおりだ。私が有するSpotifyモデルに関する知識はこれらがすべてと言ってよい。

Spotify’s Failed #SquadGoals

www.jeremiahlee.com

Spotifyモデルの失敗についてまとめたドキュメント。Jeremiah Leeによって書かれ、2020年4月に公開された。

Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds

（PDF）https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Spotifyモデルを解説したホワイトペーパー。Henrik KnibergとAnders Ivarssonによって書かれ、2012年10月に公開された。

ユニコーン企業のひみつ ― Spotifyで学んだソフトウェアづくりと働き

www.oreilly.co.jp

Spotifyモデルを解説した書籍。Jonathan Rasmusson 著、島田浩二・角谷信太郎 翻訳でオライリー・ジャパンから2021年4月に出版。

大規模アジャイルを機能させるためのアイデアが詰まった一冊で、おすすめの書籍。noteに書いた感想文はこちら。

note.com

なお、拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』も、本稿と扱うテーマが近いため適宜参照し、引用した。ただし、同書の中ではSpotifyモデルへの言及は注釈が一件ある程度であり、内容の中心ではない。 gihyo.jp

最小限の用語集

まず、本稿を読み進めるうえで必要最小限のSpotifyモデル用語を説明する。Spotifyの組織構造を「スクワッド」と「チャプター」によるマトリクス組織と捉えると、用語を理解しやすい。

スクワッド

  • エンジニアだけでなくデザイナーやテスターも含む、職能横断の自己組織化チーム
  • チームとしてフルスタックで、フロントエンド（FE）／バックエンド（BE）の開発やデプロイまで行える体制
  • スクラムチームに近い
  • 本稿では多くの箇所で、あえて「チーム」と表記

プロダクトオーナー

  • ビジネス価値と技術的側面の両方を踏まえて作業の優先順位を決める役割
  • 各スクワッドに専任で配属
  • スクラムにおけるプロダクトオーナーに近い

チャプター

  • 専門性を軸に、スクワッドを横断して形成される人の集まり
  • ライン組織上の部門や部署に相当
  • 例：Web開発チャプター、バックエンドチャプター、テストチャプターなど

チャプターリード

  • 各チャプターのラインマネージャー
  • 採用・評価・給与・キャリア開発などを担う
  • いずれかのスクワッドにも所属

失敗の本質となる二つの問題点と「コンピテンシー」という言葉

Jeremiah Leeの文書をもとに、問題点を次の二つに分類した。

  1. 過度な自律性に対してチームがコンピテンシー不足
  2. 組織構造的にコンピテンシーリーダーが不在

以降の節では、Spotifyの組織に限らず一般化を意識しつつ、これらを考察する。したがって、原文で述べられていない点についても、必要に応じて具体化・抽象化しながら考えを深めていく。

「コンピテンシー（competency）」という言葉に馴染みがないかもしれないが、複数の参考文献でも用いられているため、あえて使用した。

コンピテンシーとは、特定の業務領域で高い能力や成果を発揮する人に共通して見られる特徴を指す。そこには知識やスキルだけでなく、態度や行動様式も含まれる。たとえば、論理的思考力、顧客志向、チームワーク、主体性、リーダーシップなどが挙げられる。

重要なのは、コンピテンシーが単なる能力や資質ではなく、具体的な行動として定義される点である。たとえば論理的思考力であれば、「複雑な課題を分解し、筋道立てて説明する」といった観察可能な行動で表される。

一方、「コンピテンス（competence）」という言葉を使う場合、コンピテンシーを発揮するための基礎的な能力自体を指している。

なお、上記の二つの問題点以外にも「3. 自縛を招いた独自の語彙」が存在するのだが、多くの組織には当てはまらず、一般化しづらいため本稿では割愛する。興味があれば、Jeremiah Leeの文書内の「Mythology is difficult to change」を読むとよいだろう。

問題1. 過度な自律性に対してチームがコンピテンシー不足

ここで求められる自律性とは、アジャイルの価値や原則、プラクティスに根ざした意思決定や行動を指す。

この自律性は個人ではなくチームに最適化された「チーム思考」に基づくものである。そして、チーム思考という言葉が指す「チーム」の範囲も、所属するスクワッド単体に留まらず、組織全体、会社全体をチームとしてとらえる。それこそが、自己組織化と言えるだろう。

しかし実際には、多くのメンバーの行動が、そのようなコンピテンシーを欠いていた。

それに気付かないまま、チームの自律性を重視するあまり、すべてをチームに委ねたらどうなるだろうか。仕事のやり方への標準化は「Howに対する強制であり、自律性に反する」と考えられたのだろう。

その結果として生じるのは、「車輪の再発明」「規模の経済の喪失」「流動性の喪失」「帰属意識の希薄化」だ。

車輪の再発明

新しく編成されたチームは、ゼロから自分たちの “仕事のやり方（Way of Working）” を作り上げることになる。参照できるテンプレートはなく、アジャイルプラクティスに関する知識や経験も乏しい。その結果、チームが本質を理解しないままアジャイルを実践し、大抵は「ウォーターフォールではない何か」にとどまる。

何が正解かわからないまま実践し、つまずきながら課題を改善していくことになるだろう。それ自体は悪くない。

しかし、これでは効率が悪い。既存のアジャイルプラクティスを用いれば解決できることまで、知らないがゆえに各チームがやり方を再発明してしまうからだ。

規模の経済の喪失

プロセス改善の観点から言えば、複数チームでソフトウェアプロダクトを開発する組織は、通常は規模の経済の恩恵を受けられる。

あるチームが得たローカルな知識を組織全体に共有し、グローバルな知識へと発展させられるからだ。それは組織内のプラクティスとなる。各チームはそのプラクティスを自チームに取り込んでプロセスを改善できる。

しかし、チームごとに “仕事のやり方” が大きく異なっていれば、他チームのプラクティスを適用しにくくなる。たとえ似た問題を抱えていても、コンテキストが違えば解決のためのプラクティスも異なるからだ。

だから、結局はそれぞれのチームで解決方法を見つけ出すしかなくなる。それがまた、チームごとに「車輪の再発明」を加速させる。

これでは規模の経済の恩恵を享受できない。

流動性の喪失

チームごとに “仕事のやり方” がまったく異なるなら、チーム間でのメンバー異動の難易度は上がる。

異動したメンバーにとっては、新しいチームのプロセスもツールも今までとは違うものとなる。もしかしたら、技術スタックだって違うかもしれない。その学習コストが高い。

そのうえ、チームオリジナルのやり方だから、わからないことがあっても、ウェブ上に情報がないこともある。そういう時はチーム内のドキュメントに頼りたいところだ。けれど、それも整備されているとは限らない。暗黙知も多いだろう。

最後の頼みの綱は、チームの仲間に聞くことだけだ。しかし、彼らが忙しそうなら、質問をためらってしまう。

新規メンバーの受け入れ自体に拒否感を示すチームもあるだろう。「学習や教育に時間を割く余裕はない」と判断するかもしれない。

結果的に組織から流動性が失われ、チームが固定化する。硬直した組織内では、属人化が横行しやすい。コードだって属人化する。さらに、チーム全体がコンフォートゾーンに浸かりやすく、業績基準も低くなる。

出典: エイミー・C・エドモンドソン 著／野津智子 訳／村瀬俊朗 解説『恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす』英治出版, 2021年, 第1章 表1.1を参考に筆者が作成

これらは、『チームの力で組織を動かす』の中でも述べている。

　属人化は、メンバーそれぞれに得意分野ができはじめることから生じます。同じチームで長く仕事を続ける中で、みんな、いずれかの分野が得意になっていきます。得意になれば、その分野の仕事は人から頼られるようになるし、自ら引き受けるようになります。得意な人がやった方が短期間で仕事が完了するし、アウトプットの品質も高くなるから当然です。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 3-3-2

　属人化の魔の手はコードにも及びます。
　大抵は、特定の領域のコードの理解容易性の低下という形であらわれます。その領域の変更はいつも同じ人が担当するから、当人だけがコードを理解すればよく、他人が理解しやすいようにコードを書く動機がないのです。そうしてコメントもなく、適切なドキュメントもないコードができあがります。
　理解容易性が低ければ、変更容易性も低くなります。コードを書いた本人以外には、どのような設計になっているのかをコードから読み取ることが難しくなるのです。別のメンバーがそこに変更を加えたくても手出しできません。そうすると、また当人が変更するしかなくなります。こうしてコードの属人化は深刻化の一途を辿ります。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 3-3-3

　私たちは、チームや組織をラーニングゾーンや高パフォーマンスゾーンに置きたいのです。
　しかしながら、チームを長く安定させ続けていると、コンフォートゾーンに陥りやすくなります。外部環境も内部環境も常に変動し続ける中で、新しいことを学び、チャレンジしなければ、優れたプロダクトをユーザーに提供することなどできません。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 5-5-4

また、人の異動に伴う知識の移動も失われる。それがまた、車輪の再発明へとつながる。

帰属意識の希薄化

チームごとの差異が大きくなると、各チームで独自の文化が育っていく。すると、メンバーからすれば他のチームがまるで別会社のように映り、関心を持ちにくくなる。

これでは、自チームへの帰属意識は高まっても、組織全体、会社全体への帰属意識は薄れる。

この状態は、全体最適な意思決定を阻害する要因にもなる。

部分最適な意思決定

「自律性」の意味を取り違えると、チームの意思決定は部分最適に陥る。組織全体や会社全体の視点で状況を捉えられず、自チームの仕事を優先してしまう。しかし、部分最適の総和は、全体最適とはならない。

チーム間での仕事の依存関係は、この問題を顕在化させる。

たとえば、チームAが受け持つ機能開発において、所有するコードaだけでなく、他チームBが所有するコードbを変更しなければならないときだ。どちらがコードbを変更するにせよ、チームAにとってはチームBの協力が必要となる。このように、複数チームに分かれたプロダクト開発には、チームを横断しなければ実現できない仕事も多い。

このような場合、もしチームBが自分たちの仕事ばかりを優先すれば、チームAの開発は停滞してしまう。

対策1. Minimum Viable "Agility" の標準化

自律性という名のもとに “仕事のやり方” をすべてチームに委ねるのではなく、組織として標準化すべき範囲を定めることが重要だ。共通のプロセスやツール、ルール、ガイドラインを定義する。それが「最小限の実行可能なアジリティ（minimum viable agility）」である。Jeremiah Lee の文書では、この言葉をLean Agile Scotland 2017でのJoakim Sundén（Spotifyのアジャイルコーチ）の発言から引用していた。

Every time you have a new team, or a team splits, they kind of have to reinvent the wheel in how they should be working.
Maybe, just maybe, we should do it that we have this "Minimum viable agility" and that's what you start with.
Feel free to opt out, but people shouldn't have to opt-in all the time.

新しいチームができるたびに、あるいはチームが分かれるたびに、自分たちがどう働くべきかを、ある意味で、車輪を再発明しなければならない。
もしかすると、もしかするとだが、「最小限の実行可能なアジリティ」を持つようにすべきなのかもしれない。そして、それを出発点とする。
オプトアウトすることは自由だ。常にオプトインすることを求めるべきではない。

（引用: Joakim Sundén「You can do better than the Spotify Model」Lean Agile Scotland 2017, 2017年10月, 26:50-27:09 ※日本語訳は筆者によるもの）

標準に含めるプロセスやツールも、既存のものを活用する。たとえば開発プロセスならスクラムを採用するといった具合だ。その他にもTDDやgit-flow, GitHub Flowなどを組み合わせられる。

こうして定めた標準は、すべてを必須にせず、オプトアウトを認めたり、複数から選択できる形にするのが望ましい。チームの環境や成熟度によって、最適な選択肢や組み合わせは異なるからである。

このように標準を設けることで、車輪の再発明を防ぎ、知識の流通による規模の経済を享受し、人の流動性を高め、さらに組織や会社への帰属意識を醸成できる。

対策2. チーム間連携方法の標準化

チーム間連携の方法や意思決定についても、標準化しておくとよい。

たとえば、チーム横断でのコード変更に関するガイドラインを設ける。先述の「チームAが受け持つ機能開発において、所有するコードaだけでなく、他チームBが所有するコードbを変更しなければならないとき」をどう扱うかである。

コードbはどちらのチームが変更するのか、外部品質・内部品質は誰が責任を負うのか。そういったポリシーを決めることも標準化のひとつだ。『チームの力で組織を動かす』では、これを「コードのオーナーシップ制」としてガイドラインを定義している。

ソフトウェアプロダクトを構成するコードは、その領域ごとにオーナーたるチームを設定し、品質責任の所在を明確にします。そのうえで、チーム内では「コードの共同所有」とし、他チームに対しては「弱いコードの所有」をポリシーとします。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 6-2

次のスライドは、書籍紹介イベントで使った登壇資料のものだ。

対策3. 何が全体最適であるかの明示

チーム間連携の手法だけを定義しても、チームが全体最適な意思決定ができなければうまく機能しない。組織全体として何を優先すべきかが曖昧であれば、チーム間での優先順位付けに統一性が欠けるからだ。先の例で言えば、チームAからの連携依頼をチームBが安易に断ってしまう恐れがある。

だからこそ、組織全体のミッションを明確にする必要がある。どこに向かっているのか、全員が共通の認識を持つことが重要だ。それに照らして、各チームが自らの意思決定を最適化、つまり「アラインメント」を施せるようにする。

さらに、ミッション（目的）を実現するための目標を設定する。目標を達成しても必ずしも目的を果たしたことにはならない。だが、目標と実績のギャップは、チームが自身の意思決定の妥当性を分析・検証するための指針となる。

加えて、目標に対する評価方法を定めることで、チームが何をすべきかがより明確になるだろう。

対策4. アカウンタビリティの所在の明示

また、自律性に見合う形で、チームにアカウンタビリティを持たせる。チームとしての意思決定に対し、その結果に責任を持ち、そうする（そうした）理由を関係者に説明できなければならない。

指示されて動くチームなら、レスポンシビリティのみでよい。言われた仕事をきちんと遂行する責任を負い、アカウンタビリティは指示側が受け持つ。

しかし、自律性を持って動くチームには指示者がいない。自分たちで決める。したがって、レスポンシビリティだけでなく、アカウンタビリティも必要となる。

ただし、「アカウンタビリティを持て」と言うだけでは単なる精神論だ。何らかの仕組みを用意する必要がある。

まず、誰が何に対してどの責任を持つのか、その所在を明確にする。ここが曖昧だと、チームやマネージャーが権限を誤用・濫用しかねない。明確化の手法としては、RACI（レイシー）マトリクスが向いているだろう。

次の表は、スクラムにおけるスプリントプランニングのRACIマトリクスの例だ。

出典: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 3-8-4 を参考に筆者が作成

  • R：Responsible（実行責任者）: 実際にタスクを実行する役割
  • A：Accountable（説明責任者）: タスクの結果に責任を持ち関係者に説明する役割
  • C：Consulted（相談先）: タスクに関連して情報やアドバイスを提供する役割
  • I：Informed（報告先）: タスクの進捗について報告を受ける役割

次に、実行と結果を可視化する。RACIマトリクスでResponsibleやAccountableに割り当てた活動は、Informedへ報告（可視化）する。

注意すべき点は、チームの失敗を “責任追及” ではなく “学習の機会” として捉えることだ。誰（どのチーム）が失敗したかではなく、なぜ失敗したのかを分析し、改善につなげることが重要だ。

理由は次のとおり。引用文では個人の失敗について述べているが、チームの失敗にも同様に当てはまる。

　もし、ミスを犯した人を責め、個人に責任を負わせようとする組織なら、失敗から学ぶこともできず、改善のチャンスを失います。また、現場の改善提案を無視したり、否定・抑圧するマネジメントが横行しているなら、誰も提案などしなくなるでしょう。
　こういった「人を信頼しない組織」では、誰もが口を閉ざすようになります。自分の失敗を隠し、問題に気づいても見ぬふりするようになるかもしれません。これではフィードバックを得ることも、そこから学ぶこともできなくなってしまいます。（中略）
　失敗した当人たちがリスクを負わずに失敗について語り、分析ができる。改善のためのアイデアを誰もが提案できる。そんな文化を持つからこそ、学習する組織たり得ます。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 1-3-4

問題2: 組織構造的にコンピテンシーリーダーが不在

チームが問題1のようにコンピテンシー不足であるにもかかわらず、組織がチームの自律性に頼りすぎると、組織全体がカオスに陥る。

従来の組織では、マネージャーがリーダーシップを発揮すべき場面である。コンピテンシーリーダーとして、彼らがメンバーに欠けた点を補う役割を担うのだ。

しかし、マネージャーらはその期待に応えることができなかった。従来組織のマネージャーに相当する「チャプターリード」が、スクワッドの活動から距離を置いた存在だったからである。

さらに、マトリクス型組織の構造的問題もあり、マネージャーが能力を十分に発揮できる体制は整っていなかった。スクワッドメンバーごとに所属チャプターが異なり、その数だけチャプターリードがいる。この複数マネージャー体制自体が問題となっていたのだ。

その結果として生じるのは、「トレードオフ不全」「相談先の重複と分散」である。

トレードオフ不全

長期的な視点に立てばスピードと品質は対立しないが、短期的にはトレードオフの関係にある。ここで言う品質とは、外部品質も含むが、特に内部品質を指す。内部品質を高めれば、プロダクトオーナーにとって将来のオプション（選択肢）が増える。しかし、そのレベルの品質を実現するには時間を要するかもしれない。

トレードオフとは、どちらか一方を完全に犠牲にすることではなく、対象となる項目それぞれにどれだけ力を注ぐかを調整することを意味する。

そのバランスを見極められるのは、対象領域を熟知した専門家だけである。そして、ソフトウェアプロダクト開発において、その多くはエンジニアリングの専門性である。

ただし、チーム内に複数のエンジニアがいれば、意見が割れて結論が出ないこともある。プロダクトオーナーがエンジニアでなければ、その意見をまとめるのも難しい。

このような場合にリーダーシップを発揮するのがエンジニアリングマネージャーだ。彼らは、マトリクス型組織の中で、チャプターリードとして配置されている。

しかし、チャプターリードはチームのソフトウェアデリバリーに関与せず、責任も負っていなかった。彼らの役割はキャリア開発と給与の査定に限定されていた。これは、おそらくチームの自律性を重視しすぎた結果の責任配置だったと考えられる。

そのため、プロダクトオーナーはエンジニアリングマネージャーに頼ることができず、適切ではないかもしれない判断を下すことになる。

相談先の重複と分散

たとえチャプターリードがソフトウェアデリバリーに責任を負っていたとしても、そこには問題が生じかねない。

理由は、一つのチームに対してチャプターリードが複数存在することにある。たとえば、チーム内のFEエンジニアが所属するチャプターのリード、BEエンジニアが所属するチャプターのリードといった具合に、専門性ごとにチャプターが区切られているからだ。

まず、プロダクトオーナーにとって相談相手が複数存在すること自体がコストとなる。誰に相談すべきか迷うこともあれば、全員を集めて協議するには大きな手間がかかる。

さらに、複数のチャプターリードがいれば、彼らの間で意見が割れることもある。その場合、対立を調停するために、さらに上位レイヤーへエスカレーションせざるを得ない。

これでは迅速な意思決定は難しい。

対策1. エンジニアリングチームを拡張したプロダクトチーム

この問題の原因は、ライン組織の切り方にある。すなわち、組織設計によって生じた構造が引き起こしている。

スクワッドと呼ばれるプロダクトチームはフルスタックである。ウェブ開発エンジニアもバックエンドエンジニアも含む。エンドツーエンドでのプロダクト開発を可能にするためだ。

一方、チャプターと呼ばれるライン組織は技術的専門性ごとに編成される。たとえば、ウェブ開発チャプターやバックエンドチャプターなどである。

必然的に、スクワッドには複数のチャプターからメンバーが集められる。

このような構造を採った理由は、技術的専門性の深化、リソースプール機能の確保、の二点にあると考えられる。

まず、スクワッドのような機能横断型組織は「知の探索」には適しているが、「知の深化」には相対的に弱い。新しいアイデアや技術を模索するのには向くが、技術を磨き上げ効率化・精緻化するのには向きにくいということだ。

そこでチャプターを機能別組織にすることで、「知の深化」を補おうとしたのだろう。

もう一つは、スクワッドの再編成を容易にする狙いである。チャプターを機能別組織としておけば、新たなスクワッドを組成したり、スクワッド間でメンバーを異動させたりする際に、チャプター間を異動する必要がない。こうして柔軟な組織運用を実現したかったのだろう。

しかし、前者の「知の深化」については、別枠の「ギルド」で担保し得た。ギルドは関心領域に基づき、スクワッド横断で形成される枠組みで、たとえばiOSギルドやAndroidギルドなどがある。

後者については、実際にはチャプターの入れ替えはそれほど頻繁ではなかったという。ソフトウェアプロダクト開発は、小規模で、かつ安定した体制で進める活動であり、プロジェクト体制のように頻繁にチームを組み替えるものではないからだ。

これらを踏まえると、この組織構造のメリットは大きくは見いだしにくい。

さらに、チャプターリードは、自律する（はずの）スクワッドの活動から遠ざけられていたため、スクワッドのソフトウェアデリバリーに十分関与できなかった。

もう少し深掘りすると、チャプターリードがメンバーの評価を正しく行えたかは疑問である。メンバーはそれぞれ別のスクワッドに配置され、チャプターリードの目の届かない場所で活動している。日々の活躍をつぶさに観察できない状況で、本当に正しく公平な評価ができたのだろうか。

結論として、機能横断型のプロダクトチームは、ライン組織上のエンジニアリングチームを拡張する形で形成するのがよいと考える。プロダクトチーム内で最も人数が多い職種であるエンジニアを基盤に据え、そこに企画者やデザイナーを加えて編成する。

もちろん、ライン組織上のエンジニアリングチームは、あらかじめソフトウェア開発・運用面でフルスタックで構成する。FE開発もBE開発もでき、運用もできる体制だ。

こうすることで、エンジニアリングマネージャーは、被評価者である全メンバーの活動をつぶさに観察できる。自らもプロダクトチームの一員としてメンバーとともに働けるからだ。

加えて、プロダクトチーム内の唯一のエンジニアリングマネージャーとして、プロダクトオーナーの片腕になれる。プロダクトチームをスタートアップ企業に準えるなら、プロダクトオーナーはCEO、エンジニアリングマネージャーはCTOである。チームがうまくいかない時の対処も主導できる。

余談だが、ホワイトペーパーでは、エンジニアリングマネージャーとプロダクトオーナーのこの関係性を「教授と起業家（professor and entrepreneur）」モデルと呼んでいた。メアリー&トム・ポッペンディークに由来するとされるが、一次ソースが見つけられなかった。これはおそらく、ポッペンディーク夫妻の著書『リーンソフトウェア開発と組織改革』を下敷きにしているのではないか。同書では「コンピテンシーリーダー（高能力・高業績リーダー）」と「製品チャンピオン」という用語で対比が示されている。

最後に

文書の中でJeremiah Leeは、自律性にはアカウンタビリティ（accountability）とアラインメント（alignment）が必要だと述べている。

ここで言うアラインメントとは、チームの活動を組織全体・会社全体の方向性と一致させることを指す。チームの自律性が「やりたいことを何でもできる」という意味に誤解されることを防ぐためのものだ。

アジャイルを実践するからといって、むやみにチームの自律性だけを重んじれば失敗する。そこでの優先順位付けにはアラインメントが施され、その意思決定にはアカウンタビリティが伴わなければならない。

Jeremiah Leeの文書は、その点に警鐘を鳴らしている。

最後にお知らせだが、2025年8月25日に拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された。Spotifyモデルについてはほぼ触れてはいないが、本ブログに興味を持っていただけた方なら、楽しんで読んでいただけると思う。

gihyo.jp

自社エンジニアが熱量を持って学び続けられる環境づくりは、技術広報のノウハウから学べる / 『技術広報の教科書』を読んで

自社エンジニアが熱心に学び続けている組織は強い。

そうした文化や環境を備える組織は、向上心の強いエンジニアにとって魅力的だ。仲間とともに日々切磋琢磨しながら自身のスキルを高め、それを仕事に活かす。その充実感は、何ものにも代えがたい。

組織にとっても、エンジニアの技術力とエンゲージメントをともに高め、技術戦略を推進するエンジンにもなる。結果として、組織のパフォーマンスは自然と高まる。

しかし、言うは易し。学び続ける環境を定着させ、文化にするのは難しい。学びをエンジニア個々の努力に委ねているのが実情という組織も多い。

そこで、技術広報のノウハウを社内に転用できるのではないか。これが本稿のテーマである。

参考書籍の紹介

書籍『技術広報の教科書─⁠─人事・広報・エンジニアが兼務から始める』が、2025年9月11日に技術評論社から出版される。私は、著者の河又さんからご恵贈いただき、いち早く読むことができた。

gihyo.jp

私自身は技術広報の担当ではないが、この書籍に興味を持ったのは、本稿タイトルが示す通りの考えがあったからだ。すなわち、自社エンジニアが熱量を持って学び続けられる環境づくりは、技術広報のノウハウから学べる、という考えである。

技術広報の活動を社内向けに転用する

書籍を読み進めると、最終章である第9章に、まさにこのテーマの節「9.2 技術広報の知見を活かすインナーブランディング」がある。

外向きのブランド価値を巧みに伝えるノウハウを社内向けに転用し、エンジニアの学びや発信を活性化させることで、結果的に組織全体の技術力とアウトプット力を底上げできる（後略）

（引用: 河又 涼 著『技術広報の教科書──人事・広報・エンジニアが兼務から始める』技術評論社, 2025年, P218）

技術広報の活動は、大雑把に言えば二つに分けられる。

  1. 社外のエンジニアに向けて、自社のブランドイメージを形成する活動
  2. 社内のエンジニアに協力を仰ぎ、情報発信を促す活動

1の活動は、言い換えると社外のエンジニアに自社の “ファン” を増やす取り組みと言える。

このベクトルを社外ではなく社内に向ければ、自社エンジニアのエンゲージメントを高める取り組みになる。

2の活動は、その過程で、発信者であるエンジニア自身の成長を促す側面もある。

さらに、その情報発信を社内のエンジニアが受け取れば、組織内にナレッジ循環が形成される。

ナレッジ循環を生み出す

日々の業務で蓄積される知識や、書籍・社外イベントなどから得た情報は、思ったよりも組織全体に広がらない。個人にとどまっていたり、チームや部門に閉じていたりする。

そうした「ローカルナレッジ」を「グローバルナレッジ」として組織全体で共有する重要性は言うまでもない。DevOpsでも繰り返し語られている。

　ある部門で新しい教訓を見つけたときには、社内のほかの部門全体がその知識を活用し、利益を得られるようにするためのメカニズムも必要である。言い換えれば、チームや個人が知識を生むような経験をしたときには、その言葉にならない知識（中略）を体系化された明確な知識に変え、実践を通じてそれが他者の専門能力の一部になるようにするということだ。
　すると、誰かがそれと同じような仕事をするときには、同じ仕事をしたことのある社員全員が蓄積した集合的な経験を背景にすることができる。ローカルな知識をグローバルな知識に転化する（後略）

（引用: ジーン・キム, ジェズ・ハンブル, パトリック・ボア, ジョン・ウィリス 著『The DevOps ハンドブック 理論・原則・実践のすべて』日経BP, 2017年, 4.3）

たとえば社内LTやテックブログの執筆は、そうした効果をもたらす。さらに、そのアウトプットの過程で知識が言語化され、理解がいっそう深まる。これが技術力の向上にもつながる。

しかし、こうした取り組みは、熱意を持って立ち上げても自然消滅、あるいは形骸化しやすい。

運営がうまくいかないからだ。登壇者や執筆者がなかなか集まらない。業務のさなかに登壇・執筆を依頼しても引き受けてくれない。そもそも尻込みするエンジニアも多い。自分の知識を過小評価して「発表するほどではない」と考えがちなのも障壁だ。

技術広報の担当者は、こうした障壁を乗り越えて、社外に向けた継続的な情報発信の環境を整えている。書籍の第4.1節「登壇者を確定する」（P86）には、そのヒントが挙げられている。

  • 基本は “やる気” を優先する
  • 登壇に対して手があがらないケース
    • 社内勉強会やミーティングでの発言に注目
    • EM・リードエンジニアとの対話を重視
    • 段階的な登壇の誘導
    • 成功事例の紹介と心理的ハードルの低減
  • 自信のなさに寄り添う
    • 発表へのフィードバック
    • リハーサルのサポート
    • デザイナーとの協力

エンゲージメントを高める

社員のエンゲージメントの高さは、組織のパフォーマンスの高さに関係する。そんな調査結果がある。

2012年に実施されたGallupの調査では、従業員エンゲージメントが上位4分の1の企業は、下位4分の1の企業に比べて、顧客評価は10%、生産性は21%、収益性は22%高かった。また、欠勤は37%少なく、離職率は25%から60%低く、品質上の欠陥は41%少なかった。

エンゲージメントとは、従業員が自分たちの組織やサービス／プロダクトに誇りを持ち、ファンになること、と言い換えられるだろう。そうなれば、熱量を持って業務にあたることができる。それが組織としてのパフォーマンスに結びつく。

まず、ナレッジ循環の環境をうまく整えられれば、それだけでもエンゲージメントの向上に寄与する。書籍では、第9.2節の項「LT大会の立ち上げ」（P220）に、サポート方法のヒントが示されている。

  • フィードバックと称賛を惜しみなく
  • 定期開催への道筋を示す
  • 運営サポートを最小限にとどめ、次第に自走させる
  • 技術広報の視点で見る「背中のひと押し」

また、現場発案による輪読会や勉強会をサポートする方法についても触れられている（P219）。

  • 現場起点の活動をサポートする

そのほか、社員インタビュー記事を作成して社内に公開することや、サービスロゴのステッカーなどのグッズを配布するのも一案だ。

技術戦略にひもづける

ナレッジ循環もエンゲージメント向上も、技術面でのビジョンに沿って方向づけることで、その取り組みは戦略的なものとなる。ここで言うビジョン（目指す姿）は、技術広報が扱うブランドイメージに近いものだ。

書籍の第7.3節の項「構築したいブランドイメージを構築する」（P178）では、次のような例が挙げられている。

  • 常に最新技術に挑戦し続ける
  • 特定の専門領域を極める
  • 顧客価値のためなら領域を越えて取り組むエンジニアたち

より具体的な例としては、「高い技術力を持つRubyエンジニアの集団」といったものがある（P179）。

ただし、ここで掲げるのはあくまでも理想とするイメージであり、現状の組織そのものではない。そこにはギャップがある。

このギャップを埋めるのが技術戦略であり、前述の取り組みはそのための施策に位置づけられる。たとえば、LT大会のテーマをRuby関連技術に寄せて計画する、といった具合だ。

ロードマップを描いて目標を決める

理想とするイメージに向かってロードマップを作り、そこに長期（3〜5年）、中期（1〜3年）、短期（半年〜1年）の定性目標を置く。注意点は次のとおりだ。

中長期になればなるほど不確実性が増すため、長期目標はやや抽象度を高めに設定し、「理想像」を示すぐらいのほうが動きやすいでしょう。初期段階であまり細部にこだわりすぎると、環境の変化や事業戦略の転換などに適応しづらくなってしまいます。

（引用: 河又 涼 著『技術広報の教科書──人事・広報・エンジニアが兼務から始める』技術評論社, 2025年, P186）

また、定量目標にこだわりすぎるのも好ましくない。理想像に向けた取り組みとその効果の因果関係を明確にするのは難しい。何をもって「高い技術力を持つRubyエンジニアの集団」が実現したと言えるのか、LT大会などがどれだけ寄与したのか——その証明にこだわりすぎても得られるものは少ない。

そこで本書が唱えるのは、行動量を基準にした指標で短期目標を作ることだ。

技術広報における目標設定の難しさを前提としつつ、短期のスパンで何らかの指標を持つこと自体は、チームの進捗可視化やモチベーション維持において有用です。なかでも、「行動量」を基準にした短期目標の活用が現実的な手段となります。

（引用: 河又 涼 著『技術広報の教科書──人事・広報・エンジニアが兼務から始める』技術評論社, 2025年, P195）

例として、次のような行動量が挙げられている。

  • 半年内にテックブログの記事を◯本以上投稿
  • 勉強会や輪読会を◯回開催
  • 社内外のイベント登壇数を◯件にする

そのうえで、中長期の観測には定量指標を持つことも有効だと述べている。

（前略）定性的な中長期目標は企業の「羅針盤」として方向性を示す役割を担います。一方で、そこに定量的な数値を付与できると、実際にどれだけ前進しているのかを把握しやすくなります。

（引用: 河又 涼 著『技術広報の教科書──人事・広報・エンジニアが兼務から始める』技術評論社, 2025年, P200）

たとえば、テックブログの本数やはてなブックマーク数などがこれに当たる。もちろん、こうした定量目標は、達成したからといって目的を果たしたとは限らない。そこに留意し、あくまで補助的な指標として位置づけるのがよい。

さいごに

以上、技術広報のノウハウを手がかりに、自社エンジニアが熱量を持って学び続けられる環境づくりについて考えてみた。EMが取り組むことを想定して書いたが、社内に技術広報の機能があるなら、迷わず一緒に取り組むべきだろう。

本稿に興味を持っていただいた方は、2025年9月11日に発売される書籍『技術広報の教科書─⁠─人事・広報・エンジニアが兼務から始める』をぜひ手に取ってみてほしい。

gihyo.jp

最後にお知らせだが、2025年8月25日に拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された。本ブログに興味を持っていただいている方なら、楽しんで読んでいただけると思う。

gihyo.jp