ITシステム保守運営の発注は、対象範囲を切り分け、委託前の準備を整えたうえで、契約と調整の方法を決め、発注後も管理を続ける流れで進めます。
特に、発注前の設計を誤ると、ブラックボックス化や「言った言わない」のトラブル、想定外の追加コストに直結します。
- 運用・保守と保守運営の役割の違い
- 対象範囲、体制、SLAの委託前準備
- 契約形態、責任分界点、再委託の条件
- マルチベンダー調整と発注後の管理
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム保守運営を外注する前に整理すべき全体像
ITシステム保守運営の外注を成功させるかどうかは、発注後の管理よりも発注前の整理でほぼ決まります。何を任せるのか、どの体制で運営するのか、社内に何を残すのかが曖昧なまま委託先を探し始めると、見積条件がブレます。
そのため、契約後に「これは範囲外です」という追加費用が次々と発生します。まずは、保守運営が指す業務の範囲と、外注先に渡すべき情報を整理します。
「運営」に含まれる運用と保守の切り分け
ITシステム保守運営という言葉には、性質の異なる2つの業務が含まれます。1つは「運用」で、監視や定時バッチ処理、バックアップといった、システムを現状のまま安定稼働させる定常業務です。ログ確認やアラート対応も、この運用に含まれます。
もう1つは「保守」で、障害修正やセキュリティパッチ適用、ハードウェア交換など、システムに変更を加える突発的・計画的な業務を指します。OSやミドルウェアのアップデートも、保守に含まれます。外注前にこの2つを分けて考えるのは、それぞれ求められるスキルも、料金体系も、契約形態も異なるからです。
定常運用は手順が決まっているため月額固定で委託しやすい一方、保守、特に障害対応や改修は工数が読みにくく、別途見積や時間精算になることが多くあります。発注書や仕様書で両者をひとくくりにすると、「障害対応は別料金です」と後から揉めがちです。最初に両者を分解し、月額固定とする範囲と都度精算とする範囲を決めておきましょう。
内製で残す業務と外注する業務の線引き
保守運営の外注では、すべてを丸投げせず、社内に残す業務を決めておくのが現実的です。システムの仕様や業務知識、過去の経緯といったノウハウまで外部に委ねてしまうと、社内に知見が一切残らず、ベンダーを切り替えられない「ロックイン」状態に陥ります。これがブラックボックス化の典型的な原因です。
実務上の線引きとしては、夜間休日の監視、一次対応、定型作業といった「人手と時間がかかるが定型化できる業務」を外注します。一方、システム企画とベンダー管理、業務要件の決定は社内に残し、最終的な意思決定も社内で行うハイブリッド体制が有効です。情報システム部門は、外注で生まれた余力を、DXや新規システム企画といった「攻めのIT」に振り向けられます。
外注を、コスト削減に加えて、限られた社内人材をコア業務に集中させる手段と位置づけると、発注の判断軸が明確になります。発注先の種類や体制比較の詳細は、関連記事のITシステム保守運営でおすすめの開発会社/ベンダー6選と選び方もあわせてご覧ください。
委託前の自社準備
発注の成否は、委託先に渡す情報の質と量で大きく変わります。委託前の準備が不十分だと、ベンダーはリスクを織り込んで高めの見積を出すか、安く受注しておいて後から追加請求するかのどちらかになります。
そこで、発注側が主導権を握るには、対象範囲、現状、求める水準を文書にして提示することが欠かせません。
対象範囲とシステム構成の明文化
まず作成すべきは、保守運営の対象となるシステムの一覧と構成情報です。サーバーからアプリケーションまでの各層のバージョンと、クラウドかオンプレミスかを、資産台帳として整理します。加えて、利用者数や稼働時間帯、外部サービスとの連携状況も、同じ台帳に整理します。
これがないと、ベンダーは何を保守すべきか把握できず、正確な見積を出せません。あわせて、対象に含める業務と含めない業務を明示します。たとえば「アプリケーションの障害一次切り分けは含むが、ソースコードの改修は別途見積」や、「OSのパッチ適用は含むが、メジャーバージョンアップは対象外」といった形で線を引き、グレーゾーンを残さないのが肝心です。
官公庁の維持管理業務委託仕様書では、全介入活動について「開始時間・終了時間・所要時間・対応理由・再発防止策」の記録提出を義務づけている例があります。こうした記録義務を発注側から仕様書に盛り込むことで、ブラックボックス化を未然に防ぐことができます。
SLAの数値設定と求める対応水準の提示
委託前の準備の核心は、外注先に求める対応水準を、サービスレベル合意（SLA）として数値で示すことです。稼働率の目標値と障害発生時の一次対応開始までの時間を定め、また復旧目標時間（RTO）と報告の頻度も定義します。SLAの項目設計やペナルティの取り決め方は、ITシステム保守運営の進め方/やり方/流れや方法/手法/工程/手順で詳しく解説しています。
ある自治体案件では、障害発生時に再委託先が「1時間以内に現地到着・対処開始」し、「対応開始から1時間以内に内容と予想作業時間を報告」する規定があります。加えて「初期報告から原則4時間以内に完全復旧」という規定もあります。そのうえで、自社システムが止まった場合の業務影響度を踏まえ、稼働率99.9%が必要か99%で十分かを見極め、過剰品質と過小品質のバランスをとりましょう。
同様に、定期保守は「原則年1回12月に実施」、定期報告は「年4回、3月・6月・9月・12月末」と、頻度とタイミングを数値で固定している例もあります。自社のSLA設計で物差しになるのが、官公庁の仕様書に見られる厳格な数値です。ただし、数値は厳しければよいというものではなく、求める水準が高いほど料金も上がります。
契約形態の選び方と責任分界点
保守運営の委託では、契約形態の選択が後々のトラブルを大きく左右します。多くの保守運営契約は準委任契約で結ばれますが、業務の性質によっては請負契約が適する場面もあります。両者の違いを理解しないまま契約すると、責任の所在が曖昧になり、障害時に「これは契約上の責任範囲外」という主張で揉めることになります。
準委任契約と請負契約の使い分け
準委任契約は「業務の遂行」そのものを目的とする契約で、成果物の完成義務はなく、善管注意義務をもって業務を実施することが求められます。日常的な監視・運用・障害対応のように、毎月の業務量が変動し、完成という概念になじまない定常的な保守運営には、この準委任契約が適しています。月額固定で人的リソースを確保する保守契約の多くがこの形態です。
一方、請負契約は「成果物の完成」を目的とし、完成しなければ報酬が発生せず、契約不適合責任（旧瑕疵担保責任）を負います。システムの大規模改修や、特定機能の追加開発、移行作業のように、ゴールが明確に定義できる業務には請負が向いています。実務では、定常運用を準委任で月額契約とし、突発的な改修はその都度、請負で別契約とする組み合わせが一般的です。
また、IPAの共通フレームでも、運用保守における請負と準委任の使い分けと、開発ベンダーと運用保守ベンダーの責任分界点を明確にする重要性が指摘されています。どちらの形態でも、契約書には業務範囲と期間、報酬を明記し、再委託の可否や損害賠償の上限も定めておくことが、後のトラブルを防ぐ基本となります。
責任分界点と再委託の取り決め
契約で必ず明確にすべきは、責任分界点です。どこまでが委託先で、どこからが発注側や別ベンダーの責任かを、システムの層（アプリケーション、ミドルウェア、OS、インフラ、ネットワーク、ハードウェア）ごとに線引きします。
たとえば「アプリケーションの不具合は開発ベンダー、インフラの障害は運用委託先、ネットワークは回線事業者」のように、層と担当を対応づけると、障害時に責任のなすりつけ合いを避けられます。また、再委託も契約段階で確認が必要です。前述の官公庁仕様では、再委託先に対しても本体と同等の到着時間・報告義務を課しています。
委託先がさらに別の会社に再委託する場合は、発注側の事前承認の要否と、再委託先の作業品質や情報管理責任を元請けが負うかを明記します。再委託を認める場合は、情報漏洩リスクを抑えるため、機密保持義務を再委託先まで及ばせておくと安心です。委託前の準備から契約までの進め方は、ITシステム保守運営の進め方/やり方/流れや方法/手法/工程/手順も参考になります。
マルチベンダー環境での発注と調整プロセス
現代のITシステムは、クラウド事業者・アプリケーション開発会社・インフラ運用委託先・ネットワーク事業者など、複数のベンダーが関与するマルチベンダー環境が当たり前になっています。この環境で保守運営を発注する際に最も難しいのが、障害発生時の原因切り分けと、ベンダー間の調整です。
発注段階でこの調整プロセスを設計しておかないと、障害時に各社が「自社の範囲ではない」と主張し合い、復旧が遅れるという最悪の事態を招きます。
原因切り分けの主導権の持たせ方
マルチベンダー環境で発注を成功させるには、障害発生時に「原因切り分けの主導権を誰が持つか」を事前に決めておくことが鍵です。発注側の情報システム部門が自ら切り分けを担うのは、専門人材がいないと現実的でない場合が多くあります。
そこで有効なのが、運用委託先に「一次切り分けと各ベンダーへの問い合わせ調整」までを役割として明示的に委託する方法です。委託先が窓口（ハブ）となり、ログやメトリクスから「どの層に問題があるか」を切り分け、該当するベンダーへエスカレーションする体制を契約に盛り込みます。
この役割を委託するなら、委託先には他社が運用するインフラやアプリケーションの情報へのアクセス権と、各ベンダーの連絡先・エスカレーションルートの共有が必要になります。発注時に、全ベンダーの体制図と連絡フローを一枚にまとめ、誰が司令塔となり、どの順番で連絡が回るかを可視化しておくと、初動が大きく変わります。
一括委託と分割委託のメリット比較
マルチベンダー環境での発注方式には、大きく分けて2つの考え方があります。1つは、運用保守を1社に一括委託し、その会社にサブベンダーの取りまとめまで任せる方式です。この方式では、窓口が一本化され、障害時の調整も委託先が担うため発注側の負担は軽くなりますが、元請けの取りまとめ力に品質が大きく依存し、中間マージンが発生する点には注意が必要です。
もう1つは、領域ごとに最適なベンダーへ個別に発注する分割委託です。各領域の専門性を活かせ、コストの透明性も高い反面、ベンダー間の調整は発注側が担う必要があり、相応の管理工数とスキルが求められます。どちらが適切かは、社内のIT管理体制の充実度とシステムの複雑さによって変わります。
たとえば、情報システム部門の体制が手薄な場合は一括委託で窓口を一本化し、ある程度の管理人材がいる場合は分割委託でコストと専門性を追求するという判断が現実的です。発注後の体制全体をどう運営していくかは、保守運営の進め方をまとめたITシステム保守運営の進め方/やり方/流れや方法/手法/工程/手順もあわせて確認しておくとよいでしょう。
失敗しない委託先の見極めと発注後の管理
委託先を決める段階で、提案書や見積書の表面的な金額だけで判断すると失敗します。安く見えても対応範囲が狭く追加費用がかさむケースや、提案時は手厚そうでも実際には低スキルの要員が配置されるケースがあるためです。
丸投げにならない仕組みは、発注前の見極めと発注後の継続的な管理の両面で整える必要があります。
提案書と見積による丸投げ体質の見極め
提案書を読む際は、対応範囲が具体的に書き込まれているかを見ます。「運用保守一式」とだけ記載され、内訳が不明瞭な見積には注意が必要です。一方で、良質なベンダーは、監視・障害対応・パッチ適用・定期報告といった作業項目ごとに想定工数と対応時間帯を明示し、範囲外となる業務についても先回りして「これは別途見積」と線引きしています。
逆に、何を聞いても「対応可能です」と曖昧に答える業者は、後から「それは聞いていない」となるリスクが高いといえます。体制面では、担当者が1名だけの属人体制になっていないかを確認しましょう。担当者の急な退職や休職で運用が止まらないよう、複数名のチーム対応やバックアップ体制、ドキュメント整備の方針を持っているかを見極めることが大切です。
あわせて、障害時の連絡体制、夜間休日の対応可否、エスカレーションのルールが具体的に説明できるかも、実力を見極める判断材料になります。複数社を比較する際の評価軸は、ITシステム保守運営でおすすめの開発会社/ベンダー6選と選び方で詳しく整理しています。
発注後にブラックボックス化を防ぐ運用
発注後の管理こそ、外注成功の分かれ目です。委託先に任せきりにすると、システムの内部状況が見えなくなり、いざベンダーを切り替えようとしたときに移行できないロックインに陥ります。そこで、月次や四半期ごとのレビューでSLAの達成状況を確認し、未達なら原因と改善策を協議する定例も有効です。
これを防ぐには、定期報告の場を設け、作業記録・障害対応履歴・構成変更の内容を文書で受け取り、社内に蓄積する運用が欠かせません。契約時に、運用手順書や構成管理ドキュメントの整備と更新を委託先の義務として盛り込み、それらの成果物が発注側に帰属すると明記しておけば、ベンダー切り替え時にも知見が手元に残ります。
また、前述の官公庁仕様のように、定期報告を年4回など頻度で固定し、記録提出を義務化することは、民間の発注でもブラックボックス化を防ぐ実践的な手段となります。発注後の運営を含めた全体像は、ITシステム保守運営の進め方/やり方/流れや方法/手法/工程/手順もあわせて参照してください。
まとめ
ITシステム保守運営の発注・外注を成功させる鍵は、発注後の管理よりも発注前の設計にあります。まず「運用」と「保守」を切り分け、内製で残す業務と外注する業務の線引きを明確にしたうえで、対象範囲とシステム構成を文書化し、SLAを具体的な数値で提示することが出発点となります。
官公庁の維持管理業務委託仕様書に見られる「1時間以内の対応開始」「4時間以内の復旧」「年4回の定期報告」「全介入活動の記録義務」といった数値は、自社のSLA設計や記録義務化の現実的な物差しになります。
契約面では、定常運用は準委任、突発改修は請負という使い分けを基本に、システムの層ごとの責任分界点と再委託の取り決めを明記します。また、マルチベンダー環境では、障害時の原因切り分けの主導権を事前に決め、一括委託と分割委託のメリットを自社の管理体制に照らして選ぶことが欠かせません。
さらに、発注後も定期報告とドキュメント整備の義務化によってブラックボックス化を防ぎ、丸投げにならない管理を続けることが、長期的に安定した保守運営につながります。このように準備を整えておけば、安心して任せられる外注体制を構築できるはずです。
▼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を創業。