リスク・課題管理

リスク登録簿りすくとうろくぼ

リスク登録簿リスクレジスターリスク管理発生確率と影響度リスク対応策リスクオーナー

リスク登録簿ってどう使うの？

簡単に言うとこんな感じ！

「このプロジェクトで起きるかもしれない困りごと」を一覧にして、起きやすさ・起きたときの痛さ・打つ手・担当者を書いておく台帳だよ。天気予報を見て傘を用意するみたいに、起きる前に備えるための道具なんだ。

リスク登録簿とは

リスク登録簿（リスクレジスター、Risk Register） は、プロジェクトで見つけた リスク を一覧にし、それぞれの 発生確率・影響度・対応策・担当者・状況 を記録して管理する表です。ここでいうリスクとは「まだ起きていないが、起きると目標（品質・費用・納期）に影響する不確かなこと」を指します。リスク管理の国際規格 ISO 31000 では、リスクを「目的に対する不確かさの影響」と定義しています。

よく混同されるのが 課題（イシュー） です。課題は「すでに起きている問題」、リスクは「これから起きるかもしれない問題」です。たとえば「ベンダーの主担当が来月異動するかもしれない」はリスクで、実際に異動が決まれば課題になり、課題管理台帳に移して対処します。

登録簿はキックオフのころに最初の版を作り、定例会議のたびに見直します。作って終わりにせず、新しいリスクを足し、消えたリスクを閉じ、点数を付け直す ことで、プロジェクトの「危なさ」の地図として働きます。

登録簿の項目と点数の付け方

項目	書く内容	例
ID・登録日	管理番号と見つけた日	R-07／2026-05-12
リスクの内容	「〜のため、〜が起き、〜になる」の形で	既存データの形式がばらばらなため、移行に時間がかかり、稼働日が遅れる
発生確率	1〜5や高・中・低	4
影響度	費用・納期・品質への影響を1〜5で	4
スコア	発生確率 × 影響度	16（高）
対応策	予防策と、起きたときの手当て	早めに試し移行を行う／稼働日を1週ずらす案を用意
リスクオーナー	見張って手を打つ担当者	情シス田中
きっかけ（予兆）	起きそうだと判断する合図	試し移行でエラーが1割を超えたら
状況	監視中・対応中・終了	監視中

スコアの高いリスクから手を打ち、低いものは「受け入れる」と決めて記録だけ残します。全部に同じ力をかけないのがコツです。

リスクって、どうやって見つければいいの？思いつかないよ…

いい質問！ひとりで考えると漏れるから、キックオフで関係者に5分ずつ「心配なこと」を書いてもらう のがおすすめだよ。現場、経理、ベンダー、それぞれ見えている不安が違うんだ。

それと、ネタ帳になるのが 過去のプロジェクトの反省メモ。「データ移行で遅れた」「承認者が忙しくて確認が止まった」みたいな話は、どの会社でも繰り返されやすいよ。

ベンダーにリスクを聞いたら「特にありません」って言われた。信じていい？

うーん、それはちょっと心配なサインだね。リスクがゼロのプロジェクトなんてまずないんだ。「特にない」は、まだ考えていないか、言いにくいかのどちらかのことが多いよ。

「発注側に原因があるリスクも含めて、上位5つを教えてください」と聞き方を変えてみて。こちらの承認の遅れやデータ準備のことを言ってもらえると、すごく役に立つんだ。

対応の考え方（脅威への5つの戦略）

戦略	考え方	システム発注での例
回避	原因そのものをなくす	実績のない新技術の採用をやめる
軽減	起きやすさや痛さを下げる	早めに試し移行をする、テスト期間を長めにとる
転嫁（移転）	他者に負担を移す	契約で責任範囲を決める、保険を使う
受容	手を打たず、起きたら対処する	影響の小さいリスク。予備の日数・予算を確保しておく
エスカレーション	自分たちの権限を超えるので上に上げる	全社の人事異動に関わるものをステアリングコミッティへ

PMBOKでは、良いことが起きる可能性（機会）も同じ登録簿で管理し、「活用・強化・共有」などの戦略を取るとしています。

歴史と背景

1980〜90年代：大規模なプロジェクトの失敗をきっかけに、リスクを一覧にして管理する手法が広がります
1996年：PMIの PMBOKガイド が「プロジェクト・リスク・マネジメント」を知識エリアとして整理。のちの版でリスク登録簿が主要な成果物として扱われます
2009年：リスクマネジメントの国際規格 ISO 31000 と用語の指針 ISO Guide 73 が発行。Guide 73 ではリスク登録簿を「特定したリスクに関する情報の記録」と定義しています
2018年：ISO 31000 が改訂され、日本でも JIS Q 31000 として取り入れられています
現在：Excelのほか、課題管理ツールやプロジェクト管理ツールの機能として管理するチームも増えています

実務のポイント

リスクを「〜のため、〜が起き、〜になる」の形で書き、原因と結果が分かるか
すべてのリスクに リスクオーナー（担当者の名前）がいるか
発注側に原因があるリスク（承認の遅れ、データ準備、担当者の異動）も載せたか
定例会議で 上位5件 を毎回見直す決まりがあるか
「受容」としたリスクに備えて、予備の日数や予算を確保したか
起きたリスクを課題管理台帳に移し、エスカレーションの手順と結び付けたか

規格	内容
ISO 31000:2018 / JIS Q 31000	リスクマネジメントの原則と進め方を定めた国際規格と日本版
ISO Guide 73:2009	リスクマネジメントの用語。リスク登録簿の定義を含む
NIST SP 800-30 Rev.1	情報システムのリスクアセスメントの手引き（米国）

参考文献・外部リンク

Risk register（Wikipedia 英語版） — 定義と、PMBOK・PRINCE2での項目の例
ISO 31000（Wikipedia 英語版） — 規格の成り立ちと2018年改訂の要点
NIST SP 800-30 Rev.1 Guide for Conducting Risk Assessments — 発生可能性と影響から評価する手順
PMI日本支部 — PMBOKガイド日本語版の案内