関係者が多すぎて決められない──意思決定者を固定する最小RACI

会議は終わった。議事録も残った。
なのに、翌日になると話が戻る。誰かが違う解釈を持ち出して、また振り出しに戻る。

関係者が多い案件ほど、これが起きます。
そしてPMほど、こう思いがちです。

もっと丁寧に根回しすべきだった。
もっと資料を作るべきだった。
もっと説明を尽くすべきだった。

でも、ここで言い切ります。
決まらない原因は、説明不足ではないことが多いです。構造の問題です。

構造の問題とは、意思決定者が固定されていないこと。
決める人が曖昧なまま、みんなが意見を言える状態だと、意見は増えます。でも決定は増えません。

前回の朝記事では、要求が増殖するのを止めるために、やらないことリストを先に合意する話をしました。

あれも本質は境界線の設計でした。

今日は、その次の論点です。
境界を引いても、決める人がいないと戻ります。だから、意思決定者を固定します。

そのための道具がRACIです。
ただし、立派なRACI表を作る必要はありません。作るほど形骸化します。
現場で回る最小形だけに落とします。

決められない現場で起きている3つのズレ

関係者が多いと、決定が止まる理由はだいたい次のどれかです。

1. 決定の種類が混ざっている

仕様を決める話と、予算を決める話と、運用を決める話が同じ会議に混ざる。
混ざると、誰が決めるかが揺れます。

2. 誰が決めるかを決めないまま進む

全員に共有しているからOK、全員がうなずいたからOK、という雰囲気決定になる。
でも後日、別の関係者が出てきて覆る。

3. 決定の責任と実行の責任が分離している

決めた人が実行に関わらない。
実行する人が決定に納得していない。
結果として、決定が守られない。

これを止める最短ルートが、役割を固定することです。
ここで役割は組織図の話ではなく、意思決定の役割です。

RACIとは何か。最小の目的だけ覚える

RACIは、役割を4種類に分けるフレームです。

• R：Responsible 実行責任、手を動かす人

• A：Accountable 最終責任、決める人、承認者

• C：Consulted 相談される人、専門家、意見提供者

• I：Informed 通知される人、共有対象

ここで大事なのは、全部を正確に分類することではありません。
現場で効くポイントは2つだけです。

• Aは1人に固定する

• CとIを増やしすぎない

これだけで決定が戻る回数が減ります。

最小RACIの作り方：1案件につき3行だけ

多くのRACIが失敗するのは、タスクを細かく分解しすぎるからです。
全タスクにRACIを当て始めると、表が巨大になり、誰も見なくなります。

最小形は、決定の論点を3つに絞ります。
3/2朝記事で書いた赤信号の3分類と揃えると運用が軽いです。

• スコープ 何をやるか、やらないか

• 期限 いつまでにやるか、遅れたら何を変えるか

• 品質 どこまでOKか、致命の定義は何か

この3つだけにRACIを当てます。表にしなくてもいい。文章でもいい。
例えばこうです。

例：最小RACIメモ

1. スコープ決定
   A：事業責任者
   R：PM、開発リード
   C：CS、営業
   I：関連部門全体

2. 期限決定
   A：PM
   R：PM、開発リード
   C：事業責任者、運用責任者
   I：関係者全体

3. 品質決定
   A：開発リード
   R：QA、開発
   C：PM、運用責任者
   I：事業責任者

このメモがあるだけで、会議が変わります。
なぜなら、何を誰が決めるかが先に固定されるからです。

Aを1人に固定するのが怖いときの考え方

Aを1人にすると、よく出る抵抗があります。

1人に責任を押し付けるのは危険では
その人が不在だったら止まる
納得感が下がる

全部もっともです。
でも、ここで誤解があります。

Aは独裁者ではありません。
Aは最後に決める人です。決める前に相談していい。むしろ相談が必須です。

だから、セットで決めるべきはこれです。

• Aは1人

• Cは必ず入れる専門領域を決める

• Aが決める期限を決める

Aを固定しないと、責任が分散して誰も決めなくなる。
Aを固定すると、相談は増えますが決定が残る。ここが違いです。

Cが増えすぎて地獄になる問題を止める

関係者が多い案件で一番つらいのは、Cが膨張して終わることです。
全員に相談しているつもりになり、誰の意見も無視できなくなる。

Cの膨張を止めるルールはシンプルです。

• Cは役職ではなく領域で決める

• Cは最大3領域まで

• Cは決定の場に出さない場合もある

例えば、品質決定ならCは運用責任者とセキュリティだけ、のように領域で絞る。
営業部長だからC、ではなく、契約上の制約があるからC、にする。

そして、相談の仕方をテンプレ化します。

• 相談したい論点は何か

• 2択は何か

• 期限はいつか

• 判断基準は何か

この形で出すと、相談が短くなります。
相談が短くなると、Cは増えても疲れにくい。逆に雑に相談するとCは増えなくても燃えます。

Iを増やすほど決まらないという逆説

Iは通知先です。
透明性のために増やしたくなる。僕もやりがちです。

でも、Iを増やすほど決まらなくなることがあります。
なぜなら、通知された人が安心するとは限らず、意見を言いたくなるからです。
結果として、Iが実質C化します。

なのでIは次のルールで扱うのが安全です。

• Iは決定後に通知する

• Iへの通知は決定ログとして残す

• Iは意見窓口を一本化する

I全員と議論しない。議論はCで止める。
意見窓口が増えると、決定はまた戻ります。

RACIを機能させるための2つの運用

RACIは作った瞬間がピークになりがちです。
形骸化しない運用は2つだけです。

1. 決定ログにAを必ず書く

決定ログには、決まった内容だけではなく、誰が決めたかが必要です。
Aが書いてあるだけで、後から覆りにくくなります。

• 決定：スコープから機能Xを外す

• A：事業責任者

• 根拠：期限赤信号回避のため

• 次アクション：代替案を次リリース候補へ

ここまで残れば、会議で戻る確率が下がります。

2. 戻りが起きたらRACIに戻して処理する

話が戻ったら、議論に巻き込まれない。
RACIに戻して、Aに判断を返します。

• その論点のAは誰か

• その人の判断期限はいつか

• Cは誰か

• Iはいつ通知するか

これを淡々とやるだけで、PMの精神消耗が減ります。
PMが抱えるべきなのは議論の感情ではなく、意思決定の交通整理です。

まとめ：関係者が多いほど、役割を先に決める

関係者が多い案件は、丁寧に説明するほど決まるわけではありません。
むしろ説明が増えるほど、論点が増えて決まらなくなることが多い。

だから最初にやるのは、資料作りではなく役割固定です。

• 決定論点を3つに絞る スコープ、期限、品質

• Aは1人に固定する

• Cは領域で最大3まで

• Iは決定後に通知し、意見窓口を一本化する

• 決定ログにAを必ず書く

これだけで、会議が終わっても戻る現場は減らせます。
そして、決まる現場は進捗報告が少なくても安心できます。決定が残るからです。

最後に問い

あなたの現場で、いま一番曖昧になっているAはどれですか。
スコープ、期限、品質。どの論点が、みんなのものになっていて、誰の責任にもなっていないでしょうか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

個別に整えたい人へ（キャリア相談）

僕は普段、30代エンジニアのキャリア停滞を抜け出す支援をしています。
現場の詰まりをほどいて、評価・役割・選択肢を整えるために、状況を一緒に棚卸しできます。

▼相談はこちら（ココナラ）：