保守開発を外部に委託するときや、別のベンダーへ保守を移すときは、RFP（提案依頼書）と要件定義がプロジェクトの成否を左右します。それは、保守がすでに動いているシステムに変更を加える非定型業務が中心で、しかも他社が作ったシステムを引き継ぐケースが多いためです。
何を保守し、どのSLA水準を求め、既存資産がどこまで揃っているかをRFPに落とし込めないと、見積りを横並びで比べられず、契約後に「その対応は範囲外」といった揉め事が起きます。この記事は、保守開発のRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。
全体像をまだ把握していない方は、まず保守開発の完全ガイドから読むことをおすすめします。また、現場・経営・情シスの三者の合意形成プロセスも、保守開発の実務に即して掘り下げます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
保守移管RFPの起点となる資産の棚卸し
新規開発では「何を作りたいか」から考えますが、保守開発のRFPは、まず「いま何があるのか」を把握するところから始まります。
保守の対象はすでに存在するシステムなので、その資産の所在と状態が曖昧なままでは、ベンダーは正確な見積りを出せません。だからこそ、資産の棚卸しは保守移管RFPの土台になります。
RFPに記載すべきシステム資産の一覧
保守移管のRFPには、引き継ぐ対象となるシステム資産を漏れなく記載する必要があります。資産ごとに、現在どこにあり、誰が管理し、引き継ぎ時に提供できるかを明示しておけば、ベンダーは保守に必要な前提を正確に把握できます。
とくに重要なのは、ドキュメントの有無と最新性を正直に書くことです。前のベンダーから十分なドキュメントを受け取れるのか、それとも設計書がなくソースコードしかないのか。この違いは、保守の難易度と費用を左右します。
ドキュメントがない場合、ベンダーはソースコードから仕様を読み解くリバースエンジニアリングを行う必要があります。そのため、その工数を見積りに織り込まなければなりません。
資産の実態を隠したり曖昧にしたりすると、移管後に「聞いていた話と違う」となり、追加費用や信頼関係の悪化を招きます。
RFPでは、資産の状態をありのままに開示することが、適切な見積りを引き出す近道です。
引き継ぐ資産は、技術資産とドキュメント類の二つに分けて記載します。
- 技術資産：ソースコードのリポジトリ、サーバーやクラウド環境のアカウント情報、ドメインやSSL証明書、外部サービスのAPIキー、データベースの構成
- ドキュメント類：設計書、テスト仕様書、運用手順書
既存ベンダーとの解約条件と権利関係の整理
保守移管のRFPで見落とされがちなのが、既存ベンダーとの契約関係の整理です。これが不明確なまま移管を進めると、旧ベンダーが「ソースコードは当社の著作物なので渡せない」と主張し、移管そのものが頓挫する事態になりかねません。
著作権や所有権をめぐる争いは、最悪の場合、ADR（裁判外紛争解決手続き）や訴訟といった法的紛争に発展します。
こうした事態を避けるため、RFPには「現状の権利関係」と「移管にあたって新ベンダーに何を引き継ぐか」を整理して記載しておきます。あわせて、新ベンダーにも権利関係の確認を求めるのが賢明です。
引き継ぎがスムーズに進むかどうかは、技術以前に、この契約と権利関係の整理にかかっています。
保守移管で起きやすい法的紛争などの失敗・リスクの詳細は、関連記事もあわせてご覧ください。
契約まわりでは、解約の条件と権利関係の二点を確かめておきます。
- 解約条件：解約予告期間と違約金の有無
- 権利関係：ソースコードの著作権や所有権の帰属、引き継ぎへの協力義務の有無
非機能要件をSLAとして定量化する方法
保守開発のRFPでは、機能要件以上に非機能要件が重要になります。保守の対象は動いているシステムで、求められるのは「どんな品質水準で保守し続けるか」、つまり性能・可用性・セキュリティの保証だからです。
このため、RFPの質は、非機能要件を数値で定量化できるかで決まります。
IPA非機能要求グレードを使った定量化
非機能要件を定量化するうえで実用的な枠組みが、IPA（情報処理推進機構）が公開している「非機能要求グレード」です。この枠組みは、観点ごとに求める水準をグレードとして整理するための共通の物差しです。
保守開発のRFPでは、この枠組みを使って、要件を具体的な数値で示せます。
定量化の利点は、ベンダーの提案を横並びで比較できることにあります。「しっかり保守します」といった定性的な約束では、各社の提案の優劣を判断できません。
発注側が要件を「月間稼働率99.9%以上、重大障害は4時間以内に復旧着手」と数値で示せば、各ベンダーがその水準を満たせるか、いくらで提供できるかが明確になります。
非機能要件の定量化は、見積りを比べられるようにし、過剰品質による費用の無駄と、品質不足による事業リスクを避けるための、要件定義の核心です。
定量化で定めた稼働率や復旧時間が、機能としてどう提供されるかは、保守機能を整理した関連記事もあわせてご覧ください。
定量化の対象は、観点の一覧と数値で示す項目の二つに分けて整理します。
- 観点：可用性、性能拡張性、運用保守性、移行性、セキュリティ、システム環境
- 数値で示す項目：稼働率、障害復旧の時間、バックアップの頻度と保持期間
稼働率・復旧時間・免責のSLA条項への落とし込み
定量化した非機能要件は、最終的にSLA（サービス品質保証）の条項として契約に落とし込みます。そのとき重要なのは、その数値が「保証（SLA）」なのか、「努力目標（SLO）」なのかを明確にすることです。
実在例として、Amazon S3は稼働率95%未満で100%返金という明確なSLAを定めています。一方で、サイボウズは稼働率をSLOとしつつ、規約20条で「連続24時間以上停止しないことを保証する」という形を取っています。同じ「稼働率」でも、未達時の扱いはまったく異なります。
免責条項を見落とすと、サービス停止やデータ消失が起きても補償を求められない、という事態になりかねません。なお、こうしたSLA条項は民法548条の2が定める定型約款の論点とも関わります。
非機能要件は、数値で定めるだけでは発注側を守れず、契約で取り決めて初めて力を持ちます。
RFPと契約では、目標値だけでなく、未達時の扱いと免責まで書き込む必要があり、その内容は、数値の目標と、未達時・免責の取り決めに分かれます。
- 目標値：稼働率と復旧時間
- 未達時と免責：減額や返金などのペナルティ、免責になる事項
準委任前提のスコープと予算上限のコントロール
保守開発では、新規開発と違い、「何をどれだけ直すか」が事前に確定しません。バグがいつ起きるか、どんな改修要望がいつ出るかは予測できないためです。
この不確実性を前提に、契約形態とスコープ、予算をどう制御するかが、保守RFPの設計で問われます。
請負と準委任（ラボ型）の使い分け
契約形態の使い分けは、「準委任前提のスコープと予算上限のコントロール」を支える手段の一つです。システム開発の契約には、請負と準委任の二つがあります。請負は「成果物の完成」に対して報酬を払う契約で、仕様が確定した開発に向きます。
準委任は、「業務の遂行（稼働の提供）」に対して報酬を払う契約で、何が起きるか事前に確定しない保守開発と相性が良いとされます。
とくにラボ型開発は、一定のチームを月単位で確保する形態で、改修や障害対応が断続的に起きる保守開発でも、リソースを柔軟に使えます。
契約形態を業務ごとに使い分けると、コストと柔軟性のバランスが取れます。
すべてを請負にすると、変更のたびに見積りと契約をやり直す手間が生じ、機動力が落ちます。逆に、すべてを準委任にすると、成果が曖昧になりがちです。
RFPで、業務の確定度に応じた使い分けを設計することが、保守開発を無理なく回す鍵になります。
振り分けは、仕様が固まっているかどうかを基準にします。
- 請負：仕様が固まった大きな改修
- 準委任（ラボ型）：日常的なバグ修正や小改修
月間予算上限と工数枠によるスコープの制御
準委任やラボ型は柔軟性が高まる一方、放置すると費用が青天井になるリスクがあります。これを防ぐのが、月間の予算上限や工数枠の設定です。
RFPに「月◯時間の工数枠内で保守を行い、それを超える改修は別途見積りとする」といった上限を明記すれば、ベンダーは枠内で優先順位をつけて対応できます。また、発注側は費用を予測可能な範囲に収められます。
保守費用は一般に開発費の5〜15%／年が相場であり、この相場を踏まえて月間の枠を設計すると現実的です。予算上限の設計では、枠を超えた場合の扱いをあらかじめ決めておく必要があります。
これを取り決めておけば、月末に「予算を超えたがどうするか」で揉めることがなくなります。スコープと予算上限をRFPで制御することは、保守開発を「いくらかかるか分からない不安な契約」から「予測可能な安心の契約」へ変える、要件定義の重要な仕上げです。
取り決める場面は、枠を超えた改修と緊急障害の二つです。
- 枠を超えた改修：翌月に繰り越すか、追加費用で当月に対応するか
- 緊急障害：枠外で優先して対応するかどうか
まとめ
保守開発のRFP・要件定義は、新規開発とは出発点が異なり、「いま何があるのか」という資産の棚卸しと権利関係の整理から始まります。
非機能要件は、IPA非機能要求グレードのような枠組みで稼働率や復旧時間を定量化し、SLAとしてペナルティや免責まで明記してはじめて、見積りを横並びで比べられ、発注側を守る力も持ちます。
変更が事前に確定しにくい保守開発では、請負と準委任（ラボ型）を使い分け、月間予算上限や工数枠でスコープを制御することが、費用を予測可能にする鍵です。
保守費用は開発費の5〜15%／年が相場である点も、枠の設計の前提になります。
RFPは、項目を埋めるだけでなく、社内の合意を経てはじめて完結します。そのために、現場・経営・情シスの三者の関心をKGIとして調和させ、社内合意を形成しながら、引き継ぐ資産・SLA・契約形態を明文化することが欠かせません。
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を創業。