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