既存システムへの追加開発を外部に依頼するとき、最初の関門となるのがRFP（提案依頼書）と要件定義です。新規開発と違い、追加開発では「すでに動いているシステムに、何を、どこまで足すのか」を正確に伝えなければ、見積りもばらつき、リリース後に既存機能を壊すトラブルにもつながります。にもかかわらず、追加開発のRFPや要件定義書を具体的にどう書けばよいかを解説した情報は驚くほど少なく、多くの担当者が手探りで進めているのが実情です。
本記事は、追加開発のRFP・要件定義書・提案依頼書の書き方を、発注企業の視点から具体的に掘り下げる「要件定義特化」の解説です。RFPに盛り込むべき項目と粒度、既存システムの情報をどう整理して渡すか、機能要件と非機能要件をどう書き分けるか、稼働率99.9%と99.99%でコストがどう変わるかといった非機能要件の定量化、そして社内の意見対立をどうまとめるかまで、一次データとあわせて実務的に解説します。読み終えるころには、自社で追加開発のRFPを書き始められるはずです。なお、追加開発の全体像をまだ把握していない方は、まず追加開発の完全ガイドから読むことをおすすめします。
既存システムの現状をRFPに整理する方法
追加開発のRFPが新規開発と決定的に違うのは、「すでに動いている既存システムがある」という点です。ベンダーは、既存システムの構成や制約を知らなければ、追加開発の難易度も工数も正しく見積もれません。したがって、RFPの最初の仕事は、既存システムの現状を整理して伝えることになります。ここを丁寧にやるかどうかで、見積りの精度が大きく変わります。
既存の構成・技術スタック・制約を明記する
RFPに既存システムの現状を整理するとき、最低限明記したいのは、システムの全体構成、使われている技術（プログラミング言語やデータベースなど）、外部システムとの連携先、そして変更できない制約条件です。たとえば「基幹システムとは夜間バッチで連携している」「特定のサーバー環境でしか動かない」といった制約は、追加開発の設計を大きく左右します。これらを書かずに見積りを依頼すると、ベンダーは前提を推測するしかなく、結果として見積りが各社でばらばらになります。
現状を整理する作業は、同時に既存システムの「属人化」を解消する機会にもなります。仕様が特定の担当者の頭の中にしかない状態だと、その人が異動や退職をした瞬間に、追加開発が極めて困難になります。RFP作成のタイミングで既存の構成や仕様を文書化しておけば、今回の追加開発だけでなく、将来の機能追加もスムーズになります。なお、こうした影響範囲調査や既存仕様の文書化といった土台の仕組みについては『追加開発の必要機能や標準機能の一覧について』もあわせてご覧ください。
現状（AsIs）と目指す姿（ToBe）を併記する
RFPでは、既存システムの現状（AsIs）と、追加開発で実現したい姿（ToBe）を併記すると、ベンダーに意図が正確に伝わります。今の業務がどう回っていて、どこに課題があり、追加開発でどう改善したいのか。この「現状と理想のギャップ」こそが、追加開発で足すべき機能の正体です。ギャップを明確に示すことで、ベンダーは的確な提案を返しやすくなります。
AsIsとToBeの併記が重要なのは、過去の失敗事例が教えてくれます。現場の業務ヒアリングやToBeモデルの作成を怠ってベンダーに丸投げした結果、完成したシステムが現場に使われず廃止になった事例は珍しくありません。RFPの段階でToBeを明確にしておけば、こうした「作ったのに使われない」という最悪の事態を避けられます。現状の課題と目指す姿を言語化する作業は、面倒に見えても、追加開発の成否を分ける最も価値ある工程なのです。
RFPに盛り込む項目と要件の粒度
RFPに何を、どのくらいの細かさで書くかは、多くの担当者が悩むポイントです。細かすぎると作成に時間がかかり、ベンダーの提案の自由度も奪います。逆に粗すぎると、各社の見積り前提がばらつき、比較できなくなります。ここでは、追加開発のRFPに盛り込むべき項目と、適切な粒度の考え方を整理します。
追加開発のRFPに必須の項目一覧
追加開発のRFPに盛り込むべき項目は、おおむね次の通りです。
・プロジェクトの背景と目的（なぜ今この追加開発が必要か）
・既存システムの構成・技術・連携先・制約
・追加・改修したい機能の概要（ToBeのイメージ）
・スコープの範囲（今回やること／やらないこと）
・非機能要件（性能・可用性・セキュリティなど）
・予算感とスケジュール、希望する契約形態
・提案してほしい内容（体制・進め方・見積り内訳）
とくに「やらないこと」を明記する点が、追加開発のRFPでは重要です。スコープの境界を最初に示しておくことで、後から「これもやってくれるはず」という認識のずれを防げます。
見積り内訳の提示を求めることも忘れてはいけません。追加開発の費用は約8割が人件費であり、上級SEは100〜160万円、初級SEは60〜100万円、下請けや個人では40〜60万円と、人月単価には大きな幅があります。誰がどのフェーズに何人月かかわるのかを内訳で示してもらえば、見積りの妥当性を判断しやすくなります。総額だけの見積りでは、各社の前提が見えず、適正価格かどうかも分かりません。
粒度の決め方とスコープ管理の勘所
要件の粒度は、「ベンダーが工数を見積もれる程度に具体的で、かつ実装方法までは縛らない」のが理想です。たとえば「在庫が一定数を下回ったら担当者に通知する機能を追加したい」という粒度であれば、何を実現したいかは明確で、技術的な実現方法はベンダーの提案に委ねられます。逆に画面の細部まで指定すると、RFPの作成負荷が増え、より良い提案の余地も狭まります。
スコープ管理で最も避けたいのが、無制限な仕様変更による工数増です。一次データでも、無制限な仕様変更が工数増を招き予算超過につながると指摘されています。これを防ぐには、RFPの段階で「今回のスコープ」と「将来検討するスコープ」を分けて示し、追加要望が出たときは費用と納期への影響を明示して合意し直す、というルールをあらかじめ決めておくことです。柔軟さが必要なフェーズもありますが、その柔軟さがコスト管理の放棄になってはいけません。スコープの線引きこそ、追加開発の予算を守る生命線です。
機能要件と非機能要件の定量化
要件定義書では、要件を「機能要件」と「非機能要件」に分けて書きます。機能要件は「何ができるか」、非機能要件は「どのくらいの品質・性能で動くか」を定めるものです。とくに非機能要件は、見積りに大きく影響するにもかかわらず曖昧に書かれがちで、ここを定量化できるかどうかが、追加開発のRFP・要件定義の質を分けます。
稼働率99.9%と99.99%のコスト差を理解する
非機能要件の代表が、システムの可用性（止まらずに動き続ける度合い）を示す稼働率です。「できるだけ止まらないように」という曖昧な書き方ではなく、「稼働率99.9%以上」のように数値で定めることが重要です。そして、この数値の差がコストに直結する点を理解しておく必要があります。稼働率99.9%は年間で約8.8時間の停止を許容するのに対し、99.99%では約53分まで停止を減らす必要があり、後者を実現するには冗長化や監視の仕組みに大きな追加投資が必要になります。
追加開発のコストは「機能数×品質レベル」で決まり、品質を高めるほど費用が跳ね上がります。一次データによれば、品質レベルが低なら基準費用の50〜70%、中なら100〜150%、高なら200〜400%と、品質の設定次第で費用が数倍に変わります。つまり、過剰な非機能要件は予算を大きく圧迫します。本当に99.99%の可用性が必要なのか、99.9%で十分なのかを業務の重要度から見極め、必要な品質だけを定量的に要件化することが、追加開発の予算最適化の鍵になります。
性能・セキュリティ要件を数値で書く方法
稼働率以外の非機能要件も、できる限り数値で書きます。性能要件であれば「画面の表示は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・要件整理から、社内合意の伴走までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。