ITシステムの監視対応をベンダーへ委託しようとするとき、最初の関門になるのがRFP（提案依頼書）や要件定義書の作成です。「何を・どのくらいの水準で監視し、障害時にどう動いてほしいか」を発注者側が言語化できていないと、各社から返ってくる提案の前提がばらばらになり、見積もりの比較すらできません。逆に、監視項目・閾値・SLA（サービス品質保証）といった要件を数値で固めておけば、提案の質が上がり、後の認識ずれや追加費用のトラブルも防げます。
本記事は、ITシステム監視対応のRFP・要件定義書・提案依頼書の書き方を、発注企業の視点から具体的に解説する「要件定義特化」の内容です。監視項目と閾値の決め方、稼働率・初報応答・復旧時間といったSLAの数値要件、クラウドの責任共有を前提にした範囲定義、監視ツールの選定基準、そして「安すぎる見積もり」を生む隠れコストの潰し方まで、一次データを交えて掘り下げます。読み終えるころには、自社のRFPに盛り込むべき項目が具体的に見えるはずです。なお、監視対応の全体像をまだ把握していない方は、まずITシステム監視対応の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム監視対応の完全ガイド
監視項目と閾値の要件定義
RFPの土台になるのが、「何を監視するか」という監視項目の定義です。ここが曖昧だと、ベンダーは標準的な項目だけを提案し、自社固有の重要なポイントが監視対象から漏れます。監視項目は、対象システムの構成要素を洗い出し、それぞれについて「何を・どの間隔で・どの閾値で監視するか」まで具体化するのが理想です。要件定義書では、この監視項目一覧と閾値の表が、提案各社が共通の前提で見積もるための基準になります。
監視対象の洗い出しと優先度付け
監視対象の洗い出しでは、システムを構成するサーバー、データベース、ネットワーク機器、外部API、クラウドリソースなどを網羅的にリストアップします。このとき重要なのが、すべてを同じ重みで扱わないことです。事業に直結する基幹システムと、停止しても影響の小さい社内ツールでは、求める監視水準が異なります。RFPでは、監視対象を重要度でランク分けし、ランクごとに監視の手厚さを変える方針を示すと、ベンダーがメリハリのある提案をしやすくなります。
優先度付けの根拠になるのが、事業影響度のアセスメントです。「この業務が止まると、誰がどれだけ困り、いくらの損失が出るか」を整理しておくと、監視水準の妥当性を社内でも説明できます。一次データのダウンタイム損失統計では、金融・医療・EC系で5分以上の停止が1回あたり平均1,200万円の機会損失とされており、こうした数字を自社の業務に当てはめれば、どこに監視リソースを集中させるべきかが見えます。監視項目の要件定義は、技術項目の列挙ではなく、事業影響度からの逆算で組み立てるのが本質です。
閾値と通知レベルの設計をRFPに明記する
監視項目を決めたら、各項目の閾値を設計します。CPU使用率なら何%で警告・何%で重大、ディスク残量なら何%で通知、レスポンスタイムなら何秒で異常、といった具体的な数値です。閾値はシステムの特性によって適正値が異なるため、RFPでは自社の希望値を示しつつ、ベンダーの知見で調整する余地も残すと建設的です。閾値が緩すぎると手遅れになり、厳しすぎるとアラートが鳴りやまず形骸化するため、ここの設計品質が運用の実効性を左右します。
あわせて定義すべきが、閾値超過時の通知レベルです。同じ異常でも「警告レベルはチャット通知のみ」「重大レベルは電話で即時連絡」というように、レベルと通知手段・通知先を紐づけておきます。これをRFPに明記しておくと、ベンダーはアラート対応の体制を具体的に提案でき、見積もりにも反映されます。監視項目・閾値・通知レベルの三点を表形式で整理した要件定義書は、提案各社を同じ土俵で比較するための、もっとも強力な共通言語になります。
SLAの数値要件（稼働率・初報応答・復旧時間）
監視対応のRFPで核心になるのが、SLA（サービス品質保証）の数値要件です。稼働率、初報応答時間、復旧時間といった指標をどの水準で求めるかが、提案内容と費用を大きく左右します。SLAを曖昧にしたまま委託すると、「障害には対応します」という抽象的な約束だけで、いざというとき期待した速度で動いてもらえません。RFPでは、これらを具体的な数値で定義し、未達時の扱いまで踏み込んで記載することが重要です。
稼働率の要件と許容ダウンタイムの考え方
稼働率は、システムが正常に動いている時間の割合です。RFPで稼働率を定義するときは、その数値が許容するダウンタイムを正しく理解しておく必要があります。一次データによれば、稼働率99.9%なら年間で許容される停止は約8.76時間（月43.8分）、99.99%なら年間52.6分（月4.38分）です。この差は大きく、「9」が一つ増えるごとに運用コストは段階的に跳ね上がります。冗長構成や即時切替が必要になるためです。
だからこそ、RFPで稼働率を定義する前に「自社に本当に必要な稼働率はいくつか」を見極めることが重要です。すべてのシステムに99.99%を求めると、コストが過大になります。基幹の決済システムには高い稼働率を、社内の情報共有ツールには現実的な水準を、というように、システムの重要度に応じて稼働率要件を出し分けるのが賢明です。要件定義書には、システムごとに目標稼働率と許容ダウンタイムを明記し、その根拠となる事業影響度も併記しておくと、提案各社が過不足のない構成を提案できます。
初報応答時間と復旧目標時間の定義
稼働率と並んで重要なのが、障害発生時の応答と復旧の時間要件です。初報応答時間は「障害を検知してから、ベンダーが状況を一次連絡するまで」の時間、復旧目標時間は「障害を解消するまで」の時間です。一次データでは、官公庁の仕様例として1時間以内に現地到着・対処開始、1時間以内に内容と予想作業時間を報告、原則4時間以内に完全復旧という具体例が示されています。Cloud Naviでは重大なissueへの15分以内の一次対応保証という例もあり、こうした水準を自社の要件として落とし込みます。
RFPでは、これらの応答・復旧時間を障害レベルごとに定義するのが効果的です。重大障害は2時間以内に対応開始・24時間以内に完全解決、軽微な障害は翌営業日対応、というように段階を設けます。あわせて、SLA未達時の扱い（サービスクレジットや報告義務など）も記載しておくと、ベンダーの本気度を引き出せます。ただし過剰な要件は費用に跳ね返るため、現実的な水準と費用のバランスを取ることが、要件定義の腕の見せどころです。
クラウド責任共有を前提にした範囲定義
現代の監視対応RFPで欠かせない視点が、クラウドの責任共有モデルを前提にした範囲定義です。国内エンタープライズ・システム市場のクラウド比率は2022年で約5割（IDC Japan）に達しており、多くのシステムがクラウド上で動いています。クラウドでは、基盤側はクラウド事業者が、その上に乗せたアプリやデータは利用者が責任を持つという分担があります。この境界を理解しないまま委託範囲を決めると、監視や対応に穴ができます。
責任分界点を要件定義書で明確にする
RFPでは、クラウド基盤・ミドルウェア・アプリ・データの各層について、「どこをクラウド事業者が、どこを監視委託先が、どこを自社が見るのか」という責任分界点を明確に定義します。たとえば、仮想マシンのハードウェア障害はクラウド事業者の責任ですが、その上のOSやアプリの異常は利用者側の責任です。この分界を要件定義書に図示しておくと、各層の監視・対応の抜け漏れを防げ、ベンダーも担当範囲を正確に見積もれます。
注意すべきは、クラウド基盤の障害は利用者側では手出しができないという点です。基盤障害が起きても、利用者にできるのは事業者の復旧を待つことと、自社のユーザーへ状況を告知することくらいです。RFPでは、クラウド基盤障害時に委託先が何をするのか（状況把握・告知支援・代替手段の検討など）を定義しておくと、いざというときの動きが明確になります。責任共有の境界を踏まえた範囲定義こそ、クラウド時代の監視RFPの要諦です。
監視ツールの選定基準を要件に含める
監視ツールの方針も、RFPで触れておくべき要件です。OSSのZabbixはライセンス無料ですが、構築・維持に工数がかかります。クラウド型のDatadogやNew Relicは、ホスト数やメトリクス量に応じた従量課金で、中規模なら月数万〜数十万円という水準です。サーバー監視に特化したMackerelのような選択肢もあります。自社で運用するのか、委託先のツールに乗るのか、既存ツールを活かすのかを、RFPで方針として示すと提案がぶれません。
ツール選定で見落としがちなのが、ライセンス費用の従量制によるコスト変動です。クラウド型ツールは監視対象が増えると費用も比例して増えるため、将来の拡張を見込んだ試算が必要です。RFPでは「どのツールを使うか」を固定せず、「自社の規模・拡張計画・既存資産を踏まえて最適なツールを提案してほしい」と問う形にすると、ベンダーの知見を引き出せます。ツール選定基準を要件に含めることで、初期費用だけでなくランニングコストまで見据えた提案を比較できます。
隠れコストを潰す対応範囲の定義
監視対応のRFPで最後に詰めるべきが、対応範囲の定義による隠れコストの抑制です。基本料金に何が含まれ、何が追加費用になるのかが曖昧だと、契約後に「それは別料金です」という想定外の請求が続発します。要件定義書で対応範囲を細かく定義しておくことが、こうした隠れコストを未然に潰す最良の方法です。安く見える見積もりほど、範囲が狭く設定されている可能性に注意が必要です。
基本料金に含む範囲と追加費用の線引き
対応範囲の定義では、監視・一次対応・原因調査・パッチ適用・バックアップ・復旧といった各工程について、基本料金に含むものと追加費用になるものの線引きを明記します。一次データでは、運用・監視は月5万〜20万円、障害対応は営業時間内で月3万〜8万円、24時間緊急で月10万〜20万円、スポット1件で3万〜10万円という料金感があります。これらの内訳を踏まえ、自社が求める工程が基本料金に含まれているかをRFPで問うことが、追加費用の予防になります。
特に注意すべきが、月の工数上限です。月額固定型の契約では「月◯時間まで」という上限が設定されていることが多く、それを超えると追加費用が発生します。障害が多発した月に、想定外の超過費用が請求されるリスクがあります。RFPでは、月の工数上限と超過時の単価、そして上限を超えそうな場合の事前通知ルールまで定義しておくと、コストの予見性が高まります。対応範囲と工数上限の明確化が、安すぎる見積もりに潜む隠れコストを浮かび上がらせます。
契約形態と引き継ぎ要件を盛り込む
RFPには、契約形態の希望も盛り込みます。月額固定型は予算が読みやすい一方、障害ゼロの月の待機費が無駄に感じられます。実働・従量課金型は使った分だけの支払いですが、障害多発月は費用が膨らみます。稼働量に波がある中小企業では、この選び分けが重要です。RFPで「どちらの契約形態を想定しているか」「余剰工数を改善作業に充てる充填型保守は可能か」を問うておくと、自社の事情に合った提案を引き出せます。
最後に忘れてはならないのが、将来のベンダー切り替えを見据えた引き継ぎ要件です。解約予告の期間、運用ドキュメントやアカウント・監視設定の引き渡し、ソースコードの取り扱いなどを、契約段階で要件として定義しておきます。これを怠ると、いざ切り替えたいときに情報が抱え込まれ、身動きが取れなくなります。riplaはフルスクラッチ受託と国内運用保守の立場から、対応範囲・契約形態・引き継ぎまで透明に定義したRFPづくりを重視しています。隠れコストを潰す範囲定義こそ、健全な委託関係の出発点です。
まとめ
ITシステム監視対応のRFP・要件定義書は、監視項目と閾値を事業影響度から逆算して定義し、稼働率・初報応答・復旧時間といったSLAを障害レベルごとに数値化し、クラウドの責任共有を前提に範囲を区切り、対応範囲と工数上限の明確化で隠れコストを潰す、という流れで組み立てます。稼働率99.9%なら年8.76時間、99.99%なら年52.6分という許容停止の差や、官公庁仕様の1時間以内対処・4時間以内復旧といった一次データを基準に、自社に見合った水準を見極めることが要点です。
RFPを書くときに大切なのは、「立派な要件」を並べることではなく、自社の事業影響度と予算に見合った現実的な要件を、数値で明確に定義することです。曖昧さを残さないRFPは、提案の質を上げ、比較を可能にし、契約後のトラブルを防ぎます。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、監視項目・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を創業。