ITシステムのリリース対応を外部のベンダーに任せる、あるいは保守契約の一部として位置づけようとするとき、避けて通れないのがRFP（提案依頼書）と要件定義書の作成です。「リリースは適切にやってください」とだけ書いた曖昧な依頼では、いざ障害が起きたときに「どこまでがベンダーの責任か」が宙に浮き、追加費用やトラブルの火種になります。リリース対応をめぐる発注側の悩みの多くは、要件を数値と条件で明確に定義できていないことに起因します。だからこそ、リリース対応のRFP・要件定義書をどう書くかが、契約後の安心を左右します。
本記事は、ITシステムのリリース対応に関するRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から整理する「要件定義特化」の解説です。リリース対応で定義すべき機能要件、SLA・処理速度といった非機能要件の数値化、クラウド責任共有を前提とした責任分界点の明記、そしてベンダーを適切に選ぶための評価軸の設計まで、費用やSLAの一次データとあわせて具体的に解説します。なお、リリース対応の全体像をまだ把握していない方は、まずITシステムリリース対応の完全ガイドから読むことをおすすめします。読み終えるころには、自社のRFPに盛り込むべき項目の骨格が見えてくるはずです。
▼全体ガイドの記事
・ITシステムリリース対応の完全ガイド
リリース対応で定義すべき機能要件
RFP・要件定義書でまず固めるべきが、リリース対応として「何を、どこまでやってもらうか」という機能要件（作業範囲）です。ここが曖昧だと、ベンダーは自社に都合よく範囲を解釈し、後から「それは契約外です」という追加費用の応酬になります。リリース対応の範囲を、誰が読んでも同じように理解できる粒度で書き出すことが、要件定義の第一歩です。
作業範囲と頻度を具体的に書く
リリース対応の作業範囲には、定例的なアップデート対応、軽微改修や仕様変更のリリース、緊急の修正リリース、そしてリリースに伴うテストや切り戻しまでが含まれます。RFPでは、これらを項目ごとに分け、「月あたり想定何件のリリースか」「定例リリースの頻度はどうか」「緊急リリースにはどう対応するか」を明示します。一次データでは保守費の内訳のうち軽微改修が10〜15%を占めますが（出典：ripla）、この軽微改修の対応件数や規模を曖昧にすると、見積の前提がベンダーごとにバラバラになり、提案の比較ができなくなります。
また、「リリース作業の実施時間帯」も要件として定義すべきです。利用者への影響を避けるため深夜・休日にリリースする必要があるなら、その条件を書き、夜間・休日対応の有無を見積の前提に含めてもらいます。運用要員の人月単価は60万〜150万円が目安ですが（出典：ripla）、夜間・休日の対応を求めるなら、その分のコストが上乗せされるのは当然です。後から「夜間対応は別料金」と言われて揉めないよう、時間帯の要件は最初から明記しておきましょう。
曖昧な要求を翻訳して書く
発注側のRFPでよくある失敗が、「安定して運用してほしい」「迅速にリリースしてほしい」といった曖昧な言葉で要求を書いてしまうことです。これらは気持ちは伝わっても、契約上は何も保証していません。「安定」とは稼働率何%なのか、「迅速」とは何時間以内なのか。曖昧な要求を、測定可能な条件へ翻訳して書くことが、要件定義の質を決めます。
翻訳に自信がなければ、ベンダー選定の前段で要件整理を支援してもらう、あるいは複数ベンダーに要件の壁打ちをしてもらうのも有効です。重要なのは、RFPの段階で要求を数値・条件に落とし込み、提案各社が同じ前提で見積もれる状態をつくることです。曖昧なまま発注すると、契約後に「言った・言わない」の不毛なやり取りが続き、結局は発注側が損をします。要件定義は、発注側が自分を守るための交渉カードでもあります。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした曖昧要求の翻訳と数値化を含めた要件整理を重視しています。
SLA・処理速度など非機能要件の数値化
リリース対応のRFP・要件定義書でもっとも差がつくのが、SLA（サービス品質保証）や処理速度といった非機能要件をどこまで数値で定義できるかです。これらを数値で書けるかどうかが、契約後にベンダーの責任を問えるかどうかを左右します。感覚的な期待ではなく、具体的な数値目標として要件に落とし込むことが肝心です。
稼働率・応答時間・復旧時間を数値で定義する
SLAの中核は、稼働率・初報応答時間・復旧時間という3つの数値です。一次データでは、稼働率は99.9%（月あたり停止許容約43分）または99.5%、初報応答は重大インシデントで15分・通常で2時間、エスカレーションは30分、復旧は重大で4時間・通常で8時間、恒久対応は5営業日、といった水準が目安とされます（出典：ripla）。RFPでは、自社の業務にとって許容できる停止時間や復旧時間から逆算して、これらの数値を要件として明示します。
ここでリリース対応に特有の観点として加えたいのが、「リリース起因の障害」をSLAでどう扱うかです。リリース後に不具合が出てサービスが止まった場合、それは復旧時間の対象になるのか、切り戻しまでの時間に上限を設けるのか。こうした条件をRFP段階で確認しておかないと、いざ障害が起きたときに「リリース起因は別扱い」と逃げられる余地を残します。さらに、SLAを未達したときのペナルティ（減額相場として月額の一定割合）も要件に含めるかを検討します（出典：ripla）。ただしペナルティは、原因が有耶無耶にされると適用されない現実もあるため、原因記録の義務もあわせて定義しておくと実効性が高まります。
処理速度・性能要件を測定可能に書く
リリースによって機能を追加・変更する際、性能が劣化していないことを保証する性能要件も重要です。一次データのRFP例では「全画面の表示を3秒以内」といった処理速度の要件が示されています（出典：ripla）。RFPでこうした性能基準を明示しておけば、リリースのたびに「性能が基準を満たしているか」を検証する根拠になります。性能要件がないと、機能追加を重ねるうちにシステムが徐々に重くなり、利用者の不満が蓄積しても誰も責任を問えません。
性能要件を書くときは、「どんな条件で、どの操作が、何秒以内か」を測定可能な形にします。たとえば「ピーク時の同時アクセス数◯の状態で、主要画面の表示が3秒以内」というように、前提条件と対象操作を具体化します。曖昧な「速いこと」では検証できません。リリース対応の文脈では、こうした性能要件を品質ゲートに組み込み、基準を割るリリースは止める、という運用までセットで要件化できると理想的です。非機能要件の数値化は手間がかかりますが、契約後のトラブルを減らす最大の予防策になります。
クラウド責任共有を前提とした責任分界点の明記
現代のリリース対応RFPで、競合の多くが見落としているのが、クラウドやSaaSとの連携を前提とした責任分界点の明記です。AWSなどのクラウド障害、連携先SaaSのAPI仕様変更、AIサービスの想定外の挙動など、「ベンダーのコントロール外」で起きる事象の責任と費用をどう扱うか。ここを要件定義で詰めておかないと、障害時に責任のなすり合いになり、復旧が遅れます。
クラウド側障害・連携先変更の責任を整理する
クラウドの責任共有モデルでは、クラウド事業者が物理基盤やインフラの一部を担い、利用者やベンダーがその上のアプリケーションや設定を担う、という分担があります。RFPでは、この前提を踏まえ「クラウド側の障害でサービスが止まった場合、ベンダーは何をどこまで対応するか」を定義します。クラウド障害そのものはベンダーに止められませんが、障害を検知して報告し、代替手段や復旧支援を行う範囲は要件化できます。ここを書いておかないと、「クラウドの問題なのでうちの責任ではありません」で対応が止まりかねません。
同様に、連携先SaaSのAPI仕様変更への対応も要件に含めます。SaaSが予告なくAPIを変えれば、連携部分が動かなくなることがあります。これは自社システムのバグではありませんが、放置すれば業務が止まります。RFPでは、こうした連携先起因の改修を「リリース対応の範囲に含めるか」「含める場合の費用の考え方」を定義しておきます。想定外費用として、OSSの保守やデータ復旧、クラウド側障害への対応費用が後から発生しやすいため、これらの手当てを要件段階で議論しておくことが、予算超過を防ぎます。
契約形態（準委任／請負）を要件に合わせる
リリース対応の要件は、契約形態の選択とも密接に関わります。定常的なリリース運用や監視は、成果物を約束しにくいため準委任契約が一般的です。一方、特定の機能改修や移行リリースのように明確な成果物がある作業は、請負契約やSESが適することがあります。RFPでは、求める作業の性質に応じて、どの契約形態を前提にするかを示すと、提案の精度が上がります。
契約形態を曖昧にすると、責任の所在が不明確になります。準委任なのに成果物の完成責任を求めたり、請負なのに作業時間で縛ったりすると、契約と実態がずれてトラブルになります。要件定義の段階で「この作業は準委任、この改修は請負」という切り分けを意識し、それに合わせた条文を契約に反映することが大切です。リリース対応のRFPは、機能・非機能・責任分界・契約形態という4つの層を整合させて初めて、契約後の安心につながります。前述のITシステムリリース対応の完全ガイドでは、これらの全体像も整理しています。
ベンダーを適切に選ぶための評価軸の設計
RFPを出した後、各社の提案をどう評価するか。この評価軸の設計を疎かにすると、価格の安さだけで選んでしまい、後で品質や対応力に泣くことになります。リリース対応のベンダー選定では、価格以外の要素を適切に配点した評価軸をあらかじめ用意しておくことが重要です。
価格配点を抑え品質・体制を重視する
リリース対応・運用保守の評価では、価格の配点を抑えるのが定石です。なぜなら、保守費の安さは往々にして対応の手薄さや、いざというときの追加費用の伏線になるからです。年間保守費は開発費の15〜20%が目安とされますが（出典：ripla）、この相場から大きく外れて安い提案には、何が含まれていないかを疑う必要があります。評価軸では、価格よりも「障害対応体制」「技術力」「ドキュメント整備力」「コミュニケーションの質」といった要素に重みを置きます。
とくにリリース対応では、「事故が起きたときにどう動くか」という有事の対応力が、平時の作業の安さよりはるかに重要です。提案の中で、切り戻し手順、障害時のエスカレーション体制、夜間・休日の連絡体制がどれだけ具体的に語られているかを評価します。これらが抽象的な美辞麗句にとどまる提案は、いざというとき頼りになりません。評価軸の設計は、自社が本当に重視する価値を点数として表現する作業であり、ここに発注側の見識が表れます。
ロックイン回避を要件に織り込む
RFP・要件定義書の段階で、将来のベンダー変更（保守移管）に備えておくことも、賢い発注の条件です。ソースコードの著作権の帰属、ドキュメントの提供義務、独自パッケージへの過度な依存の回避といった点を要件に織り込んでおけば、特定ベンダーへのロックインを避けられます。著作権や独自パッケージを盾に移管を拒まれる泥沼は、契約段階の不備から生じることが少なくありません。
具体的には、リリース手順書・構成情報・運用ドキュメントを発注側が保有できること、契約終了時の引き継ぎ協力義務、そしてソースコードや設定の所有権を要件として明記します。これにより、いざ別のベンダーへ移りたくなったとき、二重コストや引き継ぎ難航のリスクを下げられます。リリース対応のRFPは、目の前の作業範囲だけでなく、契約終了後の出口まで見据えて設計するのが理想です。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした出口の確保も含めた透明なドキュメント整備を重視しています。要件定義は、発注側が長期にわたって主導権を握るための設計図なのです。
まとめ
ITシステムのリリース対応に関するRFP・要件定義書は、機能要件（作業範囲と頻度を具体的に、曖昧要求を翻訳して書く）、非機能要件（稼働率・応答時間・復旧時間・処理速度を数値化する）、責任分界点（クラウド側障害や連携先変更の責任、契約形態を整理する）、評価軸（価格配点を抑え品質・体制とロックイン回避を重視する）という4つの層で構成されます。この4層を整合させて初めて、契約後に責任を問え、トラブルを未然に防げる要件定義になります。
要件定義で大切なのは、「適切にやってほしい」という気持ちを、測定可能な数値と条件へ翻訳することです。稼働率99.9%、初報応答15分、復旧4時間、性能3秒以内といった具体値を起点に、自社の業務にとっての許容ラインから逆算してください。まずは作業範囲の明確化とSLA数値の定義という、効果が大きく着手しやすいところから固めていくのがおすすめです。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、リリース対応の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を創業。