PMOのリスク管理とは？洗い出しから対応までの5ステップと課題管理との違い

「リスク管理表は初期に作った。でも、いま誰も開いていない」。外部ベンダーとシステム開発を進めるプロジェクトで、心当たりのある方は多いはずです。結論から言うと、リスク管理がうまく回るかどうかは、表の出来では決まりません。「起きてから対処する」のではなく「起きる前に潰す」活動を、プロジェクトの定型業務としてルーチン化できるかどうかで決まります。この記事では、PMOが担うリスク管理を洗い出しからモニタリングまでの5ステップに分解し、混同されがちな課題管理との違い、管理表の作り方と運用ルール、僕の信条である「前始末」の考え方までまとめました。読み終えたら、自社プロジェクトのリスク管理表を開いて、最終更新日を確かめてみてください。

リスクとは、まだ起きていない不確実な事象のこと。すでに起きてしまった問題（課題）とは、はっきり区別されます。プロジェクトマネジメントの正体は不確実性を段階的に減らしていく営みだと僕は考えていて、リスク管理はまさにその中核です。

僕が見聞きしてきた炎上には、共通のパターンがあります。リプレース案件なのに、発注側にも受注側にもシステム全体を理解している人がいないまま進めて、考慮漏れが大量発生した。フルスクラッチ開発なのに適切なレベルのシニアアーキテクトを確保できず、機能は動くが内部の作りが崩れていて、保守や機能拡張のたびに高い修正コストを払い続けることになった。スコープが曖昧なまま「早く始めたい」に押されて契約を結び、変更要望を押し込まれてコストが膨らんだ。原因を一言でまとめれば、どれも「リスクを後回しにした」。それだけです。

ではPMOは何をするのか。リスク管理でPMOが担う一番の仕事は、リスクを見つけて潰す活動をPM個人の注意深さに任せず、組織の定型業務として回る構造にすることです。洗い出しの場を設計し、管理表の運用ルールを決め、定例のリスクレビューをアジェンダに固定する。個人技を仕組みに変える、と言ってもいい。

もうひとつ、前提として押さえてほしい心構えがあります。YouTubeの講座でも強調した点です。

format_quote

好機リスクに対しては、起こることを期待しない。そして脅威リスクに関しては、起こらないと願うのではなくて、必ず起こると思ってかかる。これがリスクに対してのPMの正しい受け方になります。

リスクという言葉には下振れ（脅威）だけでなく上振れ（好機）も含まれますが、人間は起きてほしいことは起きると期待し、起きてほしくないことは起きないと思い込みたい生き物です。リスク管理はこの本能に逆らう活動だからこそ、個人の意志ではなく仕組みで担保する必要がある。PMOの出番はここにあります。

リスク管理表と課題管理表がごちゃ混ぜになっている現場は珍しくありません。両者は「まだ起きていないか、もう起きたか」で明確に分かれます。

使い分けのルールはシンプルです。リスクが顕在化した瞬間に、リスク管理表ではクローズし、課題として課題管理表へ転記する。この一方通行を徹底します。逆に、課題管理表に「〜かもしれない」という未来形の行が並び始めたら、リスクとして抜き出して評価し直すサインです。

混ざったまま放置すると何が起きるか。課題の期限管理のリズムでリスクまで扱われるため、「期限が来ていないから見なくていい」ものとしてリスクが埋もれ、定例で誰も言及しなくなります。リスクは期限ではなく鮮度で管理するもの。この時間軸の違いこそ、表を分けるべき理由です。なお、すでに形骸化してしまったリスク管理の立て直しは、本記事とは別の大きなテーマなのでここでは深入りしません。

ステップ1：リスクを洗い出す

すべての起点です。ここで拾えなかったリスクは、評価も対応もされないまま、ある日突然目の前に現れます。

やり方は二段構え。まず、リスクについて考える時間をカレンダーに確保して、とにかく考え抜きます。「リスクは最初に考えました」と言うのは簡単ですが、本当に考え抜いているPMは少ない——これはYouTubeの講座でも強調した点です。自分の頭から出せるものは全部出した、と言い切れるところまでやる。そのうえで二段目として、類似システムや類似業務の経験者、プロジェクト内のリーダークラスといった第三者にレビューしてもらい、自分の頭にない観点を借ります。

発注側の立場なら、洗い出しのときに最低限この5点を確認してください。

• 契約・スコープ：曖昧な部分を残したまま契約・発注しようとしていないか
• 体制：システム全体を理解している人が発注側・受注側のどちらかにいるか。フルスクラッチならシニアアーキテクト級の技術者を確保できているか
• 自社側キーマン：業務仕様を即断できる人が、最後まで会議に出続けられるか
• 技術：生成AIのように「やってみないと精度が分からない」要素はどこにあるか
• 変更管理：現場からの変更要望を受け止めて交通整理できるリーダーがいるか

冒頭で挙げた炎上パターンは、すべてこのどれかで事前に拾えたものです。

ステップ2：発生確率と影響度で評価する

洗い出したリスクのすべてに対応しようとすると、コストがいくらあっても足りません。そこで発生確率と影響度の2軸でスコアリングし、優先順位をつけます。凝った点数計算は不要で、それぞれ高・中・低の3段階あれば十分。大事なのは数字の精緻さではなく、「どれから手を付けるか」をチームで合意しておくことです。

ステップ3：対応計画を立てる——回避・軽減・転嫁・受容

優先度の高いリスクから、対応方針を決めていきます。対応は4つに分類できます。

ここで絶対に外せない順番があります。

format_quote

まずは転嫁ですとか軽減を考えるのじゃなくて、回避できるリスクそのものをなくしてしまうのが一番いいに決まってるので、まずはそこから考えていく。

回避を最初に検討し、無理なら軽減や転嫁、最後に受容の順です。受容を選んでいいのは、発生しても影響がごく小さいリスクだけ。対応にはコストがかかるため、つい受容に流したくなりますが、そこでサボらないことがPM・PMOの踏ん張りどころです。

ステップ4：対応策を実行し切る

意外かもしれませんが、ここが一番よく抜けます。初期にリスク管理表を作り、対応策も書いた。ところが、その対応策が実行に移されたかどうかを誰も追っていない——冗談みたいな話ですが、本当によくあるんです。対応策には担当と期限を付け、実行状況を進捗管理のサイクルに乗せてください。

目指す状態も明確です。提案や要件定義といったプロジェクトの初期段階までにリスクを洗い出し切り、対応計画に書いた打ち手をやり切っておく。たとえばフルスクラッチ案件なら、提案時点でシニアアーキテクトが必要なことは分かるのだから、早めに確保へ動き、要件定義と並行してリファレンス実装やベースコードの作成まで終わらせてしまう。僕のプロジェクトでは、ほとんどこの形で進めていました。

format_quote

プロジェクトの立ち上げフェーズですとか要件定義フェーズ、こういった初期段階でリスクを事前に潰していくという姿勢こそが、プロジェクト成功の最大の鍵になるのかなと思っています。

ステップ5：モニタリングとレビューをルーチン化する

初期に潰し切るのが基本ですが、プロジェクトが進めば新しいリスクは必ず出てきます。逆に、当初恐れていたリスクが陳腐化することもある。不安視していた外部の開発チームが、蓋を開けたら非常に高品質だった、というように。だから週次や月次でリスクレビューを定例化し、「新しいリスクは出ていないか」「陳腐化したリスクはないか」「顕在化したものはないか」の3点を確認します。レビューをカレンダーに固定しないと、目の前の業務に押されて、リスクを考える時間は絶対に取れません。

リスクが顕在化してしまったら、まず影響範囲を明確にし、必要ならスケジュール・コスト・スコープのベースラインを更新します。「なんとか乗り切れないか」という根性論で進めると、火は必ず燃え広がります。そして発注側として大事なのは、ベンダーが悪いリスク情報を早く出せる関係をつくること。事前にリスクを共有されていれば、顕在化したときも「残念だが、聞いていた話だ」と冷静に判断できます。事前共有を歓迎する発注者であること自体が、実は強力なリスク対策なんです。

この5ステップを実務に落とし込む際は、リスク管理表を含むテンプレートを土台にすると、ゼロから様式を考える手間を省けます。

リスクの洗い出しから対応計画・モニタリングまでの流れは、YouTubeの講座で約20分かけて解説しています。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「【PM講座 #10/12】リスクの具体的なマネジメント術を解説【プロジェクトマネジメントの教室】」

道具はシンプルで構いません。最低限、次の項目があれば回ります。

そして、表の出来よりも運用ルールが結果を分けます。

1. 定例のアジェンダに固定する：リスクレビューを「時間が余ったらやる」扱いにしない
2. 更新のオーナーを決める：全員の共有物は誰も更新しない。PMOが更新責任を持つ
3. 顕在化したら課題管理へ移管する：リスク管理表に「対応中の問題」を残さない
4. 陳腐化したらクローズ理由を書いて閉じる：行数を誇る表にしない。生きているリスクだけを見る

なお、この記事ではあえてテンプレートの配布はしていません。項目をコピーするより先に、上の運用ルールを自社の定例に組み込むほうが効くからです。それでも運用が止まってしまったときは、リスク管理が形骸化する原因の特定と立て直しから取り組む必要があります。

ここまで読んで、「そこまでやるのか。コストが掛かりすぎないか」と感じた方もいるはずです。実際、リスクの洗い出しにも対応策の実行にもコストは掛かります。それでもやるべき理由は明快で、事後対処のコストは事前対処よりはるかに大きいからです。

バグ一つ取っても、事前にケアするコストと比べて、事後だと3倍、5倍掛かります。不具合の修正だけでは済まない。バグレポートの作成、他に同じ問題が潜んでいないかの横展開の分析、お客様への説明、最悪の場合は本番障害としてエンドユーザーへのデータ補正まで、コストは雪だるま式に膨らんでいきます。柳井さんの言う「後始末じゃなく前始末」です。後始末の典型がプロジェクトの遅延対応で、リカバリにかかるコストと手間を考えれば、前始末との差がどれほど大きいか実感できるはずです。僕はこれを人のマネジメントにも当てはめていて、社員が限界を迎えてから慌てるのではなく、「そろそろきついかも」ぐらいの段階で手を打つようにしています。リスク管理の思想は、ヒトにもモノにも共通なんです。

タイミングがどれだけ効くかについて、動画ではこう話しました。

format_quote

リスクの対応計画は、手前であれば手前であるほどインパクトを抑えることができるし、後になれば後になるほど、発生した時のインパクトも大きくなってしまう上に、打てる手立てがどんどん少なくなっていくんですよね。

発注側の読者に強調したいのは、初期段階でリスク対応に予算と時間を割く意思決定は、発注側にしかできないということです。要件定義前の「早く始めたい」をぐっとこらえて、リスクの洗い出しと対応に時間を使う。一見遠回りなこの判断は、3〜5倍のレートで返ってくる投資です。逆に、この工程を削って浮いたはずのコストは、テスト工程以降に何倍にもなって請求されます。

• リスクは「まだ起きていない不確実な事象」。すでに起きた課題とは表も運用も分け、顕在化したら課題管理へ一方通行で移す
• 実践は5ステップ。洗い出し → 確率×影響度の評価 → 対応計画 → 実行 → モニタリング。対応計画は回避 → 軽減・転嫁 → 受容の順で検討する
• 洗い出しは考え抜く時間の確保と第三者レビューの二段構え。対応策は提案・要件定義までに打ち切るのが理想形
• 管理表は項目の豊富さより運用ルール。定例レビューをルーチン化し、期限ではなく鮮度で管理する
• 前始末は後始末の3〜5倍安い。初期のリスク対応コストは削る対象ではなく投資

リスク管理は、特別な才能が要る仕事ではありません。考える時間を確保し、決めた対応をやり切り、レビューを定例に固定する。この地味な仕組みの積み重ねだけで、炎上の大半は防げます。いまあなたのプロジェクトが平穏だとしたら、それは仕組みの成果でしょうか、それとも単に運が良いだけでしょうか。リスク管理表の最終更新日が、その答えを静かに教えてくれます。

※本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

---

プロジェクトのリスク管理を仕組みから整えたいときは

「リスク管理表はあるが、更新が止まっていて機能している自信がない」「ベンダーからのリスク報告がいつも事後になってしまう」「定例のリスクレビューを回したいが、社内に設計できる人がいない」。こうした状態は、担当者の意識の問題ではなく、仕組みの不在が原因であることがほとんどです。

クリエイティブテックスタジオでは、リスクの洗い出しワークショップから管理表の運用設計、定例レビューの立ち上げまで、発注側に立つPMO支援を提供しています。お話を伺ったうえで、外部PMOを入れるまでもないケースや、他社のほうが適しているケースであれば、その旨も正直にお伝えします。

まずは現状のリスク管理表を見せていただくところからでも構いません。無料相談からお気軽にご連絡ください。支援内容の詳細はPMO支援サービスにまとめています。