プロジェクトマネージメント

プロジェクトの責任分担管理表であるRACI。Responsible、Accountable、Consulted、Informedの4つの役割が基本だが、実はこれに役割を追加した発展版もいくつかある。必ず必要な役割ではないだろうが、発展版も把握しておくことで、プロジェクトの状況に応じて提示できる解決策の幅が広がるだろう。まだ、RACIの基本を学習していない方はこちらを先に参照してほしい。（→RACIチャートの意味とは？プロジェクトの責任分担を見える化する！）

Responsibleを分解したRASCI

通常のRACI図では、実行責任者であるResponsibleは複数人いても問題ない。しかし、あまりに多いと、タスクの実行・完了の最終責任が誰にあるのか不明確になるという弊害もある。そんな時に、あくまで実行責任者を一人に特定し、その他の実行者をSupportとして明確に区別したのが、RASCIだ。従来のResponsibleを2分割したものとも言える。

Responsible（実行責任者）：タスクの実行・完了に責任を負う者。
Support（サポート）：Responsible配下に当てられた者。Responsibleと共に実際にタスクを実行する。（実際にタスクを実行するため、Consultedとは違う。）

担当者だけでなく無関係者も明確化したCAIRO（RACIO）

通常のRACI図に、Oを追加したものだ。

Omitted、もしくはOut of Loop（部外者）：タスクに関係ない者。

通常のRACIでは、タスクに関与しないリソースを特に役割がなく基本的には部外者であると明確化することも有効な場合もある。（Oの人間は、特定の会議に呼ばないという規則を作って、リソースの効率化するなど）

検証者と承認者を追加したRACI-VS

RACIに新たな二つの役割を追加したものだ。

Verifies（検証者）：成果物が当初の基準を満たしているか検証する者。
Signs off（承認者）：Verifiesの検証結果を承認する者。承認し、次の工程への受け渡しに責任を持つ。

Verifiesは、Accountableが設定した基準などを、Responsibleが達成しているかを検証する役割だ。第三者的に検証する場合もある。
Signs offは、Accountableと同じ人物であることもあるが、クライアントなどAccountableとは別になることもある。Signs offが多すぎると、プロジェクトのスピードが落ちる。

いずれも成果物の結果に責任を持つ者(Accountable)と、その結果の判断をする者を明確に分けたい時に有効だろう。

バリエーションを知ることで、引き出しが増える。

RACI図さえ知っていれば、基本的な対応は可能だ。しかし、RACI一つしか知らないと、それが絶対だと思ってしまいフレームワークに囚われた状態になってしまう。派生系を知っていれば、プロジェクトの状況に合わせて柔軟に活用することもできる。また、フレームワークは本来作るものだ。状況に応じては、その状況にあったオリジナルな役割を追加するという柔軟性があってもよいだろう。

RACI(レイシー)チャートとは、プロジェクトにおいて、プロジェクトメンバーの役割を明確にするためのフレームワークだ。コンサルタントがプロジェクトマネージメントでよく使用したりする。ステークホルダー（関係者や組織）が多い時に特に有効なツールとして利用できる。そんなRACIチャートがどんなフレームワークで、どのような場面で利用されるのか、解説する。

RACIチャートとは、役割や責任を定義するフレームワーク

「この件は誰がボールをもっているんだ？」
「渡辺さんが進めてたんじゃなかったの？」
それぞれの役割が明確でないと、このように、誰も進めていないタスクが発生したり、ボールの押し付け合いが発生したりする。
このような事態が発生しないようにプロジェクト、特にステークホルダーが多いプロジェクトでは、役割の明確化が重要だ。
RACIチャートは、そんな時のために使用されるフレームワークの一つだ。

RACIチャートは一言で言えば責任分担表だ。
RACIチャートでは参加者を以下の4つに分類する。
参加者は、人の場合もあれば、複数の組織が関わる場合は、組織単位の場合もある。

Responsible（実行責任者）：タスクを実際に実行することに責任を持つ人。複数いることもある。
Accountable（説明責任者）：タスクの結果に最終責任を持つ人。成果物やタスクの遂行に対して上層部などへ説明責任を持つ。タスクの承認者ともいえる。１人にすべきである。
Consulted（協業先）：タスクに対して相談を受ける人。実行や成果に明確な責任は持たないが、必要な専門知識などをもっており必要に応じてサポートする。
Informed（報告先）：タスクの進捗・完了や成果物について、報告を受ける人。

Consulted（協業先）とInformed（報告先）は、必ずしも必要でないが、Responsible（実行責任者）とAccountable（説明責任者）は必須となる。

RACIチャートを作る際、しっかりこの4つの定義を理解している必要がある。いざ作り始めて、作りづらさを感じる時は、ここの定義がしっかりわかっていないもしくは明確に決定されていない場合が多い。以下がよくごっちゃにされてしまう役割の違いだ。

あいまいにされやすいResponsibleとAccountableの違い

上司と部下で例えるとわかりやすい。部下はタスクを実際に実行するが、その結果を更に上の部長に報告するのはその部下の上司だ。部下がやらかしたら、上司が責任をとらされる。だから、上司は部下のタスク内容を管理や承認する。この場合の部下がResponsibleで上司がAccountableだ。

実際の現場でタスクの最終責任者が実際に実行する場合、つまりResponsibleとAccountableが同じ人物の場合も当然ある。

わかりにくいConsultedとInformedの違い

ConsultedとInformedもまた、区別がつかず混同されることが多い二つだ。
わかりやすい違いは２点。
・Consultedではコミュニケーションが双方向だが、Informedは一方通行の報告。
・Consultedでは主に動く前にコミュニケーション(相談)する。Informedでは主に動いた後にコミュニケーション(報告)する。
Consultedはどう進めるか困ったときに聞く人、Informedは進捗があった後に伝えておく人だ。

 RACIチャートの例

上記のRACIの各役割の定義を踏まえ、実際のRACI表（チャート）は例えば以下の通りになる。

縦軸に人（もしくは組織）、横軸にタスク、そして各マスに役割が記載されている。
見ての通り、ResponsibleとAccountableは同じ場合もあれば、ConsultedとInformedはない場合が多い。

多数のステークホルダーで責任分担の認識をしっかり共有することが重要

RACIチャートが最も効果を発揮するのは、多数の参加者（ステークホルダー）がいる複雑なプロジェクトの場合だ。逆に、少人数のプロジェクトでは、わざわざRACIチャートを作らなくとも、各タスクの担当者を決めているレベルで十分回るケースが多い。複雑なプロジェクトでは、ボールがどこになるのか不明確にならないよう、RACI図を整理して公開しておくとよい。

逆にうまく行っていないプロジェクトで、現在のRACIチャートを書いて、役割が不明確なところを特定するという、問題解決的な使い方も可能だ。役割の不明確さだけでなく、AccountableとResponsibleの担当部署が遠すぎて、うまく連携できていない、という課題を特定できたケースも過去にあった。
ステークホルダーが多く、複雑なプロジェクトでは、RACIチャートを整理するのも手だ。

→問題解決の幅が広がる！RACIの4つだけでないRACI図の発展版