目次
はじめに
目的
本資料は、プロジェクト管理におけるリスクマネジメントの全体像を分かりやすく伝えることを目的としています。基本的な定義から、実践的な6つのステップ、よくあるリスクの種類、使える手法までを順に解説します。現場ですぐ使える実例を交えて、プロジェクト成功につなげることを重視しました。
読者想定
プロジェクトマネージャー、チームリーダー、プロジェクトに関わるメンバーや、リスク管理を学び始めた人を想定しています。専門用語は最小限にし、はじめて学ぶ方でも理解できるようにしています。
本資料の使い方
各章は独立して読めますが、順に読むと理解が深まります。例えば「納期遅延」「要件変更」「予算不足」など具体例をもとに、リスクの見つけ方→評価→対策→監視までの流れを体験してください。実務ではチームで話し合い、記録を残すことをおすすめします。
学び方のポイント
小さなプロジェクトから試して習慣化してください。リスクは一度で終わらず変化しますので、定期的に見直すことが重要です。次章からは、まず基本的な定義を丁寧に説明します。
プロジェクトリスクマネジメントの基本定義
とは何か
プロジェクトリスクマネジメントは、目標達成に影響する「不確実な事象」を体系的に扱うプロセスです。PMBOK第7版では、リスクを正または負の影響を与える不確かな事象と定義します。単なる危険だけでなく、計画に影響するあらゆる不確かさを含みます。
目的
主な目的は、望ましくない結果を減らし、好ましい機会を活かすことです。スケジュール遅延や予算超過を防ぐだけでなく、予期せぬ好機を取り込むためにもリスクを扱います。
主な活動（簡潔）
- 特定：関係者と協力して起こり得る事象を洗い出します。
- 分析：影響の大きさや発生確率を評価します。定性的な評価でも充分に役立ちます。
- 対応計画：予防、軽減、移転、受容など具体策を決めます。
- 監視・管理：計画の効果を見て必要に応じて調整します。
具体例
- 需給不足→代替調達先を確保
- 技術的課題→試作で早期に検証
- スコープ変更→承認ルールを明確化
- 人員の離脱→スキルの共有とバックアップを用意
プロジェクトマネージャーの役割
プロジェクトマネージャーはリスクを先回りして特定し、対応を実行し、チームや関係者に情報を伝え続けます。日々の観察と定期的なレビューで計画を守りやすくします。
リスクマネジメントの重要性と役割
なぜリスクマネジメントが重要か
リスク管理は、プロジェクトを予算・スケジュール・品質の目標に沿って進めるための基本です。例えば見積り漏れで追加費用が発生したり、承認遅延で納期が伸びると、全体計画が崩れます。リスクを先に洗い出すことで、被害を小さくできます。
主な役割
- 問題の早期発見と優先順位付け: 発生可能性と影響度で対応順を決めます。具体例としては、セキュリティ脆弱性は高優先で対応します。
- 対応策の準備: 回避、軽減、移転、受容といった選択肢を用意します。ベンダー契約で責任範囲を明確にするのも有効です。
- コミュニケーション: 関係者に状況を共有し、共通認識を作ります。定期的なリスクレビューが効果的です。
組織での実践ポイント
- リスク登録簿（リスクログ）を作り、担当と期限を明記する。
- 定例会でリスク状況を更新する。
- 予備予算と予備日を確保しておく。
大規模ITプロジェクトで特に重要な点
複数ベンダーや部署が関わると、責任の曖昧さで対処が遅れます。契約書にエスカレーション手順を入れ、受け渡し基準（Acceptance Criteria）を明確にしてください。テスト計画や移行リハーサルを早めに行うと運用移行時のトラブルを減らせます。
リスクマネジメントの6つのステップ
プロジェクトのリスクは放置すると大きな影響を招きます。ここでは実際に進めるときの6つのステップを、具体例を交えてわかりやすく説明します。
1. リスクマネジメント計画の立案
役割分担や報告ルール、判断基準を決めます。たとえば、週次でリスクレビューを行い、重大リスクはプロジェクトマネージャーが報告するなどを定めます。
2. リスクの洗い出し・特定
関係者ヒアリング、過去事例、チェックリストでリスクを列挙します。例：納期遅延、技術的障害、要員不足などをチームで洗い出します。
3. リスクの分析
影響の大きさと発生確率を評価し、優先順位をつけます。簡単なランク付け（高・中・低）やスコア表を使うと判断が早くなります。
4. リスクへの対応策立案
回避・軽減・受容・移転の観点で対策を検討し、担当者と期限を決めます。例：納期リスクには外部支援の手配で対応する、と明記します。
5. 対応実施
決めた対策を実行し、予防策や緊急対応手順を運用します。実施状況は記録して、問題発生時にすぐ参照できるようにします。
6. リスクの監視とコントロール
リスクは時間とともに変化します。定期的に見直し、状況に応じて計画を更新します。レビュー結果は次回の計画に反映して改善を続けます。
プロジェクトで発生し得る主なリスクの種類
概要
プロジェクトにはさまざまなリスクが生じます。ここでは現場で頻繁に見られる主要なリスクを挙げ、具体例と簡単な対策案を示します。
リソース不足
人員や技術、設備が足りないケースです。例：メンバーの急病で重要作業が滞る。対策：代替要員の登録や優先度付けで影響を小さくします。
運用上のトラブル
手順ミスやツール故障など運用に伴う問題です。例：バックアップ失敗でデータ欠損。対策：運用手順書の整備と定期的な検証を行います。
パフォーマンス低下
システムや人の作業効率が落ちる状況です。例：負荷増加で応答が遅くなる。対策：負荷試験や余裕のある設計で耐性を持たせます。
コミュニケーション不足
情報共有や報告が不十分な状態です。例：要件変更が関係者に伝わらず手戻り発生。対策：定期ミーティングと議事録で情報の透明性を保ちます。
目標の不明確さ
目標や範囲が曖昧で方向性がぶれるリスクです。例：顧客の期待と納品物が合わない。対策：成果物定義と受け入れ基準を早期に合意します。
予算超過
支出が見積りを上回るリスクです。例：外注費が膨らむ。対策：定期的にコストレビューを行い、予備費を確保します。
スケジュール遅延
納期に間に合わない事態です。例：設計遅延で全体スケジュールがずれる。対策：マイルストーン管理と早期警告で調整します。
外部依存・法規リスク
サプライヤー遅延や法令変更で影響を受ける場合です。例：外部APIが停止する。対策：代替手段と契約条項の見直しを用意します。
各リスクは単独で起きる場合と連鎖する場合があります。早めに洗い出し、簡単な対策を講じることで影響を小さくできます。
リスク管理に用いられる主な手法とフレームワーク
はじめに
リスク管理では、体系的かつ継続的に危険を見つけ、対応を決めて実行します。ここでは実務でよく使う手法とフレームワークを具体例とともにわかりやすく説明します。
リスクアセスメント（早期発見と評価）
リスクの発見と優先順位付けを行います。例：要件が不明確なら「仕様確定遅延」のリスクを洗い出し、発生確率と影響度を高・中・低で評価します。まずは簡単なスコア表を作ると運用しやすいです。
リスクヘッジ（影響軽減策）
リスクを避ける・減らす・移す・受け入れるの4つの対応を検討します。例：納期リスクにはスケジュールにバッファを入れる、外部委託で対応する、保険を掛けるなどです。
RBS（Risk Breakdown Structure）
リスクを階層的に整理します。大分類（技術、人員、外部）→ 中分類 → 個別リスクの順で並べると見落としが減ります。会議での共有資料として有効です。
PDCAサイクル
計画（Plan）→ 実行（Do）→ 評価（Check）→ 改善（Act）を回します。リスク対策を実行したら定期的に効果をチェックし、必要なら対策を修正します。
リスク登録簿（リスクレジスター）
リスクの一覧表を作り、説明・発生確率・影響・担当者・対策・ステータスを記録します。例：担当者が明確だと対応漏れを防げます。
定性的・定量的分析
定性的分析は優先度の判断に適します。定量的分析は影響を数値化し、期待損失（EMV）やモンテカルロで全体影響を把握します。小規模では定性的で十分な場合が多いです。
FMEA（故障モード影響解析）とシナリオ分析
重要な機能ごとに故障モードを列挙し、重大度と発生確率で優先順位を決めます。障害が起きた場合の具体的な対応シナリオも作っておきます。
トリガーとコンティンジェンシープラン
リスクが現実化した際に取る具体行動（代替サプライヤー使用など）と、その開始条件（トリガー）を設定します。例：納期遅延が2週間を超えたら代替手配を開始。
役割と定期レビュー
リスクオーナーを決め、定例でレビューします。経営層やステアリング委員会と情報共有すると重要度の高い決定が速くなります。
ツールと運用
簡単なスプレッドシートで始められますが、プロジェクトが大きくなれば専用ツール（リスク管理ソフト）を検討します。ポイントは継続して更新することです。
終わりに
これらの手法を組み合わせて使うと、体系的で実行力のあるリスク管理が実現します。定期的な見直しを忘れずに運用してください。