保守監視の発注は、委託範囲を決めて現状を棚卸しし、RFPで複数社を同じ条件で比べたうえで、SLA・KPIやセキュリティ要件、契約形態を詰めていく流れで進みます。
段取りを誤って要件が曖昧なまま契約すると、追加費用やブラックボックス化、責任の押し付け合いといったトラブルに発展します。
- フル委託とセレクティブ委託、発注先の種類
- 現状棚卸し、RFP、複数社比較と並走期間
- SLA・KPIとISMSなどのセキュリティ要件
- 契約形態、RACI、丸投げと乗り換えの回避
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
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が曖昧だと、各社が前提条件を勝手に解釈してしまい、見積もりの比較が成り立たなくなります。
監視委託の条件をそろえて比べられるよう、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）の役割を割り当てて整理する手法です。RACIでは、「この作業は自社とベンダーのどちらが、どこまで責任を持つのか」を一覧で示せます。
RACIが特に効果を発揮するのは、クラウド基盤やSaaS、監視ツール、MSPが複数絡むマルチベンダー環境です。障害が起きたとき、基盤の障害なのか、設定ミスなのか、アプリの不具合なのかで、各社が責任を押し付け合う事態は珍しくありません。そこで、発注の段階でRACIとSLAのグレーゾーンの扱いを取り決めておけば、障害時に切り分けと一次対応の責任者が明確になり、復旧までの時間を短縮できます。
料金体系や規模別の費用感とあわせて契約形態を検討したい場合は、ITシステム保守監視の費用相場を解説した記事も参考にしてください。月額固定と従量課金の違い、サーバー台数別の月額目安、内製の隠れコストとの比較を具体的に扱っています。
発注で失敗しないための実務ポイント
保守監視の発注は、契約して終わりではありません。むしろ契約後の付き合い方や、想定外の事態への備えが、長期的な運用品質を左右します。見落とされがちなのは、丸投げ依存を避ける視点と、期待外れだった場合のリカバリーの2つです。
丸投げ依存とベンダーロックインを避ける設計
発注のメリットは大きい一方で、すべてを外部に任せきると「社内に誰も運用がわからない」状態に陥り、特定ベンダーから抜け出せなくなる「ベンダーロックイン」のリスクがあります。これを避けるには、発注の段階から「ナレッジを自社にも蓄積する仕組み」を契約に組み込むことが有効です。
具体的には、運用手順書（プレイブック）やインシデント対応履歴を自社も閲覧・保管できる形で共有してもらう、定例レビュー会に自社担当者が参加して運用の中身を理解する、といった取り決めです。また、将来的に運用を自社へ引き戻す「内製化（リパトリエーション）」を見据えるなら、ベンダーから社内へのナレッジ逆移管の手順や並走期間も、契約交渉の段階で決めておくと安全です。
発注後も、いつでも主導権を取り戻せる状態を保つことが理想です。
「ハズレ」を引いた場合の乗り換えへの備え
どれだけ慎重に選定しても、契約後に「対応が遅い」「報告が形骸化している」といった不満が出ることはあります。そうした場合に業務を止めずに乗り換えられるよう、あらかじめ出口戦略を契約に含めておくことが賢明です。発注の段階では「うまくいかなかった場合」を想定しにくいものですが、出口の確保は、発注者の交渉力を高め、ベンダーに緊張感を持たせることにもつながります。
具体的には、契約期間と更新条件、解約予告期間、解約時のデータ・運用ドキュメントの返還義務を明記しておきます。特に重要なのは、解約時に運用ドキュメントや監視設定を引き継げる形で返してもらう条項です。これがないと、別ベンダーへの乗り換え時に運用情報がブラックボックスのまま失われ、移行に膨大な工数がかかります。
発注先の比較検討を本格的に進める際は、ITシステム保守監視のおすすめ会社を比較した記事もあわせてご覧ください。対応範囲やSLA、セキュリティ認証、自動化率といった観点で各社を整理しており、選定の判断材料になります。網羅的に全体像を把握したい場合はITシステム保守監視の完全ガイドもおすすめです。
まとめ
ITシステム保守監視の発注・外注を成功させる鍵は、契約前の準備にあります。まず現状を棚卸しして委託範囲（フル委託かセレクティブ委託か）を明確にし、監視対象と対応時間、SLA、セキュリティ要件を盛り込んだRFPで複数社を同じ条件で比べます。これが、失敗を防ぐ土台になります。
そのうえで、SLA・KPIで品質を数字で定め、ISMS等の認証でセキュリティ体制を確かめます。業務フェーズに応じて準委任と請負を使い分け、RACIで、どこまでを自社とベンダーのどちらが受け持つかを明らかにしておきます。
発注者が、丸投げ依存を避けるためのナレッジ蓄積の仕組みと、万一に備えた乗り換えの出口戦略まで契約に織り込んでおけば、発注後も主導権を保ったまま安定した運用を実現できます。
夜間・休日の対応疲れやひとり情シスの限界を解消しつつ、ブラックボックス化や責任の押し付け合いといったリスクを抑えるには、本記事で紹介した発注の段取りを一つずつ押さえることが近道です。
自社の状況に合った委託範囲と契約の形を見極め、納得のいく発注を進めてください。
▼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を創業。