議題

プロジェクトで問題が発生したとき、よく聞く言葉があります。

「そんな問題があるとは知らなかった。」

しかし、本当に怖いのは、知らなかった問題でしょうか。

私は違うと思っています。

「問題を知っていたのに、十分な対応まで完了しなかった。」

こちらの方が、プロジェクトでは遥かに怖い。

2026年、GMOインターネットグループ傘下のサービスで不正アクセスが発生しました。

その後の記者会見で、2024年4月の段階で、グループ内のセキュリティ専門家からシステム上の課題を指摘されていたことが明らかになっています。

指摘後、緊急メンテナンスも複数回実施されました。

つまり、

何もしていなかったわけではありません。

それでも、結果として問題を防ぐことはできませんでした。

GMO側は会見で、リスク分析に不足があったことや、グループ内の指摘をサービス運営に十分生かすことができなかったと説明しています。

これはセキュリティだけではありません。

システム開発。

業務改善。

新規事業。

組織改革。

あらゆるプロジェクトで起こり得る問題です。

---

何が起きていたのか

報道された内容を時系列で整理すると、次のようになります。

• 2024年4月：グループ内のセキュリティ専門家がシステム上の課題を指摘
• 2024年4〜5月：緊急メンテナンスを4回実施
• 2026年8月5日：攻撃者が顧客のリモートデスクトップ環境へ侵入
• 2026年10月20日：顧客からの問い合わせを受け、GMO側が問題を認識
• 2026年11月2日：記者会見で、2024年の指摘や対応状況について説明

ここで重要なのは、

2024年に問題が見つかり、それに対して対策も行われていたことです。

しかし結果として、その対策では十分ではありませんでした。

これはプロジェクト管理で非常に重要なポイントだと思います。

---

プロジェクトでも、同じことが起きる

プロジェクトでは、日々多くの課題が出てきます。

例えば、

• この仕様では将来問題になる
• このシステムは古い
• この処理には性能上の懸念がある
• この運用は属人化している
• この権限設計にはリスクがある
• このスケジュールではテスト期間が足りない
• この担当者に業務が集中している

担当者が指摘する。

課題管理表へ書く。

会議でも話す。

そして対応方針を決める。

ここまでは、多くの会社がやっています。

しかし、その後が問題です。

「課題として登録済み」

「担当者へ連絡済み」

「一度修正済み」

この状態になった瞬間、なぜか安心してしまうことがあります。

---

課題管理表に書いた瞬間、仕事が終わるわけではない

プロジェクト管理でよく使われるものに、課題管理表があります。

課題。

担当。

期限。

対応方針。

ステータス。

非常に重要です。

しかし、課題管理表には大きな落とし穴があります。

「書いたことで管理した気になってしまう。」

例えば、

課題：セキュリティ上の懸念あり

担当：Aさん

対応：検討中

期限：未定

となっている。

この状態を半年間管理しても、何も改善していなければ意味はありません。

課題管理の目的は、

課題を一覧化することではありません。

課題をなくすことです。

---

「対応完了」と「問題解決」は違う

今回のGMOの事例でも、2024年の指摘後に複数回の緊急メンテナンスが実施されています。

つまり、対応そのものは行われています。

しかし、後の結果を見ると、十分な対策になっていなかったことになります。

プロジェクトでもよくあります。

修正しました。

確認しました。

会議しました。

担当者へ伝えました。

資料を更新しました。

これらは、すべて「作業」です。

大切なのは、その作業によって、

本当にリスクが許容可能な状態まで下がったのか。

を見ることです。

---

プロジェクトで怖いのは「未対応」だけではない

私は、未対応にはいくつか種類があると思っています。

• 完全未対応：課題を認識しているが何もしていない
• 対応中：対応しているが完了していない
• 暫定対応：一時的な対策だけ行っている
• 対応済みと思っている：作業は完了したが、リスクが残っている

この中で意外と怖いのが、最後です。

「もう対応したから大丈夫。」

と思っている状態です。

未対応なら、まだ危険だと認識できます。

しかし、対応済みだと思ってしまうと、その課題を見ること自体をやめてしまいます。

---

優先順位という言葉にも注意が必要

プロジェクトでは、すべての課題を同時に解決することはできません。

当然、優先順位を付けます。

重要度。

緊急度。

影響範囲。

工数。

費用。

これらを見ながら順番を決める。

これは必要です。

しかし、

「優先順位が低い」

という判断が、いつの間にか、

「対応しなくていい」

へ変わることがあります。

GMO側も会見で、サービスの安定稼働や他の脆弱性への対応を優先する中で、リスク分析に不足があったと説明しています。

ここで問題なのは、優先順位を付けたことではありません。

一度決めた優先順位を、その後も再評価できていたのか。

という点だと思います。

---

優先順位は、一度決めたら終わりではない

プロジェクトは動き続けています。

半年前は小さな問題だったものが、半年後には重大な問題になっているかもしれません。

利用者が増える。

取引額が増える。

データ量が増える。

外部環境が変わる。

攻撃手法が変わる。

事業規模が変わる。

当然、リスクも変わります。

---

重大課題は5つの視点で見る

重要な課題については、少なくとも次の5つを管理する必要があると思います。

1. 影響度：起きた場合、どの程度の被害になるのか
2. 発生可能性：どの程度起こり得るのか
3. 対応期限：いつまでに解決する必要があるのか
4. 残存リスク：対策後にも何が残っているのか
5. エスカレーション条件：どの段階で誰へ報告するのか

特に重要なのが、5番目です。

現場担当者が重大な問題を理解していても、意思決定できる人まで情報が届かなければ、会社として正しい判断はできません。

---

経営まで届かない情報は、存在しないのと同じことがある

今回の会見では、熊谷代表自身が、2024年に問題を指摘されていたことを今回の事案発生後に初めて知ったと説明しています。

ここも、プロジェクトマネジメントとして非常に重要なポイントです。

現場では知っていた。

担当部署でも知っていた。

専門家も指摘していた。

しかし、経営判断が必要な問題として上まで届いていなかった。

もしそうであれば、

問題は技術だけではありません。

情報の流れにも問題があったことになります。

重大な情報は、正しい人へ届いて初めて「共有された」と言えます。

---

エスカレーションは責任逃れではない

現場では、

「上に言っても仕方がない。」

「もう少し自分たちで対応してみよう。」

「大事にしたくない。」

という心理が働くことがあります。

しかし、重大な問題ほど、この考え方は危険です。

予算を増やす。

サービスを止める。

納期を変更する。

大規模改修する。

こうした判断は、現場担当者だけではできません。

だからこそ、必要なタイミングで上位者へ伝える必要があります。

---

警告を出した人を評価できる組織か

もう一つ重要なのが、警告を出す側です。

プロジェクトで、

「このままだと危険です。」

「この納期では品質を保証できません。」

「この設計では問題が起きる可能性があります。」

と伝えるのは、意外と勇気が必要です。

なぜなら、プロジェクトの勢いを止めるからです。

経営は進めたい。

営業は売りたい。

発注元は早く公開したい。

現場も完成させたい。

その中で、

「一度止めた方がいい。」

と言う。

こういう人は、プロジェクトにとって非常に重要です。

---

コンサルタントにも同じ役割がある

コンサルタントは、クライアントが聞きたいことだけを言えばいいわけではありません。

時には、

「この計画は危険です。」

「この進め方では問題が起きます。」

「ここは一度止めるべきです。」

と言わなければならないことがあります。

それが相手にとって聞きたくない内容だったとしてもです。

もちろん、根拠なく危機を煽るのは違います。

しかし、明確なリスクが見えているにもかかわらず、

相手に嫌われたくない。

契約を失いたくない。

話を難しくしたくない。

という理由で言わないのであれば、コンサルタントとしての役割を果たしているとは言えないと思います。

---

「誰が悪いか」ではなく「なぜ止まらなかったか」

事故が起きると、

誰が悪かったのか。

誰が判断を間違えたのか。

誰の責任なのか。

という話になりがちです。

もちろん責任の所在を確認することは必要です。

しかし、再発防止という意味では、それだけでは足りません。

見るべきなのは、

• 警告はどこまで共有されたのか
• 誰が優先順位を判断したのか
• 対応期限は設定されていたのか
• 暫定対応と恒久対応を分けていたのか
• 対策後の残存リスクを確認したのか
• 重大リスクを経営へ上げるルールがあったのか
• 未解決課題を定期的に再評価していたのか

という構造です。

---

まとめ

プロジェクトには、必ず問題が起きます。

問題が一つも起きないプロジェクトなど、ほとんどありません。

だからこそ重要なのは、

問題を見つけた後、どう動くのか。

です。

課題を見つける。

伝える。

評価する。

優先順位を決める。

必要な人へ上げる。

対策する。

そして、

対策した後、本当に問題が解消されたのかをもう一度確認する。

ここまでやって、初めて課題対応は完了します。

課題管理表へ書いたから安心。

担当者へ伝えたから安心。

一度修正したから安心。

ではなく、

「本当にこの問題は消えたのか。」

そこまで確認する。

それが、プロジェクトマネジメントにおける重要な責任の一つではないでしょうか。