システムの保守費は何に払う？月額料金と頼める範囲の見方

月額が同じでも、任せられる仕事は違う

説明用の例として、月末に請求書を作るシステムが動かなくなった場面を考えます。連絡を受けるだけなのか、原因を調べるのか、データを直して請求まで再開するのかで必要な作業は違います。「保守あり」という言葉だけでは、その範囲は分かりません。障害が起きて初めて担当を探すことにならないよう、調査から再開までを見ます。

ダンドリの保守・継続開発の公表料金は月5万円〜です。当社が開発・納品したシステムが対象で、他社システムの保守のみは受けていません。これはあらゆる修正や常時対応を含む定額の保証ではなく、作業内容を確認して契約する入口の料金です。クラウドやSaaSなどの利用料は、開発会社が行う保守作業の費用と区別して確認してください。

不具合の修正と、新しい仕事への対応を分ける

仕様どおりに計算されない不具合と、取引条件が変わったため計算式を追加する改善は、目的が異なります。どちらか判断しにくい場合は、元の合意内容と再現する入力を見て、まず状況を調べます。画面上は一文字の修正でも、帳票や過去データ、承認に影響すれば確認の作業が増えます。変更するコードの量だけでは費用を判断できません。

保守契約には、契約内の作業と追加見積もりになる条件を記載します。問い合わせが重なったときの優先順位や、調査した結果を誰へ伝えるかも実務では大切です。下の表のように仕事を分ければ、社内で引き受けられるものと外部へ任せたいものを話しやすくなります。

表が収まらない場合は横にスクロールできます。

「すぐ返信します」と「すぐ使えます」は別の約束

連絡への返信が早くても、原因が外部サービスにあれば復旧を待つ場合があります。受付時間、調査に入る条件、業務を再開する判断を分けて話します。AWSの資料では、復旧まで許容する時間をRTO、失ってよいデータの時間幅をRPOとして整理しています。数値を契約書へ書くだけでは実現しないため、業務への影響と構成から目標を決めます。

説明用の例なら、出荷指示は配送の締め切りに間に合わせたい一方、月次分析は翌日に回せるかもしれません。すべてを同じ速さで復旧させるより、先に再開する業務を選びます。社内には顧客対応や手作業への切り替えを判断する人が必要です。技術担当だけでは、途中の請求をいったん止めてよいか決められないためです。

参考：Amazon Web Services：REL13-BP01 Define recovery objectives for downtime and data loss

バックアップがあっても、昨日の仕事は戻らないことがある

夜間のバックアップ後に受注が入り、昼に障害が起きたとします。夜の時点へ戻せても、その後の注文は別に回収する必要があります。これは説明用の例ですが、保存する頻度と戻せる範囲の関係を表しています。PostgreSQLの公式資料も、SQLダンプや継続的なアーカイブなど異なる方式を整理しています。採用環境に合う方式と復元可能な時点を確かめます。

データベースだけでなく、添付、設定、復号に必要な情報が揃うかも重要です。復元試験は本番への発注や通知を止めた別環境で行い、ログイン、代表データ、帳票まで確認します。外部へ送信済みの取引は元に戻らないため、復元後すぐ自動処理を動かさず、相手側の注文番号などと照合します。取得の成功通知より、実際に戻してみた結果が判断材料になります。

参考：PostgreSQL Global Development Group：PostgreSQL Documentation: Backup and Restore

何も起きなかった月にも、確認することはある

保守の仕事は障害だけとは限りません。定期処理の未完了、利用者の権限、バックアップ、依存する環境の更新など、契約で担当を決めた作業を確認します。たとえばNode.jsは本番用途にActive LTSまたはMaintenance LTSを案内しています。納品時に動いた環境も、利用中の版とサポート情報を追い、更新の時期を判断する必要があります。

報告を受けるなら、対応件数だけでなく、何を確認したか、判断待ちの課題は何かを見ると内容が分かります。予定している更新や繰り返す小さな障害が見えれば、便利機能の追加と一緒に優先順位を考えられます。月額の対価が待機体制なのか定期作業なのか、実作業の枠なのかを明確にし、何も起きなかった月の扱いも契約前に確認しましょう。

参考：Node.js / OpenJS Foundation：Node.js Releases

開発会社を選ぶときに、止まった日の説明を聞く

「納品後も対応します」から一歩進めて、請求が途中まで送られた場合にどうするかを聞いてみてください。送信失敗の表示でも、相手が受け付けた後に通信が切れただけかもしれません。全件を送り直すのではなく、成功・未処理・結果不明を分けて再開できるかが要点です。止まった原因だけでなく、残った仕事をどう片付けるかを説明できる提案が比較材料になります。

契約前には、連絡先、対応時間、社内の判断者、構成や手順の引き継ぎを揃えます。自動監視を設定することと、人が常に見守ることも違います。ダンドリの公開範囲には24時間365日の有人監視は含まれません。必要な体制を開発段階で共有し、対応できる範囲に合う運用や代替手順を決めることが、納品後の負担を見通す第一歩です。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □月額に含む調査・修正・更新の内容を確かめる。確認状況・メモ：
• □受付時間と復旧目標を分けて確認する。確認状況・メモ：
• □先に再開したい業務と社内の判断者を選ぶ。確認状況・メモ：
• □添付や設定を含め、別環境で復元を試す。確認状況・メモ：
• □外部へ送信済みの取引を照合する手順を用意する。確認状況・メモ：
• □クラウド利用料と追加改修の費用を分ける。確認状況・メモ：
• □担当交代時に渡す構成・手順・権限を確認する。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• REL13-BP01 Define recovery objectives for downtime and data lossAmazon Web Services
• PostgreSQL Documentation: Backup and RestorePostgreSQL Global Development Group
• Node.js ReleasesNode.js / OpenJS Foundation