保守契約の内容を契約前に確認すべき理由

見積もりが確定し、契約書が届いた。開発の話ばかりに気を取られ、保守契約の欄には目を通さずにハンコを押してしまった——システム開発の発注が初めての担当者に、特によく見られる光景です。保守契約は、たいてい開発契約書の後半に数ページ、あるいは「別途保守契約を締結する」という一文だけが記載されており、開発内容の話し合いに比べると圧倒的に軽く扱われがちです。しかし、実際にシステムが稼働してから困るのは、開発の中身よりもむしろこの保守契約の中身であることが少なくありません。

この記事は、これから開発会社と契約を結ぼうとしている、あるいは提案を受けている段階の担当者に向けて書いています。似たテーマの記事に「月額保守費の相場と見直し方」がありますが、あちらはすでに結んでしまった保守契約を、後からどう見直すかを扱った記事です。この記事はそれとは逆に、まだ契約していない保守契約を、締結前にどう確認しておけば開発完了後に慌てずに済むかという、時系列でいえばより手前の段階を扱います。

保守契約は、いったん結んでしまうと内容を変更するために交渉の手間がかかります。しかし契約前であれば、確認したい点をその場で質問し、必要な条項を盛り込んでもらうことができます。この「契約前だからこそできること」を具体的に整理するのが、この記事の目的です。

この記事で分かること

これから発注する開発契約に付随する保守契約について、契約書にサインする前に確認しておくべき項目を整理します。保守契約とは何か、なぜ開発契約とセットで検討すべきなのか、契約前に確認すべき8つの具体的なチェックポイント、確認を怠った場合に開発完了後によく起きるトラブルの実例、そして開発会社への質問の切り出し方までを解説します。読み終える頃には、提示された保守契約書やその説明を前に、「何を聞けばよいか分からない」状態から、「ここを確認しないと後で困る」と具体的に指摘できる状態になっているはずです。

保守契約とは何か、なぜ開発契約と別に考える必要があるのか

まず前提として、保守契約がどのような性質の契約なのかを整理しておきます。保守契約は、システムが完成し稼働を始めた後、不具合の修正や軽微な変更、問い合わせ対応などを継続的に依頼するための契約です。開発契約が「完成させること」を目的とする契約であるのに対し、保守契約は「完成後の状態を維持し続けること」を目的とする契約であり、性質がまったく異なります。

多くの中小企業の発注担当者が見落としがちなのは、この2つの契約が別物であるという点です。見積もり段階では「開発費用◯◯万円、保守費用は月額◯万円」とセットで提示されることが多いため、あたかも1つの契約であるかのように錯覚しがちですが、実際には開発契約と保守契約は別々の契約書、あるいは別々の条項として存在しています。開発契約の交渉には時間をかけて質問したのに、保守契約については「まあ相場通りでしょう」とほとんど確認せずに進めてしまう、というケースが非常に多く見られます。

なぜこの区別が重要かというと、開発契約の交渉が終わった段階、つまり要件も金額も固まった後になって保守契約の内容に疑問を持っても、すでに開発会社側は「その体制・その金額」で見積もりを組んでしまっているため、後から条件を変更しようとすると、開発費用側の見直しにまで話が波及しかねないからです。保守契約の内容は、開発契約の交渉と同じタイミングで、同じ熱量で確認しておく必要があるというのが、この記事全体を通じての結論です。

なぜ「契約前」の確認がここまで重要なのか

保守契約の内容を確認するタイミングとして、なぜ「契約前」がこれほど重要なのかを、もう少し掘り下げておきます。

• 契約前は交渉の余地がある：まだ契約書にサインしていない段階であれば、「この項目を追加してほしい」「この表現を具体的な数値に変えてほしい」といった要望を伝えやすく、開発会社側も応じやすい状況にあります
• 契約後は既成事実として扱われやすい：いったん署名した契約書は、双方が合意した内容として扱われます。後から「実はここが気になっていた」と伝えても、契約内容の変更には相応の手間と交渉が必要になります
• 開発完了後は担当者の立場が弱くなりやすい：システムが完成し、業務がそのシステムに依存し始めた後は、発注者側が「今さら他社に切り替えるわけにもいかない」という弱い立場に置かれやすくなります。契約前はこの力関係が最もフラットな時期です

保守契約における交渉力は、契約書に署名する前が最も強く、システムの稼働が始まった後は徐々に弱くなっていきます。確認すべきことは、開発契約の交渉と並行して、契約前にすべて済ませておくべきです。

この力関係の変化を理解しないまま「開発が終わってから保守について相談すればいい」と先送りにしてしまうと、いざ相談したときには開発会社側の提示条件をそのまま受け入れざるを得ない状況に陥りがちです。

契約前に確認すべき8つのチェックポイント

ここからは、保守契約を締結する前に具体的に確認しておくべき項目を、8つに分けて解説します。開発会社から保守契約書やその説明資料を受け取ったら、この順番で確認してみてください。

チェックポイント1：対応範囲はどこまでか

保守契約における対応範囲は、契約によって大きな幅があります。契約前に必ず確認しておきたいのは、次のような項目です。

• 不具合修正はどこまで無償対応の範囲に含まれるか（発注者側の操作ミスによる不具合は対象外になることが一般的です）
• 軽微な仕様変更（画面表示項目の追加など）は保守費の範囲内で対応してもらえるか、それとも都度見積もりになるか
• 利用者からの操作方法の問い合わせは対応してもらえるか
• OSやミドルウェア、利用しているライブラリのセキュリティパッチ適用は含まれるか

この対応範囲があいまいなまま契約すると、実際に困りごとが発生したときに「それは保守契約の範囲外なので、別途お見積もりします」と言われ、想定していなかった追加費用と時間がかかる事態になりがちです。契約書に「軽微な変更」という表現がある場合は、それが具体的にどの程度の作業量を指すのか、時間数や作業内容の例を挙げて確認しておくことをおすすめします。

チェックポイント2：SLA（対応時間の保証水準)は数値で明記されているか

障害が発生してから、開発会社がどれくらいの時間で対応を開始してくれるのか。この保証水準がSLA（サービス品質保証）です。契約書に「速やかに対応いたします」といった曖昧な表現しかない場合、実際に障害が起きたときにどの程度の時間で連絡がつくのか、契約書だけでは分かりません。

契約前に確認しておきたいのは、次の点です。

自社のシステムが止まった場合に、どれくらいの時間なら業務が止まっても許容できるかを事前に考えておくと、開発会社から提示されるSLAが自社にとって十分な水準かどうかを判断しやすくなります。基幹的な業務で使うシステムと、月次でしか使わない集計システムとでは、必要なSLAの水準が異なって当然です。

チェックポイント3：料金体系と、その料金で何が変わるのか

保守費の料金体系には、大きく分けて月額固定制と都度精算制があります。契約前に確認しておきたいのは、料金体系そのものだけでなく、その料金でどこまでの作業がカバーされるのかという中身です。

• 月額固定制の場合：月額に含まれる対応範囲と、それを超えた場合の追加費用の単価はいくらか
• 都度精算制の場合：作業内容ごとの単価表があるか、時間単位の見積もりの出し方はどのようになっているか
• 契約期間中に利用者数やデータ量が増えた場合、料金が自動的に見直されるのか、それとも据え置きか

料金体系の違いによって、システムの利用状況が変化した場合の負担のされ方が変わります。事業拡大に伴って利用者数が増える見込みがある場合は、その際に料金がどう変動するのかを、契約前に確認しておくと想定外の値上げに驚かずに済みます。

チェックポイント4：契約形態は請負か準委任か

保守業務が準委任契約として結ばれるのか、それとも個別の改修依頼のたびに請負契約が発生する形なのかによって、責任の所在や報酬発生の考え方が変わります。準委任契約は、一定の対応可能な状態を確保してもらうこと自体に対価が発生する契約形態が一般的です。一方、個別の改修は成果物の完成に対して対価が支払われる請負契約として、保守契約とは別に発注される場合もあります。

契約前に、保守契約全体がどちらの性質を持つ契約として位置づけられているのかを確認しておくと、「今月は障害が一件もなかったから保守費を払いたくない」といった、契約の性質と噛み合わない誤解を避けられます。準委任契約は成果を保証する契約ではなく、対応可能な体制を維持してもらうことへの対価である、という点を理解したうえで契約に臨むことが大切です。

チェックポイント5：開発完了後の検収と保守開始のタイミングの関係

見落とされがちなのが、検収(発注者が成果物を確認し受け入れること)が完了するタイミングと、保守契約が開始するタイミングの関係です。検収が完了する前に見つかった不具合は、通常は開発契約の範囲内で無償修正されるべきものですが、保守契約がすでに始まっている場合、その不具合対応が保守費の中でカウントされてしまう、あるいは「検収後の不具合」として扱われてしまうことがあります。

契約前に確認しておきたいのは、次の点です。

• 検収完了日と保守契約の開始日は同じか、それともずれがあるか
• 検収時に発見された不具合の修正は、開発契約・保守契約のどちらの対応として扱われるか
• 検収後、一定期間は契約不適合責任（契約不適合責任）に基づく無償修正の対象になるか、その期間はどれくらいか

検収と保守契約の開始タイミングがあいまいなまま進めてしまうと、開発完了直後に見つかった不具合の扱いをめぐって、開発会社と発注者の間で「これは検収前の不具合対応なのか、保守の範囲なのか」という水掛け論になりかねません。

チェックポイント6：解約・更新条件はどうなっているか

保守契約は一度結ぶと自動更新されることが一般的ですが、契約前に確認しておくべきなのは、その更新条件と、解約を申し出る際のルールです。

確認しておきたい代表的な項目は、「自動更新の有無」「解約を申し出る場合の通知期限（一般的には解約希望日の1〜3ヶ月前までの通知を求める契約が多く見られます）」「契約期間中の中途解約が可能か、可能な場合に違約金などの条件があるか」の3点です。

これらは、将来的に他の開発会社へ切り替えたいと思ったとき、あるいはシステム自体を廃止したいときに、どれくらいの期間的な余裕を見ておく必要があるかに直結します。特に解約の通知期限を見落とすと、「もう使わないシステムなのに、通知が遅れたせいであと1年分の保守費を払う契約になっていた」という事態にもなりかねません。

チェックポイント7：作業範囲を超える依頼をした場合の見積もりの出し方

保守契約の範囲を超える作業（大規模な機能追加など）を依頼したい場合、どのように見積もりが出されるのかも、契約前に確認しておきたい項目です。単価の目安、見積もりが出るまでの標準的な日数、見積もり自体に費用が発生するのかどうかを確認しておくと、実際に追加の依頼をする際にスムーズに進みます。

開発会社によっては、保守契約とは別にSOW（作業範囲記述書）（作業範囲記述書、依頼する作業の範囲・成果物・期間などを明確にした文書）を都度作成する運用を取っているところもあります。このような運用が明文化されているかどうかも、契約前に確認しておくと、実際に追加依頼をする際の認識のズレを防げます。

チェックポイント8：エスカレーションのルートは明記されているか

保守を依頼している担当者に問い合わせても解決しない、あるいは連絡がつかないといった状況が発生した場合に、どこに、どのように連絡すればより上位の担当者につながるのか。このエスカレーションのルートが契約書や覚書に明記されているかも確認しておきたいポイントです。

小規模な開発会社の場合、保守の窓口が担当者1名に集中していることも珍しくありません。その担当者が休暇中や退職した場合の連絡ルートが確保されているかどうかは、いざというときの安心感に直結します。

チェックリスト：契約前に確認する8項目

ここまでの内容を、契約書を前にしたときにそのまま使えるチェックリストの形にまとめます。

• [ ] 対応範囲（不具合修正・軽微な変更・問い合わせ・パッチ適用）が具体的に明記されているか
• [ ] SLA（一次対応・復旧までの目標時間、対応可能な曜日・時間帯）が数値で明記されているか
• [ ] 料金体系と、その料金でカバーされる作業範囲、超過時の単価が明記されているか
• [ ] 保守契約が請負・準委任のどちらの性質か理解し、納得しているか
• [ ] 検収完了のタイミングと保守契約開始のタイミングの関係、検収時不具合の扱いが明確か
• [ ] 自動更新の有無、解約通知期限、中途解約の条件を確認したか
• [ ] 保守範囲外の追加依頼をした場合の見積もりの出し方が分かるか
• [ ] エスカレーションのルート（担当者不在時の連絡先）が確認できているか

このチェックリストの項目のうち、1つでも「分からない」「確認していない」がある場合は、契約書に署名する前に開発会社へ質問することをおすすめします。

確認を怠るとどうなるか：開発完了後によくあるトラブル

契約前の確認を省略してしまった結果、開発完了後にどのようなトラブルが起きやすいのかを、具体的なパターンで見ていきます。これから発注する担当者にとって、確認の必要性を実感してもらうための参考にしてください。

パターン1：想定していた対応が「範囲外」だった

システムが稼働を始めて数ヶ月後、「この画面にもう1項目表示を追加したい」という軽微な要望が出てきた際、保守契約の範囲内で対応してもらえると思い込んでいたところ、実際には「軽微な変更」の定義が契約書になく、都度見積もりの対象だと言われるケースです。契約前に「軽微な変更」の具体例をすり合わせておかなかったことが原因です。

パターン2：障害発生時、対応開始までに想定以上の時間がかかった

SLAが契約書に数値で明記されておらず、「なるべく早く対応します」という説明だけで契約してしまった結果、実際に障害が起きたときに、対応開始までに数日かかってしまったというケースです。業務が完全に止まってしまい、大きな損失につながることもあります。

パターン3：検収後に見つかった不具合が「保守費の対象」として扱われた

検収完了のタイミングと保守契約開始のタイミングを確認していなかったために、本来であれば開発契約の契約不適合責任に基づき無償で修正されるべき不具合が、「保守契約の範囲内での対応」として扱われ、保守費の中で処理されてしまう(実質的に無償対応ではあるものの、開発会社側の記録上は保守対応としてカウントされ、翌年の契約更新時に「対応件数が多かった」という理由で値上げの根拠にされてしまう)ケースです。

パターン4：解約したいタイミングで通知期限を過ぎていた

システムを廃止する、あるいは他社に乗り換えることを決めた際、契約書の解約通知期限を確認していなかったために、通知が遅れて契約がさらに1年自動更新されてしまったケースです。解約条件は、契約直後には気にしないことが多いですが、後になって重要性に気づく項目の代表例です。

パターン5：窓口の担当者が退職し、連絡が取れなくなった

保守を担当していた開発会社側の担当者が退職し、その後の連絡先やエスカレーションのルートが分からず、しばらく保守対応が滞ってしまったケースです。エスカレーションのルートが契約前に確認・明記されていれば、担当者の異動・退職があっても対応の空白期間を短くできた可能性があります。

これらのトラブルに共通しているのは、いずれも契約前であれば数分の質問で防げたという点です。開発完了後に発覚すると、対応に時間がかかるだけでなく、開発会社との関係にも影響しかねません。

開発会社への質問の切り出し方

保守契約の内容について確認したいことがあっても、「細かいことを聞いて印象を悪くしないだろうか」と遠慮してしまう担当者は少なくありません。しかし、契約前の確認は発注者として当然の権利であり、まっとうな開発会社であれば、質問されて困る内容ではないはずです。

質問を切り出す際の参考例を挙げます。

「保守契約の内容について、開発完了後に認識のズレが起きないよう、いくつか確認させてください。対応範囲について、軽微な変更とはどの程度の作業を想定されていますか。また、障害発生時の一次対応までの目安の時間があれば教えてください」

このように、疑いや不信感からではなく、「後で困らないように」という前向きな目的を明示して質問すると、開発会社側も具体的に回答しやすくなります。逆に、こうした質問に対して曖昧な返答しかなく、明文化を渋るような開発会社であれば、それ自体が1つの判断材料になります。

質問への回答は、口頭だけでなく、できる限り書面（契約書本文、別紙、メールでのやり取りなど）に残しておくことも重要です。口頭での説明は、担当者の記憶違いや、後任者への引き継ぎ漏れによって、いざというときに確認できなくなるリスクがあります。

保守契約書に条項として盛り込んでもらいたい項目

チェックポイントの確認と並行して、可能であれば契約書そのものに、次のような条項を具体的な形で盛り込んでもらうよう依頼することをおすすめします。

1. 対応範囲を列挙した別紙（不具合修正・軽微な変更の定義・問い合わせ対応の可否・パッチ適用の有無）
2. SLAを数値で明記した条項（一次対応までの目標時間、対応可能時間帯）
3. 検収完了日と保守契約開始日の関係を明記した条項
4. 解約通知期限と中途解約の条件を明記した条項
5. 保守範囲外の追加作業を依頼する場合の見積もり手続きを明記した条項

すべてを盛り込んでもらえるとは限りませんが、契約前であれば「この条項を追加してもらえますか」という依頼がしやすく、開発会社側もひな形の契約書をベースに、個別の条項を追記する形で対応してくれることが多いものです。契約後にこれらを追加しようとすると、変更契約や覚書の締結といった追加の手続きが必要になり、心理的にも実務的にもハードルが上がります。

複数の開発会社から提案を受けている場合の比較の視点

相見積もりを取っている段階であれば、保守契約の内容も比較材料の1つとして扱うことをおすすめします。開発費用だけを横並びで比較すると、保守契約の条件が緩い(=発注者に不利な)会社ほど、開発費用を安く見せられてしまう場合があるためです。

比較する際は、次のように条件をそろえて確認すると、金額だけでなく実質的な差が見えやすくなります。

• 同じ対応範囲(不具合修正・軽微な変更・問い合わせ対応の有無)で見積もりを依頼しているか
• 同じSLA水準(一次対応までの目標時間)を前提に金額を出してもらっているか
• 保守費が月額固定か都度精算かを揃えて比較しているか

条件をそろえずに金額だけを比較すると、「保守費が一番安い会社を選んだら、対応範囲が実は一番狭かった」という結果になりかねません。開発費用と保守費用は別会計で見えても、実質的には1つのシステムを維持していくためのトータルコストとして捉えることが大切です。

すでにシステムを発注済みで、保守契約がこれから始まる場合

この記事は主にこれから開発会社と契約する担当者を想定していますが、すでに開発契約は締結済みで、これから保守契約だけを個別に結ぶ、という段階の担当者にも同じチェックリストが有効です。開発契約と保守契約が別のタイミングで締結される場合、保守契約の交渉だけを単独で行うことになりますが、確認すべき項目自体は変わりません。

この段階では、開発会社側もすでにシステムの内容を把握しているため、対応範囲やSLAについて、より具体的な回答を得やすいという利点もあります。開発が完了する前、システムの稼働開始日が決まった段階で、逆算して保守契約の交渉のタイミングを設定しておくとよいでしょう。

中小企業の担当者が特に見落としやすいポイント

最後に、システム担当と総務・経理を兼務しているような、専任の情報システム担当者がいない体制の会社で、特に見落とされやすいポイントを補足します。

• 保守契約の存在自体を認識していない：見積書の中に「保守費」という項目があっても、それが独立した契約であるという認識がないまま、開発費用の一部として支払ってしまっているケースがあります
• 担当者交代時に引き継がれない：保守契約の内容を確認した担当者が異動・退職すると、契約内容の詳細が引き継がれず、次の担当者は契約書を読み返すところから始めることになります。確認した内容はシステム管理台帳などの形で記録に残しておくことをおすすめします
• 開発会社が「業界標準」と説明する内容を鵜呑みにする：保守契約の条件について「これが業界の標準的な内容です」と説明されると、比較対象がないためそのまま受け入れてしまいがちです。標準かどうかを判断する材料として、可能であれば他社の見積もりも並行して取得しておくと安心です

専任のIT担当者がいない体制だからこそ、契約前の確認を怠ると、後から気づいて対処する余力がないまま問題が積み重なっていきます。この記事のチェックリストを、契約書を受け取った際にそのまま印刷して使えるチェックシートとして活用してください。

まとめ：保守契約の確認は、開発契約と同じ熱量で

これから発注する開発契約に付随する保守契約は、開発内容そのものに比べて軽視されがちですが、実際にシステムが稼働してから発注者を悩ませるのは、多くの場合この保守契約の中身です。この記事で解説した内容を振り返ります。

1. 保守契約は開発契約とは別物の契約であり、開発契約の交渉と同じタイミングで、同じ熱量で内容を確認する必要がある
2. 契約前は交渉の余地があるが、契約後・稼働開始後は発注者側の交渉力が弱くなっていく
3. 確認すべき項目は、対応範囲・SLA・料金体系・契約形態・検収との関係・解約条件・追加依頼の見積もり方法・エスカレーションルートの8点
4. 確認を怠ると、開発完了後に「範囲外」「対応が遅い」「解約できない」といったトラブルに直面しやすい
5. 質問は前向きな目的を示して切り出せば、まっとうな開発会社であれば具体的に回答してもらえる

保守契約の確認は、開発会社を疑うための作業ではなく、双方が同じ認識でスタートするための準備作業です。この記事のチェックリストを手元に、これから届く契約書、あるいはすでに手元にある契約書を、ぜひ一度見直してみてください。そして、すでに保守契約を結んでいて、その内容が実態に合っているか不安がある方は、契約後の見直しの進め方を解説した記事もあわせてご覧ください。