システム開発が終わると、次に考えなければならないのがリリース後の保守です。

しかし、

「そもそも保守は必要なのか」

「毎日監視してもらう必要があるのか」

「障害が起きたときだけ対応してもらえば十分ではないか」

と判断に迷う担当者も多いのではないでしょうか。

必要な保守内容は、すべてのシステムで同じではありません。

社内で数人だけが使うシステムと、多くの顧客が利用するサービスでは、停止したときの影響が大きく異なるからです。

そこで重要なのが、

「何を保守してもらうか」から考えるのではなく、「このシステムが止まったら何が困るのか」から考えること

です。

この記事では、システム開発後にどこまで保守が必要なのかを、発注担当者が判断する方法を分かりやすく解説します。

システム保守とは

システム保守とは、リリース後もシステムを安定して利用するために、障害対応、監視、バックアップ、セキュリティ対応などを行うことです。

ただし、必要な保守内容はシステムによって異なります。

すべてのシステムに24時間監視や緊急対応が必要なわけではありません。

まずは、自社のシステムが止まったときにどの程度の影響が出るのかを整理することが大切です。

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

システムは完成した状態のまま、何年も変わらず利用できるとは限りません。

システムそのものを変更していなくても、周囲の環境は変化します。

例えば、

  • ブラウザやOSが更新される
  • クラウドサービスの仕様が変わる
  • 外部サービスのAPIが変更される
  • セキュリティ上の問題が見つかる
  • 利用者が増える
  • データ量が増える

といった変化があります。

そのため、システムを継続して利用するのであれば、リリース後に誰が状態を確認し、問題が起きたときに誰が対応するのかを決めておく必要があります。

運用と保守の違い

「運用」と「保守」は同じ意味で使われることもありますが、役割は少し異なります。

一般的に、運用は日常的にシステムを使い続けるための作業、保守は障害対応や修正など、システムを正常な状態に保つための技術的な対応を指します。

例えば、アカウント管理や日々の問い合わせ対応は運用、障害の原因調査やプログラム修正は保守として扱われることがあります。

ただし、契約によっては「運用保守」とまとめて対応する場合もあります。

開発会社へ依頼するときは、どこまでが契約に含まれているのかを確認しておきましょう。

最初に考えるのは「システムが止まったら何が起きるか」

保守内容を決めるとき、最初から

「24時間監視が必要か」

「毎月何時間の保守を契約するか」

と考える必要はありません。

まず次の質問を考えてみてください。

このシステムが1日使えなくなったら、会社はどのくらい困るでしょうか。

例えば、

影響が比較的小さいシステム

  • 社内で月に数回使う集計ツール
  • 一部の担当者だけが使う管理画面
  • 別の方法でも一時的に業務を続けられるシステム

このようなシステムであれば、数時間停止しても業務への影響が限定的な場合があります。

影響が大きいシステム

  • 毎日の業務で利用する基幹システム
  • 顧客情報を管理するシステム
  • 社員の多くが使う業務システム

停止すると多くの人の仕事が止まるため、早い対応が必要になります。

影響が非常に大きいシステム

  • ECサイト
  • 予約システム
  • 顧客向けWebサービス
  • 決済に関係するシステム

停止が売上や顧客対応へ直接影響する場合は、より早く障害を把握し、対応を始められる体制が必要になります。

システムの重要度を3段階で整理する

システムの重要度を3段階で整理した図

自社で判断するときは、システムを次のように整理すると分かりやすくなります。

重要度 システムの例 止まった場合 保守の考え方
低 一部の社内ツール 一時的に別の方法で対応できる 営業時間内の障害対応などを検討する
中 日常業務で使う管理システム 社内業務が一部止まる 監視やバックアップ、早めの障害対応を検討する
高 EC・予約・顧客向けサービス 売上や顧客対応へ直接影響する 監視や迅速な障害対応を重視する

これは厳密な分類ではありません。

自社の業務への影響を整理するための考え方です。

「低だから最低限でよい」「高だから必ず24時間対応が必要」と決めつけるのではなく、実際の利用時間や業務への影響を見て判断します。

重要度に合わせて保守内容を決める

必要な保守内容を整理した図

システムの重要度が分かったら、次に必要な保守内容を考えます。

主な保守には次のようなものがあります。

障害対応

システムが動かない、エラーが発生するなどの問題が起きたときに原因を調査します。

特に重要なのは、

誰に連絡すれば調査を始めてもらえるのか

を決めておくことです。

障害が起きてから担当会社や担当者を探す状態は避けましょう。

監視

システムやサーバーが正常に動いているかを継続して確認します。

利用者から「使えません」と連絡を受けて初めて障害に気付くのか、システム側で異常を検知できるのかでは、対応開始までの時間が変わります。

特に顧客向けシステムでは検討したい項目です。

バックアップ

問題が発生した場合に備えて、データを戻せるようにしておく対応です。

ここでは「バックアップを取っているか」だけでなく、

必要になったときに本当に戻せる状態なのか

も確認する必要があります。

バックアップがあっても、復旧手順が確認されていなければ、障害時にすぐ戻せるとは限りません。

重要なシステムほど、どのデータを、どの頻度で保存するのか、どの時点まで戻せればよいのかを整理しておきましょう。

セキュリティ対応

システムで使用しているソフトウェアなどに問題が見つかった場合、必要に応じて更新や対応を行います。

開発時には問題がなかったシステムでも、時間がたって新しいセキュリティ上の問題が見つかる場合があります。

そのため、

「誰が情報を確認するのか」

「問題が見つかったとき誰が判断するのか」

を決めておくことが重要です。

外部サービスの変更への対応

Webシステムでは、自社システムだけで完結していない場合があります。

例えば、

  • メール配信
  • 決済
  • 地図
  • 認証
  • クラウド
  • 他社システムとの連携

などです。

外部サービス側の仕様が変われば、自社システム側でも対応が必要になることがあります。

そのため、どの外部サービスを利用しているのかを把握しておきましょう。

「全部入り」の保守が必要とは限らない

保守について考えると、

「できるだけ手厚い契約にした方が安心なのでは」

と思うかもしれません。

しかし、必ずしもすべてのシステムに同じ保守体制が必要なわけではありません。

例えば、一時停止しても翌営業日に対応すれば問題ない社内システムに、24時間の緊急対応体制まで用意すると、必要以上の体制になる可能性があります。

反対に、顧客が24時間利用するサービスなのに、

「担当者が平日の昼間しか確認できない」

という状態では、業務上のリスクがあります。

24時間監視や休日・夜間対応などを追加すると、その分だけ保守費用も増えるのが一般的です。

そのため、

システム停止時の影響と、必要な対応時間を比べながら保守内容を決めること

が重要です。

発注側と開発会社の役割を分ける

すべてを開発会社へ任せる必要もありません。

例えば次のように役割を分けることができます。

発注側 開発会社
社内からの問い合わせをまとめる 技術的な原因を調査する
障害の影響を確認する システムを修正する
対応の優先順位を決める サーバーやアプリを確認する
業務上必要な変更を整理する 技術的な対応方法を提案する

発注側がすべての技術を理解する必要はありません。

一方で、開発会社だけでは、

「この機能が止まると会社としてどのくらい困るのか」

までは判断できません。

そのため、

業務上の判断は発注側、技術的な判断は開発側

というように役割を整理すると、保守を進めやすくなります。

保守を外注するか社内で対応するか

保守方法は、大きく分けると、

  • 社内で対応する
  • 外部へ依頼する
  • 社内と外部で分担する

という方法があります。

社内に対象システムを理解している技術者がいるのであれば、一部を社内で対応できる場合があります。

一方、

  • 社内にエンジニアがいない
  • インフラやセキュリティまで対応できない
  • 担当者一人に知識が集中している
  • 障害時にすぐ対応できない

という場合は、外部へ依頼する方法を検討します。

すべてを外注するのではなく、社内に窓口担当者を置き、専門的な対応を開発会社へ依頼する方法もあります。

保守と機能追加は分けて考える

もう一つ整理しておきたいのが、保守と機能追加の違いです。

例えば、

「今まで動いていた機能が動かなくなったので直す」

ことと、

「新しく承認機能を追加する」

ことは目的が異なります。

後者は保守ではなく、追加開発として扱われることがあります。

保守契約に何が含まれているかを確認しておきましょう。

改修や追加開発にかかる費用について詳しく知りたい方は、こちらも参考にしてください。

システム改修の費用相場は？見積もりの内訳・高くなる理由と作り直しの判断基準

開発前から保守について考えておく

保守は、システム完成後に初めて考えるものではありません。

開発会社へ相談する段階で、

  • 誰が保守するのか
  • 障害時の連絡先
  • 必要な対応時間
  • バックアップ方法
  • サーバーなどの管理者
  • 外部サービスの管理方法

を確認しておくと、リリース後の混乱を減らせます。

システム開発を発注する流れ全体を確認したい方は、こちらも参考にしてください。

システム開発の発注は何から始める？初めてでも迷わない11ステップと準備するもの

また、開発会社へ保守まで依頼する場合は、開発実績だけでなく、リリース後の対応体制も確認しておきましょう。

開発会社を選ぶときの確認ポイントについては、こちらで詳しくまとめています。

システム開発会社はどう選ぶ？発注前に確認したい8つのポイント

自社に必要な保守を確認する5つの質問

保守体制を決めるときは、次の5つを確認してみてください。

  1. このシステムが1日止まったら、どの業務が止まるか
  2. 顧客や売上への影響はあるか
  3. 障害が起きたとき、社内で対応できる人がいるか
  4. データが失われた場合、どこまで戻せればよいか
  5. 夜間や休日にも対応が必要か

この5つに答えると、自社に必要な保守体制が見えやすくなります。

まとめ

システム保守は、すべてのシステムで同じ内容を用意する必要はありません。

まず、

システムが停止した場合に、業務・売上・顧客へどの程度影響するか

を確認します。

そのうえで、

  • 障害対応
  • 監視
  • バックアップ
  • セキュリティ対応
  • 外部サービスへの対応

などから、必要な保守内容を決めます。

特に、障害時の連絡先、対応時間、バックアップ方法、発注側と開発会社の役割は、リリース前に整理しておくことが重要です。

必要以上に手厚い体制を用意するのではなく、自社のシステムの重要度に合った保守体制を考えましょう。

システム開発・保守についてご相談ください

ニチコマでは、Webシステムや業務システムの開発についてご相談を承っています。

新規開発だけでなく、リリース後の運用や保守も含め、システムの状況に合わせてご相談いただけます。

お問い合わせ

参考文献