---
name: delegation-brief
description: 仕事やプロジェクトをだれかに任せるときの依頼書を書く。目指す結果、なぜ大事か、制約、Tell から Delegate までの権限委譲レベルで示す決める権限、使える資源と相談相手、途中確認のタイミング、完了の条件。マネージャーや創業者が、仕事を任せたい、プロジェクトを引き継ぎたい、担当者を決めたい、引き継ぎメモを書きたい、マイクロマネジメントせずに任せたいときに使う。
---

# 仕事を任せるときの依頼書

任せ方の失敗は2通り。マネージャーがすべての判断を手放さない（だから何も進まない）か、範囲を決めずに渡す（だから結果にだれもが驚く）か。よい依頼書は、完了の姿と、判断の種類ごとに相手がどこまで決められるかを示して、両方を防ぐ。そのために Management 3.0 の7段階の権限委譲レベルを使う。

## 使う場面

- プロジェクト、仕事、定常業務を、部下、業務委託先、同僚に任せるとき。
- 相手が「〜してもいいですか？」と何度も聞きにくるとき。決める権限がはっきりしていなかった。
- 休暇や休職の前に、担当範囲を引き継ぐとき。
- 四半期の目標づくり（okr-draft を使う）や、チーム全体の役割の定義（team-charter を使う）には使わない。

## 用意するもの

- 任せる仕事かプロジェクトと、任せる相手。
- 目指す結果と期限。
- わかっている制約。予算、ブランド、法務、システム、必ず関わる人。
- 仕事の中で出てきそうな判断。わからなければ、仕事の内容からいちばんありそうなものを3〜5個挙げ、「[仮定]」と印をつける。

## 手順

1. **手順ではなく結果を書く。** 終わったときに何が実現しているかを1文で。できれば測れる形で。「ウェビナーを開く」ではなく「3月12日（木）にウェビナーを開き、申込150件以上」。
2. **なぜ大事かを書く。** 目標とのつながりを1〜2行で。目的がわかっていると、人はよい判断をする。
3. **制約を並べる。** 動かせない制約だけ。予算、日付、ツール、社内ルール、何をだれが承認するか。好みにすぎないものは、好みと書く。
4. **領域ごとに決める権限を設定する。** 主な判断の領域ごとに、レベルを1つ選ぶ。1 Tell（私が決めて伝える）、2 Sell（私が決めて理由を説明する）、3 Consult（相手の意見を聞いて私が決める）、4 Agree（一緒に決める）、5 Advise（私が助言し、相手が決める）、6 Inquire（相手が決めて、あとで私に伝える）、7 Delegate（相手が決める。伝えなくてよい）。このスキルの既定値は、任せられる力のある相手なら、ほとんどの領域を5か6にし、お金、法務、社外への発信だけを3以下にする。
5. **資源を渡す。** 予算、ツール、資料、そして相談できる人の名前と、それぞれ何を手伝えるか。
6. **途中確認を決める。** このスキルの既定値は、期間のおよそ20%の時点で早めの確認を1回（方向違いを安く見つけるため）、取り返しのつかない工程の前に1回、最後に振り返りを1回。それぞれの確認で何を見るかを書く。
7. **完了を定義する。** 確かめられる基準を3〜5個。何を返してもらうか（資料、報告、リンク）も入れる。

## 出力の形式

```markdown
# 依頼書 — [仕事] → [任せる相手]
**依頼者:** [氏名] · **日付:** [日付] · **期限:** [日付]

## 目指す結果
[1文: 終わったときに何が実現しているか]

## なぜ大事か
[目標につながる1〜2行]

## 制約
- [動かせない制約]
- [好み（好みと明記）]

## 決める権限
| 判断の領域 | レベル | ここでの意味 |
|---|---|---|
| [領域] | [1〜7と名前] | [例:「任せるので、決めたらあとで教えて」] |

## 資源
- [予算 / ツール / 資料]
- [人] — [手伝えること]

## 途中確認
| いつ | 何を見るか |
|---|---|
| [日付] | [例: 計画と最初の案] |

## 完了の条件
- [ ] [確かめられる基準]
- [ ] [返してもらうもの]
```

## 例

**入力:** 「森です。今日は2月3日（火）。顧客向けウェビナーを、マーケティング担当の小林さんに任せたい。3月12日（木）開催で、申込150件が目標。録画は開催から2日以内にウェブサイトに載せる。ウェビナーはアップセルの見込み客がいちばん多く生まれる場で、今回は第1四半期のアップセル目標を支える。告知の予算は18万円。登壇はCEOの石井さんで、日付は石井さんの予定で決まっている。石井さんは2月20日（金）までに内容の骨子のために30分取れる。できれば45分に収めたい。昨年のウェビナーの資料とメールの流れは共有ドライブにあり、配信ツールのアカウントは業務推進の吉田さんが用意できる。細かく口出ししたくないが、タイトルと顧客に出るものは気にしている」

**出力:**

```markdown
# 依頼書 — 3月の顧客向けウェビナー → 小林さん
**依頼者:** 森 · **日付:** 2月3日（火） · **期限:** 3月12日（木）

## 目指す結果
3月12日（木）に石井さんが登壇する顧客向けライブウェビナーを開き、申込150件以上、開催から2日以内に録画をウェブサイトに載せる。

## なぜ大事か
ウェビナーはアップセルの見込み客がいちばん多く生まれる場。今回は第1四半期のアップセル目標を支える。

## 制約
- 告知の予算: 18万円。
- 日付は固定: 3月12日（石井さんの予定）。
- 好み: 45分に収める。

## 決める権限
| 判断の領域 | レベル | ここでの意味 |
|---|---|---|
| ウェビナーのタイトルと説明文 | 3 Consult | 2〜3案を出してもらい、私が選ぶ |
| 顧客へのメール | 5 Advise | 下書きに私がコメントしたうえで、最後は任せる |
| 告知の経路と費用の配分 | 6 Inquire | 任せる。何にいくら使ったかは教えて |
| 配信ツールと運営 | 7 Delegate | すべて任せる |

## 資源
- 告知の予算18万円
- 昨年のウェビナーの資料とメールの流れ（共有ドライブ）
- 石井さん — 内容の骨子、2月20日（金）までに30分
- 吉田さん（業務推進） — 配信ツールのアカウント

## 途中確認
| いつ | 何を見るか |
|---|---|
| 2月10日（火） | タイトル案と告知の計画 |
| 2月24日（火） | 申込数と目標の差 |
| 3月13日（金） | 結果と録画のリンク |

## 完了の条件
- [ ] 3月12日にウェビナーを開いた
- [ ] 申込150件以上（届かなくても数を報告する）
- [ ] 3月14日までに録画をウェブサイトに載せた
- [ ] 1枚のまとめ: 申込数、参加数、使った費用
```

## 送る前のチェック

- [ ] 目指す結果が1文で、正しいか正しくないかを確かめられる。
- [ ] すべての判断の領域に、レベルとふつうの言葉での意味がある。
- [ ] 制約の欄には動かせない制約だけがあり、好みは好みと書いてある。
- [ ] 期間の25%より前に、早めの途中確認がある。
- [ ] 完了の条件に、確かめられる基準が3〜5個ある。

## よくある失敗

- 仕事を渡しても、判断をすべてレベル1のまま手元に置く。それは作業の割り振りで、任せたことにならない。
- 決める権限を言わないまま、あとから相手の判断をくつがえす。レベルは仕事を始める前に決める。
- 最後にしか確認しない。その時点では、方向違いを直すのに高くつく。