はじめに
プロジェクト計画書は「誰のための文書」なのかで、体制図・役割分担を記載する重要性に触れましたが、「役割」を書くだけでは不十分な場面があります。特に、複数の関係者が絡む意思決定の場面で、最終的に誰が決めるのかが曖昧なままプロジェクトが進んでしまうケースです。
SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応してきた経験から、RACIという考え方を使った役割分担の整理方法を解説します。
「関わっている人」と「決める人」は違う
プロジェクトの意思決定の場面では、多くの人が「関わって」います。業務部門も、情報システム部門も、ベンダーのPMも、何らかの形でその決定に関わっています。しかし、実際に最終判断を下す人(Accountable)は、原則として1人でなければなりません。
ここが曖昧なまま進めると、「業務部門はOKと言ったのに、情報システム部門が後から反対した」というような、決定が覆る事態が起きます。RACIという枠組みを使うことで、作業項目ごとに関係者の立場を明確にできます。
- **R(Responsible:実行責任者)** 実際にその作業を行う人
- **A(Accountable:説明責任者)** 最終的な意思決定・承認を行う人。必ず1名のみ
- **C(Consulted:相談先)** 意思決定の前に意見を求められる人
- **I(Informed:報告先)** 決定後に結果を知らされる人
Aは必ず1名に絞る
RACIを整理する際に一番つまずきやすいのが、Accountable(説明責任者)を複数人にしてしまうことです。「みんなで決める」という建前は聞こえが良いですが、実際には誰も最終責任を取らない状態になりがちです。
重要な意思決定ほど、Aを1名に絞ることを徹底してください。これは独裁的な進め方を推奨しているのではなく、「最終的に誰が責任を持つか」を明確にすることで、意思決定のスピードと説明責任の両方を確保するためです。
体制図は「ボックス&ライン」でなくてもいい
体制を整理するというと、組織図のようなボックス&ライン形式の図を思い浮かべる人が多いですが、実務上は一覧表形式の方が運用しやすいことがほとんどです。
ボックス&ライン図は見栄えが良い反面、メンバー変更のたびに図を描き直す手間がかかります。一覧表であれば、行の追加・削除だけで体制変更に対応できます。見た目の整った資料を作ることより、プロジェクトが進む中で実際に更新され続けることの方がずっと重要です。
まとめ
プロジェクトの意思決定を迷走させないためには、「誰が実行するか」だけでなく「誰が最終決定するか」を明確にすることが欠かせません。RACIという枠組みを使い、Accountableを必ず1名に絞ることで、意思決定のスピードと説明責任を両立できます。
実際に使っている体制表・RACI表のテンプレートは、noteで配布しています。
執筆者プロフィール:SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応。基幹システム刷新・DX推進プロジェクトに多数従事。


コメント