“決める人がいない”案件を正すガバナンス再設計術

なぜ「決める人がいない」案件が生まれるのか

“決める人がいない”状態は、能力不足というより設計不足で起きます。典型は次の3つです。

• 責任者はいるが、決裁者がいない
  進行はPMが担うのに、最終OKを誰が出すかが曖昧。
• 関係者が多すぎて「全員合意」になっている
  合意が必要な範囲が肥大化し、1人の反対で止まる。決めるより「揉めないこと」が優先される。
• 決める粒度が混在している
  仕様変更の判断と、予算追加の判断が同じ会議・同じルートで回るなど、重い判断が常態化する。

この状態が続くと、意思決定が遅れるだけでなく、現場では次のような問題が起きます。
「誰も責任を取らない」→「誰も決めない」→「その場しのぎ」→「炎上」
だからこそ必要なのが、RACIと承認フローでガバナンスを再設計することです。

まず整えるべきガバナンスの前提

最初にやるべきは、RACIを書くことではなく、“決裁”の定義を揃えることです。ここが揃わないと、RACIは形だけになります。

決裁事項を3種類に分ける

案件で起きる判断を、まず次の3つに分類します。

1. 方向性の決定：目的、優先順位、スコープの原則
2. コスト/リスクの決定：予算、納期、品質基準、受入条件
3. 実務の決定：設計方針、タスク配分、手順や手段

“決める人がいない”案件は、1)や2)が3)の会議に紛れ込んで、誰も責任を持てなくなっていることが多いです。

「決裁権限の境界」を作る（金額・期間・影響）

決裁者が決まらない理由の1つは、「どこまでが自分の権限か不明」があります。
境界は、次の3軸で切るとシンプルです。

• 金額：追加費用〇万円までは現場、超えたら事業責任者
• 期間：遅延〇日まではPM、超えたらプロジェクトオーナー
• 影響：ユーザ影響（停止/機能削除/法令）なら上位決裁

この「境界」を文章で作るのが、ガバナンス再設計の土台です。

RACIで“責任の空白”を埋める作り方

RACIは役割分担のフレームです。

• R（Responsible）：実行責任者（手を動かす主担当）
• A（Accountable）：説明責任者（最終決裁・最終責任）
• C（Consulted）：相談先（意見を求める、双方向）
• I（Informed）：共有先（知らせる、一方向）

ポイントは、Aを必ず1人にすること。ここが複数になると「全員の合意＝誰も決めない」に戻ります。

RACIの作り方

手順1：成果物/意思決定の単位で行を作る
タスクではなく、判断が必要な“単位”にするのがコツです。

例：

• 要件凍結
• 仕様変更（軽微/重要）
• リリース可否
• 追加予算
• 受入基準変更

手順2：登場人物（役割）を列に出す
個人名ではなく役割で定義します。
例：
スポンサー、事業責任者、業務責任者、PM、開発リーダ、QA、運用、法務/セキュリティ

手順3：Aを先に置く → 次にRを置く
「誰が最終責任を持つのか」を最初に固定します。
その上で、実行するRを置き、C/Iを必要最小限に。

よくあるRACIの地雷

• Aが空欄：決める人不在の温床
• Aが複数：合意地獄になる
• Cが多すぎる：承認より遅い“相談渋滞”が起きる
• Rがいない：誰も動かない（会議だけ増える）

RACIは「きれいに埋める表」ではなく、遅延の原因を見つける検査表として使うのが実務的です。

承認フローを再設計する

次は承認フローです。狙いは「最短で決める」こと。
承認フローは、長いほど安心に見えますが、実際は責任が薄まって不安が増えることが多いです。

承認フロー設計の原則

• 承認は“意思決定”にだけ付ける（作業報告には付けない）
• 承認者はAだけ（Cは相談、Iは共有）
• 合意は“事前”に取る（会議で初めて見せない）
• 期限を決める（○営業日で未回答なら承認/差し戻し など）

「軽微変更」と「重要変更」を分ける

仕様変更が全部重いルートを通ると、決裁者が疲弊して止まります。
だから、変更を2段階に分けます。

• 軽微変更：影響小（工数小・納期影響なし・品質基準維持）
  → PM/開発リーダがAで決める
• 重要変更：納期/予算/受入基準に影響
  → スポンサー/事業責任者がAで決める

ここで重要なのは、「軽微」の条件を数字で決めることです。
例：追加工数〇人日まで、遅延〇日まで、コスト〇万円まで、など。

例外フロー（緊急時）を用意する

「障害」「セキュリティ」「法令」「サービス停止」などは、通常フローだと間に合いません。
緊急時は次の形が強いです。

• 一次判断（即時）：現場A（運用責任者など）が止血
• 二次判断（24h以内）：上位Aが追認し、恒久対策へ
• 記録義務：判断理由・代替案・影響範囲を残す

“緊急＝何でもアリ”にしないために、追認と記録が必須です。

現場で回る運用に落とす

設計しても、運用に落ちなければ元に戻ります。定着の鍵は「会議」「テンプレ」「見える化」です。

会議の型：決裁会議と共有会議を分ける

• 決裁会議：Aが出席し、決める。議題は“決めること”だけ。
• 共有会議：進捗・課題共有。決裁は持ち込まない。

共有会議に決裁を持ち込むと、参加者が多くなり、決められません。

変更申請テンプレ（最低限でOK）

承認を速くするには、資料を軽くします。おすすめの最小セットはこちらです。

• 何を変えるか（差分）
• なぜ必要か（背景・狙い）
• 影響（費用・納期・品質・運用・ユーザ影響）
• 代替案（最低1つ）
• 推奨案（提案者の結論）
• 必要な決裁（誰に何を決めてほしいか）

これが揃うと、Aは判断しやすく、Cは相談しやすくなります。

KPIで“決められているか”を測る

数字で見ると改善が回ります。

例：

• 決裁リードタイム（起票→承認までの日数）
• 差し戻し率（情報不足の割合）
• 相談渋滞（Cが多すぎる案件の比率）
• 緊急対応の追認遅延（24h超の割合）

運用が乱れると、まずリードタイムが悪化します。

よくある失敗とリカバリ

失敗1：RACIを作ったが、結局“全員C”になった

原因：不安だから関係者を増やしている。
リカバリ：Cは「判断に必要な専門性」に限定し、Iへ落とす。Cの上限を決める（例：最大3者）。

失敗2：Aを役職で置いたが、忙しくて機能しない

原因：Aの仕事量が過多。
リカバリ：権限境界を下ろし、軽微変更は現場Aに委譲。重要変更だけ上位Aへ。

失敗3：承認フローが短くなったが、揉め事が増えた

原因：合意形成を会議内でやっている。
リカバリ：事前相談（C）を“会議前”に完了させる運用へ。決裁会議では選択肢が絞れている状態にする。

失敗4：例外フローが濫用される

原因：例外条件が曖昧。
リカバリ：例外条件を明文化し、追認期限と記録を義務化。濫用はKPIで検知する。

まとめ

“決める人がいない”案件は、個人の問題ではなくガバナンスの設計不足で起きます。
まず「決裁の種類」と「権限の境界」を定義し、RACIでA（最終責任者）を必ず1人に固定しましょう。その上で承認フローを「意思決定だけ」に絞り、軽微/重要・通常/例外を分けると、判断が速くなり炎上が減ります。最後は会議の型、変更テンプレ、KPIで運用定着させることが成功の鍵です。