フレームワーク活用ガイドひとことで言うと#
プロジェクトで発生するすべての決定事項に明確な期限とエスカレーションルールを設けることで、「誰かが決めてくれるのを待つ」状態を構造的に排除するプロトコル。
押さえておきたい用語#
- 決定遅延（Decision Delay）
- 情報不足・責任回避・合意形成の難航などにより、必要な判断が先送りされること。プロジェクト停滞の最大要因の一つ。
- エスカレーション
- 期限内に決定できない場合に、一段上の権限者に判断を引き上げる仕組み。プロトコルの中核ルールにあたる。
- デフォルト決定（Default Decision）
- 期限を過ぎても判断が出ない場合に自動的に適用される選択肢。「決めない＝現状維持」ではなく「決めない＝Aに決まる」と設定する。
- 決定ログ
- いつ・誰が・何を・なぜ決めたかを時系列で記録する文書。後から「なぜこう決まったか」を追跡できるようにする。
意思決定期限プロトコルの全体像#
こんな悩みに効く#
- 「検討中」のまま何週間も決まらない案件がある
- 決定待ちでタスクがブロックされメンバーの手が空く
- 合意が取れないまま会議が繰り返される
- 「もう少し情報が揃ってから」が口癖のステークホルダーがいる
基本の使い方#
具体例#
年商30億円のEC企業。サイトリニューアルプロジェクトが3か月遅延しており、原因分析の結果 未決定事項が16件 滞留していた。デザイン、決済手段、送料体系など、各部門が「もう少し検討したい」と先送りにしていた。
決定期限プロトコルを導入し、16件すべてに期限（最長2週間）とデフォルト案を設定。
| カテゴリ | 件数 | 期限内決定 | エスカレーション | デフォルト適用 |
|---|---|---|---|---|
| デザイン | 5件 | 4件 | 1件 | 0件 |
| 機能仕様 | 7件 | 5件 | 1件 | 1件 |
| ビジネスルール | 4件 | 3件 | 0件 | 1件 |
2週間で16件中14件が期限内に決定、2件がデフォルト適用。プロジェクトの遅延は1か月で回復し始めた。
化学メーカー（従業員800名）の新工場建設プロジェクト。設計段階で仕様変更が頻発し、変更の承認に毎回 平均12営業日 かかっていた。
プロトコルを導入し、設計変更の影響額に応じた期限を設定。500万円未満は 3営業日（部長決裁）、500万円以上は 5営業日（役員決裁）、期限超過で自動的に1段階上にエスカレーションするルールにした。
導入後3か月で、設計変更の平均決定日数は 12日→4日 に短縮。プロジェクト全体のスケジュール遅延も累計で 3週間分 回復した。「決めないことがコスト」という意識がチーム全体に浸透した効果が大きい。
教育支援NPO（スタッフ8名）。大型助成金の申請プロジェクトで、理事会の承認が遅れて過去2回申請期限を逃していた。
決定期限プロトコルを簡易版で導入。助成金申請に必要な決定事項（予算案・活動計画・連携先の承諾）に逆算で期限を設定し、デフォルト決定を「前年と同じ内容で申請」とした。
Googleスプレッドシートで決定ログを管理し、期限の3日前にSlackで自動リマインダーを飛ばす仕組みにした。結果、全7件の決定事項が期限内に完了し、提出期限の 1週間前 に申請書類を提出。3度目にして初めて助成金（500万円）の獲得に成功している。
やりがちな失敗パターン#
- 期限だけ設定してデフォルト決定を決めない ─ 期限があっても「超過したらどうなるか」がないと先送りの圧力が弱い。デフォルト案を必ずセットにする
- すべての決定に同じ期限をつける ─ 影響度に応じて期限を変える。小さい決定に2週間は長すぎるし、大きな決定に3日は短すぎる
- エスカレーション先が不明確 ─ 「誰にエスカレーションするか」が曖昧だと期限を過ぎても宙に浮く。組織図に基づいて事前に指定する
- 決定ログをつけずに口頭で運用する ─ 記録がないと「あの決定はいつ誰がした？」が追跡できない。シンプルなスプレッドシートで十分なので必ず文書化する
よくある質問#
Q: デフォルト決定とはどう設定するのですか？ A: 「期限までに決定が出なかった場合に自動採用される案」をあらかじめ決めておくことです。例えば「3営業日以内に反対意見がなければ案Aで進める」のように設定します。デフォルト決定があると「黙認は承認」という文化が生まれ、先送りのコストが明確になります。
Q: 意思決定の影響度によって期限の目安を教えてください。 A: 影響が限定的で覆しやすい軽微な決定は1〜3営業日、中程度の影響でリソースや工数が絡む決定は1週間、組織戦略や重要な契約などインパクトが大きい決定は2〜4週間が目安です。重要なのは影響度に応じて「長すぎない期限」を設定し、必ず厳守することです。
Q: エスカレーション先はどのように指定すべきですか？ A: 事前に意思決定マトリクス（RACI等）を使って指定します。「このカテゴリの決定はXさんが承認者、期限超過時はYマネジャーにエスカレーション」という形で文書化しておくことで、期限超過時にも行動できます。エスカレーション先が不明確だと期限超過が宙に浮くため、担当者の明示が最重要です。
Q: 期限内の決定率70%という目標は高すぎますか？ A: 最初は50〜60%でも十分です。プロトコル導入直後は慣れが必要なため、まず60%を目標に始め、四半期ごとに5〜10%ずつ改善する段階的アプローチが現実的です。期限内決定率を月次でチームに共有するだけで意識が変わり、自然に向上する傾向があります。
まとめ#
意思決定期限プロトコルは、すべての決定事項に期限・エスカレーションルール・デフォルト決定を設けることで、判断の先送りを構造的に防ぐ仕組み。「決めないこと自体がコスト」という認識をチームに浸透させ、決定ログで全件を可視化することがポイント。月次で期限内決定率を追跡し、プロトコル自体も改善していく。