リスク管理

リスク管理の目的は、不確実性そのものをゼロにすることではなく、プロジェクトが受ける揺れ幅を許容できる範囲に収めることにあります。納期・コスト・品質・スコープといった制約は互いに引っ張り合っており、どこかが崩れると連鎖します。PMは、この連鎖の起点になりそうな事象を先に見つけ、備えを用意する役割を担います。

ここで扱う「リスク」は、悪い方向の脅威だけではありません。想定より早く進む余地や、追加の機会につながる好機も、計画に影響する不確実性として同じ枠組みで扱うことがあります。ただし実務では、まず脅威側の管理を優先して整えるのが一般的です。

PMがこの領域を担うのは、リスクが特定の担当者ではなく、プロジェクト全体の見通しにかかわるからです。開発リーダーは技術的な難所を、営業側は顧客都合の変更を、それぞれ部分的に把握しています。PMはそれらを一つの台帳に集約し、全体として何が最も危ういかを判断できる位置にいます。断片的な不安を、優先順位の付いた一覧に変えるのが、この活動の中心的な価値です。

進め方は、大きく四つの段階を繰り返す形になります。順に見ていきます。

• 識別：何が起こりうるかを洗い出す
  PMがメンバーや関係者に声をかけ、過去の類似案件の失敗や、要件定義書・基本設計といった成果物の曖昧な箇所を手がかりにリスクを列挙します。この段階では良し悪しを判断せず、数を出すことを優先します。
• 分析：影響度と発生度合いで並べ替える
  洗い出した項目を、起きたときの打撃の大きさと、起きやすさの二軸で見立てます。両方が高いものから対応の順番を決めます。厳密な数値化が難しい場合は、高・中・低の区分でも実務は回ります。
• 対応：方針を決めて備える
  各リスクに対し、回避・軽減・移転・受容といった方針から選びます。誰が、いつまでに、何をするかを決め、必要なら代替案（コンティンジェンシー）を用意します。
• 監視：状況の変化を追い続ける
  定例会などでリスク台帳を見直し、状況が変わった項目を更新します。新しいリスクが出れば識別に戻ります。

この四段階は一度で終わりません。要件が固まる、結合テストに入るといった節目ごとに、見えていなかった不確実性が現れるため、マイルストーンに合わせて回し直すのが基本です。

典型的なつまずきは、リスク台帳を一度作って満足し、その後更新されなくなることです。序盤に埋めた一覧が、中盤には現実と合わなくなっているのに誰も見ていない、という状態が起こりがちです。台帳は作る作業ではなく、見直し続ける仕組みだと捉えたほうが実態に合います。

もう一つは、対応方針が「注意する」「気をつける」といった曖昧な言葉で止まってしまうことです。誰の作業にもならない言葉は、実質的に何も決めていないのと変わりません。担当者と期限、具体的な行動まで落として初めて備えになります。

関係者との温度差も見落とされやすい点です。PMが重大だと見ているリスクを、依頼元のステークホルダーが軽く受け止めていると、対応に必要な時間や予算が確保できません。リスクの見立てそのものを早い段階で共有し、認識をそろえておくことが、後の合意を得やすくします。深刻さを一人で抱え込むと、いざ問題が表面化したときに、備えていなかったように見えてしまいます。

リスク管理と混同されやすいのが課題管理です。両者は扱う時間軸が異なります。リスクはまだ起きていない不確実な事象を指し、課題（イシュー）はすでに起きて対処が必要になった事象を指します。リスクへの備えが間に合わず現実になれば、それは課題管理の対象へ移ります。つまり二つは地続きで、リスク管理がうまく機能するほど、課題として噴き出す量を抑えられます。

体系的な枠組みとしては、PMBOKがリスク管理を知識領域の一つとして扱っています。識別・分析・対応・監視という流れも、こうした体系で整理されてきた考え方に沿っています。実務でそのまま全部を適用する必要はありませんが、抜け漏れを点検する物差しとして参照する価値があります。

また、スコープや品質の管理とも切り離せません。スコープが曖昧なままだと、それ自体が大きなリスク源になります。リスク管理は独立した作業というより、他の管理領域の不確実性を横串で見る視点だと考えると、位置づけがつかみやすくなります。

リスク管理の力は、職務経歴書や面接で伝わりにくい一方、実務では評価につながりやすい領域です。「大きなトラブルなく完遂した」という成果は、裏側で先回りの備えが効いていたことを意味しますが、そのままでは見えません。転職を検討する場面では、どんなリスクを事前に見立て、どの方針で対応し、結果としてどの制約を守れたのかを、具体的な工程や成果物に結びつけて語れると、再現性のある力として伝わりやすくなります。

また、この視点は担当する案件の規模が上がるほど比重を増します。関係者が増え、不確実性が重なる環境で全体を見渡せる人は、より上流の役割を任されやすくなります。日々の管理を、経験の棚卸しとして言語化しておくことが、次のキャリアの選択肢を広げる助けになります。

リスク管理と課題管理は何が違いますか。

扱う時間軸が違います。リスクはまだ起きていない不確実な事象で、起きる前に備えます。課題はすでに起きて対処が必要になった事象です。備えたリスクが現実になれば課題管理へ移るため、二つは地続きの関係にあります。

小規模なプロジェクトでもリスク管理は必要ですか。

規模に応じて軽くするのが現実的です。厳密な数値化や分厚い台帳がなくても、主要な懸念を数点書き出し、影響度と発生度合いで並べ、担当と期限を決めるだけでも効果があります。形式よりも、見直し続ける習慣のほうが重要です。

リスクの洗い出しはいつ行えばよいですか。

計画段階で一度行い、その後もマイルストーンごとに繰り返すのが基本です。要件が固まる、テスト工程に入るといった節目で、見えていなかった不確実性が現れます。一度で完了させず、プロジェクトの進行に合わせて回し直す前提で組むとよいでしょう。