リスク登録テンプレート Permalink
このテンプレートを使って、Quire でプロジェクトのリスク登録を運用しましょう。各リスクを5×5マトリクスでスコアリングし、担当者を1名設定して、対応策を子タスクとして管理し、決まったサイクルで全体をレビューします。
リスク登録プロジェクトにアクセスして自分のワークスペースに複製すれば、一から作成する必要はありません。
また、ワークフローを効率化するためにすぐに使えるテンプレートも多数ご用意しています。
リスク登録を理解する
リスク登録とは、プロジェクトで起こりうる問題と、それぞれへの対応策をまとめた生きたリストです。ここで重要なのは「生きた」という言葉です。8月時点と11月時点で内容がまったく変わっていない登録は、誰も使っていない証拠であり、リスクが管理されているように見えて実際には管理されていないため、何もない状態より悪いと言えます。
リスクは分類ごとにセクションにまとめられており、集中している箇所が一目でわかります。1つの分類に5件のリスクが集まっている場合、たいていは5つの独立した問題ではなく、1つの構造的な問題があることを示しています。
リスク本体は6つのセクションに分かれており、予算とコスト、スケジュールと納期、リソースと人材、技術と品質、ベンダーとサードパーティ、外部・市場・コンプライアンスをカバーしています。下部の7つ目のセクションにはレビューサイクルが管理されています。Categoryフィールドには7つの選択肢があり、外部・市場とコンプライアンス・法務を分けることで、フィルタリング時にも両者を区別できます。
テンプレートには20件のサンプルリスクが詳細に記載されており、自分のリスクに置き換える前に、良い項目の形を確認できます。
5×5マトリクスでリスクをスコアリングする
発生可能性を1〜5で評価し、影響度を1〜5で評価して、掛け合わせた結果をリスクスコアに入力します。この数値を基に並べ替えを行うことが、登録で行う最も有用な操作です。
| ↓ 発生可能性 / 影響度 → | 1 無視できる | 2 軽微 | 3 中程度 | 4 重大 | 5 深刻 |
|---|---|---|---|---|---|
| 5 ほぼ確実 | 5 | 10 | 15 | 20 | 25 |
| 4 高い | 4 | 8 | 12 | 16 | 20 |
| 3 可能性あり | 3 | 6 | 9 | 12 | 15 |
| 2 低い | 2 | 4 | 6 | 8 | 10 |
| 1 まれ | 1 | 2 | 3 | 4 | 5 |
注意: リスクスコアは数式ではなく、手動で入力する番号です。Quire の数式は2つのSelectフィールドを掛け算できないため、発生可能性と影響度のラベルを数値だけでなく読みやすい形で保つかわりに、手動で掛け算を行うトレードオフがあります。
リスクレベル
スコアは4つのバンドのいずれかに分類され、各バンドには異なる対応義務が課されます。これにより、スコアリングが単なる形式的な作業にならずに済みます。
| バンド | スコア | 必要な対応 |
|---|---|---|
| Low | 1〜4 | 受け入れて記録。四半期ごとにレビュー。対応計画は不要。 |
| Medium | 5〜9 | 担当者を設定して対応記録を作成。1か月ごとにレビュー。 |
| High | 10〜14 | 担当者を設定して、日程付きの資金計画を作成。週単位でレビュー。 |
| Critical | 15〜25 | スポンサーにエスカレーション、コンティンジェンシーを確保、ステアリンググループに報告。 |
スコアリングでよくある2つの誤り
すべてに4を付ける。 登録の大半がHighに集中している場合、スケールが機能しなくなり、優先度リストとして機能しなくなります。意識的にばらつきを持たせてください。1になるものがあることを受け入れることが重要です。
誤った影響でスコアリングする。 出来事の一般的な深刻さではなく、プロジェクト目標への影響でスコアリングしてください。サプライヤーの倒産は深刻に聞こえますが、他に2社のサプライヤーが対応できるなら、プロジェクトへの影響は軽微です。
テーブル表示でレジスターを確認する
テーブル表示は Professional、Premium、Enterprise プランのみでご利用いただけます。詳しくは料金ページをご覧ください。
このテンプレートはテーブル表示で最大限に活用できます。すべてのスコアリングフィールドが列として表示され、リスト表示では難しい項目間の比較が一目でできます。
リスクスコアの降順で並べ替えすると、登録が順位付きの作業リストになります。テーブルでフィールド値を直接編集できるため、月次の再スコアリングが短時間で完了し、実際に実施されやすくなります。
カスタムフィールド
評価を記録する8つのカスタムフィールドがあります。
| フィールド | タイプ | 用途 |
|---|---|---|
| Risk ID | テキスト | R-01のような安定した参照番号。タイトル全体を貼らずにメモでリスクを引用できる |
| Category | 選択 | プロジェクトのどの部分が影響を受けているか |
| Likelihood | 選択 | 1(まれ)〜5(ほぼ確実) |
| Impact | 選択 | 1(無視できる)〜5(深刻) |
| Risk Score | 番号 | 発生可能性×影響度、1〜25 |
| Risk Level | 選択 | スコアをLow、Medium、High、Criticalに分類 |
| Response Strategy | 選択 | 回避、軽減、移動、受容、エスカレーション |
| Date Identified | 日付 | 長期間見直されていない項目を特定するのに便利 |
リスク項目を記述する
テンプレートのすべてのサンプルリスクは、説明の中で同じ4部構成に従っています。この形式をコピーしてください。
- リスクステートメント:何が起こりうるか。可能な限り数値を添えて記述する
- トリガーまたは早期警告:これが現実になりつつあることを示す観察可能なシグナル
- 発生した場合の結果:プロジェクトへの影響。これが影響度スコアの根拠となる
- 現在の対応策:戦略と具体的なアクション
「クラウド費用が月額42,000ドルから58,000ドルに増加する可能性がある」は実用的な記述です。いつ起きているかがわかるからです。「コストが増える可能性がある」は不十分です。トリガーも同様に重要です。観察可能なシグナルがなければ、誰かが気づくことに頼ることになりますが、「気づく」はコントロールではありません。
担当者は1名
すべてのリスクに担当者を設定します。チームや役割ではなく、必ず1名の個人です。リスクを共同で所有すると実質的に誰も所有していない状態になり、担当者のいないリスクは登録が形骸化する最も確実な予兆です。
担当者は必ずしも対応作業を行う人ではありません。対応策が存在し、常に最新の状態に保たれており、機能がストップしたときにエスカレーションされることに責任を持つ人です。
対応策を子タスクとして管理する
具体的な手順は、各リスクの下の子タスクとして追加し、それぞれに担当者と期限の日を設定します。これが、実際に変化をもたらす登録と、単に状況を記述するだけの登録との分かれ目です。
対応策が本物かどうかを確かめるテストがあります。担当者と期限の日を持つタスクとして記述できなければ、それは対応策ではなく願望です。「状況を監視する」や「ベンダーと密に連絡を取る」は、どちらもこのテストに合格しません。
対応戦略
すべてのリスクには対応戦略を1つだけ設定します。
- 回避:リスクが発生しないよう計画を変更する。使えるときは最も低コストな選択肢だが、通常スコープの削減を伴う。
- 軽減:発生可能性、影響度、またはその両方を低減する。ほとんどのHighリスクへのデフォルト対応。
- 移動:保険、固定価格契約、ペナルティ条項などにより、財務的な結果を他者に移動する。コストは移動するが混乱は移動しないため、時間のロスは依然として発生する。
- 受容:リスクを認識し、予算を確保した上で、それ以上の対応は行わない。Lowリスクには有効だが、決定を記録しておく必要がある。受容は選択であり、対応しないことではない。
- エスカレーション:自分の権限外にある場合はスポンサーに引き上げる。推奨事項を添えれば責任の回避にはならない。
対応ワークフローを追跡する
Free Subscriptionプランでは各プロジェクトに最大5つのステータスを設定できますが、このテンプレートは6つ使用しています。複製後にAnalyzingをPlanning Responseに統合するか、サブスクリプションプランをアップグレードして6つすべてを保持してください。詳しくは料金ページをご覧ください。
リスク自体が完了することはありません。完了するのはリスクへの対応です。6つのステータスでその進捗を追跡します:Identified、Analyzing、Planning Response、Mitigating、Monitoring、閉じました。
ボード表示ではすべての項目がステータス別にグループ化され、各カードにスコアリングフィールドが表示されます。対応の子タスクもリスクと並んで表示されるため、リスクだけを確認したい場合はフィルターでトップレベルに絞り込んでください。
閉じましたは、リスクへのエクスポージャーが恒久的になくなったことを意味します。心配するのをやめただけではありません。まだ発生しうる場合はMonitoringに置いてください。
タグ
5つのタグが分類をまたいで機能し、スコアリングフィールドでは答えられない問いに対応します。
- Trigger Fired:早期警告がすでに発動している。最初に確認すべき項目
- Launch Blocker:未解決の場合リリースを停止する
- Escalated to Sponsor:チームの権限外
- Contingency Reserved:この項目のために予算が確保されている
- Needs Re-scoring:前回の評価以降に状況が変化した
決まったサイクルでレビューする
登録の最下部にあるガバナンスセクションには、繰り返しのタスクとしてレビューが設定されており、誰かが覚えているかどうかに関わらず予定どおりに表示されます。
それぞれ異なる役割を持つ4つのサイクル:
| サイクル | 内容 |
|---|---|
| 週単位 | HighとCriticalのみ、スコア順で並べ替え。約30分。 |
| 隔週 | スプリント計画の終わりに20分、不足しているリスクを追加。 |
| 1か月ごと | 登録全体を再スコアリングし、該当しなくなったものを終了。 |
| 四半期 | ステアリンググループへの1ページレポート。 |
週単位のレビューでは、各リスクに対して3つの質問をします:
- スコアが変わったか、リスクレベルの更新が必要か?
- 対応策が実際に移動しているか、3週間以上進行中のままになっていないか?
- トリガーが発動したか?
登録のどのフィールドにも変更がなかったレビューは、実際には行われなかったのと同じです。
ヒント: リスクを終了する際は、実際に発生したかどうか、予測した影響と実際の影響の比較、同じスコアをつけるかどうかを記録してください。最後の質問こそが次のプロジェクトを楽にする部分であり、それを省略することが、多くのチームが5年後も1年目と変わらずリスクのスコアリングが上達しない理由です。
リスクのスコアリング方法と登録を生きた状態に保つ方法について、ブログでさらに詳しく読む。
よくある質問
リスク登録とは何ですか?
リスク登録とは、プロジェクトで起こりうる問題と、それぞれへの対応策を、発生可能性、影響度、担当者、対応策とともにまとめた生きたリストです。前回のレビューで何も変わっていなければ、レビューは行われなかったと同じです。
リスク登録には何を含めるべきですか?
リスクステートメント、発生可能性の評価、影響度の評価、総合スコア、担当者1名、対応戦略の6つが必要です。安定したリスクID、分類、特定日があると、実用性が大きく向上します。
リスクの発生可能性と影響度はどのようにスコアリングしますか?
それぞれを1〜5で評価して掛け合わせます。発生可能性はまれからほぼ確実、影響度は無視できるから深刻まで評価します。出来事の一般的な深刻さではなく、プロジェクト目標への影響でスコアリングしてください。
5×5リスクマトリクスとは何ですか?
発生可能性と影響度をそれぞれ1〜5で評価したグリッドで、スコアは1〜25の範囲になります。スコアはバンドに分類され、各バンドに異なる対応義務が課されます。これによって番号が必要なアクションに変換されます。
5つのリスク対応戦略とは何ですか?
回避、軽減、移動、受容、エスカレーションの5つです。移動はコストを移動するだけで混乱は移動せず、受容は対応しないことではなく文書化された決定です。
リスク登録でリスクの担当者は誰が担うべきですか?
チームや役割ではなく、必ず1名の個人を指名してください。担当者は対応策が存在し常に最新の状態であることに責任を持つ人であり、必ずしも対応作業を行う人ではありません。実際の作業は子タスクで別途担当者に割り当てられます。
リスク登録はどのくらいの頻度でレビューすべきですか?
HighとCriticalは週単位で、不足しているリスクの追加は隔週で、全体の再スコアリングは1か月ごとに、ステアリンググループへの報告は四半期ごとに行います。テンプレートにはこれらが繰り返しのタスクとして設定されており、自動的に予定に表示されます。
Quire でリスク登録を作成するにはどうすればよいですか?
リスク登録テンプレートを複製し、テーブル表示に切り替えて、リスクスコアの降順で並べ替えます。サンプルリスクで4部構成の項目の形を確認し、サンプルを削除したあと、フィールドとセクションを残して自分のリスクを5件ほど追加してください。
Quire に既製のリスク登録テンプレートはありますか?
はい。リスク登録プロジェクトにアクセスして自分のワークスペースに複製すると、8つのカスタムフィールド、6段階のワークフロー、分類セクション、5つのタグ、繰り返しのレビュータスクがすべて設定済みの状態で使い始められます。