PMBOKベースのリスク管理を実務に落とす

リスク管理と聞くと、難しい理論や分厚い表を思い浮かべるかもしれません。しかし本質はシンプルで、「起きたら困ることを先に考え、手を打っておく」ことです。本システムのリスク管理は、国際的なプロジェクトマネジメントの知識体系であるPMBOKの考え方をもとに項目が設計されています。この記事では、それを日々の実務で回す方法を紹介します。

リスク管理の4ステップ

ステップ	やること	本システムでの操作
1. 特定する	起きたら困ることを書き出す	リスクを起票する
2. 評価する	発生確率と影響度から優先度を決める	評価の項目を入力する
3. 対応策を決める	避ける・減らす・移す・受け入れる、のどれかを選ぶ	対応策を記録し、必要な作業をTODOやWBSとして関連付ける
4. 監視する	状況の変化を定期的に確かめる	ステータスを更新し、定例会で確認する

優先度の決め方

すべてのリスクに同じように対応する必要はありません。発生確率と影響度の組み合わせで、手を打つ順番を決めます。

リスクの優先度（発生確率×影響度）

対応策の4つの型

型	考え方	例（キーマンの異動リスク）
回避	リスクの原因そのものをなくす	異動の時期をずらしてもらうよう人事と調整する
軽減	起きる確率や影響を小さくする	業務知識をWikiにまとめ、2人目の担当者を育てる
転嫁	影響を他者に移す	ベンダーとの契約で知識の引き継ぎ作業を依頼する
受容	起きたときに対応すると決めておく	異動が決まったら、引き継ぎ期間を2週間設けると決めておく

リスクが現実になったら

リスクが実際に起きたら、それはもう「課題」です。次の手順で記録をつなぎます。

新しく課題を起票し、元のリスクと関連付ける
リスクのステータスを更新し、コメントに「課題○○として顕在化」と書く
用意していた対応策があれば、それを課題の対策として使う

この記録が残ることで、「予測できていたリスクか」「対応策は役に立ったか」を後から振り返ることができます。

リスクの洗い出しに使える観点

観点	問いかけの例
スケジュール	他のプロジェクトや繁忙期と重ならないか？
要員	特定の人にしか分からない作業はないか？
技術	初めて使う技術や製品はないか？
外部	取引先や他部門の回答待ちで止まる作業はないか？
要件	まだ決まっていない要件や、意見が割れている要件はないか？

運用のコツ

月1回は全員で洗い出す：リスクは一度書いて終わりではありません。工程が変わるたびに新しいリスクが生まれます。
数は多すぎないように：優先度の高い10件前後をしっかり監視するほうが効果的です。
「心配ごと」の段階で気軽に起票する：確度が低くても、書いておけば全員で共有できます。

まとめ

リスク管理は、未来の課題を減らすための投資です。本システムでは、リスクの記録から対応作業、課題への転化までが一つの仕組みの中でつながるため、理論だけで終わらない、実際に回るリスク管理ができます。