リスク登録簿：とは何か、作り方とテンプレート

リスク登録簿は、漠然としたプロジェクトへの不安を、構造化された管理しやすいリストへと変える文書です。すべてのプロジェクトにはリスクがあります。問題は、そのリスクが誰かの頭の中にあるか、チーム全員が行動できる共有文書にあるかです。

リスク登録簿とは何か

リスク登録簿とは、特定されたリスク・確率と影響のスコア・担当オーナー・計画された対応戦略を一つの共有文書に記録するプロジェクト管理ツールです。リスクログとも呼ばれますが、実際には両方の用語はほぼ同義語として使われています。

登録簿はリスクを排除しません。リスクを可視化することで、チームがどのリスクを軽減するか、どれを監視するか、どれを単に受け入れるかを判断できるようにします。文書化されたリスクは管理できるリスクです。誰かの記憶の中だけにあるリスクは、爆発を待つ期限です。

重要なポイント

• アクティブなリスク管理の実践を持つプロジェクトは、そうでないプロジェクトより目標を達成する確率が2.5倍高い（PMI Pulse of the Profession, 2023）。
• 不十分なリスク管理はプロジェクト失敗の2番目に多い原因であり、世界中の**プロジェクト専門家の39%**が挙げています（PMI, 2024）。
• プロアクティブにリスクを管理する組織は、そうでない組織と比べて13倍少ないコストを無駄にしています（PMI Pulse of the Profession, 2023）。

リスク登録簿に入れるもの（列項目）

リスク登録簿は、すべての列が明確な目的を持つときに最もよく機能します。標準的なフィールドとその役割を以下に示します。

現実的な数行を入力したリスク登録簿の例を示します。

リスクスコアの列は優先順位付けのエンジンです。スコア6以上のリスクは通常、週次アジェンダに上がります。スコア3以下のリスクは、状況が変わらない限りウォッチリストに移せます。

リスク登録簿 vs リスクログ vs RAIDログ

これらの用語は必要以上に重複しており、プロジェクトチームで実際の混乱を引き起こします。以下に明確な比較を示します。

実際には「リスク登録簿」と「リスクログ」はほとんどのチームで互換的に使用されます。意味のある区別は、独立したリスク登録簿（リスクのみ、完全な深度）と、リスクを前提条件・課題・依存関係とともに1文書に中程度の深度でまとめたRAIDログの間にあります。

ほとんどのプロジェクトマネージャーにとって、RAIDログが適切な出発点です。プロジェクトが十分に大きく、または規制が厳しく、リスクカテゴリーだけでも完全な確率・影響分析を伴う専用文書が必要な場合にリスク登録簿が適します。

リスク登録簿のメリット

リスクが危機になる前に表面化させる。 リスク登録簿を作成するプロセス自体が、何か実際に起こる前に何が失敗しうるかをチームに考えさせます。プロジェクトキックオフでこの演習を行うチームは、そうでないチームよりも数週間から数ヶ月早く問題を把握します。

不確実性に関する共通言語を生み出す。 チーム全員が同じリスク登録簿を指せるとき、「ベンダーのタイムラインが心配です」が「R-001は高・高評価でAlexが軽減策を持っています」になります。この具体性がステータスミーティングの会話の進み方を変えます。

プロジェクトマネージャーが示せるものを提供する。 スポンサーが納品日の遅延理由を問いただしたとき、リスク登録簿は事象が記録されていたか、誰がオーナーだったか、軽減計画が実行されていたかを示します。これは防御的なものではありません。プロジェクトチームが時間をかけて信頼性を構築する方法です。

リスクを作業分解構成図と連動させる。 リスクを文書化すると、どのワークストリームが最も高いリスクを抱えているかを追跡できます。これはスケジュールのバッファをどこに配分するか、最も優秀な人材をどこに配置するかを決める際に役立ちます。

より良いステークホルダー分析につながる。 どのリスクがどのステークホルダーに影響するかを知ることで、誰に情報提供すべきか、誰に相談すべきか、誰が対応計画を承認する権限を持つかを判断できます。

よくある失敗

一度リスクを記録して二度とレビューしない。 定期的にレビューされないリスク登録簿はフィクションになります。リスクはステータスが変わります。新たなリスクが浮上します。オーナーが去ります。週次ステータスミーティングに10分間のリスクレビュー枠を固定で確保してください。そうしなければ文書は漂流します。

曖昧な説明を使う。 「コミュニケーションリスク」はリスクではありません。「クライアントのステークホルダーがスコープ文書の承認確認を返送しておらず、プロジェクトが構築フェーズに移れない」がリスクです。リスクが記録されたときの場にいなかった人でも何が問題かわかるほど具体的にしてください。

チームにリスクを割り当てる。 「ITチーム」はオーナーではありません。1人の指名された人物がオーナーです。その人物はリスクを監視し、必要に応じてエスカレーションし、各レビューでステータスを更新します。チームに責任を持たせることはできません。個人にはできます。

すべてを高評価にする。 すべてのリスクが9であれば、9というものがなくなります。スコアを誠実に評価してください。適切に評価された登録簿は、実際に重要なリスクにエネルギーを集中させます。9だらけの登録簿はノイズを生み出し、対応する必要のないものに注目を消費します。

登録簿をコンプライアンス成果物として扱う。 プロジェクトガバナンスフレームワークが必要とするからリスク登録簿を作成し、二度と開かないプロジェクトマネージャーがいます。リスク登録簿は積極的に使用している生きた文書でのみ価値を発揮します。

解決されたリスクのクローズを忘れる。 リスクが軽減または回避されたとき、何が起こったかのメモとともにクローズしてください。そのクローズしたエントリーが、次の類似プロジェクトのための組織的な知識になります。

リスク登録簿の作り方

ステップ1：リスクを特定する

プロジェクトキックオフから始めます。コアチームと構造化されたブレインストーミングを実施してください。何が失敗しうるか？成立しないかもしれない前提条件は何か？外部チームやベンダーから何を依存しているか？過去の類似プロジェクトの教訓文書を参照してください。目標は、ランク付けを始める前に可能な限り多くのリスクを表面化させることです。この段階では質より量を優先します。

議論を促すカテゴリーの例：技術的リスク・資源リスク・スケジュールリスク・予算リスク・外部依存関係・コンプライアンスおよび規制リスク・ステークホルダーリスク。

ステップ2：明確で具体的な説明を書く

各リスクについて、何がリスクであり、なぜプロジェクトに重要かを説明する1〜2文の記述を書きます。略語を避けてください。「API統合の失敗」は「サードパーティの決済APIが認証プロトコルをサポートしない可能性があり、カスタムミドルウェアの構築が必要になってスケジュールに4〜6週間追加される」より役に立ちません。

ステップ3：確率と影響をスコアリングする

登録簿全体で一貫したスケールを使用します。3段階スケール（低・中・高を1・2・3にマッピング）はほとんどのチームで機能します。5段階スケールは大規模プログラムに適しています。同じ登録簿内でスケールを混在させないでください。

プロジェクトの文脈・チーム・ベンダーの実績・市場についての知識をもとに、リスクが発生する可能性に基づいて確率をスコアリングします。リスクが実現した場合の結果の深刻度に基づいて影響をスコアリングします。そして掛け算します。中程度の確率（2）と高影響（3）を組み合わせると6というスコアになります。

ステップ4：スコア順に優先順位付けしオーナーを割り当てる

リスク登録簿をスコアの高い順に並べ替えます。6以上のリスクには積極的な軽減計画と週次レビューを設定します。3〜4のリスクはウォッチリストに入れ、月次でレビューします。1〜2のリスクは受容されます。記録しますが、軽減リソースは配分しません。

4以上のすべてのリスクに指名されたオーナーを割り当てます。その人物はリスクの監視・対応計画の実行・ステータスの変化の報告に責任を持ちます。RACIマトリクスと相互参照して、オーナーの割り当てがプロジェクトの説明責任の役割と一致していることを確認してください。

ステップ5：対応戦略を定義する

各リスクには文書化された対応策が必要です。4種類の標準的な対応タイプがあります。

• 回避：プロジェクト計画を変更してリスクを完全に排除する。例：ベンダーの実績が芳しくない場合、リスクが実現する前にベンダーを変更する。
• 軽減：確率または影響を下げるための措置を取る。例：キーパーソンリスクの影響を軽減するために第2の開発者をクロストレーニングする。
• 転嫁：リスクを第三者に移転する。例：プロジェクト保険を購入するか、ベンダー契約にパフォーマンス条項を追加する。
• 受容：リスクを認識し予備計画を準備するが、プロアクティブな措置は取らない。軽減コストが潜在的な影響よりも大きい低スコアリスクに最適。

ステップ6：プロジェクト全体を通じてレビューと監視を行う

リスク登録簿はキックオフの成果物ではありません。生きた文書です。週次ステータスミーティングでレビューしてください。ステータスを更新し、対応計画が実行されているか確認し、解決されたリスクをクローズし、浮上した新たなリスクを追加します。プロジェクトライフサイクルの高リスクフェーズでは、高評価のオープン項目について週の中間にリスク確認を検討してください。

リスクが実現したとき、それは課題となり、それに従って追跡すべきです。RAIDログではリスクセクションから課題セクションに移動します。独立したリスク登録簿ではステータスを「実現済み」に変更し、別途課題ログのエントリーを作成します。

プロジェクトタイプ別リスク登録簿の事例

プロジェクトタイプによってリスクのプロファイルは異なります。3つの一般的な文脈でのリスク登録簿エントリーの例を示します。

ソフトウェアプロジェクトでは技術的リスクと資源リスクが支配的になりがちです。建設では規制コンプライアンスと天候関連のスケジュールリスクが最も重要です。マーケティングローンチではベンダーとクリエイティブ納品のタイムラインが最大のリスク要因です。登録簿の構造は3つすべてで同じです。カテゴリーとスコアだけが変わります。

プロジェクトが複数のワークストリームを含む場合、リスク登録簿をクリティカルパス法分析と連動させることを検討してください。クリティカルパスのタスクに影響するリスクは、同じ確率・影響スコアであっても、フロートタスクに影響するリスクより高い優先度を受けるべきです。

ベストプラクティス

リスクごとに1人の指名されたオーナーを割り当てる。 チームではなく、役職でもなく、個人を指定します。

すべてのステータスミーティングで登録簿をレビューする。 10分間のざっとした確認でも、最新かつ信頼できる状態を保つのに十分です。

スコアの高いリスクをプロジェクトスコープ記述書に連動させる。 リスクが核となる成果物を脅かす場合、それはPMのメモではなく、スポンサーとの会話が必要な事項です。

書面のメモとともにリスクをクローズする。 リスクが解決または回避されたとき、何が起こったかを文書化します。類似プロジェクトの将来のチームはそのクローズされたエントリーを活用します。

登録簿が整理されずに大きくなることを防ぐ。 80件のオープンリスクを抱えた登録簿は使いものになりません。受容されたリスクをクローズし、解決済みをアーカイブし、チームが実際に行動できるものにアクティブリストを絞り込む。

重大度を色だけで示さない。 色覚に多様性があるチームメンバーがいる可能性があり、エクスポートすると書式が失われることが多いです。テキストラベル（低・中・高）を色分けと併用し、書式が変わっても情報が残るようにしてください。

よくある質問

リスク登録簿とリスク評価の違いは何ですか？

リスク評価はリスクを特定・評価するプロセスです。リスク登録簿はその評価の結果を記録し、さらに時間をかけて継続的に追跡するアウトプット文書です。リスク評価を行って登録簿を作成します。その後、リスクの状況が変化しているかどうかを監視するためにプロジェクト全体を通じて登録簿を維持します。

リスク登録簿はどのくらいの頻度で更新すべきですか？

最低でも週1回、定期的なプロジェクトステータスミーティングで更新します。深刻度の高いオープンリスクは、特にそのリスクが最も発生しやすいプロジェクトフェーズでは、より頻繁な確認が必要です。変更依頼・新たな依存関係・予期せぬ事象がチームが以前追跡していなかった不確実性をもたらすたびに、新たなリスクを追加してください。

リスク登録簿のオーナーは誰ですか？

プロジェクトマネージャーが文書としての登録簿のオーナーであり、最新の状態に保つ責任があります。ただし、各リスクにはそれぞれ指名されたオーナーがいます。そのリスクの監視と対応に責任を持つ人物です。この区別は重要です。PMがすべてのリスクのデフォルトオーナーになるべきではありません。リスクに最も近い人物（技術リーダー・財務アナリスト・調達マネージャーなど）が通常、適切なオーナーです。

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

タイミングです。リスク登録簿はまだ起きていない事象を追跡します。課題ログはすでに発生している問題を追跡します。リスクが実現すると、リスク登録簿から課題ログに移行します。一部のチームは両方を1つの文書に組み合わせますが、ステータスが将来のリスクとアクティブな課題を明確に区別している限り、問題ありません。

すべてのプロジェクトにリスク登録簿が必要ですか？

必ずしも正式な形では必要ありません。少人数チームによる2週間の内部プロジェクトなら、共有メモやキックオフでの簡単なリスク会話でも乗り切れます。しかし、複数のステークホルダー・外部依存関係・一定以上の予算・規制への関与を持つプロジェクトには正式なリスク登録簿が必要です。プロジェクト憲章は判断の良い基準点です。プロジェクトが憲章を必要とするほど複雑であれば、リスク登録簿も必要です。

---

最良のリスク登録簿は、実際に使えるほどシンプルで、実際に意味があるほど詳細なものです。上記の9列から始め、リスクを誠実にスコアリングし、実際のオーナーを割り当て、毎週文書をレビューしてください。一貫してそれを行えば、登録簿はプロジェクトを通じてチームが持つ最も価値ある会話の一つになります。

関連記事

• RAIDログ：リスク・前提条件・課題・依存関係
• プロジェクト憲章：スコープの定義とステークホルダーの合意
• 作業分解構成図（WBS）の作り方
• RACIマトリクス：あらゆるプロジェクトで役割を明確にする
• ステークホルダー分析マトリクス
• プロジェクト管理におけるトリプルコンストレイント