意思決定を速くするのは「気合」ではなく、権限と情報の設計です。
人材と組織を経営する：意思決定を遅らせない権限設計ガイド
取締役や役員会は、最終責任を負う一方で、現場の判断まで抱え込むとスピードは落ちます。逆に、現場に丸投げしても品質は崩れます。必要なのは「判断の粒度」と「責任の境界」をあらかじめ設計し、承認待ちを例外処理にする仕組みです。
1. 権限は“仕事”ではなく“リスク”で切る
権限設計で最初に決めるべきは「誰がやるか」ではなく、「どの程度のリスクなら現場で判断してよいか」です。判断基準が曖昧だと、現場は安全のために上位者へエスカレーションし続けます。すると、役員会は意思決定の渋滞を受け止める係になります。
- 金額、顧客影響、法務・規制、評判リスクなどを“決裁の上限”に変換する。
- リスクの大きさを「Yes/No」ではなく「レベル（例：低・中・高）」で扱う。
- レベルごとに、承認者と意思決定の根拠（必要なデータ）を固定する。
2. “決める”前に、情報の型を揃える
権限があっても、判断材料がバラバラだと結局は差し戻しが増えます。差し戻しは承認プロセスではなく、情報不足の問題です。決裁が速くなるのは、「判断できる形の情報」が最初から揃うからです。
決裁に出す“最小情報セット”
- 目的とトレードオフ（何を優先し、何を後回しにするか）。
- 選択肢の比較（最小2案、可能なら反証も）。
- 数字の前提（仮定、期間、前提条件、計測方法）。
- リスクと対策（最悪ケースと、回避・軽減策）。
- 実行計画（担当、期限、レビュー日）。
3. 役員会は“承認”ではなく“例外の監査”にする
意思決定が遅い組織の多くは、会議が「承認の場」になっています。しかし、承認が必要な範囲を絞れていない限り、会議は増えていきます。役員会が扱うべきは、ルール外の例外、重大な前提変更、長期の方向性です。
- 定常運用は現場決裁に固定し、役員会は「例外だけ」を集約する。
- 前提が変わった場合の“トリガー”を事前に定義する。
- 承認ログを残し、判断の再利用（次回の標準化）につなげる。
4. 権限表（RACIの次）を“更新可能”にする
組織が成長すると、権限設計は必ず古くなります。だからこそ、権限表は「一度作って終わり」にしないことが重要です。月次の小さな更新を前提にし、現場からのフィードバック導線を持ちます。
更新の観点（運用で回す）
- 承認待ちの件数と平均滞留時間が増えていないか。
- 差し戻し理由が「情報不足」になっていないか。
- 例外処理の頻度が高すぎないか（ルール未整備のサイン）。
- 現場決裁の品質が、後追いの是正で帳尻を合わせていないか。
5. 立ち上げ手順：最初の30日で“詰まり”を潰す
理想の権限設計を一気に作るより、最初はボトルネックを特定して潰す方が成果が出ます。経営者の仕事は、設計そのものより「詰まりの原因」を切り分けることです。
- 直近3か月のエスカレーションを棚卸しし、滞留が多い論点を上位10件に絞る。
- 論点ごとに、リスクレベルと“最小情報セット”を決める。
- 現場決裁で動かし、例外が増えるかどうかをレビューする。
- 例外が増えたら、ルールを更新して例外を減らす。
まとめ：速さは権限の設計で手に入る
意思決定を遅らせないための要点はシンプルです。リスクで権限を切り、情報の型を揃え、役員会は例外の監査に寄せる。そして運用で更新し続ける。これができると、組織は“判断の渋滞”ではなく“学習のサイクル”を回し始めます。