📊
【保守・運用】何もしてないから動かなくなったということは、点検もメンテナンスも監視もしてないから動かなくなったということです

2025/08/08に公開
 はじめに

 対象何とかして保守の重要性を訴えたいITエンジニア向け。

 何もしてないなら動かなくなるのは当たり前
 保守しないという選択
「何もしてないのに動かなくなった」
ITエンジニアなら何度か聞いた台詞です。確かに本当に何もしていないのに動かなくなることもあります。しかし大抵の場合は「何かしたから動かなくなった」という事実を認めたくなくて、そのような言い回しになるのでしょう。
今回はその逆、「何もしてないから動かなくなった」話です。正確には保守をしないという選択をした結果として、システムが動かなくなったという話です。
保守をしないのも一つの選択です。そしてその選択には必ず結果が伴います。何かを選ぶということは、同時に何かを諦めるということでもあります。行動しないことも、それ自体が一つの行動なのです。
保守をしないという選択をしたのだから、動作不良や不具合、最悪はシステム停止という結末も当然の帰結です。特に驚くようなことではありません。

 Webアプリに車検はない
toBのWebアプリに車検はありません。もし利用しているライブラリのバージョンがEOLを過ぎていても、車のオイルやタイヤのように交換の機会は設けられていません。日次・月次の点検の義務もなければ、車検のように最低限の安全を確保するための点検もありません。
車検制度では2年に一度必ず安全性をチェックしますし、定期点検も法的に義務付けられています。ブレーキパッドの厚さやタイヤの溝の深さ、ライトの明るさまで細かく基準が定められており、基準を満たさなければ公道を走れません。
Webアプリはセキュリティホールが見つかっていても、パフォーマンスが劣化していても、そのまま運用し続けることができてしまいます。
問題はこのような状況が正常として扱われることです。車なら「車検切れで運転したら違法」という共通認識がありますが、Webアプリには同じような強制力のある仕組みがありません。

 自主的な保守の必要性
自社開発であれば自主的に、保守契約を結んでいるなら予算と相談で。定期的に点検やメンテナンス、日々の監視・モニタリングをしなければなりません。事故を起こしてからでは遅いのです。
ITエンジニアは最も近くでシステムの調整を行っています。だから調子の善し悪しや部品交換の時期も把握しています。余裕を持ってメンテナンスの打診をしますが、予算やスケジュールの確保ができなければ放置してもお咎めなし、というのが現状です。
車の整備士なら「このまま走り続けるとブレーキが効かなくなる可能性があります」と言えば、多くのドライバーは修理を依頼するでしょう。ITエンジニアが「このままだとシステムが停止する可能性があります」と言っても「今は動いてるから大丈夫」で片付けられがちです。
いつも呼び出されるのは、システムが止まって困ってからです。

 開発者とて落ち着いて対応したい
開発者からしてみれば、前からずっと必要性は訴えている訳です。事前調査して見積を出して、この後のプロジェクト計画を見て、差し込めそうな時期を考えて陳情しています。何もしてないから予測通りに動かなくなったのであって、当事者意識も責任感もあったもんじゃありません。予測可能、回避不可能とはこのことです。
突然アプリが止まって困るのは、ユーザーもマネージャーもメンバーも同じ。苦情や請求が山ほど届くような障害が起きたら企業が傾きます。一刻も早く動くようにしないといけませんので、担当になった開発者は急かされながら対応しますが、その実、陳情が無視されたことは忘れません。
深夜にサーバーがダウンして緊急対応を求められたときは、車でいえば高速道路でエンジンが止まったような状況です。路肩に停車してレッカー車を呼ぶにも時間がかかりますし、後続車に追突される危険もあります。事前に点検していれば防げたはずの事故が、コスト削減の名のもとに見送られた結果として起きているのです。
しかも障害対応中は、普段使わない古いドキュメントを探したり、前任者に連絡を取ったり、バックアップからのデータ復旧手順を確認したりと、慣れない作業が山積みです。Webアプリの障害は複雑で、原因特定にも時間がかかります。

 開発者の自己防衛
さらに厄介なのは、障害対応が完了した後の振り返りです。「なぜ事前に対策しなかったのか」という追及に対して、過去の提案資料やメールのやり取りを証拠として提示できなければ、開発者の怠慢として処理されてしまうリスクさえあります。
私自身、過去にライブラリの脆弱性やサーバーの容量不足について事前に報告したものの、対応を後回しにされて結果的に障害が発生した経験があります。そのとき痛感したのは、ITエンジニアとして自分の身を守るためのエビデンス残しの重要性です。
メールやチャットで保守の必要性を訴えた記録、会議での発言議事録、リスクを説明した資料などは必ず残しておきましょう。万が一システム障害が発生して責任追及される場面で「事前に報告していたが対応されなかった」ことを証明できるからです。

 車の管理方法を見習う
 点検・監視
車に日常点検や車検があるように、Webアプリにも同様の仕組みを取り入れて、習慣化してみる試みはいかがでしょうか。
日次点検
死活監視などサーバーの稼働状況をチェックする。
各種ログ・通知の内容を確認する。
バックアップ・バッチ処理の結果を確認する。

月次点検
モニタリングツールでパフォーマンス分析を行う。
パッケージの脆弱性などセキュリティ周りの点検を行う。
データベース・ディスク容量に余裕があるか見る。

定期点検 1年ごと
インフラコストの検証。
権限設定・ユーザーの棚卸し。
運用フロー・ドキュメントを更新する。

車検 2年ごと
インフラ構成・アーキテクチャの見直し。
外部のセキュリティ診断を依頼する。

毎日、車に乗る前にタイヤの空気圧やライトの点灯確認をするように。毎月、バッテリーや冷却水の量をチェックするように。こうして聞くと、実施していない現場ヤバいなって思いませんか。

 計画的な部品交換
保守費用をあらかじめ確保し、予算の範囲内で定期的にメンテナンスを行うのはどうでしょうか。Webアプリには税金はかかりませんし、車検のように法的な義務もありませんが、だからこそ計画的な保守が重要です。
車のオイル交換やタイヤ交換のように、使用しているライブラリやフレームワークも定期的に新しいバージョンに更新する必要があります。セキュリティパッチが適用されたり、パフォーマンスが改善されたり、新機能が追加されたりするからです。
現実には「動いているから触らない」という判断が下されがちです。車で例えるなら、エンジンオイルが真っ黒になっても「まだエンジンは動いてるから大丈夫」と交換を先延ばしにするようなもの。短期的にはコストを抑えられますが、中長期的には大きなリスクを抱えることになります。
年間の保守予算を確保し、四半期ごとや半年ごとに計画的にメンテナンス期間を設けることで、システムの健全性を保ち続けることができるのです。

 保守契約と予算確保
車を購入するときは車検費用や定期点検費用、部品交換代を考慮して総コストを計算するのが一般的です。同じようにWebアプリの開発・運用でも、保守費用を初期段階から見積もっておくべきでしょう。
開発費用の何割かを年間保守費用として確保したり、3年に一度のリニューアル費用を開発費用の半分程度で見積もったりといった具合です。車ならオイル交換やタイヤ交換で年間数万円、車検代が2年ごとに20万円といった感覚でしょうか。
社内開発の場合は、保守専任のITエンジニアの工数を確保するか、開発チームの工数の一部を保守作業に割り当てる必要があります。外部の開発会社に依頼している場合は、保守契約を結んで定期的なメンテナンスを依頼するのが現実的です。
重要なのは「壊れてから修理する」のではなく「壊れる前に保守する」発想への転換です。車が故障してから慌てて修理工場を探すより、信頼できる整備工場と長期的な関係を築いた方が、結果的にコストも安く、安心して利用できます。
Webアプリも同じです。障害が発生してから慌てて対応するより、普段から保守を依頼できるパートナーと契約を結んでおく方が、事業継続の観点からもコスト面からも賢明な選択といえます。

 おわりに
正直なところ、この手の保守・運用は軽視されがちです。特に中小企業やベンチャー企業では「今動いているから問題ない」「予算がないから後回し」という判断が多い印象です。
保守・運用の重要性を理解してもらうのは簡単ではありませんが、ITエンジニアとして技術的責任を果たしつつ、自分自身も守れるよう準備しておくことが大切だと考えています。