ITシステムの性能監視をベンダーに委託したり、監視基盤を構築したりするとき、成否を分けるのは「要件定義書やRFP（提案依頼書）で、何を・どの水準で監視するかをどれだけ具体的に書けるか」です。性能監視の要件が曖昧なまま発注すると、いざ運用が始まってから「測りたかった指標が監視されていない」「アラートの基準が決まっておらず誰も対応しない」「契約範囲外の作業に追加費用を請求された」といったトラブルが続出します。逆に、監視項目・閾値・SLA・責任分界を数値で明文化できれば、相見積もりの比較も容易になり、隠れコストも潰せます。
本記事は、ITシステム性能監視のRFP・要件定義書・提案依頼書に何を盛り込むべきかを、発注企業（情シス）の視点で整理する「要件定義特化」の解説です。監視項目と閾値の数値要件、SLA（稼働率・初報応答・復旧時間）の定義、クラウドの責任共有モデルを前提とした責任分界、監視ツール選定基準と対応範囲の明文化までを、一次データの数値とあわせて具体的に解説します。なお、性能監視の全体像をまだ把握していない方は、まずITシステム性能監視の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム性能監視の完全ガイド
監視項目と閾値の数値要件を定義する
性能監視の要件定義で最初に固めるべきは、「何を監視するか（監視項目）」と「どの値で異常とみなすか（閾値）」です。ここが曖昧だと、ベンダーは最低限の死活監視だけで「監視しています」と主張でき、肝心の性能劣化を見逃す契約になりかねません。RFPには、対象システムごとに監視すべきメトリクスと、警告・重大の二段階以上の閾値を、できる限り数値で書き込むことが重要です。
監視対象メトリクスと収集間隔を明記する
RFPには、CPU使用率・メモリ使用量・ディスクI/Oと空き容量・ネットワーク帯域といったリソース指標に加え、レスポンスタイム・スループット・エラー率・データベースのスロークエリといったアプリケーション指標まで、監視対象を列挙します。あわせて、各指標の収集間隔（例：1分間隔か5分間隔か）と、データの保持期間も明記しておきます。収集間隔が粗いと短時間のスパイクを取り逃すため、システムの重要度に応じて要求水準を変えるとよいでしょう。
この監視項目の網羅性が、後の運用品質を大きく左右します。たとえば死活監視だけを依頼していると、「サーバーは生きているがレスポンスは極端に遅い」という劣化状態を検知できません。要件定義の段階で、リソース・レスポンス・アプリ内部・ログまでを含む多層の監視を求めるか、どこまでを範囲とするかを意識的に決めることが、後の「見えていなかった」という後悔を防ぎます。監視項目の表をRFPに添付し、ベンダーに対応可否を回答させると、比較が明確になります。
閾値とアラート時のアクションを定義する
監視項目を決めたら、各項目に警告・重大といった段階別の閾値を設定します。CPU使用率80%で警告・95%で重大、平均レスポンス3秒超で警告・5秒超で重大、といった具合です。さらに重要なのは、閾値を超えたときに「誰が・何をするか」というアクションをセットで定義することです。アラートが鳴っても対応手順が決まっていなければ、監視は意味をなしません。
RFPには、各閾値に対する一次対応の内容（自動再起動、担当者通知、エスカレーションなど）と、その対応をベンダーが担うのか自社が担うのかを明記します。これを曖昧にすると、障害時に「それは契約範囲外です」と突き返され、対応が空白になる事態が起きます。閾値とアクションを一体で要件化することが、検知を確実に解決へつなげる前提です。閾値はシステム特性に応じて運用しながら調整するものなので、定期的な閾値見直しを契約に含めるかも検討しておきましょう。
SLA(稼働率・初報応答・復旧時間)を数値で定義する
性能監視の要件定義で、監視項目と並んで重要なのがSLA（サービスレベル合意）です。稼働率、障害発生時の初報応答時間、復旧目標時間を数値で定義することで、ベンダーに求める品質と、それに見合う費用が明確になります。SLAは費用に直結するため、過剰でも過少でもなく、システムの事業影響度に見合った水準を要件に落とし込むことが肝心です。
稼働率99.9%と99.99%の違いを理解して定義する
稼働率は「9」の数で許容ダウンタイムが大きく変わります。一次データによれば、稼働率99.9%は年間約8.76時間・月約43.8分・日約7.3分の停止が許容範囲、99.99%は年間約52.6分・月約4.38分・日約4.4秒となります。この差は単なる数字以上で、「9」が1つ増えるごとに運用コストは段階的に跳ね上がります。99.99%を実現するには冗長構成や即応体制が必要になり、費用が大きく膨らむのです。
だからこそ、要件定義では「とりあえず高い稼働率」を求めるのではなく、システムが止まったときの事業影響度から逆算して水準を決めるべきです。基幹システムや顧客向けサービスは高い稼働率を、社内向けの補助システムは現実的な水準を、というメリハリが重要です。RFPには、対象システムごとに要求稼働率を明記し、その根拠となる事業影響度の評価もあわせて共有すると、ベンダーから過不足のない提案を引き出せます。過剰SLAは無駄なコストを生むため、社内のビジネス部門と要求水準を事前合意しておくことが望まれます。
初報応答時間と復旧目標時間を明記する
稼働率と並んで定義すべきが、障害発生時の応答・復旧に関する時間要件です。一次データの官公庁仕様例では、1時間以内に現地到着・対処開始、1時間以内に障害内容と予想作業時間を報告、原則4時間以内に完全復旧、といった水準が示されています。また、Cloud Naviでは重大インシデントについて15分以内の一次対応を保証、あるシーズホスティングでは検知から60分以内に通知し12時間で復旧、といった例があります。一般目標としては重大障害2時間以内に対応開始・完全解決24時間以内が一つの目安です。
RFPには、これらを参考に「初報（一次対応・状況報告）まで何分以内」「完全復旧まで何時間以内」を、重大度別に数値で要求します。あわせて、SLA未達時のサービスクレジット（料金の一部返還）や、損害賠償の上限・免責条項についても確認しておくべきです。多くの契約では間接損害（機会損失など）は免責とされるため、稼働率の数値だけでなく、未達時に何が補償され何が補償されないかまでを要件・契約で押さえることが、後のリスク管理につながります。
クラウド責任共有を前提に責任分界を定義する
今や国内エンタープライズ・システムのクラウド比率は2022年時点で約5割（IDC Japan）に達しています。クラウド前提のシステムでは、性能監視の要件定義に「責任共有モデル」の視点が欠かせません。クラウド基盤側の障害はユーザーが手出しできず、サービスクレジット以上の補償は受けられないことが多いため、どこまでが自社・ベンダーの責任で、どこからがクラウド事業者の領域かを明確に線引きする必要があります。
監視の責任分界点を契約で明確にする
クラウド環境では、物理サーバーやネットワーク基盤はクラウド事業者が、その上で動くOS・ミドルウェア・アプリケーションは利用者側が責任を持つ、という分担が基本です。性能監視の要件定義では、この分界点を踏まえ、「アプリケーション層のレスポンスは委託先が監視」「クラウド基盤の障害情報は事業者のステータスページを参照」といった役割を明文化します。分界が曖昧だと、障害時に責任のなすり合いが起き、復旧が遅れます。
とくに注意したいのが、クラウド基盤の障害は利用者側で復旧できないという「監視のブラックボックス化」です。基盤が落ちれば、いくら自社が監視していても手出しできず、サービスクレジットによる料金返還以上の補償は望めません。要件定義では、こうした基盤障害に備えたマルチリージョン構成やフェイルオーバーといったアーキテクチャ上の自衛策を盛り込むか、どこまで許容するかを事業影響度から判断します。クラウドの便利さの裏にある「自分では直せない領域」を理解した上で要件を組むことが重要です。
発注者側の初動・報告フローも要件に含める
性能監視の要件定義というと、ベンダーに求める監視内容ばかりに目が向きがちですが、発注者（情シス）側の動きも要件に含めるべきです。ベンダーから障害の初報を受けた後、社内の経営層や業務部門へどう状況を報告し、いつエスカレーションするか、という発注者側のフローを決めておかないと、いざというとき情シスが立ち往生します。監視はベンダーに丸投げできても、社内への説明責任は自社に残るからです。
具体的には、障害レベルごとの社内報告ルート、BCP（事業継続計画）との連動、重大障害時の意思決定者を要件・運用設計に盛り込みます。性能劣化が事業に波及しそうなときに、誰が業務停止やサービス縮退の判断をするかまで決めておけば、混乱を最小化できます。riplaはフルスクラッチ受託と国内運用保守の立場から、ベンダー側の監視だけでなく、発注者側の初動・報告フローまで含めた要件整理を支援しています。監視の要件定義は、ベンダーと自社の両方の動きを一体で設計することで完成します。
監視ツール選定基準と対応範囲を明文化する
性能監視のRFPでは、どの監視ツールを使うか、そして委託先の対応範囲がどこまでかを明文化することで、隠れコストを潰せます。「安すぎる見積もり」の裏には、監視欠如や対応範囲の狭さ、工数上限の設定が潜んでいることが少なくありません。ツール選定基準と範囲定義を要件で固めることが、後の追加費用トラブルを防ぐ鍵になります。
OSS型とSaaS型の選定基準を整理する
監視ツールの選定では、OSS型とSaaS型のどちらを前提とするかを要件で示すと、提案の方向性が定まります。OSSのZabbixはライセンスが無料ですが、自社運用では構築・維持の工数がかかります。一方、DatadogやNew Relicといったクラウド型SaaSは、ホスト数やメトリクス量に応じた従量課金で、中規模なら月数万〜数十万円が目安です。サーバー監視に強いMackerelのような選択肢もあります。
選定基準として、対応OS・ミドルウェア、クラウド環境への対応、APMやログ監視の有無、アラート連携先（チャット・電話）などを要件に列挙し、ベンダーに適合性を回答させます。費用面では、ツールのライセンス・利用料と運用人件費を分けて見積もらせると、トータルコストの比較がしやすくなります。ツールの機能だけでなく、それを使いこなす運用力までを含めて評価することが、見かけの安さに惑わされない選定につながります。
対応範囲と工数上限で隠れコストを潰す
要件定義でもっとも見落とされやすいのが、監視結果を受けた後の「対応範囲」の定義です。性能劣化を検知した後、一次対応までを委託に含むのか、原因調査やチューニングまで含むのか、それとも検知して通知するだけなのかで、費用も価値も大きく変わります。一次データでは、運用・監視の費用相場は月5万〜20万円程度、障害対応は営業時間内で月3万〜8万円、24時間緊急対応で月10万〜20万円、スポット1件で3万〜10万円といった水準が示されています。
RFPには、これらの作業区分ごとに、月額に含む範囲と、超過した場合の追加費用（人月単価は業界一般で60万〜150万円、監視オペレーター60万〜80万円、運用設計・インシデント分析80万〜120万円が目安）を明確にさせます。工数上限が設定されている場合は、上限を超えた際の扱いも確認しておくべきです。安すぎる見積もりは、対応範囲が「通知のみ」で実作業が別料金、というケースが典型です。対応範囲を要件で具体化し、見積もりを同じ土俵で比較することが、隠れコストを潰す最良の方法です。
まとめ
ITシステム性能監視のRFP・要件定義書を振り返ると、押さえるべき柱は4つに集約されます。第一に監視項目と段階別閾値、そして閾値超過時のアクションを数値で定義すること。第二にSLA（稼働率99.9%か99.99%か、初報応答・復旧目標時間）を事業影響度から逆算して定めること。第三にクラウドの責任共有を前提に責任分界点と発注者側の初動・報告フローを明確にすること。第四に監視ツール選定基準と対応範囲を明文化し、安すぎる見積もりに潜む隠れコストを潰すことです。
要件定義で大切なのは、「ベンダーにお任せ」ではなく、自社が守りたいものを数値と範囲で具体的に示すことです。監視項目・閾値・SLA・対応範囲を明確にできれば、相見積もりの比較も容易になり、運用開始後の「測れていなかった」「範囲外だった」というトラブルを未然に防げます。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、性能監視の要件整理から運用設計、発注者側のフロー作りまで一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。