フレームワーク活用ガイドひとことで言うと#
「任せる」と言っても、どこまで任せるかにはグラデーションがある。デリゲーションポーカーは権限委譲を7段階のレベルで可視化し、マネージャーとメンバーの認識を合わせるゲーム形式のツール。Management 3.0の一部として広まった。
押さえておきたい用語#
- デリゲーション（Delegation）
- 意思決定や業務の実行を部下やチームメンバーに委ねること。単なる「丸投げ」とは異なり、権限の範囲を明確にして渡す。
- デリゲーションボード
- 各意思決定テーマについて合意されたデリゲーションレベルを一覧表にしたもののこと。チーム全員が見える場所に掲示する。
- マイクロマネジメント
- 上司が部下の細かい作業まで逐一監視・指示する管理スタイルのこと。デリゲーションポーカーはこの解消を目的の一つとする。
- 自律性（Autonomy）
- メンバーが自分で判断し行動できる度合いのこと。デリゲーションレベルが上がるほど自律性が高まる。
デリゲーションポーカーの全体像#
こんな悩みに効く#
- 「任せたつもり」なのに、部下が「指示待ち」になってしまう
- 権限の範囲が曖昧で、勝手に進めすぎたり、何も決められなかったりする
- マイクロマネジメントをやめたいが、どこから手を離せばいいかわからない
基本の使い方#
デリゲーションには以下の7段階がある。
- Tell（指示する）: マネージャーが決めて伝える
- Sell（説得する）: マネージャーが決めるが、理由を説明して納得してもらう
- Consult（相談する）: メンバーの意見を聞いた上で、マネージャーが最終決定する
- Agree（合意する）: マネージャーとメンバーが対等に議論して合意する
- Advise（助言する）: メンバーが決めるが、マネージャーがアドバイスする
- Inquire（確認する）: メンバーが決めて実行し、事後にマネージャーに報告する
- Delegate（委任する）: 完全にメンバーに任せる。報告も不要
レベル1〜3はマネージャー主導、4が対等、5〜7はメンバー主導。
チームでよくある意思決定の場面を具体的に洗い出す。
例:
- 技術選定（使用するライブラリやツールの決定）
- 採用面接の合否判断
- タスクの優先順位付け
- 休暇取得のスケジュール
- バグの対応優先度
- 外部ベンダーへの発注
ポイント: 抽象的すぎると議論が噛み合わない。「〇〇の場面で、誰がどこまで決められるか」という具体的なシナリオにする。
各場面について、全員が同時にカード（1〜7の数字）を出す。
- 全員が同じ数字 → そのレベルで合意
- 数字がバラバラ → 最も高いカードと低いカードを出した人がそれぞれ理由を説明し、議論する
- 議論後に再度カードを出し、合意を目指す
面白いのは「認識のズレ」が見えること。マネージャーは「レベル6で任せてるつもり」でも、メンバーは「レベル2で指示されている」と感じていることがよくある。
合意した結果をデリゲーションボードとして可視化する。
| 意思決定の場面 | レベル | 備考 |
|---|---|---|
| 技術選定 | 5（Advise） | マネージャーは相談されたらアドバイスのみ |
| タスク優先度 | 4（Agree） | スプリントプランニングで合意 |
| 休暇取得 | 6（Inquire） | カレンダーに入れて事後報告でOK |
ボードはチーム全員が見える場所に貼り出す。状況が変わったら定期的に見直す。
具体例#
状況: 従業員25名のスタートアップ。CTOとエンジニア4名のチームで、本番環境へのデプロイ判断の権限が曖昧だった。
テーマ: 「本番環境へのデプロイ判断」
カード結果:
- CTO: カード「3」（自分に相談してから判断してほしい）
- シニアエンジニア: 「6」（自分たちで判断して、デプロイ後にSlack報告でいい）
- ジュニアエンジニア: 「2」（CTOが決めて指示してほしい）
議論の結果:
- CTOが「3」の理由: 過去に本番障害があったから不安
- シニアが「6」の理由: CI/CDが整備されたので毎回確認は不要
- ジュニアが「2」の理由: 判断基準がわからないから指示がほしい
合意: ケースごとにレベルを分離
| ケース | レベル | 理由 |
|---|---|---|
| 通常デプロイ | 6（Inquire） | テスト通過+レビュー済みなら自己判断 |
| DB マイグレーション | 3（Consult） | CTOに相談してから実行 |
| ホットフィックス（深夜） | 5（Advise） | シニアが判断、事後にCTO報告 |
「デプロイ」という1つのテーマでもケースによってレベルを分けることで、安全性と速度を両立した。認識のズレが可視化されたことが最大の収穫。
状況: 従業員60名の広告代理店。営業担当が顧客の前で「持ち帰って確認します」を繰り返し、商談スピードが遅いことが課題だった。
デリゲーションポーカーの対象テーマ:
- 見積もりの値引き判断
- 納期の調整
- 追加サービスの提案
- クレーム対応の初動
| テーマ | チームリーダーの認識 | 営業担当の認識 | 合意後 |
|---|---|---|---|
| 5%以内の値引き | 5（任せてるつもり） | 2（確認が必要と思ってた） | 6（事後報告でOK） |
| 5-10%の値引き | 3（相談してほしい） | 1（絶対に聞かないとダメ） | 4（議論して合意） |
| 納期の1週間延長 | 4（一緒に決める） | 3（確認してから回答） | 5（営業判断でOK） |
| クレーム初動 | 6（自分で対応して） | 2（怖いので指示ほしい） | 5（対応後にフィードバック） |
| 指標 | ポーカー実施前 | 実施3ヶ月後 |
|---|---|---|
| 商談1件あたりの期間 | 平均18日 | 平均11日（39%短縮） |
| 「持ち帰り」回数 | 商談あたり平均2.3回 | 平均0.6回 |
| 成約率 | 28% | 35% |
認識のズレを数値で可視化し議論したことで、「怖くて聞いていた」ケースの大半が実は任せてよかったと判明。商談スピードが4割短縮した。
状況: 教員12名の公立中学校。校長・教頭・学年主任・一般教員の間で、行事の企画・変更・中止判断の権限が不明確。「校長に聞かないと何も決められない」状況で、教員の負担感と不満が高まっていた。
デリゲーションポーカーの結果:
| テーマ | 校長の認識 | 教員の認識 | 合意後 |
|---|---|---|---|
| 授業内の活動変更 | 7（完全に任せてる） | 3（確認が必要と思ってた） | 7（完全委任を明文化） |
| 学年行事の企画 | 5（任せたい） | 2（校長承認が必要） | 5（学年主任が決定、校長は助言のみ） |
| 全校行事の変更 | 3（相談してほしい） | 1（校長指示が必要） | 3（意見を聞いて校長が最終決定） |
| 行事の中止判断（安全） | 1（自分が決める） | 1（校長判断） | 1（即断。ただし現場教員にも停止権限付与） |
| 指標 | 実施前 | 実施6ヶ月後 |
|---|---|---|
| 校長への確認待ち時間 | 週あたり延べ8時間 | 週あたり延べ2時間 |
| 教員の「裁量がある」実感 | 10点中3.2 | 10点中6.8 |
| 学年行事の企画数 | 学期あたり2件 | 学期あたり5件 |
「聞かなくていいのに聞いていた」ケースが大量に見つかり、校長も教員も驚いた。権限を明文化するだけで教員の自律性と行事の質が同時に向上した。
やりがちな失敗パターン#
- 一度決めたら変えない — チームの成熟度やメンバーの成長に応じてレベルは変わる。四半期ごとに見直すのがベスト
- すべてをレベル7にしようとする — 「完全委任」がゴールではない。リスクの高い判断はレベル3〜4が適切なこともある。大事なのは全員の認識が揃っていること
- マネージャーだけで決める — ポーカーの意味がなくなる。必ずチーム全員で議論し、認識のズレを楽しむこと
- 抽象的なテーマで議論する — 「技術的な判断」のような大きなテーマでは認識が合わない。「使用ライブラリの選定」「本番DBのスキーマ変更」のように具体化する
まとめ#
デリゲーションポーカーは、「任せる/任せない」の二択ではなく、7段階のグラデーションで権限委譲を設計するツール。ゲーム形式で楽しく認識のズレを発見でき、チームの自律性を段階的に高められる。まずはチームの「あるある」な意思決定シーンで試してみよう。