システムを外注して納品を受けたあと、あるいは受ける前に、意外と後回しになりがちなのが「保守」の話です。開発会社から保守契約の見積もりを出されたものの、月にいくらが妥当なのか、どこまでやってもらえるのか、そもそも本当に必要なのか、判断がつかない方は多いと思います。
結論から言うと、受託開発の保守は「システムを安定して使い続けるための継続的なサポート」で、費用は初期開発費の年15〜20%が一つの目安です。ただし発注者にとって本当に大事なのは金額そのものより、何をどこまでやってもらえるか（範囲）、会社が倒産・撤退したときにシステムを守れるか、別の会社に乗り換えられるか、という点です。この記事では、受託開発の保守で押さえるべき基本（中身・費用・契約形態）と、保守契約で損しないための備え（範囲とSLA・倒産時の対策・移管条件）を発注側の目線で整理します。
この記事のポイント
- 保守費用は初期開発費の年15〜20%が目安（月額数万円〜規模で大きく変動）
- 「不具合の修正」は保守内、「機能追加」は別料金。範囲の線引きを契約書で明確に
- 継続的な保守は準委任契約が一般的。SLAで対応時間や着手速度を数値で決める
- 開発会社の倒産・撤退に備え、ソース・ドキュメントの受け渡しと移管条件を先に決める
目次
受託開発の保守で発注者が押さえる基本
受託開発の保守を検討するなら、まず「何をしてもらえるのか」「いくらが目安か」「どんな契約になるのか」の3点を押さえると、開発会社の見積もりが読めるようになります。ここが曖昧なまま契約すると、後から「それは保守の範囲外です」と追加費用を請求される、といったズレが起きます。
保守で何をしてもらえるのか
受託開発の保守は、大きく「システムを止めないための作業」と「不具合が起きたときの対応」に分かれます。前者はサーバーの稼働監視、定期的なメンテナンス、セキュリティ更新など。後者はエラーや障害が起きたときの原因調査と修正です。いずれも「今あるシステムを、納品時の状態で安定して使い続ける」ための作業だと考えると分かりやすいです。
ここで発注者が必ず押さえておきたいのが、「不具合の修正」と「機能の追加」は別物だという点です。納品したものが仕様どおり動かない不具合の修正は保守の範囲内ですが、「新しい機能を足したい」「画面を作り替えたい」といった改修は、通常は保守とは別の料金になります。この境界が曖昧だと、追加要望のたびに揉めるので、契約時に「どこまでが保守で、どこからが別発注か」を文書で決めておくことが大切です。
保守が続く前提のシステムでは、開発と同じ会社に頼み続けるかどうかも論点になります。継続して手を入れる開発は、専属チームを一定期間確保するラボ型開発や、月額で開発と運用を続ける進め方と地続きです。自社のシステムがどれだけ手を入れ続けるものかで、保守の重さも変わってきます。
保守費用の相場と算出方法
保守費用の最も一般的な目安は、初期開発費の年15〜20%です。たとえば1,000万円で開発したシステムなら、年間の保守費用は150〜200万円が一つの相場になります。金額の出し方には主に、開発費に保守料率（15〜20%）を掛ける方式、定期作業と障害対応の工数に技術者単価を掛ける方式、機能の複雑さを点数化する方式があります。あくまで一般的な目安で、システムの規模・複雑さ・求める対応レベルによって大きく変わるため、実際の金額は個別の見積もりで確認してください。
費用の妥当性を見るときは、金額の大小より内訳の透明性を見ます。「保守一式・月○万円」だけの見積もりは、何にいくらかかっているのかが見えません。次のように作業と対応レベルごとに分かれていると、妥当性を判断でき、削れる部分の相談もしやすくなります。
| 保守の内訳例 | 内容 | 費用の目安 |
|---|---|---|
| 稼働監視 | サーバー・サービスの死活監視 | 月数万円〜 |
| 定期メンテナンス | 月次点検・軽微な更新 | 作業工数×単価 |
| 障害対応 | 不具合の調査・修正（回数・時間帯で変動） | 対応範囲で変動 |
| 時間外・緊急対応 | 夜間・休日の対応（オプション） | 都度加算されることが多い |
見積もりの内訳を同じ観点で見比べる考え方は、受託開発の見積もりと費用の考え方を解説した記事も参考になります。保守も開発と同じく、一式ではなく分解して妥当性を判断するのが基本です。
費用を抑えたい場合でも、単純に金額の安い保守を選ぶのは危険です。監視や障害対応の範囲を削れば月額は下がりますが、いざ障害が起きたときに対応が遅れ、結果的に事業機会の損失や緊急対応の割増費用で高くつくことがあります。逆に、ほとんど更新しない小規模なシステムに手厚い保守は不要です。判断のコツは「このシステムが止まったときの業務インパクト」を基準に、必要な範囲だけにお金をかけること。月額の安さではなく、止まらないための備えとして費用対効果で見ると、過不足のない保守を選べます。
保守の契約形態はどうなる
受託開発の保守は、多くの場合「準委任契約」で結ばれます。継続的にシステムを見守り、必要に応じて対応するという性質上、成果物の完成を約束する請負契約よりも、業務を継続して遂行する準委任契約が合うからです。一方、「この改修をここまで作りきる」といったまとまった追加開発を切り出すときは、その部分だけ請負契約にする、という使い分けが実務ではよく行われます。
準委任と請負では、発注者が受け取れる保証が変わります。準委任は「決められた稼働のなかで誠実に対応する」契約で、特定の成果を必ず出すことまでは約束しません。この違いを理解しておくと、保守契約に過剰な完成保証を期待してズレる、ということが避けられます。契約形態ごとの責任の違いは、受託開発と請負開発の違いを解説した記事で請負と準委任の観点から詳しく整理しています。
受託開発の保守契約で損しない備え
費用と契約形態が分かったら、次は「損をしないために契約へ何を入れておくか」です。保守は長く続く関係なので、始める前の取り決めが甘いと、後から動けなくなったり、余計な費用がかかったりします。特に発注者が見落としやすい3点を押さえておきましょう。
契約に入れるべき範囲とSLA
まず、前述の「どこまでが保守か」の範囲を契約書に明記します。不具合修正は含む、機能追加は別見積もり、といった線引きに加えて、対応の品質を数値で決めるのがSLA（サービス品質の合意）です。SLAでは、障害の連絡を受けてから何時間以内に着手するか、対応する時間帯（平日日中か、夜間・休日も含むか）、システムの稼働率をどの程度保つか、といった水準を取り決めます。
SLAが曖昧だと、「障害を報告したのに翌営業日まで動いてくれない」といったことが起こり得ます。逆に、24時間365日の手厚い対応は費用も上がるため、自社のシステムがどれだけ止まると困るのかに合わせて、必要な水準を選ぶのが賢い決め方です。過剰なSLAはコストの無駄、不足するSLAは業務リスクになります。
目安として、社内だけで使う業務システムなら平日日中の対応で十分なことが多く、顧客が24時間使うサービスなら夜間・休日を含む対応や高い稼働率が必要になります。「止まったら1時間でいくら損失が出るか」をざっくり見積もると、どこまでのSLAにお金をかける価値があるかが判断しやすくなります。契約書には、着手までの時間・対応時間帯・想定復旧時間・月あたりの対応回数の上限といった具体的な数字を書いてもらい、口頭の「すぐ対応します」で済ませないことが大切です。
開発会社が倒産・撤退したときの備え
発注者が最も見落としがちで、かつ痛いのが、保守を頼んでいる開発会社が倒産・撤退するケースです。このとき困るのが、システムのソースコードや設計ドキュメントが手元になく、他社が引き継げない状況です。そもそもソースコードの著作権は、開発費を全額払っても契約で定めない限り自動的には発注者に移りません。まず契約で、成果物やソースコードの権利・受け渡しを明確にしておくことが前提です。
そのうえで、万一に備える現実的な手段が3つあります。1つ目は、ソースコード・実行ファイル・データベースのバックアップなど、引き継ぎに必要なものを平時から手元に受け取っておくこと。2つ目は、設計思想や運用手順をまとめたドキュメントを残してもらうこと。3つ目は、第三者機関にソースコードを預けておく「ソフトウェア・エスクロウ契約」で、開発会社が倒産した場合に発注者がソースを受け取れるようにする方法です。すべてを行う必要はありませんが、止まると事業に影響するシステムほど、備えの優先度は上がります。こうしたリスク・契約・体制を発注側で管理する観点は、ベンダーコントロールパーフェクトガイドで全体像を確認できます。
解約・移管の条件を先に決める
もう一つ大事なのが、保守を今の会社から別の会社に移すときの条件です。対応が遅い、費用が見合わない、といった理由で保守先を変えたくなることは珍しくありません。ところが、解約や移管の条件が契約に書かれていないと、いざ切り替えたいときに「ソースを渡してもらえない」「最新のドキュメントがない」と揉め、結局その会社から動けなくなります。これがベンダーロックインです。
契約時に、解約時にソースコードと最新のドキュメント一式を受け取れること、移管に必要な協力を得られること、通知の期間などを決めておけば、いざというとき安全に乗り換えられます。ロックインを避ける考え方は、開発会社との付き合い方全般に関わるので、保守を始める前に一度整理しておくと安心です。
実務では、契約書に「解約時の引き継ぎ協力義務」を1条入れておくだけで、後の交渉が大きく楽になります。具体的には、解約の何か月前までに通知するか、引き継ぎ時にどの資料（ソース・環境情報・運用手順・アカウント）を渡してもらうか、引き継ぎ作業に費用が発生する場合の扱い、までを決めておきます。ここを最初に握っておくと、開発会社側も「囲い込むための保守」ではなく「対等なサービスとしての保守」として向き合ってくれます。乗り換えの自由を持っておくことが、結果的に今の保守の質を保つ抑止力にもなります。
よくある質問
- Q. 受託開発の保守費用は月いくらが相場ですか？
- A. 初期開発費の年15〜20%が一つの目安で、月額に直すと数万円から、規模の大きいシステムでは数十万円以上になることもあります。監視・障害対応・対応時間帯によって変わるため、内訳を分けた見積もりで妥当性を確認してください。
- Q. 保守は開発を頼んだ会社に必ず頼まないといけませんか？
- A. 必ずではありませんが、システムを作った会社は中身を理解しているため、そのまま保守も頼むケースが一般的です。別の会社に移すこともできますが、ソースコードやドキュメントの受け渡しが前提になるため、契約で移管条件を決めておくことが重要です。
- Q. 保守契約を結ばないとどうなりますか？
- A. 障害が起きたときに都度見積もり・都度対応となり、対応が遅れたり割高になったりしがちです。止まると業務に影響するシステムほど、最低限の障害対応を含む保守契約を結んでおくほうが安全です。
