RAIDログテンプレート Permalink

このテンプレートを使用して、QuireでRAIDログを運用しましょう。リスク・前提条件・課題・依存関係を1か所で管理し、テーブル表示で影響度順にランク付けして、実際に物事をクローズする週単位のレビューを実施できます。

RAIDログのプロジェクトにアクセスして、ワークスペースに複製すれば、ゼロから構築する必要はありません。

すぐに使えるテンプレート一覧も参照して、ワークフローをスピードアップしましょう。

RAIDログを理解する

RAIDはRisks（リスク）、Assumptions（前提条件）、Issues（課題）、Dependencies（依存関係）の頭文字です。RAIDログはこれら4つの継続的な記録です。何が問題になりうるか、確認せずに賭けていること、すでに問題になっていること、そしてチーム外の人から必要なものを記録します。

多くのチームはこれらの一部をどこかで管理しています。しかし4つすべてを1か所にまとめているチームはほとんどなく、そこに価値があります。予算コードの欠落は小さな管理上の問題のように見えます。しかしそれがベンダーが認証情報を提供しない理由であり、ローンチ週の合意がまだ未署名の理由でもあります。1つの根本原因が3つの別々のリストに分散し、誰もそれをつなげていないのです。

このログは5つのセクションで構成されており、重要な期限を基準に下のすべての日付が読めるよう、最上部にマイルストーンが固定されています。

4つのセクションでカテゴリー自体を管理します。5つ目のRAIDガバナンスセクションは、ログが2か月目以降も生き続けるかどうかを左右するレビューサイクルを保持します。21件の作業済みサンプル項目があらかじめ記入されているため、自分の内容に置き換える前に良い記述の形を確認できます。

RAIDログとリスク登録簿

Quireは両方を提供しており、それぞれ異なる質問に答えます。リスク登録簿は1つの分類に対する深い管理ツールです。5×5マトリックス、数値によるリスクスコア、5つの正式な対応戦略とガバナンスのサイクルがあり、すべてリスクのみに向けられています。RAIDログは4つのカテゴリーに対する浅い管理ツールで、発生確率と影響度だけでリスクをスコアリングしますが、登録簿では扱えない前提条件や依存関係も管理できます。

プロジェクトを脱線させうるすべてのことを1か所で管理したい場合はログを使用してください。リスク管理が主な業務でスコアリングの根拠が必要な場合は登録簿を使用してください。RAIDログを作業記録として、登録簿を公式な成果物として、両方を運用しているチームも多くあります。

テンプレートには、セットアップ・分類のルール・避けるべき失敗パターンを網羅したドキュメントが付属しています。

2つ目のドキュメントには週単位のレビューアジェンダが含まれており、会議を進行する担当者が当日の朝に進行順を即席で考える必要がなくなります。

4つのカテゴリーを見分ける

カテゴリーは頻繁に混同され、どこに属するかの議論はレビューの最初の10分を無駄にする良い方法です。4つのテストでほぼすべてを解決できます。

残りを解決する3つのルールがあります。

1. 現実化したリスクはもはやリスクではありません。課題に移動し、両方にオープンのまま残すのではなく、どこに移ったかをメモしてリスクをクローズしてください。
2. 誤りと判明した前提条件は単に間違いなだけでなく、結果を伴います。前提条件をクローズして、その結果をリスクまたは課題として新たに起票してください。
3. 追跡をやめた依存関係はリスクです。月次クリーンアップ時に再スコアリングしてください。

テンプレートのサンプル項目A-01は、ルール2の実例であり、それが生んだ課題に紐付けられています。

テーブル表示でログを確認する

テーブル表示は Professional、Premium、Enterprise プランでのみ利用できます。詳細は料金ページをご確認ください。

テーブル表示こそがRAIDログの本体です。すべてのカスタムフィールドを項目の隣に並べて表示し、影響度で並べ替えることでリストの上部が会議のアジェンダになります。

7つのフィールドでログを支えます。

登録日と最終レビュー日は単なる帳簿管理のように見えます。しかし3月に登録され、4月にレビューされ、9月にもオープンのままの項目は管理されていません。誰かが偶然気づかない限り、その事実を浮き上がらせるのはこの2つの日付だけです。

Note: 課題の発生確率を記入していると気付いた場合、それはおそらく再分類されていないリスクです。課題はすでに発生しているため、発生確率は100%です。

8つのタグが4つのカテゴリー全体を横断します。予算・予定・技術・スコープ・クライアント・ベンダー・人員・コンプライアンスです。これらはタイプとは異なる質問に答えます。項目がどこから来たかではなく、それがどのような性質のものかを示します。

価値ある項目を書く

有用なRAIDログとコンプライアンスの成果物の違いは、ほぼ完全に項目の書き方にあります。テンプレートのすべてのサンプル項目は同じ4つのパーツの形式に従っています。

説明は「もしXなら、Yになる」という文から始まり、次に発生した場合の影響度を誰もが気にする単位で記述し、対応策を示し、監視するトリガーを記載します。軽減作業はサブタスクとして項目にぶら下がっているため、計画と記録が同じ場所に収まります。

5つのルールが違いを生み出します。

• リスクは原因と結果として記述する。「ベンダーの遅延」は懸念事項です。「ベンダーが8月6日を逃した場合、認証テストは本番環境の認証情報なしで開始され、テストが2週間スリップする」はチームが行動できるものです。
• すべてのリスクにトリガーを設定する。リスクが仮説的な段階をストップする、観察可能なポイントです。トリガーなしでは、エスカレーションが遅れ、感覚に頼ることになります。
• 対応策を明記する。回避・軽減・転嫁・受容のいずれかを選びます。「モニタリング」は対応策ではなく、「まだ決めていない」という書き方です。
• 影響度を誰もが気にする単位で記述する。週・金額・顧客数・評判など。「高影響度」ではスポンサーに何も伝わりません。
• すべての項目に日付を入れる。期限の日のない項目は永遠に着手されません。

すべての項目に担当者として具体的な個人を1名割り当ててください。チームは何も追跡しません。なぜなら、メンバーの誰も追跡が自分の責任だとは思わないからです。

ボード表示でフローを把握する

ボード表示を状態でグループ化すると、在庫ではなく動きが見えます。これはより正直な視点です。

6つの状態でログを運用します。

「回答待ち」はその存在意義を証明します。これがなければ「進行中」が「作業している」と「9日前にメールを送った」の両方をカバーしなければならず、この2つにはまったく異なるフォローアップが必要です。

Tip: 「エスカレーション済み」列は一度読むのではなく、数週間にわたって観察してください。埋まるペースが解消されるペースを上回っているなら、それはどんな状態報告よりも信頼できる健全性シグナルです。

サブリストでクロスカッティングビューを作成する

Free Subscriptionプランでは各プロジェクトにつき2つのサブリストを作成でき、このテンプレートには4つ付属しています。複製後はチームが最もよく開く2つを残すか、サブスクリプションプランをアップグレードして4つすべてを使用してください。詳細は料金ページをご確認ください。

セクションは「これはどんな種類のものか」という質問に答えます。4つのサブリストは4つのカテゴリー全体を横断する質問に答えます。これが4つ別々のログではなく1つのログにする価値が生まれるところです。

• 今すぐエスカレーションは、カテゴリーを問わずオープンのまま残っているすべての重大影響度の項目です。これはステアリング委員会用の資料です。約6件を超えると、そのプロジェクトは管理されているのではなく見守られているだけです。
• 他者の番待ちは、次のアクションが自分にないすべての項目です。状態報告の前に開いて、上位3件を追跡してください。
• 未検証の前提条件は、手遅れになるまで誰も読まないリストです。四半期に一度、声に出して読んでください。
• ベンダーチェーンはフィルターではなく実例です。

最後のサブリストは最初に開く価値があります。4つの項目で1つのログの存在意義全体を示しているからです。

未発行の発注書は課題です。それが財務による注文承認をブロックし、それが依存関係です。それがベンダーの本番環境認証情報の提供をブロックし、これも依存関係です。そしてそれがローンチ週の合意がまだ未署名の理由であり、リスクとして記録されています。3つのカテゴリー、1つの根本原因、同じログに存在するからこそ見えます。項目は実際のタスクの依存関係で紐付けられているため、チェーンは説明されるだけでなく強制されます。

ログの正直さを維持する

レビューのないログはドキュメントであり、プロセスではありません。ガバナンスセクションには、誰かが覚えていることに依存せず予定にサイクルが組み込まれるよう、4つの繰り返しのタスクが含まれています。

ほとんどの死んだRAIDログの原因となる3つの失敗パターンがあります。静かに忍び込んでくるため、名前をつけておく価値があります。

1. 墓場になる。50件のオープン項目、そのほとんどが古くなり、人々はログを開くことをやめます。2か月間誰も触れていない項目は、実在しないか担当者がいないかのどちらかです。
2. すべてが高影響度になる。ログ全体がリスクありなら、何もランク付けしていません。20件中4件の重大な項目は現実的なプロジェクトです。14件は誰も考えていないプロジェクトです。
3. ステアリング委員会の前にしか更新されない。その時点で管理ツールから報告ツールへと変わってしまっています。

3つすべてに同じ地味な対処法があります。週単位の短いレビューと、項目を積極的にクローズすることです。

ブログでリスクのスコアリングと登録簿を生き続けさせる方法について詳しく読む。

よくある質問

RAIDログとは何ですか？

RAIDログは、何が問題になりうるか・確認せずに賭けていること・すでに問題になっていること・チーム外から必要なものを1つの継続的な記録にまとめたものです。4つすべてを1か所に集めることで、別々に見える問題が根本原因を共有していることが見えるようになります。

RAIDは何の略ですか？

Risks（リスク）、Assumptions（前提条件）、Issues（課題）、Dependencies（依存関係）の略です。プログラム業務でよく使われるRisks・Actions・Issues・Decisionsとも展開されます。Quireのテンプレートは最初のバージョンを採用しています。前提条件と依存関係は、チームが他の場所で管理していない可能性が最も高い2つのカテゴリーだからです。

リスクと課題の違いは何ですか？

時制と確実性の違いです。リスクは将来の不確実な事象で、「もしXなら、Yになる」と記述します。課題は現在の確実な事象で、すでに発生しています。リスクが現実になった時点でそれはリスクではなくなるため、課題に移動し、どこに移ったかをメモしてリスクをクローズしてください。

RAIDログとリスク登録簿の違いは何ですか？

リスク登録簿は1つの分類に対する深い管理ツールで、5×5マトリックスと正式な対応戦略を持ちます。RAIDログは4つに対する浅い管理ツールで、登録簿では扱えない前提条件と依存関係も管理します。両方を運用しているチームも多くあります。

RAIDログの責任者は誰ですか？

プロジェクトマネージャーがログ自体の責任者です。レビューサイクル・古くなった項目のクローズ・エスカレーションを担当します。個々の項目にはチームではなく、具体的な個人を1名指名する必要があります。チームは何も追跡しないからです。

RAIDログはどのくらいの頻度でレビューすべきですか？

ログ全体は週単位で約30分、影響度順に並べてレビューします。古くなった項目をクローズしてオープンなリスクを再スコアリングするには1か月ごとに行います。前提条件の再検証は四半期ごとに行います。テンプレートはこれら3つすべてを繰り返しのタスクとして保持しているため、自動的に予定に組み込まれます。

RAIDログの項目には何を記載すべきですか？

R-01のような安定したID、分類、影響度評価、担当者1名、期限の日、記載された対応策が必要です。リスクにはさらに発生確率とトリガーが必要です。トリガーとはリスクが仮説的な段階をストップして誰かが行動しなければならない、観察可能なポイントです。

RAIDログはなぜ役に立たなくなるのですか？

3つの失敗パターンがあります。古い項目で溢れた墓場になり、人々が開くことをストップします。すべてが高影響度とマークされ、何もランク付けできなくなります。あるいはステアリング委員会の前にしか更新されなくなります。すべての対処法は週単位の短いレビューと項目を積極的にクローズすることです。

Quireにすぐに使えるRAIDログテンプレートはありますか？

はい。RAIDログのプロジェクトにアクセスしてワークスペースに複製すれば、4つの分類セクションとガバナンスセクション、7つのカスタムフィールド、6つの状態、8つのタグ、4つのクロスカッティングサブリスト、21件の作業済みサンプル項目がすでにセットアップされた状態で利用できます。