チームトポロジーに基づいて採用計画を設計すれば、「とりあえず人を増やす」から「組織構造に最適な人材を、最適なタイミングで採る」に転換できます。

このページでわかること

この記事では、チームトポロジーの4つのチームタイプを採用計画に直結させる方法を解説します。

• チームトポロジーの基本概念と採用計画への応用フレームワーク

• チームタイプ別に必要なスキルセットと人物像の設計

• 認知負荷を基準にした適正チームサイズと採用タイミングの判断

• フェーズ別（シード〜シリーズB以降）の実践ロードマップ

こうした課題を抱える経営者・VPoE・採用担当者に向けた実践ガイドです。

TL;DR（この記事の要約）

• チームトポロジーは「人を増やす」前に「どんなチーム構造が必要か」を設計するフレームワーク

• ストリームアラインドチームを中心に据え、プラットフォーム・イネイブリング・コンプリケイテッドサブシステムで支える構造が基本

• 採用計画の起点は「認知負荷の限界」。チームの認知負荷が溢れたら増員のサイン

• チームタイプごとに求めるスキル・マインドセットが異なるため、ペルソナを分けて設計する

• 「1チーム5〜9人」を超えたら分割を検討し、リード人材から先行して採用する

1. チームトポロジーとは｜採用計画に使える理由

従来型の採用計画が失敗する構造

多くのスタートアップでは開発タスク量から採用数を逆算します。しかし人を増やしたのに調整コストが増えてむしろ遅くなる現象が頻発します。ブルックスが『人月の神話』で指摘したこの問題を、組織構造の側から解決するのがチームトポロジーです。

4つのチームタイプの概要

チームトポロジーは、マシュー・スケルトンとマニュエル・パイスが2019年に提唱した組織設計モデルです（出典：Matthew Skelton & Manuel Pais『Team Topologies』IT Revolution Press, 2019年）。

スカウト運用を支援してきた経験から言えば、この4分類を意識するだけで求人票の訴求力が格段に上がります。候補者は「バックエンドエンジニア募集」よりも「決済ドメインのストリームアラインドチームでEnd-to-Endのデリバリーを担うエンジニア」のほうが自分の仕事をイメージしやすいのです。

2. チームタイプ別の採用ペルソナ設計

ストリームアラインドチーム

ストリームアラインドチームはチームトポロジーの中核であり、多くの組織で最も人数が多くなります。

求める人材像:

• T字型スキル（1つの深い専門性+隣接領域もカバー）

• ドメインモデリングへの意欲（技術だけでなくビジネスロジックを理解する）

• End-to-Endのオーナーシップ（企画参加からリリース・運用まで）

求人票で訴求すべきポイント:

• 担当ドメイン（「決済」「物流」など具体的に）

• デリバリーの自律性（チーム内で完結するか）

• ビジネスインパクト（技術スタック羅列だけでは差別化できない）

プラットフォームチーム

プラットフォームチームは、ストリームアラインドチームがインフラやCI/CDを意識せずに開発できるよう内部プラットフォームを提供するチームです。

求める人材像:

• 抽象化設計力（複数チームのニーズを汎用インターフェースに落とし込む）

• Developer Experience（DX）志向（社内開発者を「ユーザー」として捉える）

• ドキュメンテーション力（セルフサービスで使ってもらうため）

採用タイミング: ストリームアラインドチームが3チーム以上になり、同じインフラ作業の重複が顕在化したとき。2チーム以下の段階では各チームが兼務するほうが効率的です。

イネイブリングチーム

他チームが新しい技術やプラクティスを習得する際の支援を行う「社内コンサル」的な役割です。

求める人材像:

• 教える能力（自分で手を動かすより他者の自走を導く）

• 技術の広さ（複数領域を横断的に理解）

• ワークショップの設計・運営スキル

常設する必要がない場合も多く、3〜6ヶ月の期間限定で組成するパターンが有効です。業務委託やアドバイザー契約の活用も検討しましょう。

コンプリケイテッドサブシステムチーム

ML/AI、暗号化、リアルタイム処理など極めて高い専門性が必要な領域のチームです。学術ネットワークやOSSコミュニティからのアプローチが有効で、報酬レンジは他チームと別テーブルで設定します。研究時間の確保がアトラクトに効きます。

3. 認知負荷を基準にした採用タイミングの判断

認知負荷オーバーフローのサイン

チームトポロジーで最も重要な概念が「認知負荷」です。心理学者ジョン・スウェラーの認知負荷理論（出典：Sweller, J. "Cognitive Load Theory" 1988年, Educational Psychology Review）を組織設計に応用したものです。

以下の兆候が出たら、チームの認知負荷が限界に達しています。これが増員タイミングの最も信頼できる指標です。

• コンテキストスイッチが1日3回以上発生する

• インシデント対応に追われて新規開発が進まない

• ドメイン知識が特定個人に集中し、不在時にチームが止まる

• コードレビューの質が低下する（形式的なApproveの増加）

• スプリントの計画と実績の乖離が常態化する

認知負荷スコアによる判断フレームワーク

採用判断を構造化するため、以下のステップで判断します。

1. チームが責任を持つドメインを列挙する

2. 各ドメインの複雑度を3段階で評価する（シンプル=1点、中程度=2点、複雑=3点）

3. 合計点をチーム人数で割る

4. 1人あたり3点以下なら適正、3〜5点なら注意域、5点超なら即時増員またはチーム分割

「感覚」ではなく「指標」で採用タイミングを判断する習慣をつけることが重要です。

4. 採用順序を間違えるとなぜ組織が詰まるのか

よくある失敗パターン

採用コンサル営業時代に見た中で、採用順序のミスで組織が停滞するパターンは非常に多いです。

典型的な失敗:

1. ストリームアラインドチームを先に大量採用する

2. 共通基盤が整っていないため各チームが個別にインフラを構築

3. 重複コードとバラバラな設計が増え、組織全体の生産性が下がる

4. 後からプラットフォームチームを作っても統合コストが膨大

推奨する採用順序

1. まずストリームアラインドチームのリード級を1〜2名採用し技術方針を確立する

2. 初期段階ではリード級がプラットフォーム的役割も兼務する

3. ストリームアラインドが3チーム規模になったらプラットフォーム専任を採用

4. イネイブリングは必要に応じて期間限定で組成する

チーム分割時の鉄則

「人が増えたからとりあえず2チームに分けよう」とリーダー候補なしで分割すると、技術方針がバラバラになります。チーム分割の3〜6ヶ月前からリード候補の採用または育成を開始しましょう。

5. フェーズ別の採用ロードマップ

シード〜シリーズA（エンジニア1〜10人）

この段階ではチームトポロジーを厳密に適用する必要はありません。ただし将来の拡大を見据えて以下を意識します。

• フルスタックに動けるジェネラリストを採用する

• 将来のチームリード候補になれるポテンシャル人材を優先する

• プラットフォーム志向のエンジニアを1人混ぜておくと基盤整備が自然に進む

• インフラはマネージドサービス中心で運用負荷を最小化する

シリーズA〜B（エンジニア10〜30人）

チームトポロジーが威力を発揮し始めるフェーズです。

• ストリームアラインドを2〜3チームに分割するためのリード人材を採用する

• プラットフォームチームの種（インフラ/SRE経験者1〜2名）を確保する

• 各チームに最低1人のシニアエンジニアを配置する

• チーム分割の判断基準：スタンドアップが15分を超える、コンフリクトが頻発する

シリーズB以降（エンジニア30人超）

4つのチームタイプ全てを意識した組織設計が必要です。

• プラットフォームチームの本格化（3〜5人の専任チーム）

• コンプリケイテッドサブシステムチーム（ML/AI領域がある場合）

• エンジニアリングマネージャーの採用（チーム数が4以上で必要）

6. AI時代のチームトポロジーと採用への影響

2025〜2026年にCursor、GitHub Copilot、Claude Codeといったコーディングエージェントが普及したことで、チーム設計にも変化が生じています。

採用計画への具体的影響:

• 外在的認知負荷（ボイラープレート生成等）はAIで軽減されるが、ドメインの複雑さは変わらない

• 従来比10〜20%程度の効率化を見込んだ人数試算が現実的

• 「AIと協働する能力」を全チームタイプの共通要件に追加する

• プラットフォームチームにAI/LLM基盤の構築経験者を加える

FAQ（よくある質問）

Q1. チームトポロジーはエンジニア何人から適用すべきですか？

厳密な適用は10人以上で効果を発揮します。ただし5人以下でも「将来どのチームタイプに分かれるか」を意識して採用すれば、拡大時の摩擦を大幅に減らせます。

Q2. ストリームアラインドチームとフィーチャーチームの違いは？

フィーチャーチームは機能完成後に解散することがありますが、ストリームアラインドチームは継続的にそのドメインを進化させます。採用では長期的なドメイン専門性の蓄積を重視する人材を求める点が異なります。

Q3. プラットフォームチームのROIはどう測定しますか？

「ストリームアラインドチームが共通基盤に費やす工数の削減量」で測定します。導入前のインフラ作業時間をベースラインとし、削減工数×人件費で定量化します。3チーム以上あれば6ヶ月以内にコスト回収できるのが一般的です。

Q4. イネイブリングチームは常設すべきですか？

必ずしも常設は不要です。新プラクティスの浸透ミッション（3〜6ヶ月）で組成し、達成後にメンバーが各チームに戻るパターンが多い��す。

Q5. リモート環境でもチームトポロジーは機能しますか？

機能しますが、チーム間のインタラクションモードをより明示的に定義する必要があります。「どのチームとどのチャンネルで通信するか」を明文化し、採用時にもリモートでの自律的コミュニケーション能力を重視しましょう。

まとめ：「意図ある採用」で組織の成長速度を変える

チームトポロジーを採用計画に取り入れることで、「何人採る」の前に「どんなチームを作る」を考える習慣がつき、認知負荷という客観指標で採用タイミングを判断できるようになります。

エンジニア採用は「人数」ではなく「構造」で勝負する時代です。組織の成長に合わせた意図ある採用計画を設計していきましょう。

チームトポロジーに基づく採用計画の設計や、チームタイプ別のスカウト戦略について相談したい方は、techcellarの採用支援サービスをご覧ください。