リスクはマネジメントしないとね（前編）

プロジェクトマネジメント

2025.03.30

大変だー！大変だー！

やれやれ、また騒がしいな……

大変です、大変です！オオハシさ〜ん、助けてください！

で、どうしたんだい、インコ君。

実はですね……
先行リリースした機能で事故が起きたみたいなんです！
クライアントから「データ欠損」の報告が三件も……！
部長に報告して、チームにも指示して……
でも、何から手をつけたらいいか分からなくて……時間だけが過ぎて……困ったなーー！

なるほど、なるほど。
本来は、こういう事態に備えて「リスクマネジメント計画」を
プロジェクト初期に作っておくべきだったんだが……

リスクマネジメント計画？なんですかそれ？
そんなの作ってないですよーー！

……

ていうか、今まさに事故が起きてるのに、
今さら計画作るんですか！？

そう思うかもしれないけど……
今の状況だからこそ「整理する枠組み」が必要なんだ。
計画とはいっても、今から作るのは“簡易版”でいい。
混乱を収め、次の行動に移すための道しるべになる。

じゃあ、まずは「リスクの特定」。
起きていることを冷静に分類していこう。

ええっと……
・データ欠損によるクレーム
・表示がおかしいという指摘もあったなぁ……
・更新が反映されていない疑いも……

よし、それなら次は「リスク管理マトリクス」で可視化しよう。
ただし、1枚にまとめるんじゃなくて、性質ごとに分けて考える。

ポイントは2つだ。
【① データの種類】
・マスター系（参照のみ）
・トランザクション系（参照・更新あり）

【② ユーザー接点と機密性】
・ユーザーに表示される情報か？
・個人情報などのクリティカルなデータか？

一般的に、マスター系の表示データは
表示ミスや誤字などが多く、発生頻度は高め。
でも、ユーザー体験を損なう程度で、
会社が傾くようなリスクにはなりにくい。

逆に、更新を伴うトランザクション系は、
頻度はそこまで高くないが、
起きると致命的だ。
特に個人情報や決済データの漏洩となれば、
会社の存続にも関わるレベルになる。

な、なるほど……同じ“データ欠損”でも
影響が全然違うんですね……！

じゃあ、それを踏まえて
マトリクスを2つに分けて考えよう。

マトリクス①：トランザクション系 × クリティカル情報
リスク項目	発生確率	影響度
決済履歴の欠損	低	高
会員情報の破損	低	高
注文データの未反映	低	中

マトリクス②：マスター系 × 表示用データ
リスク項目	発生確率	影響度
カテゴリ名の欠落	高	低
ラベル不一致	中	中
多言語メッセージの誤表示	中	中

す、すごい……マトリクスで
こんなに頭の中が整理されるとは……！

感心してないで、今回の発生事象を当てはめてみよう。

はいっ！

今回のクライアントからの報告、どれに当たると思う？

えーっと、3件あって……
一番怒られてるのが、ある特定のお客さんからの注文データが
なぜか月末だけ反映されてないってクレームで、そこが一番深刻で……
あと1件は、商品のカテゴリ名称が違うっていう指摘で……
あ！もう一つ思い出しました！
クライアント協力会社の協賛企業のバナーと社名が古いっていうクレームです！

なるほど。
じゃあ、その3件を行にして、
「発生頻度」「影響度」「緊急度」を列にして
表にしてごらん。

えーっと、表にすると……

インコ君のリスク整理表
リスク項目	発生頻度	影響度	緊急度
注文データが月末だけ反映されない	低	高	最優先
カテゴリ名称の誤記	高	中	中
協賛バナーと社名が古い	中	低	低

おおっ！！

だろ？
こうすると、部長に報告する順番も、
メンバーに誰から何を対応させるかの順番も
自然と見えてくるだろう？

ありがとーー　オオハシさーーーん！！

分析は“怖さ”を“行動”に変える手段だよ。
この結果を使って、まずは部長に報告しよう。

リスクマネジメントとは何か？事故が起きても慌てないために

今回のインコ君のように、事故（インシデント）が起こると誰もがパニックになりますよね。
特にWebシステムの現場では、スピードと変化が求められ、
「とにかくリリースを優先したい」といった判断がされることも少なくありません。

テスト不足のまま、あるいは仕様変更が間に合わないまま本番に突入することも。
その結果、思わぬバグやトラブルが発生し、現場が混乱する……というのは、よくある話です。

では、そんな時にどうすれば良いのか。
その答えのひとつが「リスクマネジメント」です。

リスクマネジメントとは？

PMBOK（プロジェクトマネジメント知識体系ガイド）では、
リスクマネジメントはプロジェクト成功の鍵を握る重要な活動として位置付けられています。

最新の第7版では、「原則」や「パフォーマンス領域」に焦点を当てた構成となっており、
従来のような詳細なプロセスのリストは示されていません。
これは、現場ごとに柔軟な適用を可能にするためのアップデートです。

ただし、現場では今もなお、PMBOK第6版までで示されていた以下のような「7つのプロセス」が、
リスクマネジメントを進めるうえでの実践的なガイドラインとして広く使われています。

リスクマネジメントの7つのプロセス（第6版までの構成）

リスクマネジメント計画の策定
リスクの特定
定性的リスク分析
定量的リスク分析
リスク対応策の計画
リスク対応策の実行
リスクの監視

1. リスクマネジメント計画の策定

まず、プロジェクト全体で採用するリスク管理の手法を明確に定義します。
リスク管理計画書を作成し、リスク管理のアプローチや体制をまとめ、リスク対応を効果的かつ組織的に進める基盤を整えます。
具体的には、使用するツールやデータソース、メンバーの役割・責任分担、リスクの発生タイミングなどを記載します。
この計画は、プロジェクト計画の初期段階で実施されるのが理想です。
詳細については、以下の記事が参考になります。

PMBOKにおけるリスク管理の基礎知識！リスク管理表の作成方法を解説

2. リスクの特定

プロジェクトに影響を与える可能性のあるリスクを洗い出します。
関係者全員が参加し、ブレーンストーミングやチェックリストなどの手法を用いて、リスク登録簿を作成します。
各リスクは明確に記述し、責任者（リスクオーナー）を指名します。
プロジェクト進行中も新たなリスクが発生するため、継続的な特定が必要です。詳細は、以下の記事が参考になります。

プロジェクト管理におけるリスクマネジメント

3. 定性的リスク分析

特定したリスクの発生確率と影響度を評価し、優先順位を付けます。
これにより、どのリスクに注力すべきかが明確になります。
リスクマトリクスなどのツールを用いて、リスクを「高」「中」「低」などに分類します。

4. 定量的リスク分析

定性的分析で優先度が高いと判断されたリスクについて、数値的な影響を分析します。
シミュレーションや感度分析を用いて、リスクがプロジェクト全体に与える影響を具体的に評価します。

5. リスク対応策の計画

分析結果を基に、各リスクへの具体的な対応策を策定します。ネガティブリスクには回避、転嫁、軽減、受容などの戦略を、ポジティブリスクには活用、共有、強化、受容などの戦略を適用します。

6. リスク対応策の実行

計画したリスク対応策を実行し、リスクの影響を最小限に抑えます。
リスクオーナーは、対応策の進捗を監視し、必要に応じて調整を行います。

7. リスクの監視

プロジェクト全体を通じて、リスクを継続的に監視します。新たなリスクの特定、既存リスクの再評価、対応策の効果検証を行い、リスク登録簿を最新の状態に保ちます。

これらのプロセスを適切に実施することで、プロジェクトにおけるリスクを効果的に管理し、成功率を高めることができます。

現実は厳しい

上記のリスクマネジメントの7つのプロセスは理想的には素晴らしいものですが、
実際には今回のインコ君のように事故が起きた後に存在を知るみたいなことがあったり
または、計画のかなり前に作って、リリースした際には資料の場所がわからなくなっていたり
当初の設計段階で作成した資料はゴミになっているということもざらです。
でも、だからと言って「リスクマネジメント」の手法を知らないとか使わないというのは
非常に勿体無いと思います。
今回のオオハシさんが行ったように　「いい感じに」使いこなすと非常に実用的なものになるわけです。

特に今回例に示した「定性的リスク分析」は頭に入れておくと計画の際もレビューの際も
実行の際も非常に強力なツールになります。
その際、ただ、表を知るだけではなく、ITやWEBシステム特有のデータの性質などから
リスクを管理することが重要です。

以下は中堅のエンジニアの人なら誰でも行っているあたり前の分類ですが、
駆け出しのインコ君のような人は知っていると気が楽になります。
では、インコ君に説明したオオハシさんの会話を振り返ります。

感覚に頼らない「リスクの分類方法」

リスクを整理する際にありがちなのが、「とにかく大変そうなものから対応する」という感覚的な判断です。
ですが、これでは本当に重大なリスクを後回しにしてしまう恐れがあります。

そこで使えるのが、以下の2軸による分類です。

① データの種類
　- マスター系（参照専用：カテゴリ名や表示ラベルなど）
　- トランザクション系（更新を伴う：注文データ、会員情報など）
② ユーザー接点・機密性
　- ユーザーの目に触れるか
　- 個人情報などの重要性を含むか

この2軸で整理することで、リスクの本質が見えてきます。

たとえば：

表示データの誤記は頻繁に起こるが、影響は限定的（＝発生頻度は高いが影響度は低い）
一方で、注文情報や個人情報の欠損は発生頻度は低くても、会社全体への影響が大きい（＝影響度は非常に高い）

リスク影響度マトリクスで見える化する

分類ができたら、次は「発生頻度 × 影響度」の2軸でマトリクス化します。
さらに「緊急度」も加えておくと、対応の優先順位が自然に導き出せます。

インコ君の今回の表

リスク項目	発生頻度	影響度	緊急度
注文データが月末だけ反映されない	低	高	最優先
カテゴリ名称の誤記	高	中	中
協賛バナーと社名が古い	中	低	低

表にすることで、直感では見えにくかった「重要だけど見逃していたリスク」が可視化され、
クライアントへの報告や、社内メンバーへの対応指示にも一貫性が出ます。

まとめ：分析はパニックを整理し、行動につなげる

事故やトラブルが起きると、誰でも焦ります。
ですが、「なにが起きたのか」「どれが重要なのか」「どこから手をつけるべきか」を冷静に可視化することで、
対応の質とスピードは格段に上がります。

今回の前編では、リスクマネジメントの基本的な考え方、
そして「分類」「評価」までのプロセスを紹介しました。

次回の後編では、具体的なリスク対応策の立て方、実行のポイント、
そして起きた後の「監視・教訓化」までの話になるのでしょうか？