はじめに
「RAIDログとリスクレジスターは、どちらもリスクを管理するものなの？」
「リスクを一覧にしているのに、別でRAIDログを作る必要があるのかな」と迷っていませんか。
プロジェクトを進める中で、会議で出た懸念点や発生済みの課題、他部署の対応待ち事項まで同じ表に入れてしまい、何をリスクとして追いかけるべきか分からなくなることがありますよね。
この記事では、RAIDログとリスクレジスターの違いや、それぞれの役割、リスク管理でどう使い分ければよいかを順を追って説明していきます。
RAIDログとリスクレジスターの違い
RAIDログとリスクレジスターは、どちらもプロジェクトのリスクを扱うため、同じような管理表に見えることがあります。
ここでは、それぞれの役割と、特に混同しやすいRiskとIssueの違いを整理していきます。
RAIDログ
RAIDログとは、プロジェクト中に発生するリスク、前提条件、課題、依存関係を1つの表で管理するための管理表です。
リスクレジスターが主に「まだ起きていないリスク」を記録するのに対し、RAIDログでは対応待ちの課題や他部署との依存関係、計画の前提条件もあわせて管理します。
たとえば、会議で新しい懸念点が出たときも、リスクなのか課題なのかを分けて記録できるため、担当者や期限、対応状況を整理しやすくなります。
プロジェクト全体の未解決事項を一か所で把握したいときに役立つ管理表です。
リスクレジスター
リスクレジスターとは、プロジェクトで起こる可能性があるリスクを記録し、あらかじめ対応を整理しておくための管理表です。
主に、リスクの内容、発生確率、影響度、対応方針、担当者、対応期限などを記載します。RAIDログが課題や依存関係まで管理するのに対し、リスクレジスターは「まだ起きていない問題」に絞って管理するのが特徴です。
リスクごとの優先順位を付け、事前に回避策や軽減策を考えたいときに役立ちます。
RiskとIssueの違いで混同しやすいポイント
RiskとIssueは、「まだ起きていないか」「すでに起きているか」で分けて考えると分かりやすくなります。
Riskは、将来起こる可能性があり、納期や品質、費用に影響するかもしれない項目です。一方、Issueは、すでに発生していて対応が必要な課題を指します。
発生前の懸念をIssueとして管理すると事前対策が遅れやすくなり、発生後もRiskのまま残すと担当者や期限が曖昧になることがあります。
記録する際は、その時点での状態を確認して分類することが大切です。
RAIDログとは？
RAIDログを正しく使うには、まず「RAID」という言葉が何を表しているのかを押さえておく必要があります。
RAIDログは、プロジェクト中に発生するリスクや前提条件、課題、依存関係を一つの表で整理するための管理方法です。
ここでは、RAIDの基本的な意味と4つの項目の内容を確認しながら、なぜプロジェクト管理でRAIDログが使われるのかを整理していきます。
RAIDの意味
RAIDとは、Risk、Assumption、Issue、Dependencyの頭文字をまとめた言葉です。
Riskは将来起こる可能性があるリスク、Assumptionは計画を立てる際の前提条件、Issueはすでに発生している課題、Dependencyは他の作業や担当者に左右される依存関係を指します。RAIDログでは、これら4つを1つの管理表で整理して管理します。
そのため、プロジェクトで確認すべき事項を種類ごとに分けながら、一元的に把握しやすくなります。
Risk・Assumption・Issue・Dependencyの内容
Riskは、まだ発生していないものの、発生すると納期、品質、費用に影響する可能性がある項目です。
Assumptionは、計画を作る時点で「この条件で進める」と置いている前提条件です。Issueは、すでに発生していて、担当者が対応しないと次の作業や判断に進めない課題です。
Dependencyは、他の担当者、部署、作業の完了に左右される関係を指し、相手側の遅れが自分たちの作業開始や完了に影響する項目です。
なぜプロジェクト管理でRAIDログが使われるのか
プロジェクト管理でRAIDログが使われるのは、会議で出たリスク、前提条件、課題、依存関係を1つの表に残し、担当者と対応期限を確認できるようにするためです。
プロジェクトが進むと、未対応の項目がメール、議事録、チャットに分かれて残りやすくなります。そのままにすると、誰がいつまでに対応するのか分からなくなり、次回会議で同じ確認を繰り返すことになります。
RAIDログにまとめておけば、各項目の状態を確認しながら、対応漏れや判断待ちを減らしやすくなります。
RAIDログはリスク管理でどう使われる？
RAIDログは、リスク管理を進めるうえで、発生前のリスクだけを記録するものではありません。
ここでは、RAIDログとリスク管理の関係を整理しながら、活用するメリットと、リスクレジスターだけでは管理しにくい理由を見ていきます。
RAIDログとリスク管理の関係
RAIDログは、リスク管理で確認すべきリスクを記録し、発生前の対応を追うために使われます。
リスクとして記録する内容は、起こり得る問題、発生した場合の影響、対応する担当者、対応期限、現在の状態です。会議で新しい懸念点が出たときにRAIDログへ追加しておくと、次回以降の会議で未対応のまま残っているリスクを確認できます。
リスクを記録しただけで終わらせず、担当者と期限まで見える形にすることで、発生前に対応を進めやすくなります。
RAIDログを使うメリット
RAIDログを使うメリットは、リスクを担当者、期限、対応状況と一緒に確認できることです。
リスクの内容だけを記録していると、誰が対応するのか、いつまでに確認するのかが曖昧になりやすくなります。RAIDログにまとめておけば、会議のたびに未対応のリスクを確認し、期限を過ぎている項目や対応待ちの項目を見つけやすくなります。
そのため、リスクを発見しただけで終わらせず、発生前の対応まで進めやすくなります。
リスクレジスターだけでは管理しにくい
リスクレジスターだけでは管理しにくい理由は、発生前のリスク以外の項目を同じ表で追いにくいからです。
プロジェクトでは、リスクとして記録した内容が実際に起きて課題に変わったり、他部署の回答待ちによって作業が止まったりすることがあります。
リスクレジスターだけで管理すると、発生済みの課題や依存関係を別の表や議事録で確認する必要があり、担当者、期限、対応状況が分かれやすくなります。
そのため、リスクの発見から課題化した後の対応まで続けて追う場合は、RAIDログのほうが管理しやすくなります。
RAIDログとリスクレジスターはどちらを使うべき？
RAIDログとリスクレジスターは、どちらか一方だけが正しいというものではありません。
ここでは、プロジェクトの状況に応じた使い分けと、実務で併用されるケースを整理していきます。
小規模プロジェクトで向いているケース
小規模プロジェクトでは、関係者が3〜5人程度で、会議やチャットで確認する項目がそれほど多くない場合、RAIDログが役立ちます。
リスクや課題、前提条件、依存関係を別々の表で管理すると、更新漏れや確認漏れが起きやすくなるためです。1つの表に分類、担当者、期限、対応状況をまとめておけば、未対応の項目も把握しやすくなります。
リスクだけでなく、プロジェクト全体の確認事項をまとめて管理したい場合に向いています。
複雑なプロジェクトで向いているケース
複雑なプロジェクトでは、関係者が10人以上になり、リスクや課題、依存関係が増える場合、RAIDログとリスクレジスターを使い分けると整理しやすくなります。
リスクレジスターでは、発生確率や影響度、対応方針、担当者、期限などを記録し、リスクごとの優先順位を管理します。一方、RAIDログでは、発生済みの課題や他部署の対応待ちも含めて、プロジェクト全体の状況をまとめて把握できます。
リスクを詳しく管理しながら、未対応の項目もあわせて確認したい場合に向いています。
実務では併用されることも多い
実務では、RAIDログとリスクレジスターを併用するケースも多くあります。
RAIDログでは、リスクや課題、前提条件、依存関係をまとめて確認し、リスクレジスターでは、重要なリスクを発生確率や影響度、対応方針まで詳しく整理します。
RAIDログだけではリスクの分析が十分でない場合があり、リスクレジスターだけでは課題や依存関係を一覧で把握しにくくなります。
そのため、全体の状況はRAIDログで確認し、重点的に対策が必要なリスクはリスクレジスターで管理する使い分けがよく行われています。
RAIDログの簡単な記載例
RAIDログは、項目を増やしすぎると更新が続かなくなり、会議で確認しづらい管理表になってしまいます。
最初は、内容・担当者・期限・状態など、最低限の項目に絞って書くと運用しやすくなります。
ここでは、RiskとIssueの簡単な記載例を確認しながら、無理なくシンプルに使い続けるコツを整理していきます。
Riskの記載例
Riskには、まだ発生していないものの、起きると納期や品質に影響する内容を記載します。
たとえば、「外部ベンダーからの回答が5営業日以内に届かない場合、設計レビューの開始が遅れる可能性がある」と書きます。あわせて、担当者、確認期限、対応状況を入れておくと、誰がいつまでに確認するのかを追いやすくなります。
Riskは発生前に対応する項目なので、「回答期限を事前に確認する」「代替案を準備する」など、発生を防ぐための行動まで記録します。
Issueの記載例
Issueには、すでに発生していて、対応しないと作業や判断が止まる内容を記載します。
たとえば、「設計レビューで指摘された認証方式の修正方針が決まっておらず、開発着手日までに仕様を確定できない」と書きます。あわせて、担当者、対応期限、現在の状況を入れておくと、誰がいつまでに判断するのかを確認しやすくなります。
Issueは発生済みの課題なので、「修正方針を決める」「関係者に確認する」など、次に取る行動まで記録します。
シンプルに運用するコツ
RAIDログをシンプルに運用するには、最初から入力項目を増やしすぎないことが大切です。
項目は、分類、内容、担当者、期限、対応状況の5つに絞ると、会議中でも記録しやすくなります。内容は1行で書き、担当者は1人に決め、期限は「確認中」ではなく日付で入れます。
入力する項目を少なくしておくことで、更新に時間がかからず、週1回の確認でも未対応のRiskやIssueを追いやすくなります。
まとめ
RAIDログとリスクレジスターは、どちらもプロジェクト管理に役立つ管理表ですが、役割は同じではありません。
リスクレジスターは発生前のリスクを詳しく管理するためのもので、RAIDログはリスクだけでなく、課題や前提条件、依存関係もまとめて整理できるのが特徴です。
小規模プロジェクトではRAIDログだけで十分な場合もありますが、関係者やリスクが増えるプロジェクトでは、リスクレジスターと併用すると状況を把握しやすくなります。
また、RiskとIssueを混同せず、「まだ起きていないこと」と「すでに起きていること」を分けて管理することも大切です。
どちらが優れているというわけではなく、プロジェクトの規模や管理したい内容に合わせて使い分けることがポイントです。
それぞれの役割を理解し、自分のプロジェクトに合った方法を選んでみてください。