4 つの役割タイプ
RACI には 4 つの参加者タイプがあり、以下に説明します。 RACI マトリックスを作成する前に、それぞれを理解することが必須です。
実行責任者
タスクや成果物を完成させるための「実行責任」を担う役割。 たとえば、実行責任者の役割がテクニカル ライターであれば、テクニカル ライターはオンライン ヘルプ ファイルの作成を担当することができます。 ソフトウェア開発者は、ヘルプ ファイルを書くのではなく、そのファイルを製品に組み込むことになるかもしれませんが、それは別の作業になります。
説明責任者
「説明責任者」の役割は、タスクの完了に関する最終的な権限や説明責任を有します。 前述のテクニカル ライターがオンライン ヘルプを作成し、ソフトウェア開発者がそのヘルプ ファイルを組み込むという例と同様に、プロダクト マネージャーはそのファイルが製品に入っているかどうかを確認する責任があります。
相談先
「相談先」を担う役割は、タスクのアドバイザーとなります。 たとえば、スクラム マスターは対象分野の専門家であるため、相談を受ける場合があります。 この役割を担う人が多すぎると、作業時間が長くなり、パフォーマンス低下のリスクが高まるため、アドバイザーは慎重に検討する必要があります。
報告先
「報告先」の役割は、タスクの完了について最新の情報を得ることです。 この役割をグラフ化することで、依存関係を明らかにし、タスクのステータスの透明性を確保することができます。 ステータスの更新が必要な人の特定は複雑になる可能性があるため、時間をかけてさまざまな役割の人に相談し、タスクがいつ完了したかを知る必要があるかどうかを判断することをお勧めします。 たとえば、お客様がある機能の開発に特別な関心を持っているため、セールス マネージャーがステータスの更新を要求することがあります。
どのような場合に RACI を使うのか
RACI マトリックスは、プロジェクト管理の一般的な実践方法として有用ですが、RACI パラダイムの実践には明確な指標があります。
- 承認プロセスが滞っている場合、それは役割の混乱が原因かもしれません。
- 恣意的に決定が覆されることが多い場合も、役割を明確にした方が良いでしょう。
- また、同じ分析タスクを多くの人が行っているということもよくある状況です。 タスクが進まないのは、誰がやるべきかわからないからかもしれません。
- タスクを実行する権限が理解されていない場合は、役割とタスク、責任と権限を定義する必要があるかもしれません。
このような混乱を解消し、役割やタスクを明確にすることが RACI マトリックスの最大の機能です。
RACI は最も人気のあるモデルの一つですが、それ以外にも以下のようなモデルがあります。
- PACSI- 複数の関係者が 1 人の説明責任者の作業を確認し、拒否できる状況で使用されます。 役割には、Performed (実行者)、Accountable (説明責任者)、Control (管理者)、Suggested (提案者)、Informed (報告先) などがあります。
- RAPID- Bain & Company が作成した、役割と責任を明確にすることで意思決定の説明責任を明確にする方法。 役割としては、Recommend (推薦)、Agree (同意)、Perform (実行)、Input (インプット)、Decide (決定) があります。
RACI の価値
RACI モデルを導入することで、より多くの有能な人材をプロジェクトに参加させることができます。 しかも、グラフの開発は簡単です。 プロジェクト マネージャーは、この方法を使って、プロジェクトの配置が一目でわかるグラフをすばやく作成できることを高く評価するでしょう。
RACI のメリットは以下のとおりです。
- 役割の混同がなくなる。
- あるプロジェクトにリソースが過剰に割り当てられ、別のプロジェクトのリソースが不足することを防ぐ。
- 役割を担うすべての人に対して、役割を明確に定義する (何が期待されるかを明確に理解することが、円滑なプロジェクトの鍵であり、後の紛争解決の必要性を減らします)。
- リソースの割り当ての際に、見落とされるタスクをなくす。
- 人事異動の際のリソースの再配分を迅速かつ効率的に行う方法を提供する。 新入社員は、プロジェクトにおける自分の役割や、関わりを持たなければならない人の役割をすぐに確認することができる。
最後に、報告先カテゴリーに同じ重みを与えられているため、RACI マトリックスは役割間のコミュニケーションを促進します。 コミュニケーションは期待されることを明確に理解するための鍵であり、スムーズなプロジェクトにつながります。
RACI マトリックス
RACI チャートとは、責任者や役割に関連するすべてのプロジェクト活動のマトリックスです。 「すべてのプロジェクト活動」には、計画、テスト、設計、サポートなど、開始した日からのすべてが含まれます。
RACI マトリックスの作成には、次の手順が含まれます。
- マトリックスのグラフ化方法を決定する—スプレッドシート、ホワイトボード、ソフトウェア ソリューションなど、さまざまなツールやテンプレートを使用することができます。
- プロジェクトのタスク (または成果物) を特定する—主な関係者とミーティングを行い、プロジェクトのタスクのリストを作成します。 ここでいう「タスク」には、開催する必要のある会議やイベントなどのアクティビティ、機能や製品などの成果物が含まれます。 タスクは、マトリックスの X 軸または Y 軸を横切ってラベル付けされます。 たとえば、アジャイルで開発されたソフトウェア プロジェクトのグラフを作成している場合、スプリント デモ ミーティングは必須のアクティビティであり、タスクとしてマトリックスに含める必要があります。タスクとして RACI マトリックスのメンテナンスを追加することも忘れないでください。 通常、プロジェクト マネージャーが RACI マトリックスを管理します。
- プロジェクトの役割を特定する—プロジェクトの役割は、タスクに使用されなかったマトリックスの軸の下にラベル付けされます。 プロジェクトの役割は、マトリックスをより理解しやすくし、忘れていたデータを追加するのにも便利です。 役割を特定すると、その役割に応じたタスクが思い浮かぶので、それをタスク軸に追加します。 また、タスク軸は、役割を特定し、リソースの割り当てを明確にするのに有効です。 この時、役割にも名前を付けると良いでしょう。1 つの役割に 1 つの名前を付けるのが最適です。
- 軸の交点にラベルを貼る—X 軸と Y 軸が交わるところに R、A、C、I のラベルを貼り、各タスクについて誰が実行責任者、説明責任者、相談先、報告先になるのかをマトリックスに記入して完成させます。
RACI ガイドライン
RACI マトリックスはプロジェクトに固有のものですが、留意すべき大まかなガイドラインやベスト プラクティスがあります。
- 複数のレベルでの監督を避ける - 1 つのレベルで十分
- チームワークの強化
- グラフの流動性を維持する - 必要に応じて変更を加え、変更があった場合はユーザーに知らせる
- 1 つのタスクに対して 1 つの説明責任者のみを割り当てる
- 説明責任者が、タスクを確実に完了させる権限を持っていることを確認する
- コンサルタントの数が多すぎると、時間がかかりすぎる (回答を待つ、意見を集めるなど) ので避ける 逆に少なすぎるとパフォーマンスが低下するので、「適切な数」を探してみてください
- 割り当てられた役割を全員に通知する
適切な RACI テンプレートを見つける
RACI テンプレートは、時間を節約し、グラフを構築するための出発点となります。 しかし、数多くのテンプレートがありますので、さまざまなスタイルを検討し、プロジェクトのニーズに合ったものを見つける必要があります。
テンプレートの中には、X 軸をタスクに、Y 軸を役割に使うものもあれば、その逆のものもあります。 一般的に、タスクが役割を上回る場合は、タスクに X 軸を、役割に Y 軸を使用すると、ほとんどのコンピューターのモニターで、タスクごとに最大数の役割を一目で確認できます。 一方で、タスクを X 軸にして、役割に基づいてグラフをフィルターする (例: あるタスクの「I」の役割だけを表示するようにフィルターする) 方が簡単だと思うかもしれません。 また、ほとんどのテンプレートは何らかの形で色分けされています。
どのテンプレートを選択するにしても、テンプレートを使用すると、グラフを作成する際の基本的な作業の多くが不要になり、役割とタスクを定義するための時間を確保することができます。
RACI プロジェクト管理
RACI 分析
RACI プロジェクト管理は、RACI マトリックスの分析と管理に重点を置いており、問題の特定、役割の競合の解決、役割の分類の修正、チームへのフィードバックの機会の提供ができるようにします。 分析はチーム ミーティングで行われるべきですが、ミーティングに役割を担うすべての人が参加する必要はありません。
RACI マトリックスは、垂直方向と水平方向に分析されます。 ここでは、役割の軸 (水平か垂直か) を見直す際に注意すべき点をご紹介します。
- ある役割の責任が大きすぎる場合、一部の責任を再割り当てすべきでしょうか、それともより多くの人をその役割に割り当てるべきでしょうか？
- 1 人だけが説明責任者である場合、その人がすべての決定を行うことを期待するのは妥当でしょうか。あるいはボトルネックを生じさせて、プロジェクトを脅かすことにならないでしょうか？
- ここでは、タスクの軸 (水平か垂直か) を見直す際に注意すべき点をご紹介します。
- 実行責任者がいないタスクがある場合、誰かを割り当てるべきでしょうか、それともタスクをなくすべきでしょうか？
- 説明責任者がいないタスクがあった場合、誰が意思決定権を持つのでしょうか？
- 1 つのタスクに対して複数の説明責任者がいる場合、1 人の人を説明責任者にすることで衝突を避けることができます。
- 相談する人が多すぎる場合は、関係者と話をする人を 1 人配置できないかを検討してください。
役割の混乱
プロジェクトの期間中、チーム メンバーが役割の混乱に陥ることはよくあることです。 RACI マトリックスは、プロジェクトに関連する役割を明確に識別し、生産性を向上させるのに役立ちます。特に、役割の混乱で悩まされている場合に有効です。 役割の混乱の兆候は次のとおりです。
- 誰が意思決定を行うかに関する懸念—意思決定者は通常、説明責任者とされていますが、実行責任者が意思決定を行っている場合もあります。 その場合、チームはそれぞれの状況で誰が意思決定をするのかを知る必要があります。
- 非難—仕事が時間内に終わらないと、非難されることがあります。 これを避けるためには、誰が責任を負うのかを知ることが重要です。
- リソースの割り当ての不備—RACI マトリックスは、リソースの割り当てを非常に明確にするはずですが、1 つのタスクに非常に負担がかかり、誰がいつ何をすべきかという問題につながることがあります。
- 非効率なコミュニケーションによるアクションの欠如—知らされていなければ、その人はタスクを実行する必要があることを知らないかもしれません。
- 間違った相手に相談しているために相談件数が多すぎる—プロジェクトのスケジュールを危険にさらさないように、相談先を明確に表示する必要があります。
役割の混乱が疑われる場合に介入し、役割を明確にして、全員が期待を認識できるようにすることは、プロジェクト マネージャーの義務です。
プロジェクト管理部門向けの Smartsheet
プロジェクト管理・共同作業・コミュニケーション用プラットフォームの Smartsheet は、スプレッドシート形式で使いやすく、役立つ機能も豊富に備えています。 ガント、カレンダー、グリッド、ダッシュボードなどの多彩なビューを利用できるので、思いどおりのプロジェクト管理が可能です。 プロジェクト要件の追跡、ドキュメントの保存、タイムラインの作成、重要な詳細情報の整理ができます。
