リスク管理（リスクマネジマント）はPMのキモ

リスク管理は、プロジェクトマネジメントでもっとも重要です。

プロジェクトマネジメントとは、リスクを早期に発見し対策することを繰り返すことであると言っても過言ではないと思います。

もし、計画が完璧であれば、リスクなどありません。

ですが、この世の中に完璧な計画は存在しないのが事実です。

だとすれば、必ず計画通りにいかないリスクが存在することになり、そのリスクを対処すれば成功すると言えます。

リスク管理の最初の一歩はリスクに気づくこと

リスク管理で重要なのは、リスクに気づくことです。

リスクとは、「まだ問題になっていないけど、この先問題になるかもしれない事象」のことを言いますので、事前に、問題になりそうなことを洗い出すことが重要です。

プロジェクト開始時点が、もっとも不確定要素が多いですから、リスクも一番多いと言うことができます。

また、リスクの数は、プロジェクトが進行するにしたがって、減少します。

プロジェクト開始時点で、リスクを洗い出しておくと後の管理がとても楽になります。

リスクの洗い出し方

リスクを洗い出す際に、良くありがちなのは、過去の経験に基づいて、過去に発生した課題や問題からリスクを洗い出すという行動です。

確かに、これも正解ですし、効果もありますが、同じプロジェクトは2つと無いと言われるように、過去の経験をなぞっても必ずしも成功すると限りません。

過去の経験を参考にしながらも、今回のプロジェクトにおけるリスクを洗い出すことができれば、成功に大きく一歩前進することができます。

では、どのようにリスクを洗い出すのが良いのでしょうか。

フレームワークを使って、リーダやメンバーとブレーンストーミングすることをお勧めします。

使うフレームワークは、以下の２つです。

• QCD（品質、コスト、納期）
• PMBOKの知識エリア

具体的には、例えば以下の表をブレーンストーミングで作成します。

PMBOK知識エリア	リスク内容	品質	コスト	納期
スコープ
タイム
コスト
品質
人的資源
コミュニケーション
リスク
調達
統合

この表では、縦軸にPMBOKの知識エリアを、横軸に、リスク内容とそのQCDを並べました。

ブレストで洗い出したリスクをリスク内容に記載し、そのリスクがQCDのどれに影響するのかをマークします。

例えば、「発注側責任者が忙しく、打ち合わせの日程調整が難しい。」というリスクがあれば、コミュニケーションの行のリスク内容に、そのことを記載し、納期のセルに○印を付けます。

QCDのセルは、○印の代わりに、大・中・小などの文字を記載しても良いでしょう。

納期であれば、「小＝１週間未満の遅延、中＝２週間未満の遅延、大＝それ以上」などと定義しておくとよりわかりやすくなります。

最後に、ブレストでなかなか発言が無いような場合に使える、ヒントを掲載しておきますので、これを参考に、ブレストの参加者に問いかけて、リスクを洗い出してください。

スコープ

• 要件が変更になる可能性（流動的要素）はあるか？
• ユーザ側の担当者が変更になる可能性はあるか？
• ユーザ側担当者の意見が覆る可能性はないか？
• ユーザ側担当部署とそれ以外の利害関係部署との力関係は問題ないか？
• ユーザ企業の外部環境（景気、規制、業界動向など）に変化が発生する可能性はあるか？

タイム

• 全体スケジュールは長くないか？（長期間プロジェクトによるリスク）
• 全体スケジュールは短くないか？（短期間プロジェクトによるリスク）
• 季節特有の問題は発生しないか？（熱中症、インフエンザなど）
• ユーザ業務の繁忙期などを考慮できているか？
• スケジュールに余裕はあるか？
• 適度にマイルストーンを設定できるか？

コスト

• コストに強い制約（追加不可、目標原価率など）があるか？
• 予備費はあるか？
• コストダウンの施策はあるか？
• 見積りの精度に自信があるか？
• 為替の影響はないか？（オフショア、海外製品購入など）
• 業界全体で人手不足になる可能性はないか？（単価高騰など）
• ユーザ企業の財務状況に問題ないか？（急な予算削減など）

品質

• 自社に実績（事例）の無い技術を採用しているか？
• 業界であまり事例の無い技術を採用しているか？（リリース直後の製品など）
• 初経験のプロジェクトメンバーはいないか？（初めての○○技術挑戦など）
• 協力会社（外部ベンダー）との取引実績は豊富か？（初取引ではないか？）
• 品質目標（管理指標）を容易に設定できるか？
• 品質を上げるプロセスがしっかりできているか？（レビュー方法、テスト方式など）
• 納期優先の雰囲気・風潮はないか？（納期に厳しい制約、ノルマなど）
• アンコントローラブルな領域はないか？（パッケージ製品の採用など）

人的資源

• 代替の効かない人材がいるか？（希少スキル）
• 育成メンバーがいるか？（生産性低下）
• メンバーの性格や相性に問題はないか？（体制、組織編制に問題はないか）
• メンバーのモチベーションに問題はないか？
• 複数社が参加する（マルチベンダー体制）プロジェクトか？
• チームを横断する役割を持った調整役がいるか？（PMO、標準化、共通部品など）
• 体制・役割・責任・権限が明確になっているか？
• 責任と権限が一致しているか？
• リーダが管理するメンバーの人数は適正か？

コミュニケーション

• 意思決定者は明確か？（社内、顧客、協力会社）
• 定例的な会議対はあるか、また、各会議体の目的と役割は明確か？
• 会議体のルーチン（サイクル）に問題はないか？（レポートラインとタイミング）
• 例外事象発生時のルールがあるか？
• コミュニケーションツール（報告書、スケジュール、WBS、各種管理表など）はそろっているか、また、メンバーはそれらを使用した実績があるか？
• メンバーのモチベーションに問題はないか？
• 職場環境に問題はないか？（オフィス空間、生活環境、仕事道具など）
• 組織のライフサイクルモデルを意識した体制になっているか？
• ユーザとのコミュニケーション頻度、時間に制約はないか？（繁忙期、常に多忙）
• ユーザはプロジェクト経験があるか？

リスク

• このプロジェクトの一番の制約条件はなにか？（納期、品質、コスト）
• プロジェクト推進におけるトップ方針はあるか？（会社方針、組織目標など）
• 挑戦目標はあるか？（失敗する可能性が高い目標）
• リスクおよびリスク対策を報告し、了承を得る会議体はあるか？（ステアリングコミッティなど）
• コンティンジェンシープランはあるか？
• 予備費はあるか？
• 外的要因（プロジェクト外）による影響はないか？
• プロジェクト外に、リスク発生時のフォロー体制があるか？

調達

• 調達困難な要素があるか、また、それを考慮した計画になっているか？（希少性、代替不可など）
• 特殊な契約などがないか？（事例無し、契約に時間かかる）
• リードタイムの長い調達を把握しているか？
• クリティカルな調達に対して、十分な余裕があるか？（リードタイムなど）
• 初期不良が発生した際の対策が十分か？（人的資源調達含む）

統合

• PMの力量は十分か？（PM経験、顧客業界経験、知識など）
• 自社内、自組織内にプロジェクトマネジメントノウハウは豊富か？
• プロジェクト運営に関する各種ドキュメントのひな形、サンプルや標準があるか？
• 過去の類似プロジェクトを調査し、失敗事例を再現する可能性があるか？
• プロジェクト実行計画書（プロジェクト運営計画書）はあるか？
• プロジェクト監査組織はあるか？
• プロジェクトが火を噴いた際のリカバリー体制があるか？