追加開発のRFP（提案依頼書）と要件定義書では、既存システムの現状と、足す機能の範囲を具体的に書くことが最初の関門になります。既存システムに何を足すかを正確に伝えないと、見積りがばらつき、リリース後に既存機能を壊すトラブルにもつながります。
具体的な書き方の解説は少なく、多くの担当者が手探りで進めているのが実情です。全体像は、まず追加開発の完全ガイドでご確認ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
既存システムの現状をRFPに整理する方法
追加開発のRFPが新規開発と決定的に違うのは、「すでに動いている既存システムがある」という点です。ベンダーは、既存システムの構成や制約を知らなければ、追加開発の難易度も工数も正しく見積もれません。
したがって、RFPの最初の仕事は、既存システムの現状を整理して伝えることです。ここを丁寧に進めるかどうかで、見積りの精度が変わります。
既存の構成・技術スタック・制約の明記
変えられない制約は、追加開発の設計を左右します。たとえば「基幹システムとは夜間バッチで連携している」「特定のサーバー環境でしか動かない」といったものです。
これらを書かずに見積りを依頼すると、ベンダーは前提を推測するしかありません。そのため、見積りが各社でばらばらになりがちです。
現状を整理する作業は、既存システムの「属人化」を解消する機会にもなります。仕様が特定の担当者の頭の中にしかない状態だと、その人が異動や退職をした途端に、追加開発が極めて難しくなります。
RFPを作る時点で既存の構成や仕様を文書にしておけば、今回の追加開発だけでなく、将来の機能追加もスムーズに進みます。
影響範囲調査や既存仕様の文書化といった土台の仕組みについては、『追加開発の必要機能や標準機能の一覧について』もあわせてご覧ください。
既存の構成は、全体の作りと連携先・制約の2面に分けてRFPに書きます。
- 全体構成と使用技術：システムの全体像と、言語・データベースなどの技術
- 連携先と制約条件：外部システムとの連携先と、夜間バッチなど変えられない条件
現状（AsIs）と目指す姿（ToBe）の併記
RFPに既存システムの現状（AsIs）と、追加開発で実現したい姿（ToBe）を併記すると、ベンダーに意図が正確に伝わります。
現状と理想のギャップこそが、追加開発で足すべき機能の中身です。
ギャップを明確に示すことで、ベンダーは的確な提案を返しやすくなります。
AsIsとToBeの併記が重要なのは、過去の失敗事例からも分かります。現場の業務ヒアリングやToBeモデルの作成を省き、ベンダーに任せきりにした結果、完成したシステムが現場に使われずに廃止された事例は珍しくありません。
そこで、RFPの段階でToBeを明確にしておけば、こうした「作ったのに使われない」という最悪の事態を避けられます。現状の課題と目指す姿を言語化する作業は、面倒に見えても、追加開発の成否を分ける最も価値のある工程です。
現状（AsIs）と目指す姿（ToBe）は、RFPの中で対にして書きます。
- 現状（AsIs）：今の業務の進め方と、そこにある課題
- 目指す姿（ToBe）：追加開発で実現したい改善の内容
RFPに盛り込む項目と要件の粒度
RFPに何を、どのくらいの細かさで書くかは、多くの担当者が悩む点です。細かすぎると作成に時間がかかり、ベンダーの提案の自由度も奪います。
逆に粗すぎると、各社の見積り前提がばらつき、比較できなくなります。そこで、追加開発のRFPに盛り込むべき項目と、適切な粒度の考え方を順に見ていきます。
追加開発のRFPに必須の項目一覧
RFPに盛り込む項目は、おおむね次のとおりです。背景や既存システムの情報だけでなく、依頼の範囲や見積りの条件も含めます。
- プロジェクトの背景と目的（なぜ今この追加開発が必要か）
- 既存システムの構成・技術・連携先・制約
・追加・改修したい機能の概要（ToBeのイメージ）
・スコープの範囲（今回やること／やらないこと）
・非機能要件（性能・可用性・セキュリティなど）
・予算感とスケジュール、希望する契約形態
・提案してほしい内容（体制・進め方・見積り内訳）
とくに「やらないこと」を明記する点は、追加開発のRFPで重要です。スコープの境界を最初に示しておくことで、後から「これもやってくれるはず」という認識のずれを防げます。
見積りについては、内訳の提示を求めることも欠かせません。追加開発の費用は約8割が人件費であり、上級SEは100〜160万円、初級SEは60〜100万円、下請けや個人では40〜60万円と、人月単価には大きな幅があります。
誰がどのフェーズに何人月かかわるのかを内訳で示してもらえば、見積りの妥当性を判断しやすくなります。一方で、総額だけの見積りでは、各社の前提が見えず、適正価格かどうかも分かりません。
粒度の決め方とスコープ管理の勘所
要件の粒度は、画面の細部まで指定しすぎないのが理想です。細部まで決めると、RFPの作成負荷が増えるうえ、より良い提案の余地も狭まります。何を実現したいかが明確であれば、技術的な実現方法はベンダーの提案に委ねられます。たとえば「在庫が一定数を下回ったら担当者に通知する機能を追加したい」と書いてあれば、ベンダーは機能の大きさを見積もれます。
スコープ管理で最も避けたいのは、無制限な仕様変更による工数増です。一次データでも、工数増が予算超過につながると指摘されています。
これを防ぐには、RFPの段階で「今回のスコープ」と「将来検討するスコープ」を分けて示します。そのうえで、追加要望が出たときは費用と納期への影響を明示し、合意し直すルールをあらかじめ決めておくことです。
柔軟さが必要な場面もありますが、その柔軟さがコスト管理の放棄になってはいけません。スコープの線引きは、追加開発の予算を守るうえで欠かせません。
粒度とスコープは、どこまで具体的に書くかと、変更をどう扱うかで線引きします。
- 粒度：工数を見積もれる具体さで書き、実装方法は縛らない
- スコープ：今回の範囲と将来検討する範囲を分け、変更時は費用と納期を合意し直す
機能要件と非機能要件の定量化
要件定義書では、要件を「機能要件」と「非機能要件」に分けて書きます。機能要件は「何ができるか」、非機能要件は「どのくらいの品質・性能で動くか」を定めるものです。
とくに非機能要件は、見積りに影響するのに曖昧に書かれがちです。ここを定量化できるかどうかが、追加開発のRFPと要件定義の質を分けます。
稼働率99.9%と99.99%のコスト差の理解
非機能要件の代表が、システムの可用性（止まらずに動き続ける度合い）を示す稼働率です。「できるだけ止まらないように」とぼかした書き方では、どこまで止まらないのかが分かりません。
追加開発のコストは「機能数×品質レベル」で決まり、品質を高めるほど費用が跳ね上がります。
一次データによれば、品質レベルが低ければ基準費用の50〜70%、中なら100〜150%、高なら200〜400%となり、設定次第で費用は数倍に変わります。つまり、過剰な非機能要件は予算を圧迫します。
必要な品質だけを数値で要件にすることが、追加開発の予算を無駄なく使うことにつながります。
稼働率と品質レベルは、停止の許容量と業務の重要度から決めます。
- 稼働率：停止時間の許容量を、99.9%か99.99%かの数値で書く
- 品質レベル：業務の重要度から、必要な水準だけを選ぶ
この数値の差は、そのままコストに直結します。稼働率99.9%は年間で約8.8時間の停止を許容するのに対し、99.99%では停止を約53分までに抑える必要があります。
99.99%を実現するには、冗長化や監視の仕組みに大きな追加投資が必要になります。
性能・セキュリティ要件を数値で書く方法
稼働率以外の非機能要件も、できる限り数値で書きます。性能要件であれば「画面の表示は3秒以内」「同時アクセス100人でも処理できる」のように書きます。
セキュリティ要件であれば「個人情報は暗号化して保存する」「アクセスログを1年間保管する」といった具合です。
数値や具体的な基準で書くことで、ベンダーは必要な設計と工数を正確に見積もれ、リリース後に「思ったより遅い」といった認識のずれも防げます。
既存システムは、すでに何らかの性能やセキュリティの水準で動いています。そのため、非機能要件の定量化は、追加開発でとくに注意が必要です。
追加する機能だけ過剰な水準を求めても、既存部分とのバランスが取れず、コストが無駄になることがあります。
追加機能が既存の重要データに触れる場合は、既存と同等以上のセキュリティ水準を満たす必要があります。
既存システムの品質水準を踏まえて、追加部分の非機能要件を数値で定めます。この既存との整合性こそが、追加開発の非機能要件で最も難しい点です。
非機能要件は、性能とセキュリティの両面で数値に書けます。
- 性能：画面の表示時間や、同時アクセス数などの処理能力
- セキュリティ：個人情報の保存方法や、アクセスログの保管期間
社内の合意形成と要件確定の進め方
追加開発の要件定義でつまずく原因の多くは、技術ではなく社内の意見対立にあります。現場は使いやすさを求め、経営はコストを抑えたがり、情報システム部門は既存システムへの影響を懸念します。
立場の違いを乗り越えて要件を確定させる合意形成術こそ、競合がほとんど触れない、追加開発の要件定義の核心です。
立場の異なる関係者をまとめる合意形成術
優先順位を全員で決めるプロセスがあれば、後から「自分の意見が反映されていない」という不満が出にくくなります。要件定義は、機能を決める作業であると同時に、社内の合意を作る作業でもあります。
大塚商会のフィッティングコンサルの事例では、約5.5か月で40回弱の打ち合わせを重ね、開発費の5〜6%をコンサルに充てて要件を磨き込んでいます。
大塚商会の事例は、要件定義と合意形成に相応の時間と費用をかけることが、結果として開発全体の成功につながることを示しています。
要件定義を軽視して急いで開発に入ると、後から手戻りが頻発し、かえって時間と費用がかさみます。だからこそ、合意形成への投資は、追加開発で最も確実な対策になります。
合意形成のコツは、各関係者の関心事を要件定義書の中で見えるようにすることです。関心事の共有から優先順位の決定へと、順に進めます。
- 関心事の共有：現場・経営・情報システム部門の関心を要件定義書に書く
- 優先順位の決定：限られた予算の中で、何を先に実現するかを全員で決める
現場の使いやすさ、経営のコスト、情報システム部門のリスク管理は、三者それぞれの関心です。
議事録と検収条件による認識ずれの防止
要件定義の合意は、必ず記録に残します。この地道な記録が、後のトラブルを防ぐうえで最も効きます。
スルガ銀行と日本IBMの事件では、初期見積り約95億円に対し追加で127億円が要求され、最終的に高裁が約41.7億円の支払いを命じる事態となりました。
訴訟記録は72冊に及び、打ち合わせの「箸袋」のメモまで証拠として扱われたと言われます。とくに、何が合意され、何が合意されていなかったかを記録で示せるかどうかが、紛争の行方を左右したといえます。
合意形成と並んで欠かせないのが、検収条件をあらかじめ定めておくことです。追加開発した機能が「完成した」と認める基準を、要件定義の段階で文書に書いておきます。
たとえば、どんなテストに合格すれば検収とするのか、既存機能が壊れていないことをどう確認するのかを決めておきます。この検収条件が曖昧だと、リリース後に「これは完成ではない」「いや要件は満たしている」という水掛け論になりかねません。
要件定義書に検収条件まで書き込んでおけば、追加開発を双方が納得する形で終えられます。
認識のずれを防ぐには、打ち合わせの決定事項と検収の基準を記録しておきます。
- 打ち合わせの決定事項：議事録にまとめ、双方で確認した内容
- 検収の基準：合格とするテストと、既存機能の確認方法
まとめ
追加開発のRFP・要件定義を振り返ると、その本質は「既存システムの現状を正確に伝え、追加するスコープを明確に線引きし、非機能要件を数値で定め、合意と記録を徹底する」ことに集約されます。
既存の構成や制約をRFPに明記し、AsIsとToBeを併記してギャップを示します。そのうえで、稼働率99.9%か99.99%かといった品質レベルを、コストとの関係から数値で定めます。
そして、関係者の合意を作りながら、議事録と検収条件で認識のずれを防ぎます。これらを押さえれば、見積りは比較しやすくなり、予算超過や訴訟リスクも避けられます。
要件定義で大切なのは、「曖昧さを残さず、数値と記録で定める」という姿勢です。スルガ銀行と日本IBMの事件が示すように、合意の曖昧さは巨額の紛争を招きます。逆に、要件定義に時間と費用をかけた大塚商会の事例のように、丁寧な合意形成は開発全体の成功につながります。
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を創業。