プロジェクトを進めていると、「リスクがあることは分かっていたのに対応が遅れた」「前提条件が変わったのに計画を見直していなかった」「課題が発生しているのに誰も管理していなかった」といった問題が起こることがあります。
プロジェクト管理では、タスクやスケジュールだけを見ていれば十分というわけではありません。実際には、リスク、前提、課題、依存関係といった、プロジェクトを左右する要素を継続的に管理する必要があります。
そこで役立つのが、RAIDログです。
RAIDログは、Risks、Assumptions、Issues、Dependenciesの4つを整理して記録するためのフレームワークです。日本語では、リスク、前提、課題、依存関係を一覧で管理する表と考えると分かりやすいです。
プロジェクトでは、「まだ起きていないが起きると困ること」「計画の前提になっていること」「すでに発生している問題」「他の作業や人に依存していること」があります。これらを頭の中だけで管理していると、抜け漏れや対応遅れが起こりやすくなります。
RAIDログを使えば、プロジェクトの不安要素や管理すべき事項を見える化し、関係者と共有しながら早めに対策を打てるようになります。
この記事でわかること
・RAIDログとは何か
・RAIDログは何に使うのか
・RAIDログの基本的な考え方
・RAIDログの使い方
・RAIDログの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「RAIDログはプロジェクトのリスク、前提、課題、依存関係をまとめて管理するための型だ」とつかめれば十分です。
RAIDログとは？
RAIDログとは、プロジェクト管理で重要になる4つの要素を記録・管理するためのフレームワークです。
RAIDは、次の4つの頭文字です。
・Risks
・Assumptions
・Issues
・Dependencies
Risksは、リスクです。まだ発生していないものの、発生するとプロジェクトに悪影響を与える可能性があるものを指します。
Assumptionsは、前提です。プロジェクト計画を立てるうえで「こうであるはず」と置いている条件のことです。
Issuesは、課題です。すでに発生しており、対応が必要な問題を指します。
Dependenciesは、依存関係です。ある作業や判断が、他の作業、部門、外部業者、意思決定などに左右される関係を指します。
たとえば、社内システム導入プロジェクトで考えると、「外部ベンダーの納品が遅れる可能性がある」はリスクです。「利用部門が期限内に要件を出してくれる」は前提です。「テスト環境で不具合が発生している」は課題です。「セキュリティ部門の確認が終わらないと本番公開できない」は依存関係です。
初心者向けに言い換えるなら、RAIDログは「プロジェクトで気にしておくべき不安、前提、問題、待ち状態を一覧で管理するノート」です。
一言でいうと、RAIDログはプロジェクトのリスク、前提、課題、依存関係を見える化して管理するためのフレームワークです。
RAIDログは何に使うのか
RAIDログは、プロジェクトの不確実性や問題を整理し、対応漏れを防ぐために使います。
プロジェクトでは、計画通りに進まないことがよくあります。納期遅れ、予算超過、関係部署の確認遅れ、外部業者の対応遅れ、仕様変更、品質問題、承認待ちなど、さまざまな要素が進行に影響します。
RAIDログを使うと、こうした要素を一覧化し、関係者と共有できます。
RAIDログは次のような目的で使われます。
・リスクを早めに把握する
・プロジェクトの前提条件を明確にする
・発生中の課題を管理する
・依存関係を見える化する
・対応責任者を明確にする
・対応期限を管理する
・定例会議で確認すべき事項を整理する
・問題が放置されることを防ぐ
・関係者との認識ズレを減らす
たとえば、プロジェクト会議で「何か問題はありますか」と聞くだけでは、重要なリスクや課題が漏れることがあります。RAIDログを使えば、「リスクは何か」「前提は変わっていないか」「課題は解決したか」「依存関係は詰まっていないか」と視点を分けて確認できます。
これにより、プロジェクトの状態をより実務的に把握しやすくなります。
どんな人に向いているか
RAIDログは、プロジェクトを管理する人や、複数の関係者と仕事を進める人に向いています。
特に、次のような人におすすめです。
・プロジェクトマネージャーを任された人
・リスクや課題の管理に不安がある人
・定例会議で何を確認すべきか整理したい人
・関係部署や外部業者との調整が多い人
・課題が発生しても対応が遅れがちなチームにいる人
・プロジェクトの前提条件を明確にしたい人
・依存関係や待ち状態を見える化したい人
・上司や関係者にプロジェクト状況を説明する必要がある人
RAIDログは、大規模プロジェクトだけでなく、中小規模の業務改善や社内施策にも使えます。
たとえば、社内研修の企画、Webサイト制作、新商品開発、営業キャンペーン、システム導入、外部委託プロジェクト、イベント準備、制度改定など、幅広い仕事で役立ちます。
特に、「問題が起きてから慌てることが多い」「関係者の確認待ちで仕事が止まりがち」「リスクや課題が会議で流れてしまう」という職場では、RAIDログを導入する価値があります。
RAIDログの基本的な考え方
RAIDログの基本は、プロジェクトで管理すべき事項を4つの種類に分けて整理することです。
1つ目は、リスクです。
リスクは、まだ発生していないものの、発生するとプロジェクトに影響する可能性があるものです。たとえば、「外部業者の納品が遅れる可能性」「重要メンバーが多忙で作業時間を確保できない可能性」「顧客から追加要望が出る可能性」などです。
2つ目は、前提です。
前提は、プロジェクト計画を立てるうえで置いている条件です。たとえば、「予算は承認済みである」「対象者は100名程度である」「既存システムとの連携は不要である」「法務確認は1週間以内に完了する」などです。
前提は、崩れると計画に影響します。だからこそ、前提条件として明示しておくことが重要です。
3つ目は、課題です。
課題は、すでに発生している問題です。リスクはまだ発生していないものですが、課題はすでに現実の問題になっています。たとえば、「テストで不具合が出ている」「資料レビューが遅れている」「予算が不足している」「担当者が未定のままになっている」などです。
4つ目は、依存関係です。
依存関係は、ある作業が他の作業や人、組織、外部要因に左右される状態です。たとえば、「法務確認が終わらないと契約できない」「営業部門の顧客リストがないと案内メールを送れない」「外部ベンダーの納品がないとテストできない」などです。
RAIDログで大切なのは、これらを単に書き出すだけでなく、対応責任者、期限、状態を管理することです。
たとえば、リスクを書くだけでは不十分です。「誰が監視するのか」「発生したらどう対応するのか」「いつまでに対策するのか」を決める必要があります。
RAIDログは、プロジェクトの不安要素を会議で話すためのメモではなく、実際に対応を進めるための管理表です。
RAIDログの使い方
手順1 プロジェクトの状況を整理する
最初に、プロジェクトの目的、範囲、関係者、スケジュールを確認します。
RAIDログは、プロジェクト上のリスクや課題を管理するものです。そのため、まずはプロジェクト自体の前提を理解しておく必要があります。
たとえば、社内システム導入プロジェクトであれば、次のような点を確認します。
・何を導入するのか
・導入目的は何か
・対象部署はどこか
・期限はいつか
・予算はいくらか
・関係者は誰か
・外部ベンダーはいるか
・承認者は誰か
・品質やセキュリティの要件はあるか
これらが曖昧なままだと、何がリスクで、何が前提で、何が課題なのか判断しにくくなります。
RAIDログを作る前に、WBSやガントチャート、RACIなどでプロジェクト全体を整理しておくと、より使いやすくなります。
手順2 Risksを洗い出す
次に、リスクを洗い出します。
リスクは、まだ起きていないけれど、起きる可能性があり、起きるとプロジェクトに影響するものです。
リスクを考えるときは、次のような視点が役立ちます。
・納期に影響する可能性はないか
・コストが増える可能性はないか
・品質に問題が出る可能性はないか
・関係者の協力が得られない可能性はないか
・外部業者や他部署の対応が遅れる可能性はないか
・法務、知的財産、セキュリティ上の懸念はないか
・顧客や利用者から追加要望が出る可能性はないか
・重要メンバーが離脱する可能性はないか
たとえば、研修プロジェクトなら「講師の都合が急に悪くなる可能性」「受講者が集まらない可能性」「教材レビューが遅れる可能性」などがリスクです。
リスクを洗い出したら、発生確率、影響度、対応策、担当者を決めます。リスクマトリクスと組み合わせると、どのリスクを優先すべきか判断しやすくなります。
手順3 Assumptionsを明確にする
次に、前提条件を明確にします。
前提は、プロジェクト計画を立てるうえで「こうである」と仮定している条件です。前提が崩れると、計画そのものを見直す必要が出ることがあります。
たとえば、次のような前提があります。
・予算は予定通り承認される
・対象者は100名程度である
・外部ベンダーは予定通り対応できる
・必要なデータは既存システムから取得できる
・法務確認は1週間以内に完了する
・現場部門から担当者を出してもらえる
・既存ルールの範囲内で運用できる
・仕様変更は大きく発生しない
前提は、普段の会話では暗黙のまま進みがちです。しかし、暗黙の前提が崩れたとき、プロジェクトは大きく混乱します。
たとえば、「対象者は100名程度」と思って研修計画を立てていたのに、実際には500名が対象になった場合、教材、会場、運営体制、アンケート集計方法まで変わる可能性があります。
RAIDログでは、こうした前提を明文化しておきます。そして、定例会議などで「前提が変わっていないか」を確認します。
手順4 Issuesを記録して対応する
次に、すでに発生している課題を記録します。
課題は、対応が必要な現実の問題です。リスクとは違い、すでに起きています。
たとえば、次のようなものが課題です。
・担当者が決まっていない
・レビューが期限内に終わっていない
・テストで不具合が発生している
・予算が不足している
・必要な情報が集まっていない
・外部業者からの納品が遅れている
・関係部署の合意が取れていない
・仕様変更が発生している
課題を記録するときは、内容だけでなく、担当者、対応期限、優先度、現在の状態を明確にします。
「資料レビューが遅れている」と書くだけでは不十分です。「誰がレビューするのか」「いつまでに完了するのか」「遅れている理由は何か」「代替策はあるか」を整理する必要があります。
RAIDログでは、課題を放置しないことが重要です。定例会議で毎回確認し、対応状況を更新します。
手順5 Dependenciesを整理する
最後に、依存関係を整理します。
依存関係は、プロジェクト内の作業が他の作業、人、部門、外部業者、意思決定などに左右される状態です。
たとえば、次のような依存関係があります。
・上司の承認がないと次の工程に進めない
・法務確認が終わらないと契約できない
・外部ベンダーの納品がないとテストできない
・営業部門の顧客リストがないと案内メールを送れない
・製造部門の確認が終わらないと仕様を確定できない
・予算承認がないと発注できない
・システム部門の設定が終わらないと利用開始できない
依存関係は、プロジェクトの遅れの原因になりやすい要素です。
自分たちの作業が予定通り進んでいても、他部署や外部業者の対応が遅れると、全体が止まることがあります。そのため、依存関係を早めに見える化し、関係者と調整しておく必要があります。
RAIDログでは、「何に依存しているのか」「誰が対応するのか」「いつまでに必要なのか」「遅れた場合の影響は何か」を記録します。
RAIDログの具体例
例 社内システム導入の場合
社内システム導入プロジェクトでRAIDログを使う例を考えてみます。
このプロジェクトでは、新しい業務管理システムを導入し、複数部署で利用を開始することを目的とします。
まず、リスクとしては次のようなものがあります。
・利用部門から追加要望が出て、要件定義が長引く可能性
・外部ベンダーの設定作業が遅れる可能性
・既存システムとの連携で不具合が出る可能性
・利用者教育が不十分で定着しない可能性
・セキュリティ確認で追加対応が必要になる可能性
次に、前提としては次のようなものがあります。
・予算は今期内に承認されている
・対象部署は営業部門と管理部門である
・既存システムとの連携は最低限にする
・利用開始日は10月1日である
・ベンダーは9月中旬までに設定を完了する
・各部署からテスト担当者を1名ずつ出してもらう
課題としては、次のようなものが発生しているかもしれません。
・営業部門から必要な業務フロー情報が提出されていない
・テスト環境でログインエラーが発生している
・利用者向けマニュアルの作成が遅れている
・ベンダーからの回答が予定より遅れている
依存関係としては、次のようなものがあります。
・要件定義が完了しないと設定作業に進めない
・セキュリティ部門の確認が終わらないと本番稼働できない
・各部署のテスト担当者が確認しないと利用開始判断ができない
・ベンダーの設定完了後でないと利用者研修を実施できない
RAIDログを作っておけば、定例会議でこれらを確認できます。「営業部門からの情報提出が遅れている」「セキュリティ確認が本番稼働の依存関係になっている」といった点が見えるため、早めに調整できます。
別の例 新商品発売プロジェクトの場合
新商品発売プロジェクトでもRAIDログは有効です。
新商品発売では、開発、品質保証、製造、営業、マーケティング、法務、知的財産など多くの部門が関わります。
リスクとしては、次のようなものがあります。
・試作品評価で想定外の不具合が出る可能性
・原材料の調達が遅れる可能性
・商標確認で問題が見つかる可能性
・販促資料の表現に法務上の修正が入る可能性
・発売直前に顧客要求が変わる可能性
・量産条件が予定通り確立できない可能性
前提としては、次のようなものがあります。
・発売日は年度末商戦に合わせる
・既存設備で生産できる
・主要原材料は現行サプライヤーから調達できる
・商品名は現在の候補名で進める
・営業部門は発売1か月前までに説明会を実施する
・品質基準は既存製品の基準をベースにする
課題としては、次のようなものがあります。
・試作品評価で性能のばらつきが出ている
・販促資料の訴求表現について法務確認が未完了
・営業説明資料の完成が遅れている
・原材料の見積価格が当初想定より高い
・商品名候補について商標調査の確認待ちがある
依存関係としては、次のようなものがあります。
・品質確認が完了しないと量産判断できない
・商品名が確定しないとパッケージデザインに進めない
・法務確認が終わらないと販促資料を公開できない
・営業資料が完成しないと営業説明会を実施できない
・原材料の調達条件が決まらないと収益計画を確定できない
新商品発売は、関係部署が多いため、リスクや課題が散らばりやすいプロジェクトです。RAIDログを使えば、プロジェクト全体の不安要素を一覧で確認し、重要な問題を見落としにくくなります。
具体例でわかるポイント
RAIDログの具体例からわかるポイントは、次の通りです。
・リスクと課題は分けて管理する必要がある
・暗黙の前提を明文化すると計画の弱点が見えやすい
・依存関係を整理すると待ち状態や遅延要因に気づきやすい
・関係者が多いプロジェクトほどRAIDログが役立つ
・定例会議で確認することで対応漏れを防ぎやすい
・WBSやガントチャートだけでは見えにくい要素を補える
RAIDログは、プロジェクトの裏側にある不確実性や注意点を見える化するための実務的な管理ツールです。
RAIDログを使うメリット
RAIDログを使う最大のメリットは、プロジェクトの不安要素や問題を一元管理できることです。
プロジェクトでは、リスク、前提、課題、依存関係が別々の会議、メール、チャット、議事録に散らばることがあります。そうなると、重要な情報が埋もれ、対応が遅れる原因になります。
RAIDログを使うメリットは次の通りです。
・リスクや課題を一覧で管理できる
・対応漏れを防ぎやすい
・前提条件の変化に気づきやすい
・依存関係による遅れを早めに把握できる
・定例会議の確認事項が明確になる
・関係者との認識ズレを減らせる
・対応責任者と期限を明確にできる
・プロジェクトの透明性が高まる
・上司や関係者への報告がしやすくなる
特に実務で大きいのは、「誰が、いつまでに、何を対応するのか」を明確にできることです。
問題が発生していても、担当者や期限が決まっていなければ、状況は改善しません。RAIDログでは、項目ごとに責任者、期限、状態を記録できるため、課題を放置しにくくなります。
また、RAIDログはプロジェクトの振り返りにも役立ちます。プロジェクト終了後に、どのリスクが実際に発生したか、どの前提が崩れたか、どの依存関係で遅れたかを確認すると、次回プロジェクトの改善につながります。
RAIDログを使うときの注意点
RAIDログは便利ですが、単なる記録表になってしまうと効果が薄れます。
重要なのは、記録した項目を定期的に見直し、対応状況を更新することです。書きっぱなしにすると、古い情報が残り、実態と合わなくなります。
よくある失敗例は次の通りです。
・リスクと課題を混同する
・前提条件を書き出していない
・依存関係を見落としている
・担当者や期限が決まっていない
・項目が多すぎて重要なものが埋もれる
・定例会議で確認されない
・更新されず古い情報のまま残る
・対応策が曖昧なままになっている
・課題を書くだけで解決に向けた行動がない
・誰も責任を持って管理していない
特に注意したいのは、RAIDログを「不安なことを書き出すだけの表」にしないことです。
リスクを書いたら、発生確率や影響度を考え、対応策を決める必要があります。課題を書いたら、担当者と期限を決める必要があります。依存関係を書いたら、待ち状態を解消するための調整が必要です。
また、RAIDログの項目が増えすぎると、管理が難しくなります。すべての細かい懸念を入れるのではなく、プロジェクトに影響するものを中心に管理することが大切です。
関連フレームワークとの違い
RAIDログと似た場面で使われるフレームワークはいくつかあります。それぞれの違いを理解しておくと、プロジェクト管理で使い分けしやすくなります。
リスクマトリクスとの違い
リスクマトリクスは、リスクを発生確率と影響度で評価し、優先順位をつけるためのフレームワークです。
RAIDログは、リスクだけでなく、前提、課題、依存関係もまとめて管理します。
つまり、リスクマトリクスはリスク評価に特化した道具であり、RAIDログはプロジェクト上の管理事項を広く記録する道具です。
実務では、RAIDログにリスクを記録し、重要なリスクについてはリスクマトリクスで詳しく評価すると使いやすくなります。
WBSとの違い
WBSは、プロジェクトの作業を分解するためのフレームワークです。
WBSが「何をやるか」を整理するものだとすれば、RAIDログは「何に注意すべきか」「何が問題になっているか」を管理するものです。
WBSで作業を洗い出していると、依存関係やリスクに気づくことがあります。その場合、それらをRAIDログに記録すると、実務的な管理につながります。
WBSは作業分解、RAIDログはリスク・課題管理に強いフレームワークです。
ガントチャートとの違い
ガントチャートは、作業とスケジュールを時間軸で見える化するためのツールです。
ガントチャートは「いつ何をするか」を管理します。一方、RAIDログは「進行を妨げる可能性があるもの」「すでに発生している問題」「前提条件」「依存関係」を管理します。
たとえば、ガントチャートで作業が遅れていることは分かりますが、遅れの原因が外部ベンダーの回答待ちなのか、前提条件の変更なのかまでは分かりにくいことがあります。その原因管理にRAIDログが役立ちます。
RACIとの違い
RACIは、タスクごとの役割分担を明確にするフレームワークです。
RAIDログは、リスク、前提、課題、依存関係を管理します。RACIは、誰が実行し、誰が責任を持ち、誰に相談し、誰に共有するかを整理します。
RAIDログで課題を記録したら、その課題に対して誰が対応責任を持つのかを明確にする必要があります。そのとき、RACIの考え方を使うと便利です。
RAIDログは管理対象の整理、RACIは役割分担の整理に強いフレームワークです。
ステークホルダー分析との違い
ステークホルダー分析は、プロジェクトに関わる人や組織の影響力、関心度、期待、不安などを整理するフレームワークです。
RAIDログは、プロジェクト上のリスクや課題を管理します。一方、ステークホルダー分析は、関係者との向き合い方やコミュニケーション方針を考えるために使います。
たとえば、ある部署の協力が得られない可能性がある場合、それはRAIDログ上のリスクになります。同時に、その部署をステークホルダー分析で詳しく整理し、どのように巻き込むかを考えると効果的です。
RAIDログはどんな場面で使うと効果的か
RAIDログは、関係者が多く、不確実性が高いプロジェクトで効果を発揮します。
逆に、個人で完結する単純な作業や、短時間で終わる定型業務では、RAIDログを本格的に作る必要はあまりありません。
RAIDログが効果的な場面は次の通りです。
・新商品開発
・社内システム導入
・業務改善プロジェクト
・DX推進プロジェクト
・外部ベンダーとの共同プロジェクト
・展示会やイベント運営
・社内研修プログラムの開発
・制度改定や組織改革
・新規事業立ち上げ
・Webサイト制作
・製造ライン立ち上げ
・複数部署が関わる全社施策
特に、「リスクが多い」「前提条件が変わりやすい」「課題が複数発生している」「他部署や外部業者への依存が大きい」というプロジェクトでは、RAIDログが役立ちます。
また、定例会議の議題整理にも有効です。RAIDログを見ながら、「新しいリスクはあるか」「前提に変更はないか」「未解決の課題は何か」「依存関係で詰まっているものはないか」を確認すると、会議が具体的になります。
まとめ
RAIDログは、プロジェクトのリスク、前提、課題、依存関係を整理して管理するためのフレームワークです。
プロジェクトでは、タスクやスケジュールだけでは管理しきれない要素がたくさんあります。まだ発生していないリスク、計画の前提条件、すでに起きている課題、他部署や外部業者への依存関係などが、プロジェクトの成否に大きく影響します。
RAIDログを使えば、こうした要素を一覧で見える化し、関係者と共有できます。さらに、担当者、期限、対応状況を記録することで、問題の放置や対応漏れを防ぎやすくなります。
ただし、RAIDログは作って終わりではありません。定例会議などで継続的に確認し、状況に応じて更新することが重要です。古い情報のまま放置すると、管理表としての価値が下がってしまいます。
まずは、今進めているプロジェクトについて、リスク、前提、課題、依存関係をそれぞれ3つずつ書き出して、簡単なRAIDログを作ってみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
リスクマトリクスとは？初心者向けに意味・使い方・具体例をやさしく解説
WBSとは？初心者向けに意味・使い方・具体例をやさしく解説
RACIとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
プロジェクト管理で使えるフレームワークまとめ｜初心者向けに種類・使い分け・活用例を解説
