保守契約と追加開発、その境界線をどう引くか

スクラッチ開発したシステムを運用していると、「これは保守の範囲でやってもらえるのか、それとも追加開発として見積もりが必要なのか」判断に迷う場面が必ず出てきます。境界線をどう引き、どう契約に落とし込むかを整理します。

なぜ境界が曖昧になるのか

保守契約の多くは「現状の機能を維持する」ことを目的に結ばれています。しかし実際にシステムを使い始めると、業務のちょっとした変化に合わせて「この項目も入力できるようにしたい」「この画面の並び順を変えたい」といった要望が自然と出てきます。

これらは発注側からすると「ちょっとした修正」に見えても、開発側からすると仕様変更であり、テストのやり直しや影響範囲の調査が必要な作業だったりします。双方の認識にズレがあるまま進むと、「これくらいはやってくれると思っていた」「それは追加費用が発生する」という行き違いにつながります。

保守の範囲に含まれやすいもの

仕様通り動かない不具合の修正 ：決められた仕様に対して動作が異なる場合の修正は、基本的に保守の範囲です。

障害発生時の復旧対応 ：サーバーダウンやデータ不整合など、緊急性の高いトラブルへの対応は保守契約の中心的な役割です。

セキュリティパッチの適用 ：既知の脆弱性に対する修正プログラムの適用は、システムを安全な状態に保つための保守作業です。

契約で定義された軽微な設定変更 ：マスタデータの登録項目追加など、あらかじめ「軽微な変更」として契約に含まれている作業です。

追加開発として扱われやすいもの

新しい機能の追加 ：これまで存在しなかった機能を作ることは、規模の大小にかかわらず追加開発です。

既存画面の仕様変更 ：入力項目の追加、業務フローの変更など、決められた仕様そのものを変える作業は追加開発として扱われるのが一般的です。

外部サービスとの新規連携 ：新しい決済サービスやAPIとの接続など、システムの構成自体を広げる作業も追加開発に含まれます。

データ構造に影響する変更 ：見た目には小さな変更でも、データベースの設計変更を伴う場合は影響範囲の調査が必要になり、保守の範囲を超えることが多くなります。

境界線を契約書に落とし込む

線引きの感覚をお互いに共有していても、契約書に書かれていなければ、担当者が変わるたびに認識がずれていきます。

「軽微な変更」を具体的に定義する ：「月◯時間以内の軽微な修正は保守費用に含む」のように、時間や作業量で線引きを数値化しておくと、判断に迷う場面が減ります。

判断に迷うケースの取り扱いフローを決めておく ：どちらに該当するか判断が難しい依頼が来た場合、誰がどう判断し、どう見積もりを提示するかの流れを事前に合意しておきます。

運用フェーズの変更頻度を見込んでおく ：業務の変化が激しい領域のシステムほど、追加開発が発生する前提で予算を確保しておく方が現実的です。この見込みは、本来は要件定義の段階（保守運用計画は要件定義の段階で決めておく）で話しておくのが望ましいテーマです。

境界線は「揉めないため」ではなく「良い関係を保つため」に引く

境界線を明確にする目的は、開発会社との駆け引きに勝つことではありません。曖昧なままだと、発注側は「サービスでやってくれるはず」と期待し、開発側は「無償対応が続くと採算が合わない」と感じ、どちらにとっても良くない関係になっていきます。線引きをはっきりさせておくことは、長く付き合っていくための土台づくりでもあります。