システムを稼働させ続けるうえで欠かせない運用保守ですが、いざSEやSIerへ発注・外注しようとすると「人月の見積もりが妥当か分からない」「多重下請け構造でどこまでが直接対応なのか見えない」「契約形態は準委任と請負のどちらが正解なのか」といった疑問にぶつかりがちです。SE/SIerの運用保守は、新規開発とは異なり長期にわたって費用が発生し続けるため、発注時の取り決め一つでトータルコストが大きく変わってきます。
本記事では、SE/SIerへ運用保守を発注・外注・委託する具体的な方法を、人月見積もりの読み解き方、多重下請け構造の見抜き方、契約形態の選び方、SLA交渉の実務テクニックまで踏み込んで解説します。情報システム部門の担当者や発注を検討している経営層の方が、後悔しない委託先選びと契約締結を進められるよう、現場目線の実務知識を盛り込みました。最後まで読めば、運用保守の発注プロセス全体と、見落としがちな落とし穴への備えが一通り把握できます。
SE/SIerへの運用保守発注の全体像
SE/SIerへ運用保守を発注する際は、まず「何を委託するのか」を明確にすることが出発点となります。運用保守と一口に言っても、システムの正常稼働を維持する定常業務としての「運用」と、障害対応や仕様変更に伴う改修を担う「保守」では、必要となる人材のスキルも工数の発生パターンも異なります。この境界をあいまいにしたまま発注すると、後から「それは契約範囲外です」と追加費用を請求されるトラブルに発展しがちです。
「運用」と「保守」を分けて発注範囲を定義する
運用とは、サーバーやアプリケーションの監視、データのバックアップ、アクセス制御、ユーザーからの問い合わせ対応など、システムを止めないための定常業務を指します。一方の保守は、障害が発生した際の原因究明と復旧、あるいは法改正や業務変更に伴うプログラムの改修といった、不定期に発生する作業が中心です。SE/SIerに発注する際は、この両者を切り分けたうえで、それぞれどこまでを委託範囲とするかを書面で明確化しておく必要があります。
とくに見落とされやすいのが、運用の中でも「監視はするが復旧対応はしない」「一次切り分けまでは行うが根本対応は別契約」といった役割の細かなグラデーションです。発注前にこの粒度まで詰めておくことで、障害発生時に「誰が何をするのか」で揉めるリスクを大幅に減らせます。委託範囲の定義は、後述する契約書の必須記載事項とも直結する重要な工程です。
内製と外注の判断基準とコスト構造
運用保守を内製で抱えるか外注するかは、人材の確保状況とコスト構造の両面から判断します。ソフトウェアのライフサイクル全体のコストのうち、運用保守が占める割合は40〜80%、平均でおよそ60%に達するとされており、経済産業省の調査でも従来システムの運用と新規構築への支出割合は全産業平均で約2対1という結果が出ています。つまり、システムにかけるお金の多くは「作った後」に発生し続けるということです。
内製の場合は人材の採用・育成コストと属人化リスクを抱え込むことになり、外注の場合は委託費に加えてベンダーへの依存度が高まります。自社にインフラやアプリケーションの知見を持つSEが常駐できるのであれば内製も選択肢になりますが、24時間365日の監視体制や障害時の即応性を求めるなら、専門のSIerへ外注するほうが結果的に安定する傾向があります。判断にあたっては、目先の月額だけでなく、5年程度のトータルコストで比較することが欠かせません。
運用保守の進め方の全体像については、SE/SIerの運用保守の進め方でライフサイクルに沿って詳しく解説しています。あわせてご確認ください。
人月見積もりと多重下請け構造の見抜き方
SE/SIerへの運用保守発注で最も悩ましいのが、人月単価で提示される見積もりの妥当性です。SIer業界は元請けから二次請け、三次請けへと業務が流れる多重下請け構造になっていることが多く、発注者が支払う単価には複数の中間マージンが乗っている場合があります。この構造を理解しないまま発注すると、実際に手を動かすエンジニアのスキルや人数に対して割高な費用を払い続けることになりかねません。
人月単価の内訳を分解して読み解く
人月とは「1人のエンジニアが1か月稼働する作業量」を費用換算した単位です。運用保守の見積もりが人月で提示されたら、まずその月額が「何人月分」で構成されているのか、そして1人月あたりの単価がスキルランク別にいくらに設定されているのかを開示してもらいましょう。シニアエンジニアと若手では単価が倍以上違うことも珍しくないため、提案された体制図と単価が見合っているかを確認することが重要です。
運用保守作業の中で最も時間を要するのは、実は「調査・分析」の工程で、全作業時間の約30%を占めるというデータがあります。改修やプログラム修正そのものよりも、原因を突き止め影響範囲を見極める作業に工数がかかるということです。この事実を踏まえると、ドキュメントが整備され、システムへの習熟度が高いベンダーほど調査時間を圧縮でき、結果的に人月効率が良くなることが分かります。見積もりを比較する際は、単価の安さだけでなく、対象システムへの習熟度も評価軸に加えるべきです。
多重下請け構造を見抜くチェックポイント
多重下請け構造そのものが悪いわけではありませんが、発注者として把握しておくべき点があります。まず提案時に「実際に運用保守を担当するのは御社の自社社員か、協力会社の要員か」を率直に確認しましょう。再委託が前提なら、品質管理の責任が誰にあるのか、障害時の連絡経路がどう流れるのかを明確にしておく必要があります。間に会社が増えるほど、情報伝達のロスや責任の押し付け合いが起きやすくなるためです。
見抜き方として有効なのが、作業報告書やサーバーログから実稼働時間を割り出す監査的なアプローチです。請求されている人月に対して、実際にどれだけの作業が発生しているのかをログベースで突き合わせれば、相見積もりに頼らずとも費用の妥当性を判断できます。これは保守費用が適正かどうかを見極めるITデューデリジェンスの一手法であり、長期契約に入る前に一度実施しておくと、過剰な人月を払い続けるリスクを避けられます。
費用相場や見積もりの妥当性をさらに深掘りしたい場合は、SE/SIerの運用保守の見積相場や費用についてで具体的な相場観と監査手法を解説しています。
契約形態の選び方と契約書の必須条項
運用保守を外注する際の契約形態は、大きく準委任契約と請負契約に分かれます。どちらを選ぶかによって、ベンダーが負う責任の範囲も、費用の支払い方式も、さらには印紙税の扱いまで変わってきます。委託する業務の性質に合わせて適切な形態を選ぶことが、後々のトラブル回避につながります。
準委任契約と請負契約の使い分け
準委任契約は、継続的にサービスを提供してもらう形態で、ベンダーは成果物の完成責任を負いません。監視業務や問い合わせ対応のように、明確な納品物がなく、業務の遂行そのものに価値がある運用領域に適しています。一方の請負契約は、機能改修やプログラム修正のように「この機能を完成させる」という明確な成果物を約束する形態で、完成しなければ報酬を支払う必要がないという点で発注者に有利な面があります。
運用保守の現場では、定常的な運用部分を準委任、不定期に発生する改修部分を請負として切り分ける、あるいは両者を組み合わせた契約とするケースが一般的です。ここで知っておきたいのが印紙税のメリットです。保守契約を準委任契約とすることで、請負契約に課される印紙税の対象である第7号文書に該当せず、収入印紙が不要になるケースが多くあります。契約形態の選択は、責任範囲だけでなくコスト面にも影響するため、税務も含めて検討する価値があります。
契約書に必ず盛り込むべき条項
運用保守契約のトラブルの多くは、契約書の記載不備に起因します。最低限明記すべきは、保守対象範囲、費用と支払い方式、免責事項、そして契約解除条件の4点です。とくに保守対象範囲は「対象外」の線引きをめぐって追加費用トラブルになりやすいため、含まれる作業と含まれない作業を具体的に列挙しておくことが望まれます。
意外に見落とされがちなのが、ハードウェア保守における故障部品の所有権です。HDDなどを交換した際、故障部品の所有権は保守会社に帰属するのが一般的で、機密データが残ったまま部品が持ち出されるリスクがあります。データの確実な破棄を求めるのであれば、その旨を別途契約で定めておく必要があります。また、免責事項がベンダー側に有利になりすぎていないか、障害時の責任所在や違約金条件が明確かどうかも、締結前に法務目線でチェックすべきポイントです。
SLA設定とベンダー交渉の実務テクニック
運用保守の品質を担保するうえで欠かせないのがSLA（サービスレベル合意）です。SLAを設定することで、サーバーの稼働率や障害時の応答・復旧時間を定量的なKPIとして管理でき、ベンダーの責任を数字で問えるようになります。発注の段階でSLAを契約に織り込むかどうかが、運用品質の安定を大きく左右します。
具体的な数値で目標値を定める
SLAの目標値は、抽象的な表現ではなく具体的な数値で定めることが鉄則です。参考となるのが大阪市の調達ガイドラインで示された水準で、サーバ・アプリ稼働率99.8%以上、基準応答時間達成率93%（3秒以内）、重大障害は年2回まで、障害通知遵守率100%（発生後30分以内）、ヘルプデスク電話応答率97%以上（平均20秒以内）といった具体値が設定されています。こうした公的なガイドラインを参照すれば、自社が求めるべき水準の目安を立てやすくなります。
目標値を定めたら、それが未達となった場合の対応もセットで決めておきます。改善勧告にとどめるのか、ペナルティとして費用減額を求めるのかをあらかじめ取り決めておくことで、サービスレベル管理（SLM）が機能します。数値目標と未達時のルールを両輪で設計することが、形だけのSLAにしないためのコツです。
ペナルティ条項をのませる交渉術
ベンダーは当然ながらペナルティ条項を避けたがります。これをのませるには、いくつかの実務的なテクニックがあります。一つは、ペナルティ（減額）だけでなくインセンティブ（目標を上回った場合の報酬）を組み合わせる方法です。罰則一辺倒ではなく、頑張れば報われる構造にすることで、ベンダーも納得しやすくなります。もう一つは、他社の契約事例を交渉材料にする方法で、「同業他社では稼働率99.9%で契約している」といった具体例を示すことで、要求水準の正当性を裏付けられます。
ベンダー選定の際は、既存のベンダーをあえてRFP（提案依頼）に参加させるのも有効な交渉手段です。競争原理が働くことで契約条件の大幅な見直しが起こり、既存ベンダーが条件を改善して継続するケースが30〜40%の確率で発生するというデータもあります。新規ベンダーへの切り替えをちらつかせること自体が、強力な交渉カードになるのです。発注先の選定は契約満了の6か月前には動き出し、全体で4〜6か月をかけて進めるのが現実的なスケジュール感です。
引継ぎと属人化リスクへの備え
運用保守の発注で見落とされがちなのが、ベンダー切り替え時や担当者交代時の引継ぎです。運用保守は属人化しやすい業務であり、特定の担当者しかシステムの内部を把握していないという状態は、発注者にとって大きなリスクになります。発注の段階から、引継ぎとドキュメント整備を契約条件に組み込んでおくことが、将来の安定運用につながります。
スムーズな引継ぎを実現する体制づくり
ベンダーを切り替える場合、新旧の担当者が並走する引継ぎ期間を設けることが重要です。実務的には、新担当者を1.0人月、現行担当者を週2日程度のサポートとして配置し、2か月程度のOJT形式で業務を移管していくのが効果的とされています。この期間を契約に明記し、引継ぎが不十分なまま現行ベンダーが撤退してしまう事態を防ぎましょう。
注意したいのが移行コストの影響です。新ベンダーの月額が安く見えても、移行に300〜500万円かかる場合、5年間のトータルコストでは既存ベンダー継続のほうが安くなるという逆転現象が起こりえます。切り替えを検討する際は、移行コストを含めた中長期の総額で判断することが欠かせません。発注先の比較や選定の進め方については、SE/SIerの運用保守でおすすめの開発会社・ベンダー6選と選び方もあわせてご覧ください。
キーマン退職に備えるドキュメント要件
ドキュメントがほとんど整備されていない状態で、システムを熟知したキーマンが突然退職してしまうと、運用保守は一気に立ち行かなくなります。こうした属人化崩壊への備えとして、発注時にシステム構成図、運用手順書、障害対応履歴などのドキュメント整備とその定期更新を契約上の義務として課しておくことが有効です。ドキュメントの所有権が発注者側にあることも明記しておきましょう。
万が一ドキュメントが皆無の古いシステムを引き継ぐことになった場合、近年はAIに既存コードを解析させてブラックボックス化を解消するリバースエンジニアリングの手法も現実的な選択肢になっています。開発当初の仕様を知るスタッフがいなくても、コードからシステムの挙動を読み解き、保守可能な状態へ復元する取り組みは、属人化リスクを抱えた企業にとって心強い手段です。発注の段階で、こうした緊急時の対応力をベンダーが持っているかどうかも確認しておくとよいでしょう。
まとめ
SE/SIerへ運用保守を発注・外注する際は、まず「運用」と「保守」を切り分けて委託範囲を定義することが出発点となります。そのうえで、人月見積もりの内訳を分解して妥当性を見極め、多重下請け構造に潜む中間マージンを作業報告書やログから監査的に確認することで、過剰なコストを払い続けるリスクを避けられます。契約形態は準委任と請負を業務の性質に応じて使い分け、印紙税のメリットや故障部品の所有権といった実務上の落とし穴にも目を配ることが大切です。
さらに、SLAを具体的な数値で設定し、ペナルティとインセンティブを組み合わせた交渉でベンダーの責任を担保すること、そして引継ぎとドキュメント整備を契約条件に組み込んで属人化崩壊に備えることが、長期的に安定した運用保守を実現する鍵となります。発注は契約満了の6か月前から動き出し、4〜6か月かけて慎重に進めるのが現実的です。本記事の内容を踏まえ、後悔のない委託先選びと契約締結を進めていただければ幸いです。運用保守全体を体系的に理解したい方は、各テーマを横断的に解説した関連記事もぜひお役立てください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。