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