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