ITシステム運用管理を外部に委託するうえで、その後の品質とコストをもっとも大きく左右するのが、RFP（提案依頼書）と要件定義の質です。とくに運用管理は、開発のように「完成した成果物」が見えにくく、「どこまでの範囲を、どの水準で、いくらで」面倒を見てもらうのかが曖昧なまま契約してしまいがちです。その結果、いざ障害が起きてから「それは契約範囲外です」と言われたり、逆に使わない範囲に高い保守費を払い続けたりする事態に陥ります。だからこそ、運用管理のRFP・要件定義書では、業務範囲・SLA・責任分界点・体制を、数値と条文で明確に定義することが欠かせません。
本記事は、ITシステム運用管理のRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。クラウドの責任共有を前提とした業務範囲の切り分け、SLAと処理速度の数値要件、曖昧な要求を具体的な要件へ翻訳する方法、契約形態（準委任・請負）の選び方、そして価格の配点を抑えた評価軸の設計まで、運用管理の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずITシステム運用管理の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム運用管理の完全ガイド
業務範囲と責任分界点を要件化する
運用管理のRFPでまず固めるべきは、業務範囲と責任分界点の定義です。運用管理は監視・バックアップ・障害対応・問い合わせ対応・アップデート・軽微改修など多岐にわたるため、「何が含まれ、何が含まれないか」を曖昧にすると、後の費用と責任を巡るトラブルの温床になります。とくにクラウドやSaaSを組み合わせた現代のシステムでは、責任分界点の明確化が決定的に重要です。
運用業務を費目ごとにリストアップする
業務範囲を要件化するには、運用業務を費目レベルで分解してリストアップします。保守費の一般的な内訳は、定期保守20〜30%、監視15〜25%、障害対応25〜35%、問い合わせ対応10〜20%、軽微改修10〜15%、管理・報告5〜10%です（出典：ripla）。この費目を一つずつ「自社にとって必要か」「どの水準まで求めるか」を検討し、RFPに範囲として明記します。
とくに見落とされがちなのが、軽微改修と問い合わせ対応の範囲です。「月に何件まで、何時間までの軽微改修が保守費に含まれるのか」「問い合わせは平日日中のみか、夜間休日も対応するのか」を曖昧にすると、後で「それは別料金です」というトラブルになります。RFPの段階で、各費目の対応範囲・時間帯・件数の上限を定義しておくことが、見積もりを横並びで比較する土台になります。範囲が曖昧なRFPには曖昧な見積もりしか返ってこず、結果的に契約後の追加費用に苦しむことになります。
クラウド責任共有を前提に分界点を定義する
現代のシステムは、自社・運用ベンダー・クラウド事業者・連携SaaSという複数の主体で成り立っています。RFPでは、この各主体の責任範囲を「責任共有モデル」を前提に切り分けて定義する必要があります。クラウド基盤側で起きた大規模障害、連携先SaaSのAPI仕様変更、AIを使う場合の誤判定など、「運用ベンダーのコントロール外」で起きる事象について、誰がどこまで対応するのかを事前に取り決めておくのです。
具体的には、「クラウド事業者起因の障害が起きた場合、運用ベンダーは一次切り分けと連絡をどこまで行うか」「その障害は後述のSLA稼働率の算定に含めるのか除外するのか」をRFPに明記します。この定義がないまま運用を始めると、いざ外部要因の障害が起きたときに「それはうちの責任ではない」という責任のなすり合いが発生し、復旧が遅れます。コントロール外の事象まで踏み込んで責任分界点を要件化することが、現代の運用管理RFPの差別化ポイントであり、トラブルを未然に防ぐ最大の防衛策です。
SLAと処理速度の数値要件を定義する
運用管理の品質を要件として担保するのが、SLA（サービス品質保証）と性能の数値要件です。「迅速に対応します」「安定して動かします」といった定性的な表現では、品質は守られません。稼働率・応答時間・復旧時間・処理速度を具体的な数値でRFPに記述し、それを契約上の約束として明文化することが要件定義の核心です。
稼働率・応答・復旧の数値をRFPに明記する
SLAの数値要件は、自社のシステムの重要度に応じて設定します。稼働率は99.9%（月43分程度の停止許容）か99.5%か、応答時間は重大障害の初報を15分・通常を2時間とするか、エスカレーションは30分・回答は24時間とするか、復旧は重大障害で4時間・通常で8時間・恒久対応で5営業日とするか（出典：ripla）。これらの基準を、システムの重要度ごとにRFPで提示し、ベンダーに達成可能かを問います。
注意したいのは、SLAの数値を高くするほど運用コストは上がるという点です。稼働率99.9%を24時間365日体制で保証するには相応の待機要員が必要で、その分の費用が上乗せされます。すべてのシステムに最高水準のSLAを求めるのではなく、「止まると事業が直ちに止まる重要システム」と「多少止まっても業務影響が限定的なシステム」を分け、それぞれに見合ったSLAを設定することが、コストを最適化する要件定義の作法です。重要度の階層分けをRFPに織り込むことで、過剰な保証への過払いを避けられます。
ペナルティと処理速度の要件を実効化する
SLAを実効性のあるものにするには、未達時のペナルティ（減額）を要件に含めます。稼働率を下回った場合に月額保守費の何%を減額するか、その算定方法はどうするかを定義します。ここで重要なのは、「障害の原因が有耶無耶になってペナルティが適用されない」現実を防ぐことです。原因区分（自社管理範囲かコントロール外か）の判定方法と、判定が割れた場合の手続きまでRFPに織り込むことで、ペナルティ条項を形骸化させずに済みます。
処理速度などの性能要件も、数値で定義します。RFPの例では「全画面3秒以内」といった応答時間の目標が示されています（出典：ripla）。こうした性能要件を運用の監視しきい値とSLAに連動させることで、「動いてはいるが遅い」という体感品質の劣化も契約上の管理対象にできます。SLA・ペナルティ・処理速度の数値を一体で要件化することが、運用品質を曖昧にしないための鍵です。性能やSLAの判断基準をどう設計するかは、メリット・デメリットの観点とも深く関わるため、判断軸を整理した記事もあわせてご覧ください。
契約形態の選択と評価軸の設計
業務範囲とSLAを固めたら、それをどの契約形態で結ぶか、そして複数のベンダーをどう評価するかを設計します。運用管理は「成果物の納品」ではなく「継続的なサービスの提供」が中心になるため、契約形態の選択を誤ると、責任の所在や費用の扱いが実態と合わなくなります。
準委任と請負を業務の性質で使い分ける
運用管理の契約形態は、業務の性質によって準委任と請負を使い分けます。監視・問い合わせ対応・定型運用のように「成果物ではなく継続的な業務遂行」が中心となる定常運用は、準委任契約が適しています。一方、特定の機能改修やバージョンアップ案件のように「明確な成果物の完成」が求められる業務は、請負契約やSES（システムエンジニアリングサービス）が適することがあります（出典：ripla）。
RFPでは、運用全体をどう契約形態で切り分けるかを提示し、ベンダーの提案を求めます。すべてを請負にすると、想定外の障害対応のたびに「これは契約範囲外の追加作業」となりがちで、柔軟性を欠きます。逆にすべてを準委任にすると、成果に対する責任が曖昧になることがあります。定常運用は準委任、改修案件は請負、というように業務の性質で切り分けることが、責任と費用を実態に合わせる要件定義の基本です。契約形態は法務にも関わるため、メリット・デメリットの判断軸を整理した記事もあわせて確認することをおすすめします。
価格の配点を抑えた評価軸を設計する
複数のベンダーを評価する際、価格だけで選ぶと品質を犠牲にしがちです。運用管理は長期にわたって事業を支えるため、評価軸では価格の配点を意図的に抑え、SLAの達成体制、実際の運用要員の質、ドキュメントと引き継ぎ可能性、コントロール外障害への対応方針といった「品質と継続性」の配点を厚くすることが重要です。運用要員の人月単価は60万〜150万円と幅があり（出典：ripla）、安さの裏に経験の浅い要員が割り当てられる可能性があるからです。
評価軸では、実際の運用体制図の提出を求め、「誰が監視し、誰が障害対応し、PMは誰か」を明記させることが有効です。提案のときだけ経験豊富な担当者が出てきて、実際の運用は経験の浅い要員が担う、という事態を避けるためです。また、ベンダー乗り換え時の引き継ぎやドキュメントの整備状況も評価軸に含めることで、将来のロックインを防げます。価格を抑えた多面的な評価軸を設計することが、長期的に信頼できる運用パートナーを選ぶ鍵になります。riplaはフルスクラッチ受託と国内運用保守の立場から、要件の透明な整理と、運用体制・責任分界を明示する進め方を重視しています。
曖昧な要求を具体的な要件へ翻訳する
運用管理のRFPでつまずきやすいのが、社内から上がってくる要求が「とにかく止まらないようにしてほしい」「障害には早く対応してほしい」といった曖昧な言葉でしか表現されないことです。この曖昧な要求のまま発注すると、ベンダーは解釈の幅を残した見積もりを出し、後で「思っていたのと違う」というズレが生じます。要件定義の重要な仕事は、こうした曖昧な要求を測定可能な数値要件へ翻訳することです。
定性的な要求を定量的な指標に置き換える
「止まらないように」という要求は、稼働率99.9%（月43分程度の停止許容）や99.5%という数値に翻訳します（出典：ripla）。「早く対応してほしい」は、初報応答15分・復旧4時間といった時間に置き換えます。「遅くならないように」は、全画面3秒以内といった処理速度の目標にします（出典：ripla）。このように、感覚的な要求を一つひとつ測定可能な指標へ変換することで、ベンダーは正確に見積もれ、ユーザー企業は達成状況を後で検証できるようになります。
この翻訳作業で大切なのは、数値を「自社にとっての意味」に立ち返って決めることです。稼働率を一律で99.9%にするのではなく、「このシステムが1時間止まると、いくらの損失が出るか」を考え、それに見合った水準を設定します。過剰な数値はコストを押し上げ、不足する数値は事業リスクを残します。曖昧な要求を数値へ翻訳する過程は、自社が本当に守りたいものを言語化する作業でもあります。この翻訳が要件定義の質を決め、ひいては見積もりとベンダー選定の精度を左右します。
ドキュメント整備と引き継ぎ可能性を要件に含める
RFPで見落とされがちだが極めて重要なのが、ドキュメント整備と将来の引き継ぎ可能性を要件に含めることです。運用を委託すると、システムの構成情報や障害対応の経緯がベンダー側に蓄積され、ユーザー企業の手元に残らないことがあります。これを放置すると、後でベンダーを変えたくても引き継ぎが難航し、ベンダーロックインに陥ります。
これを防ぐには、RFPに「運用ドキュメントの整備と定期的な更新」「契約終了時の引き継ぎ協力とドキュメントの引き渡し」「ソースコードや設定情報の帰属と開示」を要件として明記します。さらに、ベンダー独自パッケージへの過度な依存を避け、移管時に他社でも引き継げる構成かどうかも評価対象に含めます。ドキュメントと引き継ぎ可能性を要件化することは、契約時点では地味に見えますが、将来の選択の自由を守る保険です。運用管理の要件定義では、「いま委託すること」だけでなく「将来、変えられること」まで見据えて要件を組み立てることが、長期的な主導権を握る鍵になります。
まとめ
ITシステム運用管理のRFP・要件定義書は、業務範囲を費目（定期保守・監視・障害対応・問い合わせ・軽微改修・管理報告）ごとに切り分け、クラウド責任共有を前提とした責任分界点を定義することから始めます。そのうえで、稼働率99.9%・初報15分・復旧4時間・全画面3秒以内（出典：ripla）といったSLAと性能の数値要件を明記し、未達時のペナルティと原因判定の手続きまで織り込む。さらに、定常運用は準委任・改修案件は請負という契約形態の使い分けと、価格の配点を抑えた品質重視の評価軸を設計することで、過不足のない運用契約に近づけます。
運用管理の要件定義の質は、契約後の品質とコスト、そしてトラブル時の責任の明確さに直結します。曖昧な要求のまま契約せず、業務範囲・SLA・責任分界・契約形態を数値と条文で固めることが、現場を守る最大の防衛策です。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、作った後も継続して伴走し、責任分界の明確化からSLA設計、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。