RACIチャート(責任分担マトリックス)を作る

2017年12月16日

PMBOKにRACIチャート(責任分担マトリックス)というものが出てきます。みなさんもこれに準じたフォーマットの資料を作成しているのではないでしょうか?

簡単に言うと役割分担表です。プロジェクトの計画を立てるときには必要不可欠なものです。

しかし、PMBOKを学習することで、より深い理解ができるようになり、作成するうえでも、思いをこめられるようになりました。

RACIチャート(責任分担マトリックス)とは

PMBOKガイドから引用してみましょう。

ワーク・パッケージとそれに割り当てたプロジェクト資源を格子状に示す表

よくわかりません。ワーク・パッケージとはなにか? から説明しなければなりませんね。

ワーク・パッケージとはWBSの最下位に位置するものでした。成果物を作成するための作業を要素分解した結果の最小の粒度です。

それに、プロジェクト資源を割り当てます。ここいう資源は人的資源を指しています。

このような図ですね。WP(ワーク・パッケージ)ごとに、人的資源であるプロジェクトメンバーを割り当てています。

RACIチャートイメージ

  • R:実行責任
  • A :説明責任(一番責任が強い)
  • C:相談対応
  • I:情報提供

ワーク・パッケージに対する、人的資源の役割を入れていくことで完成します。

実際のプロジェクトでは

実際のプロジェクトでも、似たようなものをつくっているのではありませんか?

WP(ワーク・パッケージ)に該当する部分は、それぞれのプロジェクトによって粒度も異なりますが、成果物や作業に対して人を割り当てていき、責任も付けていく一覧表です。

このような考え方はPMBOK特有ではありません。ツールのひとつとしてあげられています。

これが役に立つ場面はどこなのでしょうか? プロジェクトメンバーの割り当ては普通に考えられることです。

これが効力を発揮するのは、顧客との役割分担を決めるときです。

顧客との役割分担を明確に

みなさんも、プロジェクト内部、プロジェクトメンバー向けの作業割り振りには、丹精こめて役割分担を作っていることと思います。

しかし、顧客との役割分担はどこまで詳細に作成していますか? わりとざっくりしたもの(見積もりのときに提出したもの)で済ませていませんか?

こんなレベルです。

RACIチャートイメージ現行PJ

  • ○:主担当
  • △:支援・承認

これでプロジェクトを突っ走ろうとしても、アバウトすぎて危険なことになりかねません。プロジェクトの規模によりますが、お勧めできません。

顧客レビューをするならば、顧客側の担当者を複数名記載し、その責任分担も記載しておくとよいでしょう。

同じように受け入れテストの担当なども記載します。そうすれば、顧客側の責任の持たせ方も違ってきますし、説明責任レベルを割り当てられた担当者には、実際にレビュー結果を報告してもらうこともします。

このレベルまで実施することで、顧客も責任を持ってプロジェクトへ参加してくれます。反発もありますが、そこは、顧客と納得行くまで話をします。それがプロジェクトマネージャです。

プロジェクトに対して責任を持ってもらえば、この先の進め方もやりやすくなっていきます。

まとめ

PMBOKガイドで紹介されているRACIチャート(責任分担マトリックス)は、プロジェクト内部、特にベンダー側の役割分担について書かれているように、管理人は感じました。

プロジェクトは、顧客とベンダーの両方で進めていくものです。

その視点について、感じたことを書いて見ました。参考にしてもらえればと思います。

 

PM

Posted by wpmaster