team-composition

チーム構成

開始する前に

まず、EM に関するコンテキストを確認してください。.agents/em-context.md が存在する場合は、読み込んでください。

.agents/em-context.md が存在しない場合は、詳細なアドバイスをする前に、まず最低限のマネージャーのプロフィールを尋ねて保存してください。役職／肩書き、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項を確認します。

特定の人物が会話の中心となっており、.agents/reports/[name].md が存在しない場合は、詳細なアドバイスをする前に、まずその人物の最低限のプロフィールを尋ねて保存してください。役職／レベル、在籍期間、強み、現在の課題または成長領域を確認します。

会話の中で、後から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測や一時的な不満、未解決の解釈ではなく、安定した事実やパターンを保存します。

回答スタイル

最初の回答は簡潔で役立つものにしてください。ユーザーから詳しい説明を求められない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• まず、考えられる診断または推奨事項を述べる
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大2〜3つする
• 次に取るべき具体的な行動を示し、役立つ場合はマネージャーが使える具体的な言い回しも提示する
• 関連するフレームワークに簡単に触れるが、すべての要素を説明しない
• 直接的な回答の後に、さらに詳しい説明を提案する

---

このスキルの使い方

• チームに足りないもの／次に採用する人を診断する → ダンジョンパーティーモデル
• 十分な人員がいるのにチームの動きが遅い → 樽と弾薬
• 以前は活躍していたシニアエンジニアが苦戦している（またはその逆） → コマンドー、歩兵、警察
• チームの規模が危険なほど小さい、または1人に依存している → 最小チーム規模

---

回答の基本構成

チーム構成を支援するときは、人員数を推奨する前に、必要な能力を診断してください。

1. チームのニーズ： 実行力、信頼性、連携、アーキテクチャ、探索、またはフェーズへの適合性。
2. 現在の偏り： 不足または過負荷になっているアーキタイプや能力。
3. 根拠： デリバリー、インシデント、計画、コラボレーション、士気に見られる兆候。
4. 介入策： 採用、育成、配置換え、ペア作業、オーナーシップの分割、または期待値の変更。
5. リスク： 適合しないタイプの人材をチームに加えた場合に起こること。

「シニアを採用する」を安易に答えにしないでください。不足している能力を説明します。

---

ダンジョンパーティーモデル

あらゆるロールプレイングゲームでは、バランスの取れたパーティーが必要です。戦士ばかりのチームは魔法に倒されます。ヒーラーばかりのチームは何も倒せません。エンジニアリングチームにも同じ理屈が当てはまります。

5つのアーキタイプ：

戦士

シニアの問題解決者です。難しいバグ、本番環境での緊急対応、厄介な移行を担当します。プレッシャーの中でも決断力と実行力を発揮します。本当に何かが壊れたときに頼る人です。

満たすチームのニーズ： 難易度が高く、重要度の高い業務を実行する力。

タンク

一般にキャリアの初期段階にある、信頼できる実行者で、戦士と緊密に連携します。リードすることは期待されず、明確に定義された業務を安定して遂行し、戦士の負荷の一部を引き受けることが期待されます。

満たすチームのニーズ： シニアの稼働を過度に消耗させず、標準的な業務で継続的な成果を上げる力。

ヒーラー

共感力があり、ビジネス志向で、チームの連携を支える存在です。エンジニアリングとプロダクト／デザインの橋渡し役を担うこともよくあります。難しい話し合いの進行、チーム間の摩擦の解消、厳しい時期のチームの士気の維持を得意とします。

満たすチームのニーズ： 人間関係、コミュニケーション、組織内の調整。

ウィザード

システム設計、アーキテクチャ文書、システム全体を見通した思考を担うシニアまたはスタッフエンジニアです。数段先まで影響を見通します。成果を出す速度は遅めですが、コストのかかる間違いを防ぎます。

満たすチームのニーズ： アーキテクチャの品質と長期的な技術方針。

ローグ

多才なフルスタックのユーティリティプレイヤーです。領域をまたいで状況に応じて切り替え、探索的な作業を進め、足りない部分をカバーします。どんなことでも引き受けて前進させられる人です。

**チームで担う役割：**予測できない状況での柔軟性とカバー力です。

---

モデルの活用方法

**現在のチーム構成を監査します。**各エンジニアの主なアーキタイプを特定します。次に不足を探します。足りていない、または負担が集中しているアーキタイプはどれでしょうか？

よくある不足：

• タンクがいない → ウォリアーが定型業務で燃え尽きます
• ヒーラーがいない → 技術力は高くても、組織として脆くなり、部門横断の摩擦が積み重なります
• ウィザードがいない → アーキテクチャの判断が場当たり的になり、技術的負債が膨らみます

**EM のアーキタイプの偏りに注意します。**EM は自分と同じアーキタイプの人を採用しすぎる傾向があります。元ウォリアーはウォリアーを採用し、ヒーラーを見落とします。元ヒーラーはカルチャーフィットを重視し、実行力が不足しがちです。このモデルは不足を明示することで、その偏りを抑えます。

**採用の判断に活用します。**採用枠ができたら、まず現在のチーム構成を把握します。次の採用では、最も多いアーキタイプを増やすのではなく、最も重要な不足を補います。

---

注意点

これは診断モデルであり、人を固定的な枠にはめるものではありません。多くのシニアエンジニアは複数のアーキタイプにまたがります。人にラベルを付けることが目的ではなく、チームに現在何が不足していて、次に何を重視すべきかを特定することが目的です。

---

バレルと弾薬

Keith Rabois の洞察：人員を増やしても、速度は比例して上がりません。採用する人の大半は弾薬、つまり方向づけが必要なスキルのある人だからです。チームの処理能力を制限するのは、バレルの数です。

バレルとは、アイデアを考案からリリースまで一貫して形にし、その過程で周囲の人々を巻き込める人です。方向づけを必要とせず、自ら方向を作り出します。バレルを一人加えると、実質的な成果が倍になります。バレルがいないまま弾薬だけを加えると、調整の負担が増えるだけです。

**バレルは希少で、企業文化に左右されます。**ある会社ではバレルである人が、別の会社でもそうとは限りません。そのスキルは、特定の組織をうまく動き回ることにも一部依存するからです。バレルを見つけたら、それにふさわしい待遇をしてください。株式、知名度、そして大きな裁量を与えましょう。バレルの後任を見つけるのは、ほぼ不可能です。

**実践での活用：**人員がいるのにチームの進みが遅い場合、「バレルが足りない」という診断が当てはまることがよくあります。エンジニアの増員を申請する前に、すでにいるメンバーのうち、何人が何かを最初から最後まで責任を持って進められるかを考えてください。答えが一人か二人なら、弾薬を増やしても解決しません。

---

コマンド、歩兵、警察

Robert X. Cringely のモデルによると、企業の成長段階ごとに異なるタイプの人材が必要です。

コマンド — 第一陣です。スタートアップ並みのスピードで動きます。懸命に、速く、低コストで働きます。彼らの仕事は橋頭堡を築くことです。プロトタイプを作り、アイデアを実証し、誰にも気づかれる前に先へ進みます。品質を過度に気にするのではなく、スピードを何より重視します。

歩兵 — 第二陣です。コマンドが始めたことを拡大します。体系的に働き、きちんと構築し、最初の本格的な製品をリリースします。コマンドが一日に20の判断を下したなら、歩兵はその判断を定着させます。

警察 — 第三陣です。成功した企業はいずれ、コンプライアンス、プロセス、安定性を必要とします。警察は品質の再現性を確保しますが、革新やスピードは得意ではありません。

**マネジメントの落とし穴：**多くの人は3つのモードのうち1つを強く好み、ほかのモードにはあまり向いていません。警察フェーズでのコマンドは厄介者になります。コマンドフェーズでの警察官はボトルネックになります。このミスマッチによって、「なぜこの人は苦戦しているのか」という状況の多くを説明できます。

実践での活用方法は2つあります。

1. 採用時には、チームや製品がどのフェーズにあるかを特定します。新しいものを作るにはコマンドを採用し、それを拡大するには歩兵を採用します。エンジニアリングでは、警察のスキルが不足することはほとんどありません。
2. スタートアップフェーズで活躍していたシニアエンジニアが、規模を拡大した組織で苦戦している場合（またはその逆の場合）、急にスキルが落ちたのではなく、フェーズとのミスマッチが原因であることがよくあります。

---

チームの最小人数

An Elegant Puzzle（Will Larson 著）より：チームの人数はおよそ4人を下回らないようにし、1人だけのチームは決して作らないでください。

1人または2人のチームは、構造的にもろいものです。1人が休暇を取ったり、病気になったり、退職したりするだけで、すべてが止まる可能性があります。また、実質的なコードレビューがなく、知識を複数人で共有できず、通常業務を進めながらインシデントにも対応することができません。

避けるべき失敗パターンは、小さな「チーム」を組織上の虚構として作ることです。つまり、1人のエンジニアが製品領域を「担当」し、名目上はチームとして扱われます。このエンジニアはすべてのリスクを負う一方で、本物のチームが提供するサポート体制を得られません。何か問題が起きたり、本人が退職したりしたときに、それを引き継ぐチームがありません。

実行可能なチームの最小規模（Larson の指針）： エンジニア約4人です。これだけの人数がいれば、単一障害点を作ることなく、オンコール、コードレビュー、技術設計、休暇に対応できます。

この人数を下回る場合： チームを最小規模まで拡大するか、隣接するより大きなチームに統合するか、あるいは移行計画を伴う一時的な1人または2人の体制であり、恒久的な組織構造ではないことを明確にしてください。

---

さらに詳しく

フレームワークの出典を知りたい場合、元の記事を読みたい場合、またはこのスキルのトピックについて詳しい情報が必要な場合は、references/sources.mdを読んでください。

---

関連するスキル

• hiring — 求人票を書く前に、モデルを使って求める人材像を定義します
• delegation — 領域の割り当ては、多くの場合、アーキタイプに沿って行います。システムのオーナーシップはWarriorやWizardに、チーム横断の調整はHealerに任せます
• managing-high-performers — 特にWizardは、意欲を保つために、目に見える複雑度の高い仕事を必要とします
• engineer-motivation — フェーズとの不一致（PoliceフェーズにいるCommando）は、モチベーションの問題に見えることがよくあります