ITシステムの維持運用を外部に委託するとき、その良し悪しを大きく左右するのが、提案を依頼する段階で渡すRFP（提案依頼書）と、契約に落とし込む要件定義書の精度です。維持運用は形のあるシステムを作る発注と違い、「何を、どの品質で、いつまでに」やってもらうかが曖昧になりやすく、要件が固まらないまま発注すると、後から「それは契約に含まれていない」という追加費用の応酬になりがちです。発注側が主導権を握って維持運用の質と費用をコントロールするには、RFPと要件定義書をどう書くかが決定的に重要です。
本記事は、ITシステム維持運用のRFP・要件定義書・提案依頼書を、発注企業の視点で実務的に整理する「要件定義特化」の解説です。クラウドの責任共有を前提に対象範囲を切り分ける書き方、稼働率や応答時間といったSLAの数値要件の固め方、価格配点を抑えた評価軸の設計、そして曖昧な要求を具体的な条文に翻訳する進め方まで、一次データとあわせて解説します。なお、ITシステム維持運用の全体像をまだ把握していない方は、まずITシステム維持運用の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム維持運用の完全ガイド
クラウド責任共有を前提に対象範囲を切り分けるRFP
維持運用のRFPで最初に固めるべきは、運用保守の「対象範囲」です。とくに現代のシステムはクラウド基盤や外部SaaSと連携して動くため、どこまでをベンダーが見て、どこからがクラウド事業者や連携先の責任なのかを、責任共有モデルを前提に切り分けておく必要があります。この切り分けが曖昧だと、障害発生時に「それは当社の範囲外です」という押し付け合いが起き、復旧が遅れます。
責任分界点を明記する対象範囲の書き方
対象範囲のRFPでは、システムを構成する要素ごとに、誰が運用責任を負うのかを表形式で明記します。アプリケーション層は委託ベンダー、OS・ミドルウェア層はベンダーとクラウド事業者の共有、物理基盤層はクラウド事業者、といった具合に層ごとに責任を整理するのが基本です。さらに、連携している外部SaaSのAPIが仕様変更された場合の追従対応を、誰が、どこまで無償で行うのかも、あらかじめ要件として書いておきます。
とくに見落とされがちなのが、ベンダーのコントロール外で起きる障害の取り扱いです。クラウド基盤側の大規模障害、連携SaaSのAPI仕様変更、AIを組み込んだシステムにおける想定外の挙動など、ベンダー自身が原因でない事象への対応スタンスを、RFPの段階で問うておくべきです。「自社の責任範囲外だから何もしない」のか「原因究明と暫定対応は支援する」のかで、いざというときの安心感はまったく異なります。この責任分界の設計こそ、モダンなIT環境の維持運用RFPで最も差がつくポイントです。
準委任・請負を要件で指定する書き方
対象範囲と並んで重要なのが、契約形態の指定です。維持運用では、定常的な運用や監視は成果ではなく行為に対して対価を払う準委任契約、明確な成果物がある改修などは請負契約、というように業務の性質に応じて契約形態を使い分けるのが一般的です。RFPの段階で、どの業務をどの契約形態で想定しているかを示しておくと、ベンダーからの提案の前提が揃い、比較しやすくなります。
契約形態の指定で注意したいのが、準委任契約では原則として成果（システムが止まらないこと）が保証されない点です。そのため、準委任で運用を委託しつつ、品質はSLAで担保する、という組み合わせが実務では多く採られます。一方、軽微改修や仕様変更対応のうち成果物が明確なものは請負として切り出すことで、何ができたら完了かを明確にできます。要件定義書では、業務ごとに契約形態と、それに紐づく品質保証の仕組みを対応付けて記述することが、後の責任の曖昧さを防ぎます。
SLA・処理速度の数値要件を固める要件定義
維持運用の要件定義で、最も具体的に書き込むべきなのがSLA（サービス品質保証）の数値要件です。「安定して運用してほしい」という曖昧な要求では、ベンダーごとに解釈が分かれ、提案も比較できません。稼働率、応答時間、復旧時間、処理速度といった指標を数値で定義することで、求める品質を客観的に伝えられ、提案の優劣を公平に評価できるようになります。
稼働率・応答時間・復旧時間の数値設定
SLAの数値要件は、具体的な水準を示して記述します。稼働率は99.9%（月43分の停止まで許容）や99.5%といった水準を目安に、システムの事業重要度に応じて設定します（出典：ripla）。障害時の対応については、初報応答を重大障害で15分以内・通常で2時間以内、エスカレーションを30分以内、暫定復旧を重大障害で4時間以内・通常で8時間以内、恒久対応を5営業日以内、といった水準が一つの基準になります（出典：ripla）。
性能面の要件も数値で示すと、提案の精度が上がります。たとえばRFPの例では、全画面の応答を3秒以内とする処理速度要件を掲げるケースがあります（出典：ripla）。ただし、過剰に高いSLAを求めると費用が跳ね上がるため、自社の事業にとって本当に必要な水準を見極めることが大切です。24時間365日の高い稼働率が必要なのか、平日日中の安定で十分なのかによって、必要な体制とコストは大きく変わります。要件定義では、システムが止まったときの事業損失を起点に、過不足のない数値を設定します。
未達時のペナルティ条項を要件に含める
SLAを実効性のあるものにするには、未達時の取り扱いを要件に含めることが欠かせません。目標を数値で定めても、達成できなかったときに何も起きないのであれば、それは単なる努力目標に過ぎません。要件定義では、稼働率や復旧時間が約束を下回った場合に、月額の一定割合を減額するといったペナルティ条項を求めるかどうかを明記します。
ここで現実的に押さえておくべきなのが、ペナルティが適用されにくい構造です。障害の原因が自社設備かクラウド側か連携先かで有耶無耶になると、責任の所在が確定せずペナルティが不適用になることがあります。要件定義では、SLA未達の判定方法、原因切り分けの手順、そして減額の計算方法までを具体的に定めることで、形だけのSLAを避けられます。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした数値要件と未達時の取り扱いを、現実に機能する形で整理する支援を重視しています。
価格配点を抑えた評価軸を設計する提案依頼
RFPを出した後、複数のベンダーから来る提案をどう評価するか。その評価軸の設計も、要件定義の重要な一部です。維持運用は長期にわたって品質が問われる領域であるにもかかわらず、価格の安さだけで選んでしまうと、安かろう悪かろうの運用になり、結局は障害多発や追加費用で高くつくことが少なくありません。評価軸では、価格の配点を意図的に抑え、品質や体制を重視する設計が求められます。
品質・体制を重視する配点の組み方
評価軸では、提案価格の配点を全体の3割程度に抑え、残りを技術力・運用体制・実績・SLA達成の実効性といった品質要素に配分する設計が有効です。たとえば、障害対応の体制（24時間対応か、エスカレーションの仕組みは妥当か）、過去の同規模システムの運用実績、ドキュメント管理の方針、そして担当者の継続性などを評価項目に据えます。価格の配点を抑えることで、目先の安さに引きずられず、長期的に安定する委託先を選べます。
費用の妥当性を判断する際は、相場との照合が役立ちます。維持運用費は開発費の15〜20%が目安で、規模別の月額は小5〜15万、中15〜50万、大50〜200万以上が一つの基準です（出典：ripla）。相場より極端に安い提案は、必要な体制が省かれている可能性を疑い、内訳の説明を求めるべきです。逆に高い提案は、待機要員コストや多重下請けの構造が上乗せされていないかを確認します。価格は「安いか高いか」ではなく「内訳が妥当か」で評価することが、評価軸設計の肝になります。
費用内訳の開示を提案依頼で求める
評価の精度を上げるには、RFPの段階で各社に費用内訳の開示を求めておくことが有効です。月額の総額だけでなく、定期保守・監視・障害対応・問い合わせ対応・軽微改修・管理報告といった費目ごとの内訳を提示してもらうと、各社が何にどれだけ費用をかける想定なのかが見え、比較の精度が格段に上がります。維持運用費の内訳の目安（障害対応25〜35%、定期保守20〜30%、監視15〜25%など）と照らせば、各社の見積もりの偏りも把握できます（出典：ripla）。
内訳の開示を求めることには、もう一つの効果があります。それは、契約後に「これは別料金です」と言われるグレーゾーンを、提案段階で潰せることです。どの作業が月額に含まれ、どの作業が別途見積もりになるのかを内訳とあわせて明示させておけば、軽微改修や仕様変更対応の範囲をめぐる後日のトラブルを防げます。提案依頼書は、安く発注するための道具ではなく、長期にわたって費用と品質をコントロールするための設計図だと捉えることが大切です。
曖昧な要求を具体的な条文に翻訳する進め方
RFPや要件定義書の作成でつまずく最大の原因は、現場の「こうあってほしい」という曖昧な要求を、ベンダーが見積もれる具体的な要件に翻訳できないことです。「すぐに対応してほしい」「困ったときに相談できる体制がほしい」といった要望は、そのままでは契約条文になりません。これを数値や手順に落とし込む翻訳作業こそ、要件定義の中核です。
現場要望を数値・手順に落とし込む
翻訳の進め方は、現場の要望の背景にある「困りごと」を掘り下げることから始めます。「すぐに対応してほしい」という要望の裏には、過去に障害復旧が遅れて業務が長時間止まった経験があるかもしれません。その背景を踏まえれば、「重大障害は4時間以内に暫定復旧」という数値要件に翻訳できます。同様に「相談できる体制」は、「平日日中の問い合わせ窓口を設け、回答を24時間以内に行う」といった具体的な手順に変換します（出典：ripla）。
この翻訳作業を発注側だけで行うのが難しい場合は、要件定義の支援を受けられるベンダーや第三者を活用する手もあります。重要なのは、翻訳の過程で「なぜその要件が必要か」という背景を要件定義書に残しておくことです。背景が記録されていれば、後で要件を見直す際にも、何を守るための条文なのかが分かり、過剰要件や不足要件を発見しやすくなります。曖昧な要求を放置したままベンダーに丸投げすると、ベンダー都合の解釈で要件が固まり、発注側に不利な契約になりかねません。
ドキュメント・移管条件を要件に盛り込む
要件定義書で忘れてはならないのが、将来の保守移管に備えた条件です。維持運用は長期に及ぶため、いずれベンダーを変更する可能性があります。そのとき、ドキュメントが整備されていなかったり、ソースコードの権利がベンダー側にあったりすると、移管が困難なロックイン状態に陥ります。要件定義の段階で、運用手順書や設計書を定期的に更新して納品すること、移管時の協力義務を負うことを条件に盛り込んでおきます。
とくにソースコードの著作権や、ベンダー独自パッケージの派生物の取り扱いは、移管の可否を左右する重要事項です。これらを盾に移管を拒まれると、契約解除に向けた法務対応に発展する泥沼になりかねません。要件定義書では、成果物の権利帰属、ドキュメントの納品義務、移管時の引き継ぎ協力を明記し、特定ベンダーへの過度な依存を構造的に防ぐことが大切です。要件定義は目先の運用品質だけでなく、数年後の乗り換えの自由度まで見据えて設計することが、長期的なコストと主導権を守る要になります。
まとめ
ITシステム維持運用のRFP・要件定義書を整理すると、要点は四つに集約されます。クラウド責任共有を前提に対象範囲と責任分界点を切り分けること、稼働率99.9%や初報15分・復旧4時間といったSLAの数値要件を未達時の取り扱いまで含めて固めること、価格配点を3割程度に抑えて品質と内訳で評価すること、そして曖昧な現場要望を背景ごと具体的な条文に翻訳することです（出典：ripla）。これらを発注側が主導することで、維持運用の質と費用をコントロールできます。
要件定義で大切なのは、目先の運用品質だけでなく、将来の保守移管の自由度まで見据えることです。ドキュメントの納品義務や成果物の権利帰属を要件に盛り込み、特定ベンダーへのロックインを構造的に防ぐ設計が、長期的な主導権を守ります。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を創業。