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