delegation

委任

始める前に

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

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

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

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

応答スタイル

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

基本方針：

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

---

このスキルの使い方

まず、状況を特定してください：

• 自分がボトルネックになっていて、抱え込みすぎている → まず委任する2つのこと
• タスクや人物にどの程度関与すべきか分からない → タスク関連の成熟度
• マイクロマネジメントしすぎているか、放任しすぎているか気になる → マイクロマネジメントとマネジメント不足
• エンジニアが自分から動かず、指示を待っている → 意図に基づくリーダーシップ
• 個々のタスクを超えて、エンジニアにより大きなオーナーシップを持たせたい → エンジニアに領域を任せる
• チーム全体の戦略を踏まえて仕事を割り当てる → 3層の割り当てフレームワーク
• 自分とは違うやり方で進められることに不安を感じる → references/extended.md の「委任への不安」を読む
• 休暇に入る／誰かにカバーしてもらう必要がある → references/extended.md の「不在中のカバーを依頼する」を読む
• EM として自分で引き受けるタスクを決める → references/extended.md の「自ら手を動かす：タスクを意図的に選ぶ」を読む
• チームに、完全に自律しているように見える人がいる → references/extended.md の「自由に動く人」を読む
• 繰り返し依頼しても、プロセスが何度も破綻する → references/extended.md の「意図より仕組み」を読む
• エンジニアが判断せず、答えを求めて何度も相談に来る → references/extended.md の「プッシュではなくプル」を読む
• 管理しすぎ、または放任しすぎだというフィードバックを受けた → references/extended.md の「4つの意思決定モード」を読む

---

デフォルトの応答構成

委任について支援する際は、具体策を提示する前にボトルネックを診断してください：

1. 委任する対象： マネージャーから切り離すべき仕事。
2. 成熟度の見立て： その人物またはタスクに必要なコンテキスト、自律性、フォローアップの度合い。
3. 委任時の取り決め： オーナー、意思決定権、チェックインの頻度、完了条件。
4. リスク管理： 仕事を引き取らずに、マネージャーが確認すべきこと。
5. スクリプト： 仕事を任せるとき、またはオーナーシップを再設定するときの正確な言い回し。

品質に不安を感じているマネージャーには、ただ「手放す」よう勧めるのではなく、コントロールを失うことへの恐れに正面から向き合い、レビューのサイクルを設計してください。

---

まず委任する2つのこと

1. 日々の業務：チーム担当者

最初に委任する業務として最も効果的なのは、アラート、サポート依頼、本番環境の問題など、日々の運用負荷です。

仕組み：

• 毎日／毎週、チームメンバーの1人が「チーム担当者」を務めます（交代制）。
• 担当者の役割は、アラートチャンネルの監視、サポートチームの支援、新たな問題のデバッグ、インシデント対応の調整です。
• 担当者は、すべてを修正する責任を負うわけではありません。バグを持ち込んだ開発者が修正します。担当者は調整し、学びます。
• 最初に連絡する相手はマネージャーではありません。担当者です。

導入のヒント：

• ガイドラインを記載したドキュメントを用意し、カレンダーに定期的な交代制として登録します。
• 最初の数回は、あなたに相談してもかまいません。ただし、あなた自身で解決してはいけません。
• あなたも交代制に参加し続けます。委任する業務の負担から自分を除外しないでください。

メリット：

• 単一障害点（バス係数）をなくせます。
• チーム全体の当事者意識とデバッグスキルが向上します。
• 開発者は「みんな同じ船に乗っている」と感じます。

2. 新しいプロジェクト：エピックのオーナーシップ

PMとの打ち合わせ、技術設計、作業の細分化をあなたがすべて担うのはやめましょう。

仕組み：

• 新しいエピックが始まったら、チームメンバーをオーナーに任命します。
• オーナーは、PMとの打ち合わせ、技術設計の作成、タスクへの分割、作業分担の決定を行います。
• あなたは関与し続け、意見を伝え、質問し、レビューします。ただし、決定するのはオーナーです。

各開発者が一度に主導するプロジェクトは1つだけなので、100％専念できます。その結果、あなたが5つのプロジェクトを同時に急いで進めるよりも、優れた設計が生まれることも少なくありません。

---

ナレッジのオーナーシップ

あらゆるシステムや質問について、あなたが頼られる唯一の人になっているなら、それは問題です。チームのシステムやアプリケーションをメンバー間で分担し、誰がオーナーかを明確にしましょう。システムについてあなたに尋ねられたら、オーナーに問い合わせるよう案内します。

---

委任の原則

• 担当領域を100％委任してはいけません。 交代制に参加し続け、ときには自分で作業しましょう。
• 現在の業務の少なくとも50％は共有できます。 例外は、思っているよりも少ないものです。
• 本人に代わって解決してはいけません。 苦労しているときは、助けるのではなく、コーチングしましょう。
• タスクを、その人を動機づける要因に合わせましょう。 その人の動機に合わない仕事を委任すると、先延ばしにされ、あなたは催促することになります。動機に合っていれば、頼まれなくても当事者意識を持って取り組みます。つながりを重視するエンジニアはチームの面接コーディネーターとして活躍し、影響を重視するエンジニアは、あなたが避けてきたCSスプリントを引き受け、成長を重視するエンジニアは、アーキテクチャ上の決定を任されると意欲を示すでしょう。「あなたが好まないタスクはどれも、誰かにとって成長の機会になり得ます。」（それぞれの人の動機を見極める方法については、engineer-motivation を参照してください。）

---

意図に基づくリーダーシップ

_ Turn the Ship Around_（Marquet）にある考え方です。許可を求めたり指示を待ったりする代わりに、チームメンバーは自分の意図を表明し、止められない限り実行に移します。

このパターンでは、「午後2時にリリースをデプロイするつもりです。やめたほうがよい理由があれば教えてください」と伝えます。「リリースをデプロイしてもよいですか？」と尋ねるのではありません。

効果がある理由：許可を求めると、オーナーシップが尋ねられた相手に移ります。意図を表明すれば、監督を維持しながら、行動する本人がオーナーシップを保てます。時間が経つにつれて、チーム全体が単なる実行者ではなく、オーナーとして考えるようになります。

導入方法：

• 自分のマネージャーに対して、まずあなた自身が実践します。「この採用を最終決定するつもりです。懸念があれば知らせてください」（これも、上位者から委任を得る方法です）。
• メンバーが「Xをするべきですか？」と尋ねてきたら、本人がどうするつもりかを尋ね、答えてもらいます。そのうえで、代わりに決定するのではなく、本人の意図に応じて返答します。
• 介入は、相手が持っていない情報をあなたが持っている場合に限ります。単に自分なら違うやり方をするという理由で介入するのであれば、そのコストに見合うほど本人のオーナーシップが重要でないのかを考えてみましょう。

目指すのは、指示を待つチームではなく、指示がなくても動くチームです。

---

マイクロマネジメントと管理不足

『The Dichotomy of Leadership』（Willink）より：権限委譲のスペクトラムの両端にある失敗はどちらも現実に起こり、それぞれ異なる兆候があります。

マイクロマネジメントの兆候：

• あらゆる決定を承認してからでないと先に進められない
• チームメンバーが、問題を持ち込んでもあなたが解決するだけだと思い、相談しなくなる
• 「十分な品質」の仕事までレビューして書き直す
• あなたが対応できないと、誰も動かない
• 不要な進捗確認でカレンダーが埋まっている

管理不足の兆候：

• タスクが予定から外れているのに、あなたが知るのは最後になる
• チームメンバーが、あなたの知っていた関連情報を踏まえずに重要な決定をする
• あなたが気づかないうちに品質が低下したり、基準が守られなくなったりする
• チーム内の担当者ごとに、重要な点で成果物に一貫性がない
• 問題が危機的な状況になってから知る

どちらの極端な状態も安全ではありません。エンジニアリング文化では、管理不足のほうがマイクロマネジメントよりよいと考えられがちです。その結果、多くの EM が関与を控えすぎて、問題の発見が遅れています。

適切な関与の度合いは、人やタスクによって変わります（「タスクに応じた成熟度」を参照）。しかし、上記の診断を使えば、どちらかに偏りすぎる前に兆候をつかめます。

---

適切な関与の度合い：タスクに応じた成熟度

多くのマネージャーは、「ジュニアにはより多くの監督が必要で、シニアにはあまり必要ない」というところで考えるのを止めます。しかし、それではまだ大ざっぱすぎます。

Andy Grove が『High Output Management』で提唱した概念は、**タスクに応じた成熟度（TRM）**です。これは、その人の全般的な経験年数ではなく、_特定のタスク_に対する成熟度を指します。初めて取り組む仕事をするシニアエンジニアは、そのタスクに関する TRM が低い状態です。一方、5つ目のマイクロサービスを担当するジュニアは、TRM が高い状態です。

• TRM が低い → 体系的に関与する：何をすべきか伝え、定期的に状況を確認し、いつでも相談できるようにする
• TRM が高い → 一歩引く：目標を設定し、任せて、結果を信頼する

どちらの方向に誤っても失敗につながります。

• TRM が高いのに手を出しすぎる → マイクロマネジメント、意欲の低下
• TRM が低いのに任せきりにする → 顧客（社内または社外）がその失敗の代償を払うことになる

重大な影響がありそうなタスクに取り組むときは、自分に問いかけてください。この人の _この_タスクに対する TRM は本当に高いのか、それとも全般的に高いだけなのか、と。

---

エンジニアに王国を任せる

タスクの委譲に加えて、各エンジニアには明確な担当領域を持たせるべきです。単なる実行責任だけではなく、実際の意思決定権を持つ王国です。

有効な4種類のオーナーシップ：

1. アプリケーションまたはシステム — オーナーは PM とのロードマップに関する連携を主導し、利用状況を監視し、インシデント発生時の連絡窓口を務めます
2. マイクロサービス — 健全性の監視、技術的負債の優先順位付け、貢献ガイドラインの整備を担当します
3. サードパーティとの連携 — ベンダーとの関係を主導し、リリースノートを監視し、連携の健全性を追跡します
4. 社内ツール — 社内の専門家兼推進役として、導入と更新に責任を持ちます

タスクの委譲との重要な違いは、王国のオーナーが自分の担当領域に対する意思決定権を持つことです。単に実行するだけではなく、優先順位を決めます。

エンジニア1人につき、王国は1つか2つを目安にしましょう。多くの領域に分散させすぎると、目的を果たせません。まずは自分の時間を最も多く使っている領域を特定し、そこから引き継ぎましょう。

表現も重要です。「担当領域」では、雑務を押し付けられたように感じることがあります。「王国」には権限と誇りが感じられます。どちらも、エンジニアが責任を受け入れるか、抵抗するかに影響します。

---

3 層のアサインメントフレームワーク

業務のアサインメントでは、次の 3 つの層のバランスを同時に取る必要があります。

• 効率性 — 今必要な業務に最も適した人をアサインします
• 成長 — 成長とキャリアの方向性を考慮してアサインします。多くの場合、スピードとのトレードオフが生じます
• 持続性 — 効率性や成長を最適化できない場合でも、単一障害点を防ぐためにアサインします

ナレッジマップの演習では、エンジニアとスキル／システム領域を対応づけて、カバー範囲の不足を可視化し、特定の担当者に依存する危険な領域を特定することで、3 つ目の層を具体化します。

成長や持続性のためにエンジニアを新しい領域へ配置する際は、タスク関連成熟度（上記を参照）を適用してください。Staff エンジニアであっても、初めて取り組む領域では、肩書きから想定される以上にきめ細かなガイダンスが必要です。

注意すべき落とし穴は 2 つあります。慣性（ビジネスニーズが変化しても、慣れたアサインメントが固定化すること）と、着手コスト（移行には実際にコストがかかるため、ないものとして扱わず、計画に含める必要があります）です。最後にうまくいった判断を際限なく続けるのではなく、四半期ごとに意識的にアサインメントを見直してください。

---

さらに詳しく

フレームワークの由来や原文の記事、トピックに関する詳しい情報を尋ねられた場合は、references/sources.md を参照して、リンク付きの元記事と書籍の全リストを確認してください。

---

関連するスキル

• managing-yourself — 過度な関与は、EM が行き詰まる 10 のパターンの 5 つ目です
• engineer-motivation — 各エンジニアの動機を特定し、モチベーションに沿った委任に役立てます