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

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

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

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

---

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

open.spotify.com

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

• 主な参考文献
• 前回2024年度の調査で発覚した「DORAアノマリー」という現象
• 2025年度の調査の核心は、AIによる “増幅” とシステムによる “相乗効果”
• AI導入による個人への効果を組織の成果に “変換” するためのシステム強化
• AI時代こそ “フロー” に注意を傾ける
  • よくある例: AI導入でコーディングが速くなった代償としてコードレビューで詰まる
• フローを詰まらせる見えない “摩擦” の正体
  • 気づかぬうちに効率を失ってしまう、現実のフローの複雑さ
  • フローを詰まらせる組織設計アンチパターン
• “ストリームアラインド” での継続的なフロー改善
• 摩擦を軽減する “AIケイパビリティ”
  • 明確に伝達された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

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

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

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

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

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

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

• 参考書籍の紹介
• エンジニアリングマネジメントの視点からメンバーのキャリア設計を見る
• エンジニアの役割を8つの分類と2つの軸で捉える
• エンジニアの能力を6つのカテゴリと5つのレベルで捉える
• 個人の成長を支援する
  • 「スタッフプラス」と「エンジニアリングマネジメント」という2つの方向性
• 個人のキャリア戦略と組織戦略を接続する
• 進化し続けるAI時代だからこそキャリアも組織も経験主義で適応を繰り返す
• 最後に

参考書籍の紹介

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つの軸で整理している点である。この図により、エンジニアとしてどの方向で成果を発揮していくのかを俯瞰できる。

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

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

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

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

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

• カテゴリ:

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

• レベル:

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

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

個人の成長を支援する

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

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

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

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

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

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

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

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

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

スタッフプラスの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に関する最新の調査結果をもとに、ソフトウェアプロダクト組織とエンジニアの変化を整理する。本稿では、その現状と動向を明らかにしたい。

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

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

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

---

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

open.spotify.com

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

• 開発ワークフローの変化
  • Human-AIオーケストレーション化
  • 全開発チームへのAI導入状況の均一化
• PDLC（Product Development Life Cycle）の変化
  • 開発ワークフロー以外へのAI導入
  • プロダクトディスカバリのクロスファンクショナル化
  • ディスカバリとデリバリーのデュアルトラック化
• チームと組織の変化
  • あらゆるロール/職種の「Agentic ∗」化
  • チームメンバー数の削減
  • チーム数の削減
• エンジニアに求められるスキルやコンピテンシー
  • 生成された成果物の品質に対するアカウンタビリティ
  • ラーニングアジリティ
  • プロンプト/コンテキストエンジニアリングスキル
  • フルスタック化によるエンドツーエンドでの開発スキル
  • 設計やアーキテクチャ技術
  • クラフトマンシップ
• 最後に
• 参考文献

開発ワークフローの変化

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

参考文献

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

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

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

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

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

• 参考にした主な文献
  • Spotify’s Failed #SquadGoals
  • Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds
  • ユニコーン企業のひみつ ― Spotifyで学んだソフトウェアづくりと働き
• 最小限の用語集
  • スクワッド
  • プロダクトオーナー
  • チャプター
  • チャプターリード
• 失敗の本質となる二つの問題点と「コンピテンシー」という言葉
• 問題1. 過度な自律性に対してチームがコンピテンシー不足
  • 車輪の再発明
  • 規模の経済の喪失
  • 流動性の喪失
  • 帰属意識の希薄化
  • 部分最適な意思決定
  • 対策1. Minimum Viable "Agility" の標準化
  • 対策2. チーム間連携方法の標準化
  • 対策3. 何が全体最適であるかの明示
  • 対策4. アカウンタビリティの所在の明示
• 問題2: 組織構造的にコンピテンシーリーダーが不在
  • トレードオフ不全
  • 相談先の重複と分散
  • 対策1. エンジニアリングチームを拡張したプロダクトチーム
• 最後に

参考にした主な文献

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

Spotify’s Failed #SquadGoals

www.jeremiahlee.com

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

ScalingAgile @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）” を作り上げることになる。参照できるテンプレートはなく、アジャイルプラクティスに関する知識や経験も乏しい。その結果、チームが本質を理解しないままアジャイルを実践し、大抵は「ウォーターフォールではない何か」にとどまる。

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

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

規模の経済の喪失

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

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

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

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

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

流動性の喪失

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

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

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

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

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

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

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

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

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 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マトリクスの例だ。

• 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

ソフトウェア開発の現場が日々感じている問題は、しばしば組織設計の不備を映し出す鏡である。

そうであるなら、現場で営まれる改善に向けた努力は “対症療法” にしかなり得ない。一時的に症状を緩和できても、しばらくすれば問題はぶり返す。現場はそれを再び抑えにかかる。これではまるで、終わりのないモグラたたきだ。

組織設計の改善による “原因療法” が必要なのだ。もちろん対症療法も必要ではある。しかし、根本原因を取り除かなければ、そこから生じる問題が現場を苦しめ、ソフトウェア開発の足かせであり続ける。それはビジネスの足かせでもある。

だから、組織設計に携わるマネージャーには、現場に現れる症状から組織設計上の問題を読み解く力が問われる。そして、現場のチームも巻き込んで、組織の欠陥修正や、組織のリファクタリング、リアーキテクティングに取り組むのだ。

• 参考資料
• 組織設計のひずみは現場に問題をもたらす
  • 例1: FEとBEを分ける体制がロジックを重複・分散させる
  • 例2: 従来型のままの組織の文化や価値観がスクラムを形骸化させる
• 現場を悩ませる主要な問題は三つに分けられる
• 従来型の組織が持つ文化・価値観が問題の解消を阻む
  • リソース効率には注目するが、フロー効率は意識されない
  • コミュニケーションは「多ければ多いほどよい」とされている
  • ソフトウェアの内部品質は見えない
• 組織設計がひずむ理由は四つに大別できる
• “気づきにくい” ので「組織設計アンチパターン」を活用する
• 組織設計はマネージャーとチームの協働で進める
• さいごに

参考資料

本稿は、@bufferingsさんによる記事「チームの問題の原因は外側にあることが多いよなぁ。「チームの力で組織を動かす」を読んだ。 - Mitsuyuki.Shiiba」で拙著から引用いただいた「組織設計のひずみによって生じた問題は現場だけで解決することはできない」をテーマにして書いた。こちらのブログ記事も参考いただきたい。

bufferings.hatenablog.com

引用元となった拙著は、2025年8月25日に発売されたこちら。

gihyo.jp

また最近、本書にちなんだ二つのイベントに登壇し、組織設計をテーマに発表した。本稿では、その登壇資料（下記二点）も用いながら、組織設計のひずみについて考えていく。

• 「モダンな現場と従来型の組織——そこに生じる "不整合" を解消してこそチームがパフォーマンスを発揮できる」Forkwell Library#104, 2025年8月25日
• 「現場が抱える様々な問題は “組織設計上” の問題によって生じていることがある」開発現場の課題から読み解く、組織設計の考え方 - Findy, 2025年8月27日

組織設計のひずみは現場に問題をもたらす

現場で生じる問題を、組織設計と結びつけて見る人は多くない。だが、それは確実に起きている。

例1: FEとBEを分ける体制がロジックを重複・分散させる

たとえば、バックエンド（BE）のロジックに変更を加えてテストしたら、なぜか変更前の挙動のままの箇所がある、なんて経験はないだろうか。原因を探ってみると、フロントエンド（FE）にも同じロジックがある。つまり、ロジックが重複し、保守性を低下させているのだ。

こうした症状は、FE開発とBE開発でチームを分けた体制で起こりやすい。設計を綿密にチーム間で議論するよりも、自分たちの手が届く範囲でやってしまった方が手っ取り早い。そういう意識が働く。時間に追われていればなおさらだ。これはコンウェイの法則の具体例でもある。

この体制には、単独チームでエンドツーエンドの機能開発ができないという欠点がある。新機能の開発は、FEだけ、あるいはBEだけで済むとは限らず、両方、またはデータベースまで含めて変更することも多い。

だから、チーム横断でプロジェクトを進めるしかない。その結果、チーム間の調整によるコミュニケーションコストがかさむ。けれど、そこにばかり時間を取られると、開発時間が奪われる。それを嫌って近道を選んだ結果が、ロジックの重複や分散につながるのだ。

例2: 従来型のままの組織の文化や価値観がスクラムを形骸化させる

他にも例はある。

ソフトウェア開発の現場は進化し続けている。それは、開発プロセスやデリバリー手法、アーキテクチャなど、多岐にわたる。昨今のコーディングにおける生成AIの活用がよい例だろう。

それでも、組織が従来のままだと、こうしたモダナイズは空回りしやすい。

その典型例が、開発だけでスクラムを回している状態だろう。企画・設計やテストは相変わらずフェーズ分断で進み、スプリントレビューにすら、当事者（企画、QA、運用など）が来ない。開発のリズムと組織全体のリズムが噛み合わない状態となるのだ。

背景には、職能別の完全分業と、大量生産の価値観が残っていることがある。

フェーズ間の引き継ぎを経るごとに情報は劣化し、開発側は企画側ほどドメインを理解できない。最適な設計やアーキテクチャの判断は鈍る。

さらに、PMによる中央集権的なオーケストレーションの下では、“自己管理型” の裁量はない。開発に求められるのは、期日までに、任されたタスクをきちんと終わらせることだ。「より速くより多く」に寄りがちで、アウトプットに意識が集中しがちとなる。価値検証のサイクルを高速化するという思想は失われ、アウトカムやインパクトは顧みられない。

そのうえ、開発だけがスクラム化しても、全体のリズムが一致していなければスプリントは簡単に崩される。たとえば、企画部門からの見積もり依頼や、PMからの突発タスクが割り込めば、開発時間は削られ、フローは途切れてしまう。

---

このようにして、組織設計のひずみが現場に生じさせる問題は様々にある。下記スライドは、組織設計のアンチパターンを踏んだ結果生じた問題を列挙したものだ。

もちろん、先述の二つの例や、後述するアンチパターンに当てはまっても、一概に悪い組織設計とは言えない。状況次第では最適解となることもある。この前提は踏まえておきたい。

現場を悩ませる主要な問題は三つに分けられる

組織設計のひずみの多くは、次の三種類の問題として現場に姿を現す。

1. フロー効率の低下
2. チーム境界を越えるコミュニケーションコストの増大
3. ソフトウェアの内部品質の悪化

現場に問題を生じさせる組織設計上の構造は、次の図のとおりだ。「組織構造」から順に、「バリューストリーム」「フロー」「コミュニケーション構造」「システム構造」へと問題が連鎖していく。その過程で、前節の三つの問題として現れる（逆方向の連鎖もあるが、詳細は登壇資料を見てほしい）。

つまり、組織設計の対象はこの図全体に及ぶ。組織をチーム分けしてメンバー構成を決めるだけではないということだ。

従来型の組織が持つ文化・価値観が問題の解消を阻む

そして、従来型の組織が持つ文化・価値観が、これらの問題の解消を阻み、事態をより深刻にしている。

リソース効率には注目するが、フロー効率は意識されない

組織の多くは、“フロー効率” ではなく “リソース効率” に目が行きがちだ。マネージャーの意識は、限りある人的リソースをいかに無駄なく効率的に使うかに向けられる。メンバー一人ひとりのスケジュールを隙間なく埋め尽くし、そのためにはプロジェクトを兼務させることも厭わない。

リソース効率を最大限に高めやすい体制が、「共有リソースプール」型の組織だ。この体制は、プロジェクトチーム制を採る組織によく馴染む。開発組織をリソースプールとして捉え、プロジェクト発足の都度、エンジニアをリソースとして貸し出す（アサインする）。そうして全員の稼働が100%を超えるまで、プロジェクトを並走させるのだ。

しかし、このようなリソース効率重視型の配置では、人の稼働は高まっても、仕事のフローはかえって遅くなる。

この論理は少しわかりづらいので、人気のコーヒーショップを思い浮かべてほしい。

行列ができるような人気店のスタッフは、みな大忙しだ。常に手を動かしている。つまり、彼らのリソース効率は高い状態だと言える。

一方で、行列に並ぶ客は、自分の番がなかなか回ってこないことに苛立つ。下手をすれば、一杯のコーヒーを買うために十分も二十分も待つことになる。これはフロー効率が悪い状況だ。客にとっては、スタッフが多少手を持て余しているくらいの方が、待ち時間がなく嬉しい。

この例では、コーヒーショップのスタッフが開発メンバーで、客の一人ひとりが機能開発案件を指している。開発メンバーのリソース効率が高いほど、機能開発のリードタイムが長くなるということだ。

しかし、リソース効率を高めようとするあまり、次々と仕事を詰め込んでしまう。つまり、チームのキャパを超えるほどに機能開発やプロジェクトを割り当ててしまうのだ。

その結果、大量の仕事は直列ではなく並列で処理せざるを得なくなる。マルチタスクである。そのため、本来は3日で終わる仕事でも、より長い期間を要してしまう。

さらに、プロダクト開発全体を見渡すと、チーム間での仕事の受け渡しのあちこちでフローが滞留していることにも気づく。けれど、部門ごとに完全分業している組織では、自部門内の仕事にしか関心が向かない。だから部分最適に陥りやすく、この問題に気づきにくいのだ。

これがフロー効率に関して、従来型組織で起こりがちな現実である。

コミュニケーションは「多ければ多いほどよい」とされている

コミュニケーションについては昔から「多ければ多いほどよい」とよく言われる。無論、複数人が一つの目的に向けて協働するために、コミュニケーションは欠かせない。しかし、「多ければ多いほどよい」という主張は、話を単純化しすぎている。

この標語が頭に染みついている状態では、物事を何でもかんでもコミュニケーションで解消しようとする。そうしてミーティングが乱立する。そこに手を入れてミーティングを減らそうとすれば、猛反発に遭うことすらある。

少し考えてみてほしい。コミュニケーションに時間を割けば、その分だけ実務に充てる時間が削られる。手を動かしたり考えたりする時間が失われる。その関係を概念的にグラフ化したものが下図だ。

とりわけチーム間のコミュニケーションは、互いのコンテキストをそろえる労力が要るためコストがいっそう高くなる。資料を準備したり、前提情報を説明したりといった活動が必要になるからだ。

現場メンバーの仕事のカレンダー上で予定が入っていない時間帯は “空き” ではない。実務に充てる時間である。したがって、コミュニケーションはメンバーの実務時間とのトレードオフであることを念頭に、設計しなければならない。

ソフトウェアの内部品質は見えない

ソフトウェアの内部品質は、エンジニアでなければ “見えない” からやっかいだ。見えないものは、ないのと同じである。ユーザー体験にも直接は影響しない。だから、内部品質を改善するために時間を割く必要性を感じにくい。

さらに、内部品質の悪さがビジネスにどれだけ影響を与えているか、誰も証明できない。実際、内部品質が悪いと言われながらも、開発は問題なく進んでいるように見えてしまう。であれば、改善のためにコストをかけるのはムダだと考えられてしまう。

これこそが、内部品質が抱える問題の根深さである。

しかも、こうした意見はエンジニア以外からだけ出るわけではない。エンジニアの中にも、内部品質を重視することに価値を感じていない人や、そもそも内部品質を適切に評価できない人は少なからず存在する。

結果として、内部品質上の問題は、組織の中での優先度を下げられてしまうのだ。

組織設計がひずむ理由は四つに大別できる

組織設計がひずむ理由は、主に四つに大別できる。

一つ目は、組織設計に関する知識や経験が単に不足しているために生じたケースだ。これが理由である場合、組織設計者は自ら設計した組織の品質問題に気づかない。そのため、いつまでたっても組織品質は改善されず、現場の苦労が続いていく。

二つ目は、妥協によって生じたケースだ。組織設計者はより適した設計に気づいているが、それを実現するための組織内コンセンサスが得られず、あきらめたものである。社内の政治的力学によるものかもしれない。単にリスクを甘く評価している可能性もある。なんにせよ、今後もひずみが積み重なっていくだろう。

三つ目は、リスクを承知でその組織設計を採用する意思決定をしたケースだ。組織設計者は、この設計によって現場に問題が及ぶことは理解している。しかし、現時点ではそれがより良い選択だと判断した。このタイプのひずみは、いずれ解消されていくだろう。

四つ目は、組織運営を通じて得た学びにより、現在の組織設計が陳腐化したケースだ。設計当初は最適だと考えていたが、よりよい設計があることに気づいた。組織を取り巻く環境は不確実で予測可能性が低い。だからこそ、組織設計も探索的になる。このケースは、それを体現している。

組織設計のひずみは、技術的負債とよく似ている。とても見えにくい。だから気づきにくいのだが、ひずみは確実に現場の足かせとなり、開発生産性の妨げとなる。これは技術的負債と同じ特徴だ。

実際、上記四つの類型は、マーティン・ファウラーによる「技術的負債の四象限」に倣ったものだ。左下を第一象限として時計回りに各象限を対応させてみると、上の四つがうまく当てはまることに気づくはずだ。

だからこそ、組織設計にもリファクタリングやリアーキテクティングが必要であり、ときには大規模に見直す決断が要るのだ。

“気づきにくい” ので「組織設計アンチパターン」を活用する

先述のとおり、組織設計のひずみは気づきにくいものだ。このようなときには、アンチパターンが役立つ。自組織の状態をアンチパターンの症状とパターンマッチしてみる。当てはまれば、ひずみが生じている可能性が高い。

詳細は割愛するが、以下は、書籍『チームの力で組織を動かす』に掲載した組織設計アンチパターンの数々だ（各登壇資料内でも、いくつか紹介している）。

組織設計はマネージャーとチームの協働で進める

マネージャーが担う組織設計という活動は、「設計」と言いつつも、「アーキテクティング」に近い。ITアーキテクトがシステム全体での責務分配やコンポーネント間の関係性を描くように、組織アーキテクトたるマネージャーも、チームへの責務分配やチーム間の関係性を描くのが主な役割だ。

このことから、組織設計は、“アーキテクチャ” と “設計” に分けて考えるべきだと気づく。チーム内部の設計や実装は、現場のチームと協力して作り上げたり、チームに任せればよい。こうすることで、現場のフィードバックを取り入れた、現場感のある組織を作り上げられる。

このように見ていくと、組織運営はソフトウェアエンジニアリングに似ていると実感できる。組織全体をソフトウェアシステムと見なし、それを構成するチームをコンポーネントと見立てるのだ。

その結果、チームの凝集度を高め、チーム間の結合度を下げることで、組織全体を疎結合に保つことの重要性も理解できる。それにより、書籍『LeanとDevOpsの科学』でハイパフォーマンスな組織の特徴とされる「チームとアーキテクチャが疎結合」な状態に近づけるはずだ。

さいごに

組織設計は、継続的なものだ。一度作ったらそれで終わりではない。不確実性が高く、流動的で予測可能性の低い環境の中で探索的に改善し、変化に適応し続けていくものである。

そこで注目すべきが、三つの問題――フロー効率、チーム境界を越えるコミュニケーションコスト、ソフトウェアの内部品質――である。組織設計のひずみは、必ずここに現れる。そして、そのひずみは、アンチパターンとのパターンマッチによって気づくことができる。

組織設計はマネージャーだけの仕事ではない。組織アーキテクトたるマネージャー自らがチームを巻き込み、あるいはチーム自身が積極的に関わって、協働で進めるものだ。そうすることで、現場感のある組織を作り上げることができる。

問題に対する現場での対症療法と、マネージャーとチームが協働で組織設計を見直す原因療法、この二つの側面から組織品質を改善し続けることが、組織設計のひずみを削減・解消する手立てである。

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

gihyo.jp

書籍に関する紹介記事は、下記noteにまとめた。

note.com

また、今回参考にした登壇資料は、下記二つのイベントで使用したものだ。各リンクからアーカイブ動画も視聴できるので、参考にしてほしい（それぞれ、Forkwellさん、Findyさんのアカウントが必要）。

forkwell.connpass.com

findy.connpass.com

それぞれの登壇資料はこちら。

speakerdeck.com

speakerdeck.com

ソフトウェア開発の成果は、エンジニアの特性に大きく左右される。たとえば “コードを理解する能力” がその代表例だ。

こうした特性は、作業負荷や認知負荷に直結し、開発生産性に影響を与える。この観点からの評価も、成果を正しく捉えるうえで欠かせない。

もし、理解しづらいコードを書いてしまったら、現在および将来の開発生産性が損なわれる。技術的負債とは、そうした “開発生産性の低下” を「利息を支払う」ことにたとえた概念だ。

本稿は、技術的負債を10のカテゴリに整理したGoogleの文献を参考にしつつ、技術的負債との付き合い方を考える。

• 技術的負債を10のカテゴリで捉える
  • ≫ 移行が必要なシステム
  • ≫ 不十分なドキュメント
  • ≫ 不十分なテスト
  • ≫ 低品質なコード
  • ≫ デッドコード/放棄されたコード
  • ≫ 劣化したコード
  • ≫ 専門知識不足のチーム
  • ≫ 不安定な依存関係
  • ≫ 失敗した移行
  • ≫ 洗練されていないリリースプロセス
• カテゴリを使った問題の可視化からはじめる
• “人間中心” と “AI中心” が共存するソフトウェアエンジニアリングへ

技術的負債を10のカテゴリで捉える

エンジニアは、何を “技術的負債” だと感じているのだろうか。

Googleは、社内調査を通して、それを10のカテゴリに分類した。その結果は、2023年4月に発表された次の文献にまとめられている。

参考文献: Ciera Jaspan and Collin Green, "Defining, Measuring, and Managing Technical Debt," inIEEE Software, vol. 40, no. 3, pp. 15-19, May-June 2023, doi: 10.1109/MS.2023.3242137.

こうしたカテゴリがあれば、チームや組織が抱える負債を可視化しやすくなり、管理も容易になる。どんなカテゴリに問題が集中しているのかが分かれば、チームや組織が抱える課題も鮮明になるだろう。

このように、技術的負債を分類する枠組みは、それ自体が実践的なヒントとなりうる。

注意したいのは、負債とは、実際に「利息を支払った」あるいは「利息を支払う」対象である点だ。どれだけコードの品質が低くても、そのコードを誰も見ないなら、負債とは言えない。実際に、コードを読むことや変更することに苦労してはじめて “利息の支払い” が生じ、そこが負債となる。

Google社内の調査でも、技術的負債のカテゴリ化にあたって、実際に「生産性の妨げとなった」ものをエンジニアに尋ねている。つまり、「どんな負債に遭遇したか」ではなく、“実際に利息を支払った対象” に焦点を当てている。

以降に挙げる10個が、そこで明らかになったカテゴリだ。

≫ 移行が必要なシステム

システム移行や技術スタックの更新に多くのリソースを割かれ、通常の開発業務が圧迫されている状態を指す。文献内では、たとえば、「スケーラビリティへの対応」「規制変更などへの対応」「依存関係の整理」「非推奨技術からの脱却」といった理由での移行が挙げられている。

Googleでは、このカテゴリが最も深刻な技術的負債とされている。

その背景には、同社がモノリシックなリポジトリを採用しているという特殊事情がある。リポジトリ全体にまたがる大規模な移行が、頻繁に実行されるためだ。

ただし、この問題は、モノリシックリポジトリを採用していない組織でも起こり得る。複数の開発組織を抱える企業では、共通で利用しているプラットフォームやライブラリの更新・移行への対応があるからだ。また、社内の開発ルール変更に対応する必要もあるだろう。

≫ 不十分なドキュメント

プロジェクトやAPIに関するドキュメントが存在しない、あるいは不完全な状態を指す。

必要な情報に辿り着けない状況も、これに含まれる。たとえば、社内Wikiが適切にメンテナンスされていなければ、新旧のドキュメントが混在して、どれが信頼できる情報なのか判断がつかない。また、検索しても、適切なドキュメントが見つからず、作業が滞ることもある。

≫ 不十分なテスト

テストの品質やカバレッジが低い状態を指す。テストケースが漏れていたり、テストデータが不適切な状況も含まれる。

結果として、事前に防げたかもしれない不具合が見過ごされ、余計な手戻りが発生しやすくなる。たとえば、埋め込んでしまった脆弱性の対応に追われたり、デプロイのロールバックを余儀なくされたりする。さらに、実行のたびに結果が変わるflakyなテストに悩まされることだってある。

≫ 低品質なコード

プロジェクトが生み出したアーキテクチャや設計、コードの品質が低く、主に保守性が損なわれている状態を指す。技術的負債という言葉から、真っ先に思い浮かべるのは、このカテゴリだろう。

こうした問題は、現在および将来の開発生産性の妨げになる。エンジニアの誰もが知る通り、コードを理解することに苦労したり、変更・拡張することに対する足かせとなるからだ。

文献内では、その原因として、「開発を急ぐこと」や「デモ版/プロトタイプ版の影響」が挙げられている。後者は、検証目的で作られた低品質なアーキテクチャや設計、コードが、プロダクション版に引き継がれてしまう状況を指しているのだろう。

≫ デッドコード/放棄されたコード

使われていないコードが削除されずに残されている状態を指す。

これはコード単位にとどまらず、機能やプロジェクト単位でも起こり得る。置き換えや廃止が行われたにも関わらず、古いコードが残されたままだと、エンジニアにとってはノイズとなり、認知負荷を高める。

プロジェクト単位で残されたコードが、なぜ邪魔になるのか、分かりにくいかもしれない。廃止されたプロジェクトのリポジトリなど、普段は誰も見ないからだ。そうであれば、邪魔になることなどなさそうに思える。

しかし、使われないリポジトリがコード管理システムに残り続けると、コード検索のノイズになってしまう。また、それが本当に使われていないのか判別できず、エンジニアが無駄に時間を費やすこともある。特に、Googleのようなモノリシックリポジトリなら、なおさらだろう。

≫ 劣化したコード

時間の経過とともに、品質が低下していったコードを指す。先述の「低品質なコード」とは異なり、当初は問題がなかったにもかかわらず、後から技術的負債へと変化していったものだ。

その背景には、大きく二つの原因がある。

その一つは、追加開発を繰り返すことだ。初期リリース時には想定していなかった機能追加や仕様変更を加えるうちに、内部構造には歪みが生じていく。場当たり的な修正も積み重なる。TODOやFIXMEが大量に残されたコードは、そうした兆候の一つだ。結果として、構造が複雑化し、柔軟性も失われていく。

もう一つの原因は、採用している技術や設計が、相対的に古くなることだ。依存関係にある外部ライブラリがEOLを迎えるケースは、その典型例だろう。

≫ 専門知識不足のチーム

チームが、コードベースやプロジェクトを適切に管理・開発し続けられない状態を指す。

たとえば、システムを引き継いだものの、十分に理解できないまま保守・運用するケースが挙げられる。原因はさまざまだ。引き継ぎが不十分だったのかもしれないし、メンバーの離脱によって属人化したコードが扱えなくなったのかもしれない。あるいは単に、人員が足りていないのかもしれない。

≫ 不安定な依存関係

依存しているライブラリやフレームワーク、外部サービスの動作が不安定だったり、頻繁に更新されたりする状態を指す。仕様の不整合が起きるケースも含まれる。

たとえば、依存サービスの動作が不安定だと、自チームのシステムがトラブルを起こし、緊急対応を余儀なくされることがある。バグの多いライブラリを使ってしまった場合も同様だ。

また、頻繁に更新されるライブラリを使っていると、その変化に追随するためのメンテナンスコストがかかる。旧バージョンのままでは、いずれサポートが終了するかもしれず、対応を迫られることになる。

更新に追いついても、仕様変更によって思わぬ不具合が生じ、結果としてロールバックせざるを得ないこともあるだろう。

≫ 失敗した移行

古いシステムから新しいシステムへの移行が完了しない状態を指す。ここでの「新旧」は、まったく異なる別システムの場合もあれば、同じコードベースの旧バージョンと新バージョンの場合もある。

移行が中途半端なままだと、複数のシステムやバージョンを同時にメンテナンスしなければならず、人的リソースを大きく消耗する。加えて、システム全体の複雑性も増し、保守や変更のハードルが上がっていく。こうした負担が、エンジニアの悩みの種になる。

≫ 洗練されていないリリースプロセス

本番環境へのデプロイ手順が複雑であったり、モニタリング環境が整備されていない状態を指す。これは、Ops領域に関する技術的負債である。

たとえば、継続的デリバリー/デプロイ（continuous delivery / continuous deployment）が整備されていなければ、本番反映のたびに手間と時間を要する。特に、頻繁なリリースが求められる現場では、その負担は致命的な問題になるだろう。

また、運用の自動化が進んでおらず、トイル（toil）にまみれているなら、日常的なルーチン作業に時間を奪われやすい。品質も安定しにくく、手戻りリスクも高まる。

こうした未整備な状態は、トラブル発生時の迅速な復旧を難しくし、信頼性の低下につながる恐れがある。

カテゴリを使った問題の可視化からはじめる

技術的負債への取り組みは、まず「何が問題か」を可視化するところから始まる。定量的であれ、定性的であれ、可視化できれば、問題の認識を皆で一致させやすくなる。

Googleの10のカテゴリは、その可視化に役立つ。自分たちの組織やチームでは、どのカテゴリに属する負債に悩まされているのか。たとえば、アンケートなどを通じて現場の声を集めれば、注力すべきカテゴリが見えてくる。そのうえで、何が具体的な障害になっているのかを深掘りできるだろう。

たとえば、「不十分なドキュメント」が一番の問題だと特定されたとしよう。それはチーム内のドキュメントの問題なのか、あるいは利用している社内プラットフォーム側の問題なのか。ドキュメントが不足しているのか、存在していても情報が埋もれて辿り着けないのか。

こうした問いを、組織やチームで丁寧に議論できるようになる。

対策には、目の前の問題に対処する “対処療法” 的な観点と、その原因を根本から見直す “原因療法” 的な観点の両方が必要だ。たとえば、ドキュメントが古いのであれば、まずはそれを更新する。そして、なぜ古いままで放置されるのかという根本原因にも向き合う。それは、ドキュメントの更新がプロセスに組み込まれていないといったことかもしれない。

さらに、対策を進める中でチームが得た知見は、組織全体で標準化していくとよい。チーム内にとどまっていたローカルナレッジを、組織全体で再利用可能なグローバルナレッジへと展開するのだ。

文献からは、Google社内における技術的負債の管理方法が、次の4つのステップに整理できる。

1. 問題の可視化
2. 優先順位の明確化と計画化
3. 根本原因の特定と対応
4. 組織全体での標準化

これはまさに、個々のチームの取り組みを、組織全体の学びへと昇華させるプロセスである。

“人間中心” と “AI中心” が共存するソフトウェアエンジニアリングへ

人間中心設計（human-centered design, HCD）という言葉がある。ユーザーの特性を深く理解し、それに基づいてプロダクトやサービスをデザインするアプローチだ。

この考え方は、ユーザーに向けた外部品質だけでなく、エンジニアにとっての内部品質にも応用できる。ソフトウェアプロダクトを扱うならば、どちらの視点も欠かせない。

これまでのソフトウェアエンジニアリングは、人の営みであるという点で、その観点は “人間中心” である。だからこそ、エンジニアが扱いやすいコード、設計、アーキテクチャ、環境であって欲しい。それが欠ければ、開発生産性の低下を招く。

端的に言えば、エンジニアが苦しむ状況は、開発生産性の低下と直結しているのだ。

ウォード・カニンガムが作り出した「技術的負債」という概念は、まさに “人間中心” であり、エンジニアの認知的な負荷を強調したものだ。Googleの文献内でも、“人間中心” という言葉が使われている。

私は本稿の冒頭で、次のように述べた。

ソフトウェア開発の成果は、エンジニアの特性に大きく左右される。たとえば “コードを理解する能力” は、その代表的な要素だろう。エンジニアの作業負荷や認知負荷の視点での評価も必要だということだ。

しかし、生成AIの登場によって、この状況は変わりつつある。少なくとも、エンジニアが感じる認知負荷は、徐々に緩和され始めている。

特に、AIによるコード生成の精度は目覚ましく進化しており、エンジニアが直接コードを書く時間は確実に減ってきている。これにより、認知負荷の一部がAIによって肩代わりされるようになってきた。

その結果、AIの出力をより高品質にするために、環境整備への関心も高まっている。たとえば、リポジトリ内にドキュメントを整備し、AIが参照できる情報を増やす取り組みが進んでいる現場もある。

こうした動きは、“AI中心” のソフトウェアエンジニアリングの萌芽と言える。私たちは今、長らく続いた “人間中心” の時代から、“人間中心” と “AI中心” が共存するフェーズに入ったのだ。そして今後、その重心は徐々にAI側へと移っていくだろう。

だが、技術的負債の10のカテゴリを眺めると、現在のAIが得意とする領域と、そうでない領域があると分かる。まだまだ人間が介在しなければならない箇所も多い。

たとえば、「低品質なコード」や「劣化したコード」もそうだ。コード生成は、AIが得意とする領域である。コードを理解するのも、書くのもAIであるなら、品質はさほど問題にならない。そんな期待もあるだろう。だが、現実はそう単純ではない。

いまのところ、すべてのコードをAIが生成できるわけではない。人間がコードを読み、修正する場面は依然として存在する。特に、本番トラブルのような緊急時には、人がコードを正しく理解していなければ迅速な対応は難しい。

また、AIが生成したコードの品質が十分でないケースも珍しくない。それ自体が、エンジニアの新たな認知負荷となってしまうのだ。

いつかは、すべてをAIが担う時代が来るかもしれない。だが、少なくとも今はまだ、その時ではない。

人間中心とAI中心の共存・両立を目指すのが、今のところの現実解なのだろう。