プロジェクトのリスク登録簿：会議から作るテンプレートと記入例

リスクは起こり得るもの。問題はすでに起きているもの。

登録簿は結果に影響し得る不確かな事象の一覧です。何を観察し、何を前もって行い、いつ計画を変えるかを示します。

「顧客の資料が三日遅れた」は問題です。「水曜日までに届かなければ、確認が金曜日を過ぎるかもしれない」はリスクです。関連はありますが、必要な対応は異なります。ここでは一般のプロジェクトを扱い、安全衛生、監査、規制対応の専門台帳は扱いません。

チームの会話から登録簿を作る

1. 不確かさを示す発言を見つける

   「もし」「〜次第」「まだ分からない」「間に合わないかもしれない」を探します。プロジェクトのどの成果に関わるかを明らかにします。

2. 三つに分けて書く

   原因または条件 → 起こり得る事象 → 影響。「アレクセイがリスク」より「承認が一人に依存している」の方が原因を明確に示します。

3. チームと評価をすり合わせる

   発生可能性と影響を別々に見ます。小規模なら説明付きの定性的な段階で足ります。主観的な評価を計算済みの確率として示さないでください。

4. 監視の担当者を決める

   担当者は兆候を追い、情報を集め、問題を提起します。すべての原因を一人で取り除く必要はなく、事象が起きた責任を負うわけでもありません。

5. 事象の前後に取る行動を書く

   予防策は発生可能性や影響を下げます。代替策は決めた条件で発動します。それぞれの実行担当と制約を定めます。

6. 次の確認日を決める

   節目や新しい情報が出たときに見直します。依存が解消した、事象が起きた、対象の工程が終わったなど、終了する理由を記します。

連携のためのテストアクセス

架空の発言です。提供元が必ず遅れると判断はできません。リスクを登録し、申請状況は別に確認します。

「70%」と書いていないのは、数値を裏付けるデータがないためです。提供元の回答後に評価を更新できます。日時を決めると、新しい事実なしに同じ懸念を繰り返さずに済みます。

プロジェクトに合わせて見直す

アクセスが付与されたら実際に使えるか確かめます。「準備完了」というメールだけでは依存は解消しません。リスクが現実になったら、現在の問題と代替策に結び付けます。発生可能性が下がったら理由を記録します。

登録簿を使い続けます。会議では変更のあった項目、迫った発動条件、担当者のいないリスクを見ます。何が分かり、評価がどう変わり、次に何をするかを確認します。追加対策を取らない場合も、担当と見直し条件を明記します。

チーム向けの最小限の登録簿

IDと発見日：
プロジェクトの目標または段階：
[条件]の場合、[事象]が起き、[影響]が出るおそれがある。
出典：録音／タイムコード／裏付け資料：
発生可能性と根拠：
影響と根拠：
監視の担当者：
予防策、実行者、期限：
代替策の発動条件：
代替策と承認者：
次の確認日：
状態と変更理由：

• 条件を確認できる。
• 不確かさが明示されている。
• 発動条件の監視担当が明確。
• 次回の確認日がある。