2025年から2026年にかけての年末年始は、YouTubeで「AI Engineer」チャンネルにどっぷり浸っていた。ここにはAIエンジニアリングの最前線を走るカンファレンスの登壇動画が豊富にアーカイブされている。その中から、過去半年以内に公開されたものを優先的に漁り、最新情報を貪った。

数多くの登壇の中でも特に興味深かったのが、「コードベースの特性がAI導入効果に与える影響」についての議論だ。モノリポかマルチリポ（ポリリポ）かといった分散度合い、そして複雑性や規模が、AIによる生産性向上をいかに阻害、あるいは促進するのか。

本稿では、そこから得た洞察を整理し、コードベースとAI導入効果の関係について、深く掘り下げてみたい。

---

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

open.spotify.com

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

• リポジトリの分散度合い（モノリポとマルチリポ）
  • 【調査結果】分散度が高まるほどAI導入効果は減衰する
  • 【洞察】リポジトリの境界はAIにとってのコンテキストの壁である
  • 【戦略】境界の妥当性検証と戦略的集約の検討をはじめる
• コードベースの状態（グリーンフィールド/ブラウンフィールドと低複雑度/高複雑度）
  • 【調査結果】ブラウンフィールドかつ複雑なタスクはAIとの相性が悪い
  • 【洞察】AIは2種類の複雑性を区別できない
  • 【戦略】「Easyボタン」を捨て、開発ワークフローを選択的に切り替える
• コードベースの規模
  • 【調査結果】規模が大きくなるほどAI導入効果は低減する
  • 【洞察】物理的な量そのものがAIの推論精度を汚染する
  • 【戦略】効果的なコンテキストエンジニアリングでスマートゾーンを維持する
• さいごに: 「人間にとって良い環境は、AIにとっても良い」
• 参考文献

リポジトリの分散度合い（モノリポとマルチリポ）

AIコーディングエージェントの普及に伴い、改めてモノリポの優位性が注目されている。その理由は、全ソースコードが一箇所に集約されている方が、AIにとってコンテキストの断絶が起きにくく、生成物の精度が向上しやすいからである。各モデルが有するコンテキストウィンドウの拡大も、追い風になっているのだろう。

もともとリポジトリ戦略は、ソフトウェアアーキテクチャや組織構造と密接な関係にある。

シンプルなモノリスから、FEとBEの分離、そしてクラウド登場以降に進んだマイクロサービスを始めとする分散アーキテクチャへ。その過程で、リポジトリも分割統治──マルチリポ化が進んだ。

複数チームでのソフトウェア開発では、何らかの境界でソフトウェアをコンポーネント分割し、マルチリポによるチーム単位での分割統治を選択する利点は大いにあった。

しかし、AIエージェントの登場がこの前提を揺るがしている。単なるコード補完の域を超え、リポジトリ全体を俯瞰して複雑なタスクを遂行するエージェントにとって、マルチリポによる物理的な境界は「コンテキストの壁」として機能してしまう。

モノリポの方がAI導入効果が高まるのであれば、リポジトリ戦略を転換すべきかもしれない──。マルチリポで開発を続けてきた組織にとっても、そんな考えがふと頭によぎる。

とは言え、リポジトリの移行は低コストではない。単なる「感覚」ではなく、客観的なインパクトを知る必要がある。

そもそもモノリポかマルチリポかの選択は、従来からトレードオフの関係にあった*1。そこに新たな変数として「AI導入効果」が加わった今、その影響をどこまで考慮すべきか。この問いに対し、JellyfishがOpenAIと提携して行った調査結果を紹介していたのが、Nick Arcolanoの登壇である*2。

【調査結果】分散度が高まるほどAI導入効果は減衰する

Arcolanoが解説した調査では、リポジトリの分散度合いが、AI導入によるPR数増加にどの程度の影響を与えるかに焦点をあてている。*3

分散度合いは、「集約型（centralized）」から「バランス型（balanced）」「分散型（distributed）」「高度分散型（highly distributed）」の4段階に分けられている。そのうえで、各セグメントにおいて、AI導入率が未導入（0%）から完全導入（100%）に移行することでPR数が何倍になるかの増加率を数値化している。

結果は、次の通りとなった。

分散度合い	1人あたりのPR数	増加率
集約型	2.7	3.9倍
バランス型	3.1	4.1倍
分散型	3.9	2.1倍
高度分散型	5.3	-

出典: Nick Arcolano（Jellyfish）「What Data from 20m Pull Requests Reveal About AI Transformation」AI Engineer, 2025年11月25日, 14:32~ （動画内のグラフをもとに筆者が作成）

まず、表を見て驚くのは、分散度が高いほどPR数が多くなっている点だが、「マルチリポの方が生産性が高い」ということではない。これは、一機能の開発で複数のリポジトリに変更が波及しているという、マルチリポの構造的問題に過ぎない。

特筆すべきは、AI導入による「増加率」の顕著な差だ。集約型やバランス型では約4倍という劇的な効果が得られているのに対し、分散型ではその半分にとどまる。さらに「高度分散型」に至っては、AI導入とPR数の変化に相関が見られず、むしろ微減の傾向さえ確認された。

もちろん、PR数の増加がそのまま生産性の向上を意味するわけではない。スタンフォードのYegor Denisov-Blanchの示す、ある企業のcommitベースのデータでは、AI導入によって「手戻り（rework）」が増加する傾向も見て取れる*4。

しかし、目安にはなる。先述のcommitベースのデータからも、AI導入以降、機能追加（added）が増加傾向を示しているからだ。

出典: Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 9:09~ （動画内のグラフをもとに筆者が作成）

【洞察】リポジトリの境界はAIにとってのコンテキストの壁である

Arcolanoは、AIコーディングエージェントが分散型のリポジトリ戦略を得意としない理由を、リポジトリ間の関係性が記述されていないことにある、と指摘している*5。

シニアエンジニアの脳内にのみ存在するリポジトリの関係図に、AIはアクセスできない。それがコンテキストの欠落となって、ハルシネーションを誘発し、生成物の品質を低下させる。

AI時代におけるモノリポの真価は、その圧倒的な「視野」と「操作範囲」の広さにある。コードが地続きのコンテキストとして存在することで、AIは全体最適に基づいた分析を行い、コンポーネントを横断するアトミックな変更を一括で完結できる。*6。

対照的に、マルチリポ構成はAIに「情報の断片」を用いた個別作業を強いる。リポジトリ間の整合性を保つための調整コストが、AI本来のスピードを相殺してしまうのだ。

この構図は、人間にとっても同様だ。同時に扱うリポジトリが増えるほど開発は煩雑になる。コンテキストウィンドウならぬ、脳内のワーキングメモリが飽和し、認知負荷が増大する。

そもそも、単一の機能改修で常に複数リポジトリへの変更を強いられるなら、“チームがソフトウェアを分割統治している” 状態とは言い難い。マルチリポの利点を活かせていないのだ。

それはおそらく、ソフトウェアアーキテクチャの問題だろう。リポジトリ間の凝集度が低く、結合度が極めて高いという欠陥を示唆している可能性がある。

もちろん、明確に技術スタックが異なるようなFEとBEを境界とした分散なら分かる。しかし、たとえば複数のBEシステムが複雑に絡み合っているなら問題だ。

結局、AI導入効果が伸び悩む背景には、AI以前の問題である「旧来の設計不備」が横たわっていることも多い。

【戦略】境界の妥当性検証と戦略的集約の検討をはじめる

マルチリポ環境でAI導入効果を最大化するためにまず着手すべきは、“リポジトリ境界の妥当性”、延（ひ）いては “コンポーネント境界の妥当性” の検証である。

もし単一の機能改修において、定常的にリポジトリを跨ぐ変更が発生しているなら、それは分割の単位が不適切である可能性が高い。それなら、リアーキテクチャを検討する。セットで変更されることが多いリポジトリなら、単純に、統合してしまってもよい。

リポジトリ移行やリアーキテクチャは時間と労力を要する仕事だが、長い目で見れば、AIの文脈理解を助けるだけでなく、保守コストの削減にも直結する。

一方で、ソフトウェアアーキテクチャやリポジトリ分割は適切でも、複数のリポジトリを横断して変更しなければならないこともある。ドメイン駆動設計で言う「境界付けられたコンテキスト」をまたいだ機能開発など、ざらにあるからだ。

このようなケースが頻発するのであれば、リポジトリの集約も検討の余地がある。

ただし、あまりに巨大なモノリポは、ビルド・テストの遅延やCI/CDの複雑化を伴う。そのトレードオフを踏まえたうえでの判断になるだろう。

選択肢の一つとして、ハイブリッドなリポジトリ戦略もある*7。コアなものは一つのリポジトリに集め、そうでないものはマルチリポで管理するアプローチだ。この「戦略的集約」こそが、AIの視野を確保しつつ、システムの肥大化を制御する現実的な解となるのかもしれない。

コードベースの状態（グリーンフィールド/ブラウンフィールドと低複雑度/高複雑度）

エンジニアの日常は、見通しの悪い絡み合ったコードとの奮闘に多くの時間が費やされる。新規にソフトウェアを開発するプロジェクトより、既存ソフトウェアの保守・拡張にあたることが多いからだ。

追加開発を長年繰り返してきたコードベースは、時代遅れなコードや複雑な依存関係が堆積し、それが開発の自由度を奪う。タスクの難易度が高まるほど、この制約は足かせとして重くのしかかる。

こうした開発環境の差異を、建築業の用語を借りて「グリーンフィールド」と「ブラウンフィールド」というメタファーで表現することがある。

グリーンフィールドとは汚染されていない未開発な土地を指す。再開発または再利用しようとしている、既存汚染物質を伴う用地のことはブラウンフィールドと呼ばれる。

（引用: Neal Ford, Rebecca Parsons, Patrick Kua 著／島田 浩二 翻訳『進化的アーキテクチャ ─絶え間ない変化を支える』2018年, オライリー・ジャパン, 6.2）

ソフトウェア開発においては、新規にソフトウェアを開発するプロジェクトをグリーンフィールド、既存のソフトウェアを扱うプロジェクトをブラウンフィールドと呼ぶ。

引用文内での「汚染」という言葉は、既存ソフトウェアに蓄積された “時代遅れなコード” や “複雑な依存関係” といった、エンジニアリング活動の足かせを象徴している。つまり、既存ソフトウェアを扱うプロジェクトは、開発生産性が低くなりがちだと古くから認識されていた。

AI時代において、ブラウンフィールドのこの問題は打開されたのだろうか。

【調査結果】ブラウンフィールドかつ複雑なタスクはAIとの相性が悪い

スタンフォードのYegor Denisov-Blanchは、「プロジェクトの成熟度（project maturity）」と「タスクの複雑性（task complexity）」の組み合わせの4象限で評価した結果を紹介していた*8。「プロジェクトの成熟度」は、グリーンフィールドかブラウンフィールドで分類されている。

出典: Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 13:28~ （動画内の図をもとに筆者が作成）

データが示す傾向は明白だ。AI導入による恩恵は、グリーンフィールドかつ低複雑性のタスクで最大化される一方、ブラウンフィールドかつ高複雑性の条件下では著しく減衰する。

なお、ここで言う生産性とは、コード行数やcommit数、PR数といった単純な指標ではない。独自のモデルを用ったcommitベースでのコード評価によって、バグによる手戻りなどの変更が取り除かれた結果が用いられている。*9

【洞察】AIは2種類の複雑性を区別できない

Denisov-Blanchは調査結果に対し「根本的な原因は不明」としているが、AIを駆使する多くの開発者にとっては納得感ある結果と映ったはずだ。

AIによるコード生成において、タスクの複雑性が増せば実行時間は長迷するだけでなく、成果物の品質低下で手戻りも生じる。これは日常的にAIを活用する者なら誰もが抱く肌感覚だろう。

特にブラウンフィールドのコードベースにおいては、必然的に内包される「本質的複雑性」に加え、過去の成り行きで積み重なった「偶有的複雑性」が混在する。この二重の複雑性がタスクの難易度を高め、AIのパフォーマンスを阻害する主因ではないか。

ソフトウェアには、解くべき課題に由来する「本質的複雑性（essential complexity）」と、レガシーな設計や場当たり的な回避策による「偶有的複雑性（accidental complexity）」が内包されている*10。後者はしばしば技術的負債と化す。

結局のところ、コードベースの複雑性に起因するのではないか、というのが私の見立てだ。もちろん、ブランフィールドのコードベースの方が規模が大きいかもしれず、それが一因であることも考えられる。それは、後述する別の議論で扱うことにしよう。

先述の通り、歴史の長いプロジェクトほど内部構造が複雑化しやすい。異なる機能間のロジックが明確に分離されておらず、絡み合い、本来あるべき境界線が消失している。

この複雑な依存関係を解きほぐすのは人間にとっても困難だが、それはAIにとっても同様だ。むしろ、開発者が持つ暗黙知にアクセスできないAIが介入することで、構造をさらに悪化させるリスクさえ内包している。

NetflixのJake Nationsによれば、AIは、二種類の複雑性──本質的複雑性と偶有的複雑性──を区別しない。*11

混在するこれら二つの複雑性を分離・整理するには、開発の背景、歴史的経緯、ドメイン知識に基づく高度な経験則が不可欠となる。だが、コンテキストが不足したAIには、そのような分離は行えない。ロジックも技術的負債も、単なる “既存コードの一部” として等価に認識されるだけだ。

結果、過去の奇妙なワークアラウンドやレガシーな設計思想の上に、AIが生成したコードがさらに塗り重ねられる。そうしてコードベースが抱える偶有的複雑性はさらに悪化する。

こうしてAI導入による速度的メリットは、肥大化する複雑性と手戻りのコストによって容易に相殺されてしまう。では、この「AIが複雑性を増幅させる」という不可避な停滞を前に、どのような選択をすべきなのだろうか。

【戦略】「Easyボタン」を捨て、開発ワークフローを選択的に切り替える

「期待する動作さえすれば良し」と振り切るのであれば、少なくとも内部品質の手直しコストを削減できるが、それで本当に良いのだろうか。これは従来の言葉で言えば、「『クイック＆ダーティ』を選択してスピードを優先し、品質を犠牲にするのか」という古典的な問いである。

だが、AIによって開発が加速した世界において、この選択はかつてないほど深刻な状況を招く。Capital OneのMax Kanat-Alexanderが指摘するように、質の低いPR（bad rubber stamp PRs）を量産し、形骸化したレビューを繰り返せば、コードベースは複雑化の一途を辿る悪循環に陥る*12。その悪化スピードは、これまでの比ではない。

Nationsは、AIによって助長されたこのクイック＆ダーティな選択肢を「究極の “Easy” ボタン（ultimate easy button）」と呼んだ。

ここでいう「Easy」とは、Rich Hickeyが提唱した「Simple」と対比される概念だ*13。端的に言えばクイック&ダーティを指す。目先のスピードと引き換えに「後回しにされた複雑性」を受け入れるトレードオフだ。従来で言えば、StackOverflowからの安易なコピペがその典型例と言える。

対する「Simple」は、「Complex（複雑）」の対極にあり、要素が絡み合わず、保守性の高い構造を指す。これは設計や実装に対する深い洞察と、熟慮の末にのみ到達できる境地である。

では、安易な「Easyボタン」に逃げるのではなく、AIを駆使して「Simple」をいかに実現すべきか──。

鍵となるのは、複雑なタスクにおいて、通常のワークフローから、より「コンテキストエンジニアリング」に重心を移したアプローチへと切り替えることだ。

通常のワークフローに欠けているのは、変更対象となるコードベースの綿密な調査と、そこから導き出される詳細な実装計画である。これらを抜きにして、いきなりAIにコード生成を命じたところで、到底満足な結果は得られない。

このアプローチは、AIにアドホックな指示を出して実装を継ぎはぎしていく「最も素朴な手法（most naive way）」*14とはパラダイムが異なる。目指すべきは「正確なコードの生成」そのものではなく、それを可能にする「精度の高い実装計画」をいかに構築するかという、AIとの協働のあり方だ。

Nationsもそうであるが、HumanLayerのDex Horthyは、その有望な手法としてRPI（Research, Plan, Implement）を詳述している*15*16。これはDenisov-Blanchの調査結果も踏まえ、「ブラウンフィールドにおける複雑なタスクを効果的に実行するためのコンテキストエンジニアリング」として位置づけられる。

RPI以外にも、簡易にやるならAIコーディングツールの「PLANモード」の活用もそうだろう。また、仕様の詳細化まで含めるなら「SDD（スペック駆動開発）」も同様の志向を持つと言える（※ただし、Horthyは一部のSDDツールに対しては否定的な見解を示している*17）。

コードベースの規模

複雑化と並び、規模の膨張もまた、業務システムやWebサービスのブラウンフィールドプロジェクトにとって無視できない障壁となる。「リーマンの法則（Lehman's laws of software evolution）*18」が、これを的確に言い表している。

• 複雑性の増大（Increasing complexity）:
  • 継続的に変更されるソフトウェアは、リファクタリング等の明示的な改善を行わない限り、内部の構造的複雑性が増大する。
• 継続的な成長（Continuing growth）:
  • ソフトウェアは、ユーザーの満足度を維持するため、継続的に機能を拡張し続けなければならない。

「継続的な成長」による継続的な機能拡張の結果は、それらの累積に伴うコードベース規模の巨大化である。特にAIによって開発が高速化された現代では、このサイクルまでもが加速し、コードの膨張スピードはかつての比ではない。

ここで懸念すべきは、「コードベースの規模そのものが、AI導入効果を減衰させる変数になり得るか」という点だ。

【調査結果】規模が大きくなるほどAI導入効果は低減する

Denisov-Blanchは、コードベースの規模が拡大するほど、AI導入による生産性向上の恩恵が目減りするというグラフを提示している*19。これは厳密な実証データのプロットではなく、研究チームが数多くの事例を観測する中で導き出した、理論的な傾向を視覚化したものである。

出典: Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 15:35~ （動画内のグラフをもとに筆者が作成）

提示されたグラフでは、コードベースの規模が大きくなるにつれ、AIの寄与率が急激に減衰していく曲線が描かれている。このグラフは、縦軸に「AIによる生産性向上の推定効果」、横軸にコードベースサイズ（1K LOCから10M LOCまでの対数スケール）を取る。

現実のプロジェクトに目を向けると、この減衰は決して無視できない。業務システムやWebサービスのブラウンフィールドプロジェクトが扱うコードベースが、1-2K LOCということは稀だろう。ある調査によれば、一般的なソフトウェア開発におけるコード行数の中央値は31.8K LOC、75パーセンタイル値は96.1K LOCに達する*20。

この統計を先の曲線に当てはめるならば、現代のブラウンフィールドプロジェクトの多くは、そのコードベース規模により、AI導入効果が大きく減衰していることになる。

【洞察】物理的な量そのものがAIの推論精度を汚染する

Denisov-Blanchは、規模の拡大がAIのパフォーマンスを低下させる背景として、以下の3点を挙げている*21。

1. コンテキストウィンドウの限界:
   • 大きなコンテキストウィンドウを持つモデルであっても、扱うコンテキスト長（トークン数）が増えるほど、コーディングパフォーマンスのスコアが落ちてしまう。
2. SN比:
   • 本来注目すべきロジック以外の「ノイズ」の混入が増え、モデルを誤った推論へと誘導する。
3. 複雑性（Complexity）:
   • 規模に比例して依存関係やドメインロジックが増え、複雑性が高まる。

これらの要因のうち、2と3は本質的には「コードベースの複雑性」に帰属する問題であり、既に考察した通りである。

したがって、巨大なコードベースを扱う際に生じる「規模そのもの」に起因する影響を解明するため、ここでは「コンテキストウィンドウの限界」に焦点を絞って掘り下げたい。

【戦略】効果的なコンテキストエンジニアリングでスマートゾーンを維持する

大容量のコンテキストウィンドウを持つモデルを採用するのは一つの解決策だが、無計画な対話を重ねれば、そのリソースは瞬時に枯渇する。モデルによっては、容量が逼迫すると古い情報を自動圧縮（auto compaction）するものもあるが*22、それはあくまで対症療法に過ぎない。

Horthyは、ウィンドウ容量の半分に満たない段階でもパフォーマンスの低下が始まると指摘し、その閾値を超えた領域を「ダムゾーン（dumb zone）」と定義した。例えばClaude Codeにおいては、容量の約40%がその境界線になると述べている*23。

そこで求められるのは、コンテキストを最小限に保ち、AIのパフォーマンスを最大化させる「スマートゾーン（smart zone）」を維持する工夫だ。そのためには、コンテキストウィンドウの内部構造に対する深い理解と、戦略的なコンテキストエンジニアリングが不可欠となる。

ウィンドウを占有するのは、プロンプトやコードだけではない。システムが予約している領域に加え、MCPツールのメタ情報や CLAUDE.md といったユーザー定義領域も含まれる。特に後者を無秩序に肥大化させている場合、AIの「思考の余白」を自ら奪っていることに他ならない。

コンテキストとは、単に情報を詰め込めばよいという性質のものではないのだ。だからこそ、次の4点に意識を向けたい。

1. コンテキストのリフレッシュ*24:
   • AIとの対話が迷走し始めたら、/clear などを使い、コンテキストをリセットして新しいウィンドウでやり直す。
2. サブエージェントによる階層化*25:
   • サブエージェントを活用することで、推論のプロセスを各々のウィンドウに閉じ込める。メインエージェントには「結果」のみを返却させることで、親ウィンドウの汚染を防ぐ。
3. 動的なスキルロードの活用*26:
   • エージェントスキルを利用し、必要な情報のみをオンデマンドで読み込ませる。常にすべてのドキュメントを読み込ませるような静的な管理を避ける。
4. 意図的な圧縮（Intentional compaction）*27*28:
   • RPIのようにプロセスをフェーズ分けし、各段階の成果をMarkdown等に集約する。次フェーズでそれらを参照することで、中間過程の膨大なトークンを破棄し、本質的なコンテキストの密度を高める。

これらの手法は、単なる機能の知識にとどまらず、コンテキストウィンドウの構造やAIコーディングツールの内部挙動に対する深い洞察、そして実践を通じた習熟が不可欠であることを示唆している。

従来のコーディングにおいて、優秀なエンジニアがIDEやエディタを使いこなしていたのと同様に、AI時代においてもツールの習熟は不可欠なのである。

さいごに: 「人間にとって良い環境は、AIにとっても良い」

ここまで考察してきたリポジトリ戦略、コードの複雑性、そして規模の問題は、すべて地続きの課題である。大規模なコードベースは宿命的に複雑性を内包し、大規模化を避けようとすればリポジトリを分散管理の方向へ進ませる。

しかし、いずれにしても本質的な問いは、「AIがそのタスクを遂行するために必要なコンテキストを、ノイズなく、かつ地続きに把握できているか」という点に集約される。

AIが真にパフォーマンスを発揮できるのは、境界が明確で、不必要な依存がなく、関心が適切に分離された見通しの良いコードベースだ。これは、私たちが理想としてきたソフトウェアアーキテクチャそのものに他ならない。

セッションの中でKanat-Alexanderが述べた「人間にとって良い環境は、AIにとっても良い（What's good for human is good for AI）」という言葉*29が、それをよく言い表している。

参考文献

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

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

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

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

---

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

open.spotify.com

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

• 「エンジニアの本質は課題解決である」という言葉には限定性と多義性がある
  • 「エンジニアの」と限定する不自然さ
  • 「課題解決」という言葉への解像度の低さ
  • 「課題解決である」との断定によって否定される多義性
• エンジニアリングの提供価値とは何か？
  • 複雑性を秩序に変換する
  • 再現性と効率性を創出する
  • 持続可能性を維持する
• エンジニアの本質とは？
• さいごに: 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

参考文献

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

「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月に公開された。

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

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

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

規模の経済の喪失

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

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

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

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

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

流動性の喪失

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

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

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

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

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

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

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

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

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