この記事について

システム開発を発注する顧客企業の担当者の方、予算決定者の方、IT部門の管理職の方、開発・運用保守に携わるエンジニアの方に向けて書いています。特に、システム開発後の運用保守費用や体制の必要性を、まだ十分に整理できていない方に読んでもらえたらと思っています。

この記事は、「システムの脆弱性・保守契約・運用コスト・継続的な保守体制」をテーマにした全4回シリーズの第1回です。今回は各論に深入りせず、シリーズ全体の問題提起として、運用保守がなぜ必要なのかを事業価値の観点から考えます。

PHPの脆弱性の話題から考えたこと

2026年10月、PHPに深刻な脆弱性(通称「php2shell」、CVE-2026-109618・CVE-2026-109619)が見つかり、広く話題になりました。ログイン不要で外部からサーバーを乗っ取られる可能性があるという内容で、PHP-FPMやmod_phpなど、PHPを動かす仕組みそのものに影響するため、WordPress本体やプラグインを更新するだけでは防げない、という点も注意喚起されていました。修正版は10月21日に公開され、CISAやJPCERT/CCからも注意喚起が出されています。

自分はPHP自体を直接扱っているわけではないので、技術的な当事者というより、外から業界の反応を見ていた立場です。ただ、PHPやWordPressは非常に広く使われているため、影響を受けたシステムや関係者も多かったのではないかと思います。一部では、突発的な夜間対応を余儀なくされた現場があったという話も見かけました。

その場で修正して終わりと考えるのか、それとも同様の事象が起きても対応できる構成・運用体制を事前に整えておくのか。ここに、運用保守の本質があると感じています。

システムはリリースしたら終わりではない

脆弱性、障害、問い合わせ、利用環境の変化。システムをリリースした後も、対応すべきことは続きます。開発と運用は、本来切り離して考えられるものではないはずです。

ただ、現場で仕事をしていると、開発予算と運用予算が別物として扱われ、開発が終わった時点で一区切りついたような空気になることがあります。システムは作って終わりではなく、そこからどう維持し、育てていくかが本番だと思っているのですが、この感覚が顧客側・ベンダー側の双方で共有されているとは限りません。

なぜ運用保守の予算は取りづらいのか

これまでの仕事で、開発予算は確保できても、運用保守の予算は削られる、という状況を何度も見てきました。保守の必要性を説明しても、費用対効果が見えにくく、予算化が難しい。障害が発生したときには高品質な緊急対応を期待される一方、平時の保守費用は抑えられる。保守担当者が、何もしていない待機要員のように見られてしまうこともあります。

障害が起きなければ、保守にかけた労力や価値は認識されにくいものです。顧客側からすると、保守費用は成果が見えにくく、予算を取りづらいという事情があるのも理解できます。一方で、システムを作ること自体が目的になってしまい、リリース後に何を実現したいのか、どのようにサービスを成長させたいのかが具体化されていないケースもあるのではないかと感じています。

ただ、これは顧客担当者だけの問題ではありません。予算制度や社内の意思決定プロセス、開発時点での計画不足など、複数の要因が絡み合っていると考えています。

運用保守は事業価値を守るための投資

運用保守の価値は、何かが起きたときだけにあるわけではありません。例えば、毎月1億円の売上を生み出すシステムがあったとして、月100万円の保守費用をかけることで、障害やセキュリティ事故による信用失墜、売上機会の損失などを防げる可能性があります。

もちろん、保守費用を払えばすべてのリスクを防げるわけではありません。しかし、何も起きていない平時から備えておくことに価値があります。想定しておきたいリスクとしては、情報漏えいや個人情報の流出、サービス停止や障害による機会損失、顧客からの信用低下や解約、障害発生後の調査・復旧費用、事業継続への影響などが挙げられます。

反対に、適切な保守を継続することで、サービスの安定性や顧客からの信頼を維持し、事業機会を守ることにもつながります。運用保守は単なる維持費ではなく、事業価値を守り、継続的に成長させるための投資だと考えています。

開発時点から、その後のサービスを考えてほしい

DevOpsという言葉は広く知られるようになりましたが、開発後の運用まで見据えて投資や体制を整えられている現場は、まだ多くないと感じています。

システムを作る段階で、リリース後の運用や保守、問い合わせ対応、障害時の対応まで想像できているでしょうか。例えば、サービスが想定以上に人気になり、利用者が急増したとします。しかし、問い合わせや障害に対応できる体制がなければ、せっかくサービスが伸びても、現場は謝罪やトラブル対応に追われることになってしまいます。

作っているからには、サービスには成功してほしい。だからこそ、開発時点からその後の運用を考えておく必要があると思っています。

まとめ:作る予算だけでなく、育て続ける予算も

PHPの脆弱性の話題から考えたのは、結局このことでした。システムは作って終わりではなく、その後も継続して維持・改善していく必要があります。運用保守の予算が取りづらい背景には、顧客側・ベンダー側それぞれの事情があり、どちらか一方が悪いという単純な話ではありません。

一人のエンジニアとして、率直にぼやくなら、作る予算だけでなく、育て続ける予算も取りましょうよ、というのが今回の本音です。次回以降では、保守契約でどこまで担保できるのか、保守費用の削減と運用の最適化は何が違うのか、持続可能な保守体制とはどういうものか、といった話を続けていきます。