開発会社の保守範囲を伝えるには｜障害・運用・追加改修の案内を分ける

「保守に入っているので、画面に項目を追加してほしい」。取引先からそう言われ、営業は契約内だと思い、開発側は追加見積もりが必要だと考えている。こうした食い違いをサイトの「納品後も安心してお任せください」という一文だけで防ぐことはできません。

開発会社のWeb担当者は、障害が起きたときの対応、普段の運用作業、仕様を変える依頼を分けて説明しましょう。この記事では、自社の保守資料を基に案内を作る区分表と、受付から範囲確認・着手へつなぐ掲載例を紹介します。契約の解釈や費用相場を決めるものではありません。

「保守対応」の中に、違う仕事を詰め込まない

保守という言葉から想像する仕事は、会社や利用者によって異なります。エラーが出たときに原因を調べること、定期的にデータを確認すること、新しい業務に合わせて機能を増やすことが、一つの言葉で扱われていないかを見ます。

最初に集めるのは、現行のサービス資料、保守の作業一覧、見積書や契約で確認している範囲です。営業が使う説明と、実際に対応する担当者の認識も照合します。Webの原稿だけで新しい作業範囲を決めず、何を引き受けているかが確認できたものから掲載します。

IPAの「情報システム・モデル取引・契約書（第二版）」の紹介ページも、契約のタイミングで仕様やプロジェクト管理方法、検収方法などについて共通理解を深める趣旨を示しています。本記事ではこの考え方を、サイトの標準案内と個別に確認する範囲をそろえる出発点とします。IPA「情報システム・モデル取引・契約書（第二版）」

ただし、モデル契約を紹介したことが、自社の契約内容を確定する根拠にはなりません。実際の取扱いは契約担当者と保守責任者が確認します。過去の案件の範囲を、そのまま新しいすべての相談に適用したように見せないことも大切です。

障害・運用・変更依頼の区分表を作る

次の表は、掲載内容を整理するための設計例です。三つの区分を法律や業界共通の定義として使うものではありません。自社ではどの仕事を何と呼び、どの条件で受け付けるかを確かめながら埋めます。

依頼の区分	相談される内容の例	掲載前に社内で確認すること	読者に示す次の段階
障害・不具合の連絡	いつも使える処理が動かない	対象環境、調査や復旧作業の範囲、連絡先	現象と業務への影響を伝える
定常的な運用作業	定期確認や決められた作業を頼みたい	作業内容、頻度、実施担当、報告方法	対象の作業と実施条件を確認する
追加・変更の相談	入力項目や帳票の内容を変えたい	変更枠の有無、調査、見積もり、承認方法	目的と変えたい内容を伝える

たとえば「データのバックアップ」と書くなら、取得する作業だけなのか、結果の確認や復元の確認まで含むのかを担当者に聞きます。サイト上で細かな設定値を公開する必要はありませんが、依頼者が何を任せたと考えてよいかは説明できるようにします。

一つの依頼が複数の区分にまたがる場合もあります。障害の調査から仕様変更の相談へ進むこともあれば、予定していた運用作業の前提が変わり、追加の検討が必要になることもあります。最初の分類を、そのまま費用や作業範囲の確定結果として扱わない設計にします。

他社サービスとの間を、誰が確認するかも書く

開発したアプリが外部のサービスと連携しているなら、そのサービスへの問い合わせを誰が行うかを確かめます。「連携機能を保守する」と書いても、外部サービス自体の修正や提供条件の変更まで自社で決められるわけではありません。自社が調べる範囲と、依頼者側で確認する事項を案内に残します。

たとえば、外部サービスから届くデータが変わった場合に、自社が現象を確認し、依頼者が提供元へ問い合わせる運用なら、その分担を社内資料と照合します。自社が問い合わせを代行する場合も、必要な権限や対象契約を確認しておきます。受付窓口を一本化することと、すべてを自社だけで解決することは分けて説明します。

対象システムが複数ある会社では、サービス名だけでなく対象となる環境も整理します。本番だけを対象にするのか、検証環境も含むのかで、同じ依頼への返答が変わる場合があります。公開ページでは標準的な対象を示し、個別の構成や接続情報は契約者との安全な共有先で確認します。

障害・定常運用・追加変更について依頼情報と確認範囲を対応させる編集用図 — 開発会社の案内を整理する架空の構成例。契約範囲や個別依頼の費用を判定する図ではありません。

「小さな修正」は、依頼者と同じ意味かを確かめる

「軽微な修正は保守に含みます」と書く場合、何を軽微とするかが問題になります。画面に一つ入力欄を増やすだけに見えても、保存先、入力チェック、通知、帳票などの変更が必要かもしれません。見た目の小ささを、作業量や契約範囲の説明に使わないようにします。

変更作業を月ごとの枠に含めるサービスなら、対象となる作業、枠の単位、調査や確認にかかる時間の扱いを整理します。時間、回数、対象機能など、自社が実際に管理している単位を使います。枠を超えた場合に、別見積もりになるのか、翌月の対応を相談するのかも確認します。

逆に、追加改修を個別に見積もる場合も、「保守では一切変更しません」という強い言い方が必要とは限りません。自社が行う障害修正や設定変更と、業務上の要望による機能追加を分け、範囲を確かめる手順を示します。どちらの扱いが一般的かではなく、自社の約束を伝えることが目的です。

ここでは「CSVに列を足したい」という架空の依頼を考えます。依頼者は既存の出力に一項目を足すだけだと思っていても、出力元のデータがない、権限ごとに表示を変える必要がある、といった確認事項が見つかる場合があります。受付時には、追加したい列名だけでなく、その情報を何に使うかを聞く案内にします。

公開する例文は「列追加は必ず別料金」と断定するものにせず、「目的と対象を確認し、対応範囲・費用・時期をご案内します」のように、確認後に決まることを示します。すでに契約内で対応する条件が決まっている顧客には、その条件に沿った専用の案内を用います。

受付時間・初回連絡・復旧見込みを別々に書く

「迅速に対応」という表現だけでは、連絡を受け付けること、担当者が返信すること、問題が解決することのどれを指すかが分かりません。保守ページでは、受付窓口、担当者が確認する時間帯、最初の連絡の目安を分けて示します。

AWSのサポート文書では、問い合わせの重要度ごとの表に「初回の応答時間」という見出しを使い、最初のリクエストへの対応について説明しています。これはAWSのサポートに関する情報ですが、何の時点を示す時間なのかを明記する例として参考になります。AWS サポート「ケース管理」

自社のサイトでは、その数値や提供体制を借りず、実際の対応に合わせて表現します。「受付完了の自動メール」「担当者からの初回連絡」「調査結果の共有」「復旧見込みの案内」を区別し、最初の返信までの時間を復旧までの約束にしないようにします。

メールやフォームをいつでも送れることと、担当者が常時作業できることも別です。時間外の連絡を受け付ける場合は、次に確認する時間や、契約者向けの緊急連絡方法を案内します。対応体制がないまま「24時間対応」という見出しだけを追加しないようにします。

緊急連絡先を用意する会社では、新規の制作相談と既存顧客の障害連絡を混ぜないことも重要です。一般公開の問い合わせフォームから連絡すると確認が遅れる運用なら、既存顧客が使う窓口をどこで確認できるかを示します。契約者専用情報を、そのまま全体公開する必要はありません。

原因を選ばせず、起きたことと目的を受け取る

障害連絡の入口で「アプリの不具合」「サーバー障害」「ネットワーク障害」を必須の選択肢にすると、依頼者に原因の推測を求めることになります。最初は、いつから、何をすると、どのような結果になり、誰の業務に影響しているかを受け取れる形にします。

先ほどのCSVの例なら、「列を増やしたい」は変更相談ですが、「昨日まで出力できたCSVが今日は出ない」は現象の連絡です。同じCSVという言葉でも、入口で聞きたい情報が違います。前者では使いたい目的と出力内容、後者では発生時刻や操作、表示された内容を聞きます。

AWSの同じ文書でも、問題の説明には時刻やログなど、機能要望には利用環境と目的の説明を含める案内があります。自社の受付でも、用件に応じて必要な情報を切り替える考え方を使えます。ただし、初回の公開フォームへ機密情報や大量のログを無条件に添付させる設計にはしません。

画面やログを受け取る必要がある場合は、秘密情報を除く方法と、安全に受け渡す経路を社内で決めます。パスワードや認証用の情報を、通常の問い合わせ欄に書くよう求めないことも確認します。必要な技術情報は、担当者が受け取れる方法を案内してから共有してもらいます。

変更相談は、見積もりと着手の間も案内する

追加改修の相談では、送信した時点で作業が始まるように見せないことが大切です。自社がどこまで無償で確認し、どこから調査や見積もりの費用が生じるかを整理します。費用が発生する調査を、単なる問い合わせへの返信と同じ説明で扱わないようにします。

案内には、依頼内容の確認、影響範囲の調査、費用と時期の提示、依頼者の確認、着手という関係を示します。ただし、すべての案件が同じ順番とは限らないため、標準例と個別に決める条件を分けます。緊急時の作業や、契約で事前に合意している作業を、この標準例だけで上書きしないようにします。

案内する段階	依頼者とそろえる内容	表示で避けたい食い違い
相談の受領	目的、対象システム、希望時期	受付メールが着手の承認に見える
調査の確認	調べる範囲と、調査費用の有無・条件	有料の調査が無料相談に見える
提案・見積もり	変更範囲、費用、時期、確認方法	一部の改修費が全変更の総額に見える
着手前の合意	誰が何を確認し、どの版で進めるか	古い要望や未承認の追加分で作業が進む