保守は「何でも対応」ではなく、入る／入らないの境界
業務システムの納品後、現場から来る依頼は混ざりやすいです。「画面が仕様と違う」「項目を増やしたい」「クラウドの設定を変えたい」は、見た目は近い依頼でも、契約上の扱いが違います。境界が書面にないと、対応速度と費用の期待がすれ違います。
本記事は、納品後保守の範囲の切り分けに絞ります。障害時の連絡・復旧の最小セットは関連コラムを参照してください。主CTAは開発の進め方です。
曖昧なまま
切り分けがある
不具合修正・機能追加・環境／設定変更の3つに分ける
依頼を受けるとき、まず次の3分類に置くと会話が早いです。分類は社内のチケット項目でも、発注側の依頼テンプレでも構いません。
環境・設定・外部要因
クラウド設定、外部API変更、証明書更新など
機能追加・改善要望
新しい項目、画面、帳票、連携（別見積が多い）
仕様どおりの不具合
合意仕様との不一致、再現手順がある不具合
- 「合意した仕様」の参照先（仕様書・受入条件）が分かるか
- 機能追加の依頼経路と、見積の要否が書かれているか
- 外部サービス変更時の調査・改修の扱いが触れているか
- 受付時間・窓口・優先度の置き場があるか（詳細はSLA記事）
入りやすい例と、別見積になりやすい例を並べる
契約書の文言は案件ごとに異なりますが、発注前の質問としては「次の例は保守内か」を具体で聞くと比較しやすいです。抽象的な「運用支援」だけでは境界が残りません。
保守に入りやすい
- 仕様不一致の修正
- 合意した軽微な設定支援
- 障害の初動・切り分け
別見積になりやすい
- 新機能・項目追加
- 大規模な画面改修
- 他社システム新規連携
契約前に、保守の1枚要約を添付する
開発の見積と別に、保守の1枚（対象システム、窓口、入るもの／入らないもの、別見積の例、更新のタイミング）があると、稟議と現場の期待が揃います。段階導入の第1段階が小さいほど、保守の境界も書きやすいです。
- 01
対象を書く
どのシステム・環境か
- 02
3分類を置く
不具合／追加／環境
- 03
例を並べる
入る・入らないを具体で
- 04
窓口を決める
連絡と優先の置き場
「入らないもの」が言える状態で進め方を確認する
保守の境界が口頭で言えるなら、開発プロセスのページで工程・検収・保守の位置づけを確認し、必要なら範囲の文書化から相談してください。障害時の連絡だけ先に決めたい場合はSLAの記事も併用できます。
業務の課題整理から、設計・開発・導入まで
納品後の保守範囲の切り分けから、
SHINJIDAIにご相談ください。
- 不具合と機能追加の境界が曖昧
- 環境や外部サービスの変更の扱いが決まっていない
- 契約前に入る／入らないを文書化したい
課題の整理から伴走対象システムと起きやすい依頼の種類を確認します。不具合・機能追加・環境変更の切り分けと窓口を提案。開発・検収・保守の境界を文書化し、合意した範囲で伴走します。
初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。
ID・パスワードや顧客データは、フォームに記載しないでください。
開発・保守の進め方を見るよくある質問
障害時のSLA記事との違いは？
SLA記事は、止まったときの連絡・初動・復旧の約束に焦点があります。本記事は、稼働後の依頼が「保守内か別見積か」を切る範囲の話です。両方揃えると運用の期待値が合いやすいです。
仕様どおり動かない不具合は保守に入りますか？
合意した仕様との不一致は、契約で保守または保証期間の対象になることが多いです。一方、新しい要望や「あったら便利」は機能追加として別見積になるのが一般的です。契約文言の確認が必要です。
クラウドや外部サービスの値上げ・仕様変更は？
提供元の変更はベンダー単体で止められないことが多いです。影響調査・設定変更・改修の扱いを、保守に含むか都度見積かを事前に決めておくと安心です。
保守なしで納品だけでもよいですか？
可能ですが、障害時の窓口と小改修の依頼先が空になります。最低限、連絡経路と「範囲外は見積」だけでも決めておくと、本番後の混乱が減ります。