保守で揉めるのは、金額よりも「これは保守に入るのか」という境目です。境目を先に書き出しておけば、後から交渉する場面が減ります。
使い方
保守契約の見積りや契約書を横に置き、各項目が「含まれる」「追加費用」「対象外」のどれかを書き込んでいきます。書けない項目は、そのまま相手に確認する質問になります。既に保守契約を結んでいる場合も、更新のタイミングでこのシートを埋め直すと、契約書の記載と実際の運用のずれが見つかります。開発会社とこのシートを一緒に見ながら埋めるやり方も有効です。認識の違いは、埋めている途中で出てきます。
1. 保守という言葉を5つに分けて考える
「保守」と一言で呼ばれているものには、性質の異なる作業が混ざっています。まず5つに分け、それぞれの範囲を別々に確認してください。ひとまとめの月額に見えていても、中身がどれを含むかは会社によって大きく違います。特に更新作業と改修の扱いは差が出やすい部分ですので、月額の中に何が入っているかを、この5区分に沿って相手に説明してもらうとよいでしょう。
2. 障害対応の条件を具体化する
障害対応は、保守の中でもっとも認識がずれやすい部分です。「対応します」だけでは、いつ、どれくらいの速さで、どこまでやるのかが決まりません。受付時間と連絡方法、そして復旧の目標をどう扱うかを確認してください。復旧までの時間を保証する形にすると、その分の体制が必要になり費用も上がりますので、自社の事業として本当に必要な水準を先に決めてから交渉するほうが、話が早く進みます。
- 受付時間は何時から何時までか。土日祝はどうか
- 受付時間外に障害が起きた場合、いつ着手されるか
- 連絡方法は何か(メール、チャット、電話)。緊急時の連絡先は別にあるか
- 着手までの目標時間はあるか。復旧までの目標時間はあるか
- 原因が自社側の操作や外部サービスにあった場合、費用の扱いはどうなるか
- 障害後の報告書は出るか。再発防止の対応はどこまで含まれるか
3. 更新作業の範囲を決める
Webシステムは、作った時点のまま放置すると、使っているライブラリに脆弱性が見つかったり、連携している外部サービスの仕様が変わったりして、徐々に動かなくなっていきます。更新を保守に含めない契約にすると、数年後にまとまった費用が必要になることがあります。含める場合も、どの範囲まで追従するかを決めてください。小さな更新は含み、大きな版上げは別途、という分け方が一般的です。
- セキュリティ上の問題が見つかったライブラリの更新は含まれるか
- 言語やフレームワークの大きな版上げ(メジャーアップデート)は含まれるか
- 外部サービス(決済、認証、地図など)の仕様変更への対応は含まれるか
- 更新に伴う動作確認とテストは、どこまで行われるか
- 更新を行う頻度と、事前の連絡方法はどうなっているか
4. 改修と機能追加の境目を書き出す
「文言を1か所直す」「表示順を変える」といった小さな依頼が、保守に含まれるのか別途見積りなのかは、最初に決めておかないと毎回の交渉になります。月ごとに作業時間の枠を設ける方式、件数で区切る方式、すべて別途見積りにする方式などがあり、自社の依頼頻度によって向く形が変わります。下の表に、自社で実際に起きそうな依頼を書き足したうえで、それぞれの扱いを相手と決めてください。
5. バックアップと復旧の実態を確かめる
バックアップを取っていることと、そこから復旧できることは別です。保守の範囲に、復旧の作業そのものと、その手順が実際に試されているかまで含まれるかを確認してください。どの時点の状態まで戻せるか、戻すのにどれくらい時間がかかるかは、事業として許容できる範囲かどうかを経営側が判断する必要があります。半日止まっても問題ないのか、1時間でも影響が大きいのかで、必要な備えは変わります。
- バックアップの取得頻度と、保持される期間はどれくらいか
- どの時点の状態まで戻せるか(直前か、前日か、数日前か)
- 復旧作業は保守に含まれるか。かかる時間の見込みはどれくらいか
- 復旧を実際に試したことがあるか。手順書は残っているか
- 自社側でバックアップを取得・保管する手段はあるか
6. 費用の構成と、増える条件を確認する
保守費用は、作業費と、クラウドなどの実費に分かれます。実費は利用者やデータが増えれば増えるため、事業の成長とともに変わっていきます。月額に実費が含まれている場合は、どこまでの利用量を前提にしているかを確認してください。金額は案件の規模や必要な対応水準により異なりますので、他社の例と比べるよりも、自社が必要とする範囲との対応で見るほうが確実です。
- 月額に含まれるのは作業費のみか、クラウド利用料などの実費も含むか
- 実費が含まれる場合、どの程度の利用量を前提にしているか
- 利用者数やデータ量が増えたとき、費用はどう変わるか
- 契約期間と、更新・解約の申し入れ期限はいつか
7. 保守を止めたくなったときの備えを確認する
保守は続けるものである一方、社内で内製化したり、別の会社に移したりする場面も訪れます。そのときに困らないよう、必要なものが自社の手元にあるかを確認しておいてください。この確認は、保守契約を結ぶ時点で行うのがもっとも効果的です。いざ移行を決めてから確認すると、アカウントの名義変更や資料の整備に想定外の時間と費用がかかることがあります。
- サーバー、ドメイン、外部サービスのアカウントが自社名義になっているか
- ソースコードが自社の管理下(自社のリポジトリなど)にあるか
- 構成図、設定内容、運用手順が文書として残されているか
- 解約時に引き継ぎ資料を提供してもらえるか。その費用はどうなるか
- 引き継ぎのための並走期間を設けられるか
関連するインサイト
- 技術的負債との付き合い方 — 返済の優先順位を決める技術的負債はゼロにするものではなく、管理するものです。意図的な負債と無自覚の負債の違い、負債の可視化、事業インパクトと変更頻度による優先順位の付け方、開発計画への組み込み方を経営者向けに整理します。
- 開発の内製化ロードマップ — 外注から自社チームへ移行する手順外注に頼っていた開発を自社チームへ移す手順を、現状の棚卸し、最初に内製化する領域の選定、採用と技術顧問の活用、コードとドキュメントの引き継ぎ、並走期間、移行後の外部パートナーの使い方まで段階的に解説します。
- クラウドインフラコストの圧縮 — 見直しの順番と落とし穴クラウドの利用料が事業の成長より速く増えているとき、どこから手を付けるべきか。可視化から監視の継続運用までの手順と、可用性や開発速度を損なう落とし穴を経営者向けに整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開