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