PMBOKとRACI

PMBOKは、立ち上げから計画、実行、監視、終結までの流れと、スコープ・スケジュール・コスト・品質・資源・コミュニケーション・リスク・調達・ステークホルダーといった管理領域を体系立てて説明しています。RACIは、このうち主に資源やコミュニケーションの領域で、役割と責任を明確にするための補助的な道具として登場します。

軸を分けると分かりやすくなります。PMBOKは「プロジェクト全体で何を管理するか」という枠組みを与え、RACIは「個々の作業を誰が担うか」という粒度の割り当てを扱います。前者が地図なら、後者は地図上の分担表にあたります。

• 知識体系としての役割
  PMBOKは用語や手順の共通言語を提供し、プロジェクト全体の抜けを防ぐ観点の一覧として働きます。
• RACIが担う部分
  WBSなどで分解した作業に対し、実行・承認・相談・報告の関係を一覧化し、責任の所在を目に見える形にします。

PMBOKを読んだだけでは役割の割り当ては決まりません。RACIはその空白を埋める具体的な記法として使われる、と捉えると両者の関係が整理しやすくなります。

RACIは単独では作りにくく、先に作業の分解があると進めやすくなります。PMBOKの流れに沿うと、スコープを定義し、WBSで成果物や作業を洗い出した後に、各行へ役割を割り当てる順になります。

1. 縦軸に作業や成果物を並べる
   要件定義書、基本設計書、テスト計画といった成果物や、承認・レビューなどの作業単位を行に置きます。
2. 横軸に関係者を並べる
   プロジェクトマネージャー、設計担当、開発担当、発注元の担当者、品質保証など、登場する役割を列に置きます。
3. 交点にR・A・C・Iを入れる
   各作業について、手を動かす人、最終的に責任を負う人、意見を聞く人、結果を知らせる人を記入します。

埋めた後は、各行にAが一つだけ置かれているかを確認します。説明責任者が複数いると承認の流れが滞り、ゼロだと誰も最終判断をしないまま進む恐れがあります。縦に見てAばかりの人がいれば負荷の偏りを、Rが全く無い作業があれば実行役の抜けを疑います。こうした点検をPMBOKの各管理領域ごとに繰り返すと、役割の設計が安定します。

RACIでよくあるつまずきは、作成そのものが目的化してしまうことです。きれいな表を一度作っても、関係者が中身を知らなければ役割は動きません。作成後に全員で読み合わせ、合意を取る工程まで含めて初めて機能します。

• 記号の解釈がそろわない
  CとIの違いが曖昧なまま運用すると、相談したつもりが報告だけで終わり、意見を言う機会が失われます。各記号の意味を先に言葉で定義しておきます。
• 作業の粒度が粗すぎる
  「設計」のような大きな単位では担当が重なりやすく、割り当てが曖昧になります。承認、レビュー、修正のように動詞で分けると役割がはっきりします。
• 変更が反映されない
  体制やスコープが変わっても表を更新しないと、実態と食い違います。変更管理の中で見直す対象に含めておくと、ずれを抑えられます。

PMBOKが監視とコントロールを一つの区切りとして扱うように、RACIも作成後に点検し続ける対象だと考えると、現場で使える道具になりやすくなります。

RACIと混同されやすいものに、組織図やガントチャートがあります。軸を分けて比べると役割の違いが見えてきます。

• 組織図との違い
  組織図は所属や指揮命令の上下関係を示しますが、個々の作業で誰が何をするかまでは表しません。RACIは作業単位で関与の種類を示す点が異なります。
• ガントチャートとの違い
  ガントチャートは作業の時間的な順序や期間を示します。RACIは時間ではなく責任の分担を扱うため、両者は補い合う関係です。
• RAM（責任分担マトリクス）との関係
  RACIは責任分担マトリクスの代表的な形式の一つで、関与の区分をR・A・C・Iの四つで表したものにあたります。

PMBOKではこれらを別々の道具として扱い、必要に応じて組み合わせます。どれか一つで全てを賄おうとすると、時間と責任のどちらかが抜け落ちます。何を可視化したいのかを先に決め、目的に合う道具を選ぶと、資料が増えすぎず運用も続けやすくなります。

PMBOKとRACIを結びつけて語れると、プロジェクトマネージャーとしての体制設計の考え方を示しやすくなります。知識体系で全体の抜けを防ぎつつ、RACIで役割の所在を具体化する、という二段構えは、規模の大きなプロジェクトほど効いてきます。面接や職務経歴の場面では、どの工程でどの成果物に対し、誰にどう責任を割り当てたかを語れると、抽象的な管理経験よりも伝わりやすくなります。

日々の実務でも、役割の重複や抜けに気づいて早めに手を打った経験は、調整力の裏づけになります。表を作る技術そのものより、作った後に合意を取り、変更に合わせて見直し続けた姿勢を言葉にしておくと、担当できる範囲の広さを示す材料になります。

PMBOKにRACIは必ず載っていますか。

RACIはPMBOKの中で責任分担を表す代表的な手法として紹介されてきました。ただしPMBOKは特定の様式を強制するものではなく、プロジェクトの事情に合わせて記号や粒度を調整してよい、という位置づけです。手法の一例として捉えるのが実務に合います。

RACIのAとRはどう使い分けますか。

Aは説明責任者で、その作業の最終的な結果に責任を負い、承認や判断を行う役割です。Rは実行役で、実際に手を動かす人を指します。一つの作業にAは一人に絞り、Rは複数いても構いません。両者を分けると、承認の流れと作業の流れが整理されます。

プロジェクトマネージャーはRACIのどこに入りますか。

固定ではなく、作業ごとに変わります。進捗の取りまとめではA、個別の設計作業ではIやCになることもあります。全ての行でAを担うと負荷が偏り判断も滞るため、権限を委ねられる作業は他の役割にAを任せる設計が現実的です。