「夜間や休日のアラート対応に担当者が疲弊している」「ひとり情シスで24時間365日の監視を続けるのは限界」——ITシステムの保守監視を外部へ発注したいと考えても、いざ発注となると「どこまで委託すればいいのか」「RFPに何を書けば失敗しないのか」「SLAはどう設定すべきか」といった実務の壁に突き当たる方は少なくありません。発注の段取りを誤ると、要件が曖昧なまま契約してしまい、追加費用やブラックボックス化、責任の押し付け合いといったトラブルに発展します。
この記事では、ITシステム保守監視を発注・外注・依頼・委託する際の具体的な手順を、委託範囲の決め方からRFP（提案依頼書）の作成項目、SLA・KPIの設定、ISMS等のセキュリティ確認、契約形態（準委任/請負）の選び方まで、稟議や契約交渉でそのまま使えるレベルで解説します。さらに「ハズレのベンダーを引いた場合の乗り換え」や「将来の内製化巻き戻し」を見据えた発注設計という、丸投げで終わらせないための視点まで踏み込みます。読み終えたとき、自社にとって最適な発注先と契約の形が明確になっているはずです。
ITシステム保守監視を発注する前に整理すべき全体像
保守監視の発注は、いきなり見積もりを取りに行っても良い結果にはなりません。まず「自社が何に困っていて、どこを外部に任せたいのか」を言語化しておくことが、その後のRFPや契約交渉の精度を決めます。ここでは発注の前提として押さえておきたい、委託範囲の考え方と発注先の種類を整理します。
委託範囲（フル委託とセレクティブ委託）の決め方
保守監視の委託には、運用全体を丸ごと任せる「フルアウトソーシング」と、監視・一次対応など一部だけを任せる「セレクティブ（部分）委託」があります。どちらを選ぶかで、発注の規模もRFPの書き方も大きく変わるため、最初に明確にしておく必要があります。
判断の軸になるのが「ノウハウを社内に残したいかどうか」です。フル委託は担当者の負担を一気に減らせる反面、運用がブラックボックス化し、社内ノウハウが失われやすいというリスクを抱えます。一方でセレクティブ委託は、たとえば「夜間・休日の一次監視（L1）だけを外注し、二次対応（L2）以降は自社で持つ」といった形で、コア部分のノウハウを残しながら疲弊する部分だけを切り出せます。
現場でよく使われる考え方が「80/20ルール」です。発生するインシデントのうち、定型的でマニュアル化しやすい約80%（アラート検知・初期切り分け・パスワードリセット等）を外部のL1に任せ、専門判断が必要な残り20%を自社や上位ベンダーが担うという切り分けです。まずは「自社のどの業務がこの80%に当たるのか」を棚卸しすることが、委託範囲を決める第一歩になります。
発注先の種類とそれぞれの特徴
ITシステム保守監視の発注先は、大きくMSP（マネージドサービスプロバイダー）、システム開発を手がけたSIer、監視・運用代行に特化した専門ベンダーの3タイプに分かれます。それぞれに得意領域と注意点があるため、自社が任せたい範囲と照らし合わせて選定します。
MSPはクラウド基盤の24時間365日監視や自動化を強みとし、AWS・Google Cloud等のインフラ運用を一括で任せたい場合に適しています。SIerは自社が構築したシステムをそのまま運用まで担うため、業務知識の引き継ぎがスムーズで、システム改修と保守を一体で進めたい場合に向きます。専門ベンダーは監視・アラート対応・ヘルプデスクなど特定領域に深い知見を持ち、セレクティブ委託で「ここだけ任せたい」というニーズに応えやすいのが特徴です。
なお、保守監視の「進め方」全体の流れや、各社の比較・費用の目安を先に押さえておきたい場合は、関連記事もあわせてご覧ください。発注の判断材料がより明確になります。ITシステム保守監視の進め方を解説した記事では、現状棚卸しから監視設計、委託判断までのライフサイクルを詳しく扱っています。
ITシステム保守監視の発注・外注の進め方
発注は「現状棚卸し→RFP作成→複数社からの提案受領→選定→契約→並走期間（ハイパーケア）」という流れで進めます。特に最初の棚卸しとRFPの質が、後工程のトラブルを防ぐ鍵になります。ここでは各ステップの具体的なポイントを解説します。
ステップ1：現状の棚卸しと監視対象の整理
最初にやるべきは、監視対象となるサーバー・ネットワーク機器・クラウドサービス・アプリケーションの一覧化です。「何台のサーバーを、どの時間帯に、どのレベルまで監視してほしいのか」が曖昧なまま発注すると、見積もりがブレ、契約後に「想定外の対象が増えた」として追加費用が発生します。
あわせて、現在発生している障害・アラートの傾向も整理します。月にどれくらいアラートが鳴り、そのうち何割が誤検知（ノイズ）で、何割が本当に対応が必要だったのかを把握しておくと、ベンダーに「アラート疲労の解消」や「閾値チューニング」を明確に依頼できます。たとえばCPU使用率が一瞬80%を超えただけで通知される設定を、「5分間継続したら通知」という条件に変えるだけでノイズは大幅に減ります。こうした改善要望を棚卸しの段階で言語化しておくことが重要です。
ステップ2：RFP（提案依頼書）の作成と提示
棚卸しの結果をもとに、RFP（提案依頼書）を作成します。RFPは複数のベンダーに同じ条件で提案を求めるための文書であり、これがしっかりしていれば各社の提案を同じ土俵で比較できます。逆にRFPが曖昧だと、各社が前提条件を勝手に解釈し、見積もりの比較が成り立たなくなります。
RFPに最低限盛り込むべき項目は次の通りです。
・監視対象の一覧（サーバー台数、機器、クラウド環境、アプリケーション）
・委託範囲（監視のみ/一次対応まで/復旧対応まで）
・対応時間帯（平日日中のみ/24時間365日）
・求めるSLA・KPI（応答時間、稼働率など）
・セキュリティ要件（ISMS等の認証、データの取り扱い）
・既存の監視ツールや運用ルールの有無
・将来的な内製化・体制移管の希望
特に「将来的な内製化の希望」をRFPに明記しておくことは、後述する丸投げ依存を避けるうえで効果的です。発注の段階で「いずれ社内に巻き戻す可能性がある」と伝えておくと、ドキュメント整備やナレッジ共有に前向きなベンダーを選びやすくなります。
ステップ3：複数社比較と並走期間の設計
提案を受け取ったら、最低でも3社程度を比較します。価格だけでなく、SLAの妥当性、自動化率、セキュリティ体制、過去の運用実績を総合的に評価することが大切です。たとえば一部のMSPではアラート全体の約80%を自社システムで自動処理し、人手による対応を残り20%に抑えているケースもあり、こうした自動化率の高さはアラート疲労の解消とコスト効率に直結します。
発注先が決まったら、すぐに全面移管せず「並走期間（ハイパーケア）」を設けます。通常3〜6ヶ月かけて、自社とベンダーが一緒に運用を回しながら、ドキュメントの整備とナレッジの引き継ぎを行います。この期間を省略すると、移管直後に障害対応が回らなくなったり、暗黙知が引き継がれず属人化が再発したりするため、発注時点で並走期間を契約に含めておくことを強くおすすめします。
SLA・KPIの設定とセキュリティ要件の確認
保守監視の発注で最もトラブルになりやすいのが、品質基準とセキュリティの取り決めです。「ちゃんと監視してくれるはず」という曖昧な期待のまま契約すると、いざ障害が起きたときに「契約範囲外」と言われかねません。客観的な数値とセキュリティ認証で品質を担保することが、発注者を守ります。
SLA・KPIで品質を数値化する
SLA（サービス品質保証）は、ベンダーが守るべきサービス水準を契約として明文化したものです。保守監視で設定すべき代表的なKPIには、インシデント発生から一次応答までの時間（例：30分以内）、システムの稼働率（例：99.9%以上）、平均修復時間（MTTR）などがあります。これらを数値で取り決めておけば、品質が下回った場合の対応や減額の根拠になります。
注意したいのは、SLAの数値を高く設定すればするほど費用も上がるという点です。たとえば稼働率99.9%（年間ダウンタイム約8.8時間）と99.99%（同約53分）では、求められる体制も価格も大きく異なります。自社のシステムがビジネスにどれだけ直結しているかを基準に、過剰でも過小でもない水準を見極めることが、コストパフォーマンスの良い発注につながります。
あわせて、定期レポートとレビュー会の頻度もSLAに含めておきます。月次でアラート件数・対応実績・改善提案を報告してもらい、PDCAを回す仕組みを契約に組み込むことで、運用がブラックボックス化するのを防げます。
ISMS等のセキュリティ体制を確認する
保守監視を委託するということは、自社システムへのアクセス権限や機密情報をベンダーに預けることを意味します。そのため、ISMS（ISO/IEC 27001）やプライバシーマークといった第三者認証を取得しているかは、発注前に必ず確認すべき項目です。認証の有無は、組織として情報セキュリティを管理する体制が整っているかの客観的な指標になります。
認証の有無だけでなく、運用面の取り決めも重要です。アクセスログの保管、作業時の権限管理、再委託の可否、インシデント発生時の報告ルートなどを契約書に明記しておきます。特に保守監視ではベンダー側の作業者が本番環境を操作するため、「誰が・いつ・何をしたか」を追跡できる体制が整っているかを確認しておくと安心です。
契約形態（準委任・請負）の選び方
保守監視の発注では、どの契約形態を結ぶかによって責任の範囲や成果の捉え方が変わります。業務の性質に合わない契約を結ぶと、トラブル時に責任の所在が曖昧になります。代表的な準委任契約と請負契約の違いを理解し、委託する業務に応じて使い分けることが重要です。
準委任契約と請負契約の違い
準委任契約は「業務の遂行そのもの」に対して対価を支払う契約で、成果物の完成義務はありません。保守監視のように「24時間365日、継続的に監視する」「アラートが鳴ったら対応する」といった、終わりが定義しにくい継続業務に適しています。月額固定でエンジニアの稼働や対応体制を確保する形が一般的です。
一方、請負契約は「成果物の完成」に対して対価を支払う契約で、完成責任と契約不適合責任を負います。監視基盤の構築や監視ツールの初期セットアップなど、「納品物が明確に定義できる作業」に向いています。保守監視の発注では、初期の監視環境構築は請負、その後の継続的な監視・対応は準委任、といったように業務フェーズで契約を分けるのが実務的です。
RACIで責任分界点を明文化する
契約形態を決めたら、業務ごとの責任分界点を明確にします。ここで有効なのがRACIマトリクスです。RACIとは、各タスクについて実行責任（Responsible）、説明責任（Accountable）、相談先（Consulted）、報告先（Informed）の4つの役割を割り当てて整理する手法で、「この作業は自社とベンダーのどちらが、どこまで責任を持つのか」を一覧で可視化できます。
RACIが特に効果を発揮するのが、クラウド基盤・SaaS・監視ツール・MSPが複数絡むマルチベンダー環境です。障害が起きたとき「基盤の障害なのか、設定ミスなのか、アプリの不具合なのか」で各社が責任を押し付け合う事態は珍しくありません。発注の段階でRACIとSLAのグレーゾーンの扱いを取り決めておけば、障害時に切り分けと一次対応の責任者が明確になり、復旧までの時間を短縮できます。
料金体系や規模別の費用感とあわせて契約形態を検討したい場合は、ITシステム保守監視の費用相場を解説した記事も参考にしてください。月額固定と従量課金の違い、サーバー台数別の月額目安、内製の隠れコストとの比較を具体的に扱っています。
発注で失敗しないための実務ポイント
保守監視の発注は、契約して終わりではありません。むしろ契約後の付き合い方や、想定外の事態への備えが、長期的な運用品質を左右します。ここでは、丸投げ依存を避ける視点と、ベンダーが期待外れだった場合のリカバリーという、見落とされがちな2つのポイントを解説します。
丸投げ依存とベンダーロックインを避ける設計
発注のメリットは大きい一方で、すべてを外部に任せきると「社内に誰も運用がわからない」状態に陥り、特定ベンダーから抜け出せなくなるベンダーロックインのリスクがあります。これを避けるには、発注の段階から「ナレッジを自社にも蓄積する仕組み」を契約に組み込むことが有効です。
具体的には、運用手順書（プレイブック）やインシデント対応履歴を自社も閲覧・保管できる形で共有してもらう、定例レビュー会に自社担当者が参加して運用の中身を理解する、といった取り決めです。将来的に運用を自社へ引き戻す「内製化（リパトリエーション）」を見据えるなら、ベンダーから社内へのナレッジ逆移管の手順や並走期間も、契約交渉の段階で握っておくと安全です。発注はゴールではなく、いつでも主導権を取り戻せる状態を保つことが理想です。
「ハズレ」を引いた場合の乗り換えに備える
どれだけ慎重に選定しても、契約後に「対応が遅い」「報告が形骸化している」といった不満が出ることはあります。そうした場合に業務を止めずに乗り換えられるよう、発注時点で出口戦略を契約に含めておくことが賢明です。具体的には、契約期間と更新条件、解約予告期間、解約時のデータ・運用ドキュメントの返還義務を明記しておきます。
特に重要なのが、解約時に運用ドキュメントや監視設定を引き継げる形で返してもらう条項です。これがないと、別ベンダーへの乗り換え時に運用情報がブラックボックスのまま失われ、移行に膨大な工数がかかります。発注の段階では「うまくいかなかった場合」を想定しにくいものですが、出口を確保しておくことが、結果的に発注者の交渉力を高め、ベンダーに緊張感を持たせることにもつながります。
発注先の比較検討を本格的に進める際は、ITシステム保守監視のおすすめ会社を比較した記事もあわせてご覧ください。対応範囲・SLA・セキュリティ認証・自動化率といった軸で各社を整理しており、選定の判断材料になります。網羅的に全体像を把握したい場合はITシステム保守監視の完全ガイドもおすすめです。
まとめ
ITシステム保守監視の発注・外注を成功させる鍵は、契約前の準備にあります。まず現状を棚卸しして委託範囲（フル委託かセレクティブ委託か）を明確にし、監視対象・対応時間・SLA・セキュリティ要件を盛り込んだRFPで複数社を同じ条件で比較する。これが失敗を防ぐ土台になります。
そのうえで、SLA・KPIで品質を数値化し、ISMS等の認証でセキュリティ体制を確認し、業務フェーズに応じて準委任と請負を使い分け、RACIで責任分界点を明文化する。さらに、丸投げ依存を避けるナレッジ蓄積の仕組みと、万一に備えた乗り換えの出口戦略まで契約に織り込んでおけば、発注後も主導権を保ったまま安定した運用を実現できます。
「夜間・休日の対応疲れ」「ひとり情シスの限界」を解消しつつ、ブラックボックス化や責任の押し付け合いといったリスクを抑えるには、本記事で紹介した発注の段取りを一つずつ押さえることが近道です。自社の状況に合った委託範囲と契約の形を見極め、納得のいく発注を進めてください。
株式会社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を創業。