なぜ「直して」で費用がもめるのか

社内でシステムを使っている人にとって、「思ったとおりに動かない」ことはすべて「不具合」に見えます。一方、保守会社は「当初決めた仕様(システムがどう動くべきかの取り決め)どおりに動いているか」で判断します。同じ「直して」という言葉でも、受け取る側の前提がまったく違うのです。

たとえば、販売管理システムで「請求書に担当者名が出ない」という声が上がったとします。もともと担当者名を印字する設計だったのに出なくなったのなら障害です。しかし、最初から印字しない設計だったのなら、それは「印字するように変えてほしい」という改修の依頼になります。画面を見ている社員には、この違いは分かりません。

もめごとが起きやすい会社の特徴

  • 導入時の仕様書が手元にない:何が「もともとの仕様」なのかを確かめられない。
  • 保守契約書の範囲があいまい:「システムの保守一式」のように、何が含まれるかが書かれていない。
  • 依頼が電話や口頭中心:誰がいつ何を頼み、保守会社がどう答えたかの記録が残っていない。
  • 担当者が代わった:前任者と保守会社のあいだで「これくらいはサービスで」とやっていた慣習が、引き継がれていない。

特に最後の点は、10〜100名規模の会社でよく見られます。長年の付き合いで無償対応してもらっていたものが、保守会社の担当者交代をきっかけに有償になり、「急に冷たくなった」と感じる。実際には、もともと契約外の作業だったというケースです。

障害対応と改修の基本的な線引き

考え方の基本はシンプルです。

  • 障害:もともとの仕様どおりに動かない状態。仕様どおりに戻す作業が「障害対応」です。
  • 改修:仕様そのものを変える、または機能を追加すること。「今とは違う動きにしてほしい」という依頼です。

一般的な保守契約では、障害対応は月額の保守料に含まれ、改修は都度見積もりの別料金とされることが多いです(ただし契約によって異なるため、必ず自社の契約書で確認してください)。具体例で整理すると次のようになります。

状況の例区分の目安理由
これまで出ていた月次集計表が、エラーで出力できなくなった障害以前は仕様どおり動いていた
同じ条件で検索しても、結果が日によって違う障害仕様どおりの結果が返っていない
消費税の端数処理が、設計書の取り決めと違う計算になっている障害取り決めた仕様と食い違っている
請求書のレイアウトを新しい書式に変えたい改修仕様(帳票の形)を変える
得意先ごとの掛け率を設定できるようにしたい改修機能の追加
入力画面の項目の並び順を使いやすく変えたい改修動作に問題はなく、使い勝手の変更
新しい部署を作ったので、権限設定を追加したい契約次第設定変更作業として保守に含める契約もある
ポイント

判断の物差しは「以前はできていたか、取り決めた仕様に書かれていたか」です。社内で不具合の報告を受けたら、まず「前からこうだったか」「いつから変わったか」を確認するだけで、障害か改修かの見当がかなりつきます。

判断が分かれやすいグレーゾーン

実際に費用でもめるのは、上の表のようにはっきり分けられないケースです。代表的なものと、一般的な考え方を挙げます。どれも「どちらが正しい」と一律に決まるものではなく、契約で事前に決めておくべき事項だと考えてください。

グレーゾーン保守会社側の見方発注側の見方事前に決めておくこと
法改正・税率変更への対応仕様の変更なので改修使い続けるために必要なのだから保守の範囲制度改正対応を保守に含めるか、含める場合の上限
WindowsなどOSの更新後に動かなくなったシステム自体の不具合ではない昨日まで動いていたのだから障害OS・周辺ソフト更新に伴う調査と修正の扱い
データが増えて処理が遅くなった仕様どおり動いている。高速化は改修業務に支障が出ているので障害応答時間の目安や、性能改善の扱い
操作ミスでデータが壊れた・消えた利用者側の原因なので有償復旧も保守の一部操作ミス由来の復旧作業の扱いと料金

法改正・税率変更

インボイス制度や税率変更、給与計算の制度改正など、会社の意思とは関係なく対応が必要になるものです。保守会社にとっては仕様変更なので、改修として見積もるのが一般的です。ただ、パッケージ製品の保守契約では「法改正対応を含む」と明記されている場合もあります。個別開発のシステムなら、制度改正のたびに見積もりになる前提で予算を組んでおくのが現実的です。

OS更新による不具合

Windowsの更新プログラムを当てた翌日から帳票が出なくなった、というケースです。システムのプログラム自体は変わっていないため、保守会社は「障害ではない」と言うこともあります。一方で、セキュリティ上OSの更新は止められません。調査までは保守料の範囲、修正が大規模になる場合は別途見積もり、という分け方がよく見られます。

データ量の増加による遅さ

導入から10年たって取引データが積み上がり、月末の締め処理に以前の何倍もかかるようになった、というのはよくある話です。プログラムは仕様どおり動いているため、厳密には障害ではありません。ただし、古いデータの整理(アーカイブ)や設定の見直しなど、比較的軽い作業で改善することもあります。まず原因の調査を依頼し、対策の規模を見てから判断するとよいでしょう。

操作ミスに由来するもの

誤って一括削除した、締め処理を二重に実行した、といったケースです。バックアップからの復旧作業は、多くの契約で有償扱いになります。ここで大切なのは費用よりも、そもそもバックアップが取られているか、誰が戻せるのかを平時に確認しておくことです。

自社の保守契約で何がカバーされているか、整理できていますか

10の質問に答えるだけで、システムの保守リスクの度合いと費用感の目安が分かります。登録不要・無料です。

3分の無料リスク診断を試す

契約書に書いておきたい4つのこと

グレーゾーンでもめないためには、契約書(または契約書に添付する「保守仕様書」「サービス内容明細」など)に、次の4点を具体的に書いておくのが効果的です。新規契約のときだけでなく、更新のタイミングでも見直せます。

1. 保守の範囲

「何が含まれ、何が含まれないか」を列挙します。「保守一式」ではなく、「障害の受付と原因調査」「仕様どおりに戻す修正」「操作に関する問い合わせ対応」「月1回のバックアップ確認」のように、作業単位で書くのが理想です。前の章のグレーゾーン4つについても、含むか含まないかを一行ずつ決めておくと安心です。

2. 上限時間(作業時間の枠)

「月○時間までの軽微な変更・問い合わせは保守料に含む」という枠を設ける方法です。小さな修正のたびに見積もりを取るのは、発注側にも保守会社にも負担になります。時間枠があれば、帳票の文言変更のような軽い改修も、枠の範囲内で気軽に頼めます。枠を超えた分の単価や、余った時間を翌月に繰り越せるかもあわせて決めておきます。

3. 見積もりが必要になる条件

「作業が○時間を超える見込みの場合は、着手前に見積もりを提示し、発注側の承認を得てから着手する」と書いておきます。これだけで、作業が終わってから想定外の請求が来る、という事態を防げます。調査自体に時間がかかる場合は、「調査は○時間まで保守料内、それを超える場合は事前に相談」としておくとよいでしょう。

4. 優先度と対応時間

すべての依頼に即日対応を求めるのは現実的ではありません。業務への影響に応じて優先度を分け、それぞれの対応の目安を決めておきます。

優先度状況の例対応の目安の決め方
高システムが起動しない、出荷・請求が止まる受付から着手までの時間を決める(例:営業時間内は当日着手など)
中一部の機能が使えないが、手作業で代替できる数営業日以内の着手など
低表示の乱れ、使い勝手の要望次回の定期対応でまとめて対応など

具体的な時間は、保守会社の体制や料金と相談して決めます。優先度「高」の対応を夜間・休日まで求めると、保守料は上がるのが一般的です。自社の業務時間を考えて、本当に必要な水準を選んでください。

注意

契約書の文言は、責任の範囲や損害賠償にも関わります。ここで紹介したのは考え方の整理であり、具体的な条文の作成や、すでに起きている費用トラブルの判断については、弁護士など専門家に相談したうえで進めてください。IPA(情報処理推進機構)が公開している情報システムのモデル契約書も、項目を検討する際の参考になります。

もめない依頼の出し方

契約を整えても、日々の依頼があいまいだと結局もめごとは起きます。電話で「また変なんですけど、見てもらえますか」と頼むのではなく、決まった項目を書いてメールや依頼フォームで送るようにしましょう。次の項目を社内の依頼テンプレートにしておくと便利です。

依頼テンプレートのチェックリスト
  • 依頼者の名前・部署・連絡先
  • 対象のシステム名と画面名・帳票名
  • 何が起きているか(エラー表示があれば画面の写真を添付)
  • いつから起きているか。以前は正常に動いていたか
  • 直前に変わったこと(Windowsの更新、PCの入れ替え、設定変更、データの大量登録など)
  • 再現する手順(どの操作をすると起きるか)
  • 業務への影響と、手作業で代わりができるか
  • 希望する優先度と、いつまでに直したいか
  • 依頼者としての区分の見立て(不具合だと思う/変更・追加の要望)
  • 有償になる場合は事前に見積もりがほしいか

「区分の見立て」を依頼者側に書いてもらうのは、もめごとを防ぐうえで効果があります。依頼する時点で「これは変更の要望かもしれない」と意識してもらえるためです。保守会社が「これは改修にあたります」と判断した場合も、着手前に回答をもらう流れが自然にできます。

また、社内の窓口を一人に決めておくことも大切です。現場の社員がそれぞれ保守会社に直接連絡すると、似た依頼が重複したり、誰も知らないうちに有償作業が進んでいたりします。窓口が依頼内容を一度確認してから送るだけで、「以前からこの仕様だった」と分かって依頼自体が不要になることもあります。

月次報告と依頼記録で「見える化」する

最後に、依頼と対応の記録を残し、毎月振り返る仕組みを作ります。専用のツールがなくても、Excelの一覧表で十分です。保守会社が使っている受付管理(チケット管理と呼ばれる、依頼を1件ずつ番号で管理する仕組み)を共有してもらえるなら、それを使うのも良い方法です。

記録する項目記入例
受付番号・受付日No.27/10月3日
依頼内容(要約)月次売上集計がエラーで出力できない
区分(障害/改修/問い合わせ)障害
優先度中
対応内容と完了日集計プログラムの日付処理を修正。10月5日完了
作業時間・費用2時間(保守料内)

月に一度、保守会社からこの一覧をもとにした報告をもらい、短時間でも打ち合わせをすると、次のような効果があります。

  • 区分の認識ずれを早く見つけられる:障害か改修かで意見が分かれた件を、その月のうちに話し合える。
  • 保守料が妥当か判断できる:どれくらいの作業が発生しているかが見えるので、契約更新時の交渉材料になる。
  • 同じ障害の繰り返しに気づける:毎月同じような不具合が出ているなら、根本的な改修を検討するきっかけになる。
  • 担当者が代わっても経緯が残る:前任者の口約束に頼らずに済む。

特に3つ目は重要です。「障害対応で毎回直してもらっているから無料」と思っていても、同じ不具合が何度も起きているなら、業務の手間や待ち時間というコストは発生し続けています。障害が多いシステムは、改修や入れ替えを検討するサインでもあります。

まとめ

  • 障害は「もともとの仕様どおりに動かない状態」、改修は「仕様を変える・追加すること」。判断の物差しは「以前はできていたか、仕様に書かれていたか」
  • 法改正対応、OS更新による不具合、データ増加による遅さ、操作ミスからの復旧はグレーゾーン。どちらに入るかを契約で事前に決めておく
  • 契約書には、保守の範囲・月の上限時間・見積もりが必要な条件・優先度ごとの対応目安の4点を具体的に書く
  • 依頼はテンプレートに沿って書面で、社内の窓口を一本化して出す
  • 依頼と対応を一覧で記録し、月次で振り返ると、認識ずれの早期発見と保守料の見直しに役立つ
参考資料・公式情報

※ 製品のサポート期限や制度は変わることがあります。最新の情報は各公式ページでご確認ください。