リスク登録簿（リスクレジスター）テンプレートと使い方｜11の列構成と週次更新サイクルで運用する

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

「リスクを洗い出す会議はやったのに、その一覧がどこかのフォルダで眠ったまま、結局そのリスクが現実になって慌てた」——プロジェクトの現場でよくある光景です。リスクを”見つける”ところまでは多くのチームができます。ところが、それを継続的に管理できる一枚の台帳に落とし込み、毎週更新して回していくとなると、とたんに続かなくなる。この台帳こそが リスク登録簿（リスクレジスター） です。

結論から言えば、リスク登録簿とは「起こるかもしれない事象を、リスクID・確率・影響・対応策・担当者・ステータスといった決まった列で一覧化し、プロジェクトの終わりまで更新し続ける管理表」です。ポイントは2つ。①どの列を持つか（テンプレートの構成） と ②どう回すか（更新サイクル）。この2つが決まれば、リスク管理は「一度やって終わる作業」から「毎週回る仕組み」に変わります。

なぜテンプレートと更新サイクルにこだわるのか。理由は明快で、リスク登録簿が形骸化する原因のほとんどが「列がバラバラで何を書けばいいか分からない」か「作ったきり誰も更新しない」のどちらかだからです。逆に言えば、列の意味を全員が理解し、更新のタイミングが定例に組み込まれていれば、登録簿は生き続けます。この記事では、実務でそのまま使える11列のテンプレートと、その各列の書き方、そして週次で回す更新サイクルまでを具体的に解説します。

そもそもリスク登録簿（リスクレジスター）とは？

リスク登録簿は、発生するかどうかは確実でないものの、もし発生したらプロジェクトに影響をおよぼす事象を一覧にまとめた文書です。英語では Risk Register と呼ばれ、リスクレジスターとカタカナ表記されることもあります。

ここで押さえておきたいのが、リスク登録簿が扱うのは 「まだ起きていない、未来の不確実性」 だという点です。すでに起きてしまった事実（＝課題・イシュー）は別の表（課題管理表）で扱います。「サーバーがダウンした」は課題、「サーバーがダウンするかもしれない」がリスク——この時制の違いが、リスク登録簿と課題管理表を分ける基準です。

リスク登録簿は表形式で作られることが多く、Excel やスプレッドシートで作成されるのが一般的です。プロジェクトメンバーがリスクを記入し、PM やリーダーが内容をチェック・優先順位づけして運用します。特別なツールは要りません。まずは1枚のスプレッドシートから始められます。

リスク登録簿テンプレートの11列構成

ここからが本題です。実務でそのまま使える11列のテンプレートを、各列の意味と書き方とセットで示します。最初から全部を埋める必要はありません。最低限①〜⑧があれば機能し、運用が回り始めてから⑨〜⑪を足していくのが現実的です。

#	列名	何を書くか	記入のコツ
①	リスクID	R-01、R-02 等の識別番号	通し番号でよい。並べ替えても追える
②	リスク事象	「原因 → 事象 → 影響」で記述	「〜のため（原因）、〜が起こり（事象）、〜になる（影響）」
③	カテゴリ	スケジュール／コスト／技術／要員／外部 等	分類しておくと似たリスクをまとめて対処できる
④	発生確率	5段階（1=非常に低い〜5=非常に高い）	高・中・低の3段階でも可。チーム内で基準を統一
⑤	影響度	5段階（1=軽微〜5=甚大）	コスト・納期・品質のどれに効くかも意識
⑥	リスクスコア	④×⑤（＝優先度）	数値が大きいほど優先。並べ替えの軸になる
⑦	対応戦略	回避／転嫁／軽減／受容	脅威の4戦略から選ぶ
⑧	対応策	具体的なアクション	「誰が・何を・どうする」まで書く
⑨	リスクオーナー	そのリスクの責任者（1人）	「みんなの担当＝誰の担当でもない」を防ぐ
⑩	期日	対応策をいつまでに実施するか	期日なき対応策は動かない
⑪	ステータス	未着手／対応中／完了（クローズ）	一目で全体の進み具合が分かる

各列の書き方のポイント

② リスク事象は「原因 → 事象 → 影響」で書く。 単に「納期遅延」と書くと、後から読んでも何をすればいいか分かりません。「キーメンバーが兼務のため（原因）、設計工程が遅れ（事象）、後続のテスト期間が圧迫される（影響）」のように因果でつなぐと、対応策（兼務解消の交渉）が自然に見えてきます。

④⑤ 確率と影響は必ずチームで基準をそろえる。 「確率3」が人によって意味が違うと、スコアが機能しません。「確率5＝ほぼ確実に起こる／3＝五分五分／1＝めったに起きない」のように、数字と言葉の対応表をテンプレートの片隅に固定しておきましょう。

⑥ リスクスコアは確率×影響で機械的に出す。 これがリスク登録簿の心臓部です。たとえば確率4×影響5＝スコア20なら最優先、確率2×影響2＝スコア4なら後回し、と迷わず並べ替えられます。全リスクを均等に扱おうとすると必ず手が回らなくなるので、スコア上位から対処するのが鉄則です。

⑨ リスクオーナーは必ず1人に決める。 「チームで見ます」は、実質「誰も見ない」と同義です。各リスクに監視と対応の責任者を1人だけ割り当てることで、初めてそのリスクが動き出します。

リスク登録簿の記入例（Web システム導入プロジェクト）

言葉だけではイメージしにくいので、Web システム導入プロジェクトを例に、実際の記入例を示します。

ID	リスク事象（原因→事象→影響）	カテゴリ	確率	影響	スコア	対応戦略	対応策	オーナー	ステータス
R-01	キーSEが兼務のため設計が遅れ、後続テストが圧迫	要員	4	5	20	軽減	兼務解消を上長に交渉／設計レビュー前倒し	PM	対応中
R-02	外部API仕様が未確定のため実装手戻りが発生	技術	3	4	12	軽減	ベンダーと仕様確定会を今週設定	開発リーダー	未着手
R-03	繁忙期リリースで問い合わせが集中し初期対応が遅延	外部	3	3	9	受容	予備の問い合わせ対応要員を確保	運用担当	未着手
R-04	要件追加が続きスコープが膨張し予算超過	コスト	2	4	8	転嫁	変更管理プロセスで追加分は別見積り	PM	対応中

スコア列を見れば、R-01（20）から順に手をかければよいことが一目で分かります。これがリスク登録簿の使い方の核心です。リスクを「並べる」だけでなく、「スコアで並べ替えて、上から対処する」までがワンセットです。

なお、対応策を検討する際に必要な関係者の洗い出しは「ステークホルダーマネジメント」、リスクの発生源になりやすい”やらないこと”の明確化は「プロジェクト憲章の書き方」も参考になります。

リスク登録簿を回す更新サイクル

リスク登録簿は 作った瞬間から古くなっていく 文書です。プロジェクトが進めば、消えるリスクもあれば、新しく生まれるリスクもある。だからこそ、更新を”気が向いたとき”ではなく定例に組み込むことが決定的に重要です。

更新サイクルは、次の流れで回すとシンプルです。

1. 追加：会議やチャットで挙がった新しいリスクを登録簿に足す（原因→事象→影響で記述）
2. 再評価：状況が変わったリスクの確率・影響を見直し、スコアを更新する
3. 進捗更新：各リスクのステータス（未着手／対応中／完了）を最新化する
4. クローズ：対応が終わった、あるいは発生条件が消えたリスクをクローズ（行は消さず「完了」で残す）
5. 共有：スコア上位のリスクをステークホルダーに週次で共有する

作成タイミングは、リスク登録簿は計画フェーズで初版を作り、その後は実行・監視フェーズを通じて更新し続けます。キックオフ直後に一度作って終わり、ではありません。

リスク登録簿を使うメリット・デメリット

デメリットの多くは「更新されない」「基準がぶれる」に集約されます。裏を返せば、更新を定例化し、確率・影響の基準表をテンプレートに固定する——この2点さえ守れば、リスク登録簿は強力な武器になります。

リスク登録簿でよくある失敗5選

1. 作って更新しない：最頻出の失敗。キックオフで一度作ったきり放置され、リスクが現実になってから初めて開かれる。週次レビューを定例に固定して防ぐ。
2. リスクと課題を混ぜる：未来の不確実性（リスク）とすでに起きた事実（課題）を同じ表に入れると、緊急の課題に押されて予防が後回しに。表を分ける。
3. 確率・影響の基準がバラバラ：「確率3」の意味が人によって違うとスコアが無意味になる。数字と言葉の対応表を固定する。
4. リスクオーナーを決めない／複数にする：「チームで見ます」は誰も見ない。各リスクにオーナーを1人割り当てる。
5. 列を盛りすぎて続かない：最初から20列作ると記入が苦痛になり放置される。まず8列で始め、必要に応じて足す。

よくある質問（FAQ）

Q. リスク登録簿は何で作ればいいですか？ A. 小〜中規模なら Excel／Google スプレッドシートで十分です。縦にリスク、横に11列を並べ、リスクスコア列は =確率×影響 の数式で自動計算にしておくと運用が楽になります。チームで共同編集したい場合は、Confluence・Smartsheet・Notion などのツールのテンプレートを使うのも手です。

Q. 確率と影響は「高・中・低」の3段階でもいいですか？ A. 問題ありません。3段階（3・2・1）でもスコア（確率×影響）は計算できます。厳密さよりチーム全員が同じ基準で評価できることが大切なので、迷ったらまず3段階で始め、精度が必要になったら5段階に上げてください。

Q. リスク登録簿と課題管理表（Issue Log）はどう違いますか？ A. リスク登録簿は「まだ起きていない、未来の不確実性」を、課題管理表は「すでに起きた事実」を扱います。「サーバーが落ちるかもしれない」はリスク、「サーバーが落ちた」は課題です。両者は緊急度も対応も違うため、必ず別の表で管理します。

Q. どのくらいの頻度で更新すればいいですか？ A. 週次の定例会議に「リスクレビュー」の固定枠（10 分程度）を設けるのが目安です。少なくとも各フェーズの節目（マイルストーン）ごと、および大きなリスクが新たに出たときには必ず更新します。「開いたら情報が古い」状態にしないことが登録簿の生命線です。

Q. リスクを洗い出す手順そのものが分かりません。 A. リスクの識別・分析・対応・監視という管理の全体像は「リスクマネジメントの手順｜識別・分析・対応・監視の4ステップ」で解説しています。本記事のリスク登録簿は、その4ステップを回すための台帳にあたります。

まとめ｜リスク登録簿は「列」と「更新サイクル」で決まる

リスク登録簿（リスクレジスター）を機能させるコツは、次の2点に集約されます。

1. テンプレートの列を決める：リスクID・事象（原因→事象→影響）・カテゴリ・確率・影響・スコア（確率×影響）・対応戦略・対応策・オーナー・期日・ステータスの11列。まずは①〜⑧で始め、必要に応じて足す
2. 更新サイクルを回す：週次レビューで「追加 → 再評価 → 進捗更新 → クローズ → 共有」を10分で回し、完了したリスクも行は残す

リスク登録簿の本質は、リスクを”見つける”ことではなく、見つけたリスクを一枚の台帳で”追い続ける”仕組みをつくることにあります。そして最大の勘所は、確率×影響のスコアで並べ替え、上位から機械的に対処すること。まずは今日、直近フェーズのリスクを4〜5個ピックアップし、上の記入例のように小さなリスク登録簿を1枚作ってみてください。次の定例で10分のリスクレビューを回し始めれば、「気づいたら手遅れ」がプロジェクトから減っていくはずです。

リスク管理の4ステップの全体像は「リスクマネジメントの手順」で、リスクの発生源になりやすいスコープの膨張を止める方法は「スコープクリープを防ぐ7つの実践テクニック」で詳しく解説しています。あわせてどうぞ。