業務システムの開発を発注する段になって、多くの担当者が直面するのが「RFP（提案依頼書）や要件定義書に、何をどこまで書けばいいのか分からない」という壁です。要件が曖昧なまま開発を進めると、完成したシステムが現場と噛み合わず、追加費用や納期遅延を招きます。実際、要件が曖昧だと工数が1.3〜1.5倍に膨張するというデータもあり、RFPと要件定義の精度こそが、業務システム開発の成否を最初に決定づける要素なのです。
本記事は、業務システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から具体的に解説する「要件定義特化」の解説です。RFPに盛り込むべき記載項目、見落とされがちな非機能要件の固め方、機能要件を漏れなく洗い出す手順、そして提案・見積もりの妥当性をチェックする観点まで、実務に直結する形で掘り下げます。なお、業務システムの費用相場や全体の進め方をまだ把握していない方は、まず業務システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・業務システムの完全ガイド
業務システムのRFPに盛り込むべき記載項目
RFP（提案依頼書）は、複数のベンダーに同じ条件で提案を依頼し、横並びで比較するための文書です。RFPの質が低いと、ベンダーごとに前提がバラバラの提案が返ってきて比較できず、見積もりの精度も落ちます。逆に必要項目を網羅したRFPを作れれば、ベンダーは自社の要望を正確に理解し、精度の高い提案と見積もりを返してくれます。まずはRFPの骨格となる記載項目を押さえましょう。
背景・目的・解決したい課題を明文化する
RFPの冒頭で最も重要なのが、プロジェクトの背景・目的・解決したい課題を明文化することです。「Excelの手作業が限界」「属人化を解消したい」「受発注から請求までを自動化したい」といった現状の課題と、それをシステムで「どういう状態にしたいか」というゴールを言葉にします。ここが曖昧だと、ベンダーは機能の表面だけを見て提案するため、本質的な課題解決につながりません。
目的は、できる限り定量的に書くことが望ましいです。「受注処理の工数を年間3,000時間削減する」「月末締めを3日から1日に短縮する」といった数値目標があると、ベンダーはそのゴールから逆算した提案ができます。同時に、これらの数値は完成後の効果測定の基準にもなります。発注を検討する企業の約4〜5割が「費用対効果が測りにくい」を課題視している現実を踏まえれば、目的の定量化は投資判断とRFPの両方で核になる作業です。
予算・納期・体制・前提条件を明記する
RFPには、予算感・希望納期・自社の体制・前提条件も明記します。予算を一切示さないと、ベンダーは適切な規模感を測れず、過剰なフルスクラッチ提案や、逆に安すぎて品質を犠牲にした提案が返ってくることがあります。「概算で○○○万円規模」と幅を示すだけでも、提案の方向性が揃います。小規模なら300万〜800万、中規模なら800万〜2,500万といった相場感を持っておくと、予算提示の妥当性も判断できます。
納期と体制も重要な前提です。「いつまでに稼働させたいか」「自社からプロジェクトに何人関われるか」「既存システムや使用中のSaaSは何か」といった条件は、ベンダーが提案を組み立てるうえで欠かせません。とくに、自社側の体制が弱いとプロジェクトは失敗しやすくなります。要件定義に現場を巻き込めるか、決裁者がコミットできるかを正直に書いておくことで、ベンダーは伴走の度合いを含めた現実的な提案ができます。前提条件の透明性が、後のトラブルを防ぎます。
見落とされがちな非機能要件の固め方
要件定義で最も見落とされやすく、かつトラブルの原因になりやすいのが非機能要件です。非機能要件とは、機能そのものではなく「どれだけ速いか」「どれだけ安全か」「どれだけ止まらないか」といったシステムの品質を定める要件です。ここの解像度が低いと、リリース後に「遅い」「落ちる」「セキュリティが不安」といった問題が噴出します。非機能要件こそ、要件定義の腕の見せどころです。
レスポンス・データ量・同時接続数を定める
性能に関する非機能要件は、具体的な数値で定めることが肝心です。「一覧表示は3秒以内に返す」「ピーク時に同時に何人がアクセスするか」「データは年間どれだけ増え、何年分を保持するか」といった条件を明示します。業務システムは、運用を続けるほどデータが蓄積されるため、初期は快適でも数年後に遅くなることがあります。将来のデータ増加を見込んだ性能要件が、長く使えるシステムの前提です。
これらの数値を曖昧にすると、ベンダーは最小構成で見積もり、後から「想定外の負荷で性能が出ない」「追加のインフラ費用がかかる」という事態になりがちです。逆に過剰に高い要件を求めると、不要なコストが乗ります。自社の実態に即した数値を現場から拾い、ベンダーと擦り合わせることが、コストと性能のバランスを取る鍵です。性能要件は、稼働後のリアルな隠れコストにも直結するため、見積もり段階で必ず詰めておくべき項目です。
セキュリティ・可用性・SLAと保守範囲を定める
セキュリティと可用性も、非機能要件の柱です。アクセス制御、通信の暗号化、データのバックアップ頻度、障害時の復旧目標時間などを定めます。とくに業務システムは事業の基盤となるため、止まったときに何分で初動するか、どれだけのデータ損失まで許容できるかを、SLA（サービス品質保証）として明文化しておくことが重要です。これを曖昧にすると、障害時に「保守の範囲か別料金か」で揉めます。
あわせて、稼働後の保守範囲をRFPの段階で定義しておくべきです。法改正への対応、OSやライブラリのアップデート、脆弱性が見つかったときの対応が、保守契約の範囲内なのか別料金なのかを事前に決めておかないと、後で想定外の費用が発生します。保守費は年で開発費の15〜25%が相場とされます。この継続コストとSLAの条項を契約前に明確にすることが、稼働後の安心と隠れコストの抑制に直結します。
機能要件を漏れなく洗い出す手順
RFPの後、ベンダーと進める要件定義の中核が、機能要件の洗い出しです。機能要件は「システムに何ができるべきか」を一つひとつ言語化する作業で、ここでの抜け漏れが後の追加開発や手戻りを生みます。工数比で見ると要件定義は全体の約20%、工期比では約25%を占めるとされ、それだけ重い工程です。漏れのない洗い出しの手順を押さえましょう。
現状業務（AsIs）を可視化しToBeを描く
機能要件を洗い出す出発点は、現状の業務フロー（AsIs）を可視化することです。受注担当者、営業、経理、現場作業者など、関係者に「実際にどう業務を回しているか」を細かくヒアリングし、誰が・いつ・何を・どう処理しているかを業務フロー図に落とします。この可視化を飛ばして理想論で機能を決めると、現場の実態と乖離したシステムになり、使われません。
現状を可視化したら、次に「あるべき業務の姿（ToBe）」を描きます。AsIsの無駄や手戻りを洗い出し、システムでどう改善するかを設計するのです。ここで重要なのは、現場の非協力を放置しないことです。非協力的な現場を要件定義に引っ張り出さないと、リリース直前に「こんなはずではなかった」というちゃぶ台返しが起きます。現場を巻き込み、ToBeを共同で描くことが、機能要件の質と現場定着の両方を担保します。
機能の優先順位を決めスコープを固める
機能を洗い出すと、必ず「あれもこれも欲しい」と要望が膨らみます。ここで優先順位をつけずに全部を盛り込むと、費用が膨張し、納期も延びます。「必須（Must）・あると良い（Should）・将来でよい（Could）」のように機能を仕分け、初期リリースのスコープを明確に固めることが重要です。まずMVP（最小限の機能を持つ製品）で出し、効果を見ながら段階的に拡張する進め方が、失敗を避ける王道です。
スコープを固めることは、仕様変更の多発（スコープクリープ）を防ぐ意味でも重要です。開発途中で次々と機能が追加されると、工数も費用も際限なく膨らみます。要件定義の段階で「今回はここまで」という線を引き、それ以降の追加は変更管理プロセスに乗せて費用と納期への影響を都度評価する。この規律が、業務システム開発を予算内・納期内で完了させる前提条件です。要件の確定こそ、プロジェクト全体を律する出発点になります。
規模に応じて要件の粒度を調整する
機能要件を洗い出す粒度は、システムの規模によって調整するのが現実的です。小規模なシステムであれば、主要な業務フローと必須機能を中心に固め、細部は開発を進めながら詰めても回ります。一方、大規模なシステムでは、部署をまたぐ業務や他システムとの連携が複雑に絡むため、要件定義の段階で詳細まで詰めておかないと、後工程での手戻りが致命的になります。規模が大きいほど、要件定義に割く工数と期間を厚く取るべきです。
工程全体で見ると、要件定義は工数比で約20%、工期比で約25%を占めるとされます（IPAのソフトウェア開発データ白書）。残りの約80%が設計からテストまでに費やされる以上、入口である要件定義の精度が後工程の効率を大きく左右します。要件が曖昧なまま進めると工数が1.3〜1.5倍に膨らむというデータも、この入口の重さを裏づけます。規模に見合った粒度で要件を固めることが、手戻りを抑え、見積もりの精度を高める近道です。
提案・見積もりの妥当性をチェックする観点
RFPを出し、要件をまとめた後に待っているのが、ベンダーからの提案と見積もりの評価です。ここで「金額の安さ」だけで判断すると、後から追加請求が膨らんだり、品質を犠牲にされたりするリスクがあります。見積もりの内訳を読み解き、妥当性を見極める観点を持つことが、賢い発注の最後の関門です。
そもそも、精度の高い見積もりは精度の高いRFPと要件があって初めて返ってきます。前提が曖昧なまま提案を求めると、ベンダーは安全側に倒して工数を多めに積むか、逆に見積もり漏れを起こすかのどちらかになりがちです。発注を検討する企業の約4〜5割が「費用対効果が分からない・測りにくい」を課題視しているとされますが、その不透明さの多くは、要件と前提の解像度の低さに起因します。見積もりを正しく評価する力は、ここまで述べてきたRFPと要件定義の積み重ねの上に成り立つものです。
人月単価と工数の内訳を確認する
業務システムの費用は「人月単価×工数」で決まるのが基本です。見積もりを評価する際は、この内訳を確認します。人月単価は職種や体制で幅があり、PMで110万〜150万、SE（設計）で65万〜110万、PG（実装）で50万〜90万程度が目安です。発注先の規模でも変わり、フリーランスは50万〜80万、中小開発会社は80万〜120万、大手SIerは150万〜200万といった水準です。この相場感を持っておくと、提示された単価の妥当性を判断できます。
工数の内訳も重要なチェックポイントです。要件定義・設計・実装・テスト・移行といった工程ごとに、どれだけの工数が割かれているかを見ます。極端にテストや要件定義の工数が薄い見積もりは、品質リスクの兆候です。請負契約では人月計算に1.3〜1.5倍の係数を掛け、リスクバッファとして全体の10〜20%を見込むのが一般的とされます。これらが盛り込まれているかも、見積もりの現実性を測る材料になります。
安すぎる見積もりと隠れコストを見抜く
相場より極端に安い見積もりには注意が必要です。安さの裏には、後からの追加請求、品質の低下、必要な工程の省略が潜んでいることがあります。「この金額で本当にこのスコープが収まるのか」を、内訳と照らして冷静に判断してください。安さ単独でベンダーを選ぶのは危険であり、同業界・同規模の実績、技術力や品質保証、要件定義から保守まで一貫して対応できる体制を総合的に評価すべきです。
見積もりで見落とされがちなのが、初期開発費以外の隠れコストです。クラウドの月額利用料、外部APIの利用料、ライセンス費、そして年で開発費の15〜25%にのぼる保守費は、リリース後に毎月のしかかります。提案を比較する際は、初期費用だけでなく、この継続コストを含めた総保有コスト（TCO）で評価してください。隠れコストを事前に試算し、似たケースの実額で見通しを立てることが、後悔しない投資判断につながります。
AI時代の検収基準と要件定義の押さえどころ
近年は、生成AIを使った開発が急速に広がり、業務システムの要件定義や検収にも新しい論点が加わっています。AIがコードの一部を生成したり、システム自体がLLM（大規模言語モデル）を内部に組み込んだりするケースが増えました。従来の「仕様どおり動くか」という検収だけでは、AI特有のリスクを見逃します。要件定義の段階で、AI時代ならではの検収基準を織り込んでおくことが、新たな備えとして重要になっています。
AI生成コードの品質と責任の所在を検収基準に入れる
AIにコード生成を任せる開発（いわゆるVibe Coding）は、スピードを上げる一方で、生成コードの品質を人がきちんと検証しないと、脆弱性やバグが紛れ込むリスクをはらみます。「動いているように見えるが、内部に穴がある」という事態を避けるには、要件定義の段階で「AI生成部分も含めてセキュリティレビューとテストを行う」ことを検収基準として明文化しておくべきです。誰がコードの品質に責任を持つのかを、契約と検収の両面で曖昧にしないことが肝心です。
あわせて、生成コードの著作権やバグが起きたときの責任の所在も、事前に整理しておきたい論点です。AIが生成したコードを誰が保証するのか、不具合が発生したときの修正責任はどこにあるのかを、RFPや契約で確認します。新しい技術ほど、後から「想定していなかった」というトラブルになりがちです。要件定義の段階で検収項目に落とし込んでおくことが、AI活用の恩恵を安全に受け取る前提になります。
LLM搭載システムのハルシネーション許容範囲を定める
業務システムにLLMを組み込む場合、避けて通れないのがハルシネーション（もっともらしい誤回答）への対応です。AIは確率的に文章を生成するため、常に100%正しい出力を保証できません。要件定義では「どの程度の誤りまで許容するか」「誤りが致命的な業務では人の確認を必須にするか」といった、ハルシネーションの許容範囲と運用ルールを定めておく必要があります。検収基準にこの観点がないと、稼働後に「AIが間違えた」という想定外のトラブルにつながります。
具体的には、AIの出力に対して根拠を提示させる、重要な判断は人が最終承認する、誤回答の発生率を計測して一定以下に抑える、といった条件を検収項目に組み込みます。これは従来の機能要件・非機能要件に加わる、AI時代特有の品質基準です。業務システムは事業の基盤であるからこそ、AIの不確実性をどう制御し、どこで人が介在するかを要件定義で線引きしておくことが、安心して使える仕組みづくりの鍵になります。
まとめ
業務システムのRFP・要件定義書・提案依頼書を整理すると、背景・目的・予算・前提を明記するRFPの記載項目、レスポンス・セキュリティ・SLAといった見落としがちな非機能要件、AsIsの可視化からToBeを描きスコープを固める機能要件の洗い出し、そして人月単価と隠れコストを見抜く見積もりの妥当性チェック、という流れで捉えられます。要件が曖昧だと工数が1.3〜1.5倍に膨張するというデータが示すとおり、ここの精度こそが業務システム開発の成否を最初に決めます。
RFPと要件定義は、ベンダーに丸投げするのではなく、自社が主体的に課題と目的を言語化することから始まります。現場を巻き込み、非機能要件まで解像度を上げ、見積もりを内訳から評価する。この一手間が、後の追加費用や炎上を防ぎます。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を創業。