業務システムの発注は、課題と目的を明文化し、機能と非機能の要件を固め、提案と見積もりを内訳から評価する順に進めます。その結果、追加費用や手戻りを抑えやすくなります。
各段階の要点を順に見ていきます。全体像は業務システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・業務システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
業務システムのRFPに盛り込むべき記載項目
RFP（提案依頼書）は、複数のベンダーに同じ条件で提案を依頼し、横並びで比較するための文書です。
内容が曖昧だと、各社の前提がそろわず、提案を比べられません。さらに見積もりの精度も下がり、工数が1.3〜1.5倍に膨らむ場合があります。
そこで、まずRFPの骨格となる記載項目を押さえます。必要な項目を網羅しておけば、提案と見積もりの精度を高められます。
背景・目的・解決したい課題の明文化
発注側は、RFPの冒頭でプロジェクトの背景と目的、解決したい課題を明文化します。そのうえで、現状の困りごとと、システム導入後に実現したい状態を書き出します。
- 手作業の限界：Excelでの作業が限界に達している
- 属人化の解消：特定の担当者に頼っている業務を見直す
- 業務の自動化：受発注から請求までを自動化の対象にする
課題が曖昧なままだと、ベンダーは機能の表面だけを見て提案することになり、本質的な解決につながらないことがあります。
目的は、できる限り数値にしておきます。たとえば、受注処理を年間3,000時間削減する、月末締めを3日から1日に短縮するといった目標です。数値目標は、ベンダーがゴールから逆算して提案する材料になり、完成後の効果測定にも使えます。
発注を検討する企業の約4〜5割は、費用対効果を測りにくい点を課題視しています。だからこそ、目的の定量化は投資判断とRFPの核になります。
予算・納期・体制・前提条件の明記
発注側は、概算で○○○万円規模と幅を示すだけでも、提案の方向性をそろえられます。あわせて、納期や体制、前提条件も伝えます。
- 予算：概算の幅を示して、提案の規模感をそろえる
- 納期：希望する稼働時期
- 体制：自社から参加できる人数と、決裁者の関与
- 前提：既存システムと利用中のSaaS
予算が示されていないと、過剰なフルスクラッチの提案や、品質を犠牲にした安価な提案が返ってくる場合があります。
小規模は300万〜800万、中規模は800万〜2,500万という相場感が、提示された予算の妥当性を判断する材料になります。
自社側の体制が弱いと、プロジェクトは失敗しやすくなります。そこで発注側は、現場を要件定義に巻き込めるか、決裁者が関与できるかも伝えます。
体制を正直に示すと、ベンダーは伴走の度合いも含めて提案できます。前提条件を明らかにしておくことは、後のトラブル防止にも役立ちます。
見落とされがちな非機能要件の固め方
要件定義で最も見落とされやすく、トラブルの原因になりやすいのは非機能要件です。
非機能要件は、機能以外の品質を定めるものです。その解像度が低いと、リリース後に遅さや停止、セキュリティへの不安が表面化します。そのため、要件定義の段階で非機能要件を具体化します。
レスポンス・データ量・同時接続数の設定
性能要件は、現場の業務の実態に合わせて、具体的な数値で決めておきます。
- 応答時間：一覧表示を3秒以内に返す
- 同時接続数：ピーク時のアクセス人数を決める
- データ量：年間の増加量と保持年数の見込み
業務システムは、運用中にデータが蓄積していきます。初期は快適でも、数年後に遅くなる可能性があるため、増加を見込んで要件を定めておきます。
数値が曖昧だと、最小構成の見積もりでは負荷に耐えられず、追加のインフラ費用が発生することがあります。反対に、要件を過剰に高く設定すると、不要なコストが加わります。そこで発注側は、現場から実態に即した数値を集め、ベンダーと調整します。
性能要件は稼働後の隠れコストにも関わるため、見積もり段階で詰めておく必要があります。
セキュリティ・可用性・SLAと保守範囲の設定
セキュリティと可用性は、非機能要件のなかでも基本となる項目です。あわせて、障害時の対応と保守範囲もRFPで決めておきます。
- アクセスと通信：アクセス制御と通信の暗号化
- バックアップ：データの保存頻度
- 復旧目標：障害時の復旧時間と、許容できるデータ損失
- 保守範囲：法改正、OS・ライブラリ更新、脆弱性対応を、保守内か別料金かで事前に切り分ける
事業の基盤となる業務システムでは、障害時に何分で初動するかも、SLA（サービス品質保証）として明文化しておきます。
保守範囲が曖昧だと、障害が起きたときに保守内か別料金かで揉めることがあります。また、決めないままだと想定外の費用も発生する場合があります。
保守費は年で開発費の15〜25%が相場とされます。そのため、継続コストとSLAの条項は契約前に決めておくと、隠れコストを抑えられます。
機能要件を漏れなく洗い出す手順
RFPの後、ベンダーと進める要件定義の中核は、機能要件の洗い出しです。
機能要件は、システムに何ができるべきかを一つずつ言葉にしていく作業です。抜け漏れがあると、追加開発や手戻りにつながります。
要件定義は工数比で全体の約20%、工期比で約25%を占めるとされます。そのため、洗い出しは重要な工程として進めます。
現状業務（AsIs）の可視化とToBeの描き方
機能要件の出発点は、現状業務（AsIs）を可視化することです。まず、関係者に実際の業務の流れを聞き取ります。
- 関係者：受注担当、営業、経理、現場作業者など
- 確認内容：誰が、いつ、何を、どう処理するか
- 記録方法：業務フロー図に落とし込む
可視化を飛ばして理想論で機能を決めると、現場の実態とずれ、使われないシステムになるおそれがあります。
現状を整理したら、次に無駄や手戻りを洗い出します。そのうえで、システムでどう改善するかを示すToBe（あるべき業務の姿）を描きます。
現場を要件定義に招かないと、リリース直前に「こんなはずではなかった」と指摘が出る場合があります。現場を招いて進めることは、機能要件の質と現場への定着の両方を支えます。
機能の優先順位付けとスコープの確定
機能を洗い出すと要望が膨らみやすいため、優先順位をつけて、初期リリースの範囲を決めます。
- 必須（Must）：初期リリースに必要な機能
- あると良い（Should）：初期リリースに含めるかを検討する機能
- 将来でよい（Could）：効果を見ながら後から追加する機能
すべてを盛り込むと、費用が膨らみ、納期も延びます。そこで、MVP（最小限の機能を持つ製品）で出し、効果を見ながら段階的に拡張する方法があります。
範囲を決めておけば、仕様変更が多発する事態（スコープクリープ）を防げます。さらに、機能追加が続けば、工数と費用が際限なく膨らみます。
要件定義で「今回はここまで」と線を引いておき、後からの追加は変更管理の対象にします。その都度、費用と納期への影響を評価します。
この線引きが、予算内・納期内での完了を支えます。要件の確定は、プロジェクト全体の出発点にもなります。
規模に応じた要件の粒度調整
要件の粒度は、システムの規模に応じて調整します。
- 小規模：主要な業務フローと必須機能を固め、細部は開発中に詰める
- 大規模：部門間業務や他システム連携まで事前に詳細を固める
大規模では、後工程の手戻りが大きな影響を及ぼすため、要件定義の工数と期間を厚めに取る必要があります。
工程全体では要件定義が工数比約20%、工期比約25%を占めます（IPAのソフトウェア開発データ白書）。残りの約80%は設計からテストまでに費やされます。特に、入口の精度が後工程の効率を大きく左右します。
要件が曖昧なまま進むと、工数が1.3〜1.5倍に膨らむ場合があります。規模に合った粒度で定めれば、手戻りを抑え、見積もり精度を高められます。
提案・見積もりの妥当性をチェックする観点
提案を金額の安さだけで判断すると、後から追加請求が膨らんだり、品質が犠牲になったりするリスクがあります。
見積もりの内訳を読み解き、妥当性を見極める視点が、賢い発注の最後の関門です。
精度の高い見積もりには、精度の高いRFPと要件が欠かせません。前提が曖昧だと、工数を多めに積むか、見積もり漏れが起こりがちです。
発注を検討する企業の約4〜5割は、費用対効果を測りにくい点を課題視しています。要件と前提の解像度が、評価の土台になります。
人月単価と工数の内訳
業務システムの費用は、基本的に人月単価と工数を掛け合わせて決まります。そのため、見積もりでは単価と工数の両方の内訳を確認します。
- 職種別単価：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生成部分のセキュリティレビューとテスト
- 品質責任：コードの品質を誰が担うか
- 不具合対応：生成コードの保証と修正責任
「動いているように見えるが内部に穴がある」事態を防ぐには、検収基準を明文化し、契約と検収の両面で責任の所在をはっきりさせておくことが必要になります。
生成コードの著作権や不具合時の責任も、RFPや契約で事前に整理しておきます。新しい技術ほど想定外のトラブルになりやすいからです。
これらを検収項目に落とし込むことが、AI活用の恩恵を安全に受け取るための前提になります。
LLM搭載システムのハルシネーション許容範囲の設定
業務システムにLLMを組み込む場合は、ハルシネーション（もっともらしい誤回答）への対応が必要です。
AIは確率的に文章を生成するため、常に100%正しい出力を保証することはできません。そこで、誤りの許容範囲と運用ルールを要件定義で決めておきます。
- 許容範囲：どの程度の誤りまで許容するか
- 人の確認：誤りが致命的な業務では、人による確認を必須とする
- 出力の根拠：AIが出力とあわせて根拠を示す
- 最終承認：重要な判断は人が承認する
- 誤回答率：発生率を計測し、一定以下に抑える
検収基準にこの観点がないと、稼働後にAIの誤りが想定外のトラブルへつながることがあります。
これらは、従来の機能・非機能要件に加わる品質基準です。AIの不確実性を抑えつつ、人が関わる箇所を線引きしておきます。
まとめ
RFP・要件定義書・提案依頼書では、背景・目的・予算・前提をそろえ、レスポンスやセキュリティ、SLAなどの非機能要件も固めます。
機能要件は、AsIsを可視化してToBeを描き、スコープを定めます。見積もりは、人月単価や工数、隠れコストの面から妥当性を確かめます。
要件が曖昧だと工数が1.3〜1.5倍に膨らむ場合があるため、要件定義の精度が開発の成否を左右します。
RFPと要件定義をベンダー任せにせず、自社が課題と目的を言葉にするところから始めます。
現場を巻き込み、非機能要件を具体化し、見積もりの内訳を評価することで、追加費用やプロジェクトの炎上を防げます。
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を創業。