プロジェクトのリスク管理がうまくいかない5つの原因｜形骸化からの立て直し方

リスク管理表は、ある。キックオフで洗い出しもやった。でも今その表を開くと、最終更新日は1カ月以上前——この記事を開いた方の多くに、心当たりがあるはずです。先に結論を言うと、リスク管理がうまくいかない原因は、管理表のフォーマットでも担当者の意識の低さでもなく、ほとんどの場合「運用の構造」にあります。僕は金融系SIerのシンプレクスで4年間PMを務め、独立後は発注側の立場でもプロジェクトに関わってきましたが、僕が見てきた範囲では、リスク管理が形骸化する現場の壊れ方はよく似ています。この記事では、機能不全に陥る5つの原因と、形骸化のサインの見抜き方、そして明日から着手できる立て直しのステップを解説します。

リスク管理の教科書的なプロセス（識別・分析・対応・監視）自体は、多くの現場がすでに知っています。知っているのに機能しない。だとすれば、問題はプロセスの知識ではなく、運用が壊れるポイントにある。僕が両側の立場で見てきた限り、壊れ方は次の5つに集約されます。

自社の管理表を思い浮かべながら、順に見ていってください。

原因1：洗い出しが浅いまま、プロジェクトが走り出している

リスク管理がうまくいかないプロジェクトは、たいてい入口でつまずいています。キックオフ時点の管理表に並んでいるのが「要員のスキル不足」「仕様変更の発生」といった、どのプロジェクトにも貼れる汎用リスクだけ。この案件固有のリスク——たとえばデータ移行の複雑さ、経験のない業務ドメイン、外部接続先の仕様確定時期——が書かれていない。

僕はYouTubeでリスクマネジメントの話をしたとき、こう言いました。

format_quote

プロジェクトの初期段階でリスクを潰して、大きいやつを減らそうっていうマインドセットがめっちゃ大事なんです。

プロジェクトが進むほど、打てる手は減り、1つのリスクが顕在化したときの被害は大きくなる。たとえばデータ移行は、リリース直前になって初めて着手して「実は3カ月かかる」と判明しがちな典型作業ですが、初期段階に「どのデータを、どの形式に、どう変換するか」まで具体化しておけば、致命傷になる前に対処できます。洗い出しの深さは、序盤にしか買えない保険なんです。

原因2：「起こらないといいな」の希望的観測で運用している

管理表にリスクが書いてあっても、心のどこかで「まあ、なんとかなるだろう」と思って進めている。これが2つ目の、そしてもっとも根深い原因です。動画でも話した通り、リスクは頭に浮かんではいるのに、祈りながら進んでしまう。

format_quote

リスクって、結構みんな思い浮かんではいるんだけど、「なんとかなってくれたら嬉しいなぁ」みたいな感じで進んじゃう。

希望的観測で運用されるリスク管理表は、実態としては「心配事の備忘録」です。備忘録は誰の行動も変えません。リスクとして書く以上、「起きたら誰が何をするか」まで決まって初めて管理と呼べます。

原因3：更新が個人の善意と記憶力に任されている

「リスク管理表は随時更新すること」——このルールが機能することは、まずありません。「随時」は「誰もやらない」の同義語です。更新のトリガーが定型業務に組み込まれておらず、気づいた人が気づいたときに書く運用になっていると、繁忙期に真っ先に止まるのがリスク管理表になる。そして皮肉なことに、リスクが実際に膨らんでいる繁忙期こそ、表がもっとも必要な時期なんです。

これは担当者の資質の問題ではなく、設計の問題です。人は忙しくなると、締め切りと催促のあるタスクから処理します。リスク管理表には締め切りも催促もない。だから後回しにされる。個人を責めても解決せず、更新される構造を先に作るしかありません。

原因4：リスクに「担当者」と「期限」がない

形骸化した管理表を開くと、担当者欄が「PM」「チーム全体」で埋まっていることが多い。全員の仕事は、誰の仕事でもありません。「対応中」のままステータスが3カ月動かないリスクは、実際には誰も対応していない。リスクごとに、対応策を実行する担当者1名と、対応状況を見直す期限をセットで持たせないと、表は動き出しません。

書き方の違いを比べると分かりやすい。「外部接続先の仕様確定が遅れる恐れがある（担当：チーム全体）」は動きません。「外部接続先の仕様確定が6月末を過ぎたら、7月第1週に代替スケジュール案を経営会議に諮る（担当：山田、次回見直し：6/20）」なら動きます。差は文章力ではなく、行動と名前と日付が入っているかどうかです。

原因5：悪い情報が「上がってくるのを待つ」構造になっている

最後の原因は、リスク情報の収集を報告任せにしていることです。進んでいないタスク、まずい兆候ほど、報告には上がってきません。報告する側に悪意があるわけではなく、状況を把握できていないから報告のしようがない、というケースが大半です。だからリスクは、待つのではなく組織として見つけに行く必要がある。ここを個人の注意深さに頼っている限り、管理表は「すでに顕在化した問題の記録簿」にしかなりません。

立て直しの前に、自社のリスク管理がどこまで止まっているかを確かめましょう。次の項目に3つ以上当てはまるなら、管理表は実質的に止まっています。

• 管理表の最終更新日が2週間以上前
• キックオフ以降、新しいリスクが1件も追加されていない
• ステータス「対応中」のまま1カ月以上動かないリスクが半数を超える
• 定例会議でリスクの議題が3回連続で「特になし」または時間切れスキップ
• リスクの記述が「〜の恐れがある」で止まり、対応策・担当・期限が空欄
• 課題管理表側でも、3日以上ステータスが動かないタスクが増えている

最後の項目は、僕が金融系プロジェクトのPM時代に毎朝チェックしていたポイントです。課題管理表やBacklogの更新が3日以上止まっているタスクは、「止まっている＝進んでいない」ではなく「止まっている＝状況を把握する余裕がない」のサインです。だから僕は更新が止まったタスクを見つけたら、ツール上ではなく口頭で担当者に直接確認するようにしていました。表が静かなのは平穏ではなく、異常のサインとして読む。これが形骸化を見抜く基本姿勢です。なお、リスク管理表が止まっている現場では定例会議も同じ構造で形骸化していることが多いので、あわせて点検することをおすすめします。

サインが確認できたら、立て直しです。ポイントは、フォーマットの刷新から入らないこと。表を作り直しても運用の構造が同じなら、3週間後に同じように止まります。以下の4ステップは、リスク管理の基本プロセス（識別・分析・対応・監視）の土台の上に、形骸化した現場を動かし直すための手順を重ねたものです。

ステップ1：棚卸し——死んだリスクを閉じる

まず既存の管理表を全件レビューし、すでに顕在化して課題化したもの、時期を過ぎて起こり得なくなったものをクローズします。汎用的すぎて行動につながらない項目（「メンバーのモチベーション低下」など）は、具体的な事象に書き直すか削除する。生きたリスクだけが並ぶ状態に戻すことで、表を見る意味が復活します。件数を絞ることは手抜きではなく、注意資源の再配分です。

ステップ2：「絶対起こる」前提で対応策を書き直す

残ったリスクを、発生前提で書き直します。僕がリスクマネジメントの考え方として一番強調したいのは、ここです。

format_quote

脅威リスクに関しては、「起こらないといいな」って考えがちなんですけど、基本的には絶対起こるという風に考えてください。これがわかっているだけで、本当に全然違うと思います。

「絶対起こる」と置くと、書くべきことが変わります。「発生に備えて注視する」ではなく、「発生したと判断するトリガーは何か」「発生したら誰が・何を・いつまでにやるか」「今のうちに発生確率か被害を下げる打ち手はあるか」。この3点が埋まらないリスクは、まだ管理できていないリスクです。

ステップ3：更新のトリガーを定型業務に組み込む

「随時更新」を廃止し、更新のタイミングを業務のリズムに固定します。僕の場合、毎朝の予兆チェック（課題のステータス確認）はルーチン化していました。これに加えて、週次定例の前日にリスク欄を見直すタイミングを固定することをおすすめします。個人の意識に頼らず、カレンダーと会議体に更新を紐づける。「気づいたら書く」ではなく「この時間に必ず見る」に変えるだけで、表の鮮度は劇的に変わります。

もう一つ大事なのは、見に行く対象を「書かれたこと」だけにしないことです。原因5で触れた通り、まずい兆候ほど表には書かれません。だから僕は毎朝のチェックで、更新が止まっているタスクを見つけたら、ツール上ではなく口頭で担当者に直接確認することをセットにしていました。表を見る時間と、表に出てこないものを拾いに行く動きを、同じルーチンに束ねる。ここまでやって初めて、リスク管理は「見つけに行く構造」になります。

ステップ4：会議のアジェンダに「リスクの判断」を入れる

定例会議のアジェンダに「リスクレビュー」の枠を常設し、報告ではなく判断の時間にします。扱う問いは3つで足ります。「新しく見えたリスクはないか」「トリガーに達したリスクはないか」「対応策を変えるべきリスクはないか」。5分でいい。ただし毎回必ずやる。リスクが会議で扱われ、そこでの発言が実際に判断につながる経験をチームが積むと、メンバーは「書けば動く」ことを学習し、表に書く動機が生まれます。逆に、書いても何も起きない表には、誰も書きません。

立て直しても、数カ月で元に戻る現場があります。差を分けるのは、リスク管理を「コスト」と見るか「投資」と見るかという、チームの共通認識です。

問題は、事前に対処するのと事後に対処するのとでは、事後のコストが遥かに大きい。バグ一つとっても、事前にケアするコストと比べて事後だと3倍、5倍かかります。不具合修正、バグレポート、横展開の分析、お客さんへの説明、最悪の場合は本番障害でエンドユーザーへのデータ補正まで、雪だるま式に膨らんでいく。ファーストリテイリングの柳井さんの言葉を借りるなら「後始末じゃなく前始末」で、僕はこれをリスク管理の経済合理性そのものだと思っています。毎朝10分の予兆チェックと週5分のリスクレビューは、燃えてからの火消し工数に比べれば圧倒的に安い。このコスト感覚をチーム全員が共有できたとき、リスク管理は「PMに書かされる表」から「自分たちの工数を守る道具」に変わります。

システム開発の成功率は3割と言われる世界で、リスク管理が機能しているかどうかは、その3割に入れるかを左右する数少ない変数です。なお、一度本格的に炎上してしまったプロジェクトの立て直しは、リスク管理の再建とは別の手順が必要になるため、本記事では扱いません。

この記事の土台になっているリスクマネジメントの考え方は、YouTubeチャンネルでも話しています。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「炎上リスクを最小化する究極のリスク管理テクを公開【リスクマネジメント①】」

• リスク管理がうまくいかない原因は、フォーマットや個人の意識ではなく運用の構造にある。洗い出しの浅さ・希望的観測・更新の属人化・担当者と期限の不在・報告待ちの5つが典型
• 形骸化は管理表の更新停止に表れる。更新停止・新規リスクゼロ・「対応中」の滞留をチェックリストで定点観測する
• 立て直しは棚卸し→発生前提での書き直し→更新の定型業務化→会議への判断枠の常設、の順で行う。フォーマット刷新から入らない
• 脅威リスクは「絶対起こる」前提で、トリガー・担当・期限まで決めて初めて管理と呼べる
• 前始末は後始末の3〜5倍安い。この経済合理性の共有が、運用定着の最後の鍵になる

リスク管理表が止まっているのは、チームが怠けているからではありません。止まる構造のまま運用が始まってしまっただけです。構造は、今日からでも設計し直せます。まずは管理表の最終更新日を確認するところから始めてみてください。自社だけでの立て直しが難しい場合は、表のフォーマットではなく「動く仕組み」ごと入れ直す選択肢として、外部のPMO支援を検討するのも一つの手です。

---

リスク管理の立て直しを、外部の目と一緒に進めたい方へ

「管理表はあるのに、リスクが毎回すり抜けて問題になる」「立て直したいが、日々の進行に追われて着手できない」「そもそも今の洗い出しに漏れがないか、経験者に見てほしい」——こうしたご相談は、リスク管理の運用設計を数多く手がけてきた僕たちのPMO支援でお応えできる領域です。

クリエイティブテックスタジオでは、リスク管理表の棚卸しと再設計、予兆を拾う定型業務の組み込み、会議体への定着まで、発注側の立場に立った伴走支援を行っています。詳しいサービス内容はPMO支援サービスをご覧ください。

まずは現状の管理表を見ながらの壁打ちからでも構いません。お話を伺ったうえで、外部支援を入れるまでもないケースや、他社のサービスが適しているケースであれば、その旨も正直にお伝えします。無料相談はこちらからどうぞ。