SE/SIerへの運用保守の発注は、まず委託範囲を決めることから始まります。以降は、委託先の選定、契約、費用の確認を経て、SLAの交渉と引継ぎで締めくくります。
運用保守は新規開発と違って長く費用がかかり続けるため、発注時の取り決め次第で総額が大きく変わります。
- 運用と保守の範囲、多重下請けと人月の見方
- 委託先の種類とRFP、評価表、選定の進め方
- 準委任と請負の違い、契約条項、SLAの交渉
- 費用の監査、引継ぎ、改善の仕組み
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SE/SIerへの運用保守発注の全体像
委託先を探す前に、まず「何を委託するのか」を明らかにしておく必要があります。
運用保守といっても、正常稼働を維持する定常業務の「運用」と、障害対応や仕様変更に伴う改修を担う「保守」では、必要な人材のスキルも工数の発生の仕方も異なります。そのため、この境界をあいまいにしたまま発注すると、後から「それは契約範囲外です」と追加費用を請求されるトラブルに発展しがちです。
「運用」と「保守」を分けた発注範囲の定義
運用とは、システムを止めないための定常業務を指し、サーバーやアプリケーションの監視、データのバックアップ、アクセス制御などが該当します。ユーザーからの問い合わせ対応も、運用に含まれます。一方の保守は、障害の原因究明と復旧、法改正や業務変更に伴うプログラムの改修など、不定期に発生する作業が中心です。
SE/SIerに発注するときは、両者を切り分けたうえで、それぞれの委託範囲を書面で明確にしておく必要があります。とくに見落とされやすいのが、運用のなかの「監視はするが復旧対応はしない」「一次切り分けまでは行うが根本対応は別契約」といった、役割の細かな濃淡です。
発注前にこの粒度まで詰めておけば、障害発生時に「誰が何をするのか」で揉めるリスクを大幅に減らせます。委託範囲の定義は、後述する契約書の必須記載事項とも直結する工程です。
内製と外注の判断基準とコスト構造
運用保守を内製で抱えるか外注するかは、人材の確保状況とコスト構造の両面から判断します。ソフトウェアのライフサイクル全体のコストで見ると、運用保守が占める割合は40〜80%、平均でおよそ60%に達するとされています。経済産業省の調査でも、従来システムの運用と新規構築への支出割合は全産業平均で約2対1という結果が出ています。
つまり、システムにかけるお金の多くは「作った後」に発生し続けるということです。内製の場合は人材の採用・育成コストと属人化リスクを抱え込むことになり、外注の場合は委託費に加えてベンダーへの依存度が高まります。判断にあたっては、目先の月額だけでなく、5年程度のトータルコストで比較することが欠かせません。
自社にインフラやアプリケーションの知見を持つSEが常駐できるなら内製も選択肢ですが、24時間365日の監視体制や障害時の即応性を求めるなら、専門のSIerへ外注するほうが結果的に安定する傾向があります。なお、運用保守の進め方の全体像については、SE/SIerの運用保守の進め方でライフサイクルに沿って詳しく解説しています。
人月見積もりと多重下請け構造の見抜き方
SE/SIerへの運用保守の発注で、いちばん悩ましいのが、人月単価で示される見積もりの妥当性です。SIer業界は元請けから二次請け、三次請けへと業務が流れる多重下請け構造になっていることが多く、発注者が支払う単価には、複数の中間マージンが乗っている場合があります。
多重下請けの構造を理解しないまま発注すると、実際に手を動かすエンジニアのスキルや人数に対して割高な費用を払い続けることになりかねません。
人月単価の内訳の読み解き方
人月とは、1人のエンジニアが1か月稼働する作業量を費用に換算した単位です。運用保守の見積もりが人月で示されたら、まず月額が何人月分で構成されているのか、1人月あたりの単価がスキルランク別にいくらなのかを開示してもらいます。シニアエンジニアと若手では単価が倍以上違うことも珍しくないため、体制図と単価が見合っているかを確認することが大切です。
さらに、運用保守作業の中で最も時間を要するのは、実は「調査・分析」の工程で、全作業時間の約30%を占めるというデータがあります。つまり、改修やプログラム修正そのものよりも、原因を突き止め影響範囲を見極める作業に工数がかかるということです。
この事実を踏まえると、ドキュメントが整備され、システムへの習熟度が高いベンダーほど調査時間を圧縮でき、結果的に人月効率が良くなることが分かります。見積もりを比較する際は、単価の安さだけでなく、対象システムへの習熟度も評価項目に加えるべきです。
多重下請け構造を見抜くチェックポイント
多重下請け構造が直ちに問題になるわけではありませんが、発注者として把握しておくべき点があります。再委託が前提なら、品質管理の責任が誰にあるのか、障害時の連絡経路がどう流れるのかを明確にしておく必要があります。間に入る会社が増えるほど、情報の伝達が途切れたり、責任を押し付け合ったりする事態が起きやすくなるためです。
まずは提案の段階で、「実際に運用保守を担当するのは御社の自社社員か、協力会社の要員か」を率直に確認してください。また、見抜く方法として有効なのが、作業報告書やサーバーログから実稼働時間を割り出す監査に近い進め方です。たとえば、請求されている人月と実際の作業量をログで突き合わせれば、相見積もりに頼らずとも費用の妥当性を判断できます。
これは、保守費用が適正かを見極めるITデューデリジェンスの一手法です。長期契約に入る前に一度実施しておけば、過剰な人月を払い続けるリスクを避けられます。なお、費用相場や見積もりの妥当性を深掘りしたい場合は、SE/SIerの運用保守の見積相場や費用についてで具体的な相場観と監査手法を解説しています。
契約形態の選び方と契約書の必須条項
運用保守を外注する際の契約形態は、大きく準委任契約と請負契約に分かれます。どちらを選ぶかで、ベンダーが負う責任の範囲も、費用の支払い方式も、さらには印紙税の扱いまで変わります。
委託する業務の性質に合った形態を選ぶことが、後々のトラブル回避につながります。
準委任契約と請負契約の使い分け
準委任契約は、継続的にサービスを提供してもらう形態で、ベンダーは成果物を完成させる責任を負いません。監視業務や問い合わせ対応のように、明確な納品物がなく、業務の遂行そのものに価値がある運用領域に適しています。
一方の請負契約は、機能改修やプログラム修正のように「この機能を完成させる」という明確な成果物を約束する形態で、完成しなければ報酬を支払う必要がないため、発注者に有利な面があります。運用保守の現場では、定常的な運用部分を準委任、不定期に発生する改修部分を請負として切り分ける、あるいは両者を組み合わせた契約とするケースが一般的です。
ここで知っておきたいのが、印紙税のメリットです。保守契約を準委任契約とすることで、請負契約に課される印紙税の対象である第7号文書に該当せず、収入印紙が不要になるケースが多くあります。このように、契約形態の選択は、責任範囲だけでなくコスト面にも影響するため、税務も含めて検討する価値があります。
契約書に盛り込むべき条項
運用保守契約のトラブルの多くは、契約書の記載不備に起因します。最低限明記すべきは、保守対象範囲、費用と支払い方式、免責事項の3点に、契約解除条件を加えた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か月かけて慎重に進めるのが現実的です。本記事の内容を踏まえ、後悔のない委託先選びと契約締結を進めていただければ幸いです。運用保守全体を体系的に理解したい方は、各テーマを横断的に解説した関連記事もぜひお役立てください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。