ITシステム原因調査のRFP/要件定義書/提案依頼書について

ITシステムの原因調査や障害対応を外部に委託する際、見積もりの妥当性や対応品質を左右するのが、発注側が用意するRFP（提案依頼書）や要件定義書の精度です。「障害が起きたら対応してほしい」という曖昧な依頼では、ベンダーごとに前提がバラバラの見積もりが返ってきて、比較も判断もできません。原因調査の範囲、応答・復旧の時間要件、対象とするログや監視項目を数値で定義してこそ、各社を同じ土俵で比べられます。

本記事は、ITシステム原因調査を委託するためのRFP・要件定義書の書き方を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。調査範囲と責任分界点の定義、応答・復旧時間とSLAの数値要件、ログ・監視項目と調査基盤の要件、隠れコストを潰す契約・体制要件まで、リサーチで得たSLA実値や費用相場とあわせて掘り下げます。なお、原因調査の全体像をまだ把握していない方は、まずITシステム原因調査の完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・ITシステム原因調査の完全ガイド

調査範囲と責任分界点を定義する要件

RFPでまず明確にすべきは、原因調査としてどこからどこまでを委託するかという範囲と、どちらが何の責任を負うかという責任分界点です。ここが曖昧だと、障害発生時に「それは契約範囲外です」というすれ違いが起き、肝心なときに調査が止まります。範囲と分界点の二つを、工程と層の観点から定義します。

原因調査の範囲は、検知・一次切り分け・原因特定・暫定対策・恒久対策という工程ごとに、どこまでを委託するかを明記します。たとえば「一次切り分けと原因特定まではベンダー、恒久対策の実装は別途見積もり」のように、工程の境界を数値や具体例で示すのです。範囲を曖昧にすると、ベンダーは安全側に狭く見積もり、いざ恒久対策が必要になったときに高額な追加費用を請求される、という事態を招きます。

費用の目安として、障害対応は営業時間内なら月3万〜8万円、24時間緊急対応なら月10万〜20万円、スポット1件なら3万〜10万円です。範囲を明記すれば、この相場のどこに位置する見積もりなのかを判断できます。月額の固定費にどの工程まで含むのかを、RFPの段階で工程表として提示することが、後の認識齟齬を防ぐ最良の方法です。工程ごとに成果物（調査報告書・恒久対策の設計書など）を明記しておくと、各工程が完了したかどうかを客観的に判定でき、対価の妥当性も評価しやすくなります。

クラウド基盤を使っている場合、責任分界点の定義はさらに重要です。クラウドの責任共有モデルでは、基盤そのものの障害はクラウド事業者の責任で、利用者側は手出しできません。RFPでは「クラウド基盤に起因する障害はどう扱うか」「事業者からの情報をどう収集し報告するか」を明記し、調査範囲の境界を引く必要があります。国内エンタープライズ市場のクラウド比率は2022年時点で約5割（IDC Japan）に達しており、この前提整理は多くの企業に必須です。

責任分界点を引く際は、アプリケーション層・ミドルウェア層・OS層・基盤層のどこまでをベンダーが調査し、どこからがクラウド事業者の領域かを層ごとに整理します。この切り分けがないと、基盤障害なのに自社ベンダーに原因を追わせて時間を浪費する、といった非効率が起きます。範囲と分界点の明確な定義は、原因調査RFPの土台であり、ここを曖昧にしたまま発注すると後悔します。

実際の現場では、開発元・インフラ事業者・ネットワーク事業者・パッケージ提供元など、複数のベンダーが一つのシステムに関わっていることが珍しくありません。障害が起きたとき、それぞれが「うちの領域ではない」と主張し合うと、原因調査が宙に浮き、復旧が大幅に遅れます。RFPでは、複数ベンダーが絡む障害で「誰が全体の調整役を担い、各社の調査を取りまとめるか」という役割を要件として定義しておくことが重要です。調整役が不在のまま発注すると、障害時に発注側が各社の板挟みになります。

この調整役には、システム全体の構成を把握し、各層の切り分けを主導できる立場のベンダーが適しています。RFPに「他ベンダーとの連携・情報連携の手順」「障害時の合同対応の進め方」を要件として書き込めば、各社が責任を押し付け合う事態を防げます。riplaはフルスクラッチ受託の立場からシステム全体の構造を把握しているため、複数ベンダーが絡む障害でも、作った当事者として調査の取りまとめ役を担えます。調整役の要件は、マルチベンダー環境での原因調査を空転させないための、見落とせない契約項目です。

応答・復旧時間とSLAの数値要件

原因調査RFPの核となるのが、応答時間・復旧時間・稼働率といったSLA（サービス品質保証）の数値要件です。これらを具体的な数字で定義することで、提案の質を客観的に比較できます。応答・復旧の時間要件と、稼働率の要件という二つの軸で見ていきます。

応答時間の要件は、障害検知から一次対応開始までと、初報の状況報告までを分けて定義します。実例として、官公庁の仕様では「1時間以内に現地到着・対処開始」「1時間以内に内容と予想作業時間を報告」とされ、Cloud Naviは重大インシデントに15分以内の一次対応を保証しています。自社の業務影響に照らし、この水準のどこを求めるかをRFPに数値で書き込みます。重要システムほど短い応答を求めますが、短いほど費用は上がります。

復旧時間の要件も、暫定復旧と完全復旧を分けて定義します。一般的な目標として「重大障害は2時間以内に対応開始、完全解決は24時間以内」、シーズホスティングの例では「検知から60分以内に通知、12時間で復旧」といった水準があります。原因調査の場合、原因特定までの目標と、対策完了までの目標を切り分けて要件化すると、調査の遅延と復旧の遅延を別々に評価できます。数値があってこそ、SLA未達のペナルティも設計できます。

応答・復旧の数値目標を定めたら、それを達成できなかったときの取り扱いを要件として明記します。多くの契約では、SLA未達時にサービスクレジット（保守費の一部減額）が適用されますが、その算定方法や上限が曖昧だと、いざというとき機能しません。RFPの段階で「どの目標を、どの程度下回ったら、いくら減額するか」をベンダーに提示させ、保証型の水準を求めるのか、努力目標型で足りるのかを事業影響度に照らして線引きします。ペナルティの設計まで含めて、初めて数値要件は実効性を持ちます。

あわせて、応答時間や復旧時間をどの時点から計測するかという測定基準も要件化します。障害の検知時刻を起点とするのか、利用者からの報告受付時刻を起点とするのかで、同じ目標値でも実質的な厳しさが変わるためです。月次でSLAの達成状況を報告させる運用を要件に含めておけば、契約後も品質を客観的に監視できます。原因調査は工数が読みにくいだけに、測定基準とペナルティを曖昧にすると、未達かどうかの判定で揉めて形骸化しがちです。ここを数値と起点で明確に固めることが、SLAを絵に描いた餅にしない要点になります。

稼働率の要件は、求める「9」の数で費用が段階的に跳ね上がる点に注意が必要です。稼働率99.9パーセントは年間8.76時間・月43.8分の停止を許容するのに対し、99.99パーセントは年52.6分・月4.38分まで厳しくなります。「9」が一つ増えるごとに運用コストは大きく上昇するため、自社の業務に本当に必要な水準を見極めることが要件定義の腕の見せ所です。

過剰なSLAは無駄な費用を生みます。事業影響度を評価し、「このシステムは月数十分の停止なら許容できる」と判断できれば、99.9パーセントで十分なケースが多くあります。RFPでは、稼働率の要件と、その根拠となる事業影響度の評価を併記すると、ベンダーも適正な提案をしやすくなります。riplaはフルスクラッチ受託の立場から、システムの重要度に応じた適正なSLA設計を一緒に検討し、過剰でも過少でもない要件づくりを支援します。SLAは高ければよいものではなく、事業に見合うことが肝心です。

ログ・監視項目と調査基盤の要件

原因調査の精度は、どのログをどう取得し、何を監視するかという基盤の要件で決まります。調査に必要なデータが残っていなければ、どんな優秀な担当者でも原因にたどり着けません。監視項目と閾値の要件、調査基盤とツールの要件という二つを定義します。

RFPには、監視する項目と、異常と判断する閾値を具体的に列挙します。CPU使用率・メモリ使用率・ディスク残量・レスポンスタイム・エラー率など、調査の手がかりになる指標を網羅し、それぞれ何パーセントや何秒を超えたらアラートを上げるかを数値で定めます。あわせて、ログをどこから・どのくらいの期間保持するかも要件化します。ログの保持期間が短いと、後から原因を追えなくなるためです。

IBMの2024年調査では、データ漏洩の検知まで平均204日かかるとされており、長期のログ保持が原因調査と侵害検知の両面で重要であることが分かります。監視項目と閾値、保持期間を要件として固めておけば、調査に必要なデータが確実に残り、いざというときに過去にさかのぼった分析ができます。「何を見て・何を残すか」の定義が、調査の可否を左右する根幹の要件です。逆に、必要な監視項目やログが取得されていない状態で発注すると、いざ障害が起きても手がかりが残っておらず、調査自体が成立しないという事態を招きます。

調査基盤として、どの監視ツールを使うかの選定基準もRFPに含めます。OSSのZabbixはライセンス無料で柔軟ですが構築・維持に工数がかかり、クラウド型のDatadogやNew Relicはホスト数・メトリクス量に応じた従量課金です。自社が求める対象規模、既存資産との親和性、運用体制に照らして、ツールの要件を整理します。ベンダーが特定ツールに縛られず提案できるよう、満たすべき機能要件を中立的に書くのがコツです。

セキュリティ起因の障害も視野に入れるなら、SIEMのSplunk Cloudや、EDRのCrowdStrike・Microsoft Defender for Endpointといった製品への対応可否も選定基準に加えます。SOC運用を併せて委託する場合、対象台数あたりの料金感（例：CEC SOCは月30万円〜／1,000台、SHIFTのSOC運用支援はシルバーで月9万円〜）も把握しておくと、見積もりの妥当性を判断できます。調査基盤の要件は、原因調査の実効性を担保する重要な項目です。

見落とされがちなのが、ベンダーが原因調査を行うために、発注側が何を提供するかという要件です。ログへのアクセス権限、監視ダッシュボードの閲覧権、検証環境、本番への接続経路など、調査に必要な環境を誰がどう用意するかを定義しないと、いざ調査というときに「権限がなくてログを見られない」という空白が生じます。とくにクラウド環境では、監視情報やアクセスログにベンダーが到達できるかが、切り分けの速さを大きく左右します。提供物の要件を明記することは、調査の実効性の前提です。

一方で、権限の付与はセキュリティと表裏一体です。本番環境への広範なアクセスを安易に渡すと、それ自体が情報漏洩や誤操作のリスクになります。RFPでは、調査に必要な最小限の権限を、必要な期間だけ付与する運用や、操作ログを残す前提を要件として盛り込みます。アクセス権限と環境提供の要件は、調査の速さとセキュリティのバランスを取る設計であり、発注側の責任範囲として事前に詰めておくべき項目です。ここを曖昧にすると、緊急時に権限調整で時間を浪費し、せっかくのSLAも活かせません。

隠れコストを潰す契約・体制要件

RFPの最後に詰めるべきが、見積もりに表れにくい隠れコストを潰す契約・体制の要件です。基本料金は安く見えても、対応範囲外の作業や工数上限超過で追加費用がかさむと、結局は割高になります。追加費用の線引きと、体制・引き継ぎの要件を定義します。

月額固定の契約では、基本料金に含まれる工数上限と、それを超えた場合の単価を明記させます。原因調査は障害の難度によって工数が読みにくいため、「月◯時間まで含む、超過分は人月単価◯◯万円」という形で線引きを要件化します。人月単価の相場は業界一般で60万〜150万円、監視オペレーターで60万〜80万円、運用設計・インシデント分析で80万〜120万円が目安です。この相場を知っておけば、超過単価の妥当性を判断できます。

「安すぎる見積もり」には、対応範囲が狭い、SLAがない、工数上限が極端に低いといった落とし穴が潜みます。RFPで範囲・SLA・工数上限を数値で定義していれば、各社の見積もりがこの前提を満たしているかを機械的にチェックでき、安さの裏にあるリスクを見抜けます。隠れコストは、要件の曖昧さから生まれます。曖昧さを潰すことが、最良のコスト管理です。とくに原因調査は工数が事前に読みづらい領域だけに、線引きの一文があるかないかで、年間の総支払額が大きく変わってきます。

体制の要件では、誰が一次対応し、どんな基準でエスカレーションするか、連絡経路はどうなっているかを定義します。原因調査は時間との勝負であり、夜間や休日に連絡がつかなければ意味がありません。24時間365日の対応体制を求めるのか、営業時間内に限るのかを明記し、それに応じた費用を見積もらせます。報告のフォーマットや頻度も要件化すると、障害時の情報共有が円滑になり、社内の経営層や業務部門への二次連絡もスムーズに回ります。

将来のベンダー切り替えに備え、引き継ぎの要件も忘れずに入れます。調査手順書・監視設定・アカウント情報・ソースコードの引き渡し方法、解約予告期間を契約に盛り込むことで、特定ベンダーへの過度な依存を避けられます。riplaはフルスクラッチ受託と国内運用保守の立場から、システムを作った当事者として透明性の高い体制と引き継ぎ可能なドキュメントを重視し、隠れコストの少ない原因調査の要件づくりを支援します。要件定義の丁寧さが、長期の運用コストを決めるのです。

まとめ

ITシステム原因調査のRFP・要件定義を整理すると、調査範囲と責任分界点の定義、応答・復旧時間とSLAの数値要件、ログ・監視項目と調査基盤の要件、隠れコストを潰す契約・体制要件という四つの柱で構成されます。工程ごとの範囲とクラウド責任共有の分界点を引き、初報15分〜1時間・復旧2〜24時間といった数値でSLAを定め、監視項目・閾値・ログ保持期間とツール選定基準を固め、工数上限と引き継ぎを契約に盛り込む。これらを数値で定義することが、見積もりの比較と妥当性判断を可能にします。

要件定義で大切なのは、「曖昧さこそが隠れコストとトラブルの源」という認識です。範囲・時間・項目・契約をすべて数値と具体例で書き切れば、ベンダーは同じ前提で提案でき、発注側は安さの裏のリスクを見抜けます。まずは自社の重要システムについて、許容できる停止時間とログ保持期間を決めることから始めてください。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、システムを知る当事者として適正なSLA設計と要件づくりを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。