要件定義は、試算の目的とKPIを決め、使えるデータと機能を整理し、RFPで提案を比べる順に進めます。この順で進めると、現場の判断に役立つ仕組みにつながります。
要件定義書とRFPの作り方を、発注企業の立場から説明します。全体像はシミュレーションシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・シミュレーションシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
試算の目的とKPIから要件を定める進め方
要件定義は、技術の検討より先に試算の目的をはっきりさせるところから始めます。目的が曖昧なまま機能を決めると、要件が膨らみ、見積りの判断基準も失われます。
要件が不明確なプロジェクトでは、開発費が30〜50%増えるという一次データもあります。そのため、目的の設定とKPIの定義を最初に固めておく必要があります。
試算対象と意思決定のひも付け
発注側は、どの業務のどの判断を良くしたいのかを一文で書けるようにしておく必要があります。「在庫を最適化したい」という言い方のままでは、何を判断したいのかが分からず、目的が漠然としたままです。
- 判断する人：試算結果を使って決める担当者
- 試算対象：どの業務で何を判断するかを定める
- 対象範囲：効果と実現性の高い領域から始める
たとえば、発注担当者が勘に頼らず、データに基づいて商品ごとの適正発注量を決める、という形まで具体化します。すると、試算対象、入力データ、出力結果も見えてきます。
候補は効果と実現性のマトリクスで整理し、両方が高い領域に絞ります。対象を欲張って広げると、要件が膨らみ、途中で頓挫するおそれがあります。
MVP（最小限の実用版）で在庫最適化に絞ると、開発費は200万〜300万円程度です。一方で、生産計画まで含める場合は、500万〜700万円規模になります。
目的の範囲は、そのまま費用を左右します。そのため、最初は対象を狭く深く定義することが、要件定義の基本です。
精度目標とKPIの数値定義
目的が定まったら、成果を測る指標（KPI）を数値で決めておきます。たとえば、廃棄ロスの削減率や計画立案時間の短縮が、成果のKPIにあたります。
- 成果のKPI：業務の成果を数値で測る指標
- 精度目標：需要予測の誤差など、合格ラインの数値
- 測定方法：担当者と頻度、確認する数値を取り決める
また、シミュレーション自体の精度目標も必要です。需要予測であれば、予測誤差をどの範囲に収めるかを要件に明記します。
目標がないと、ベンダーは完成の基準を判断できません。その結果、過剰な作り込みや、精度が不十分なままの納品といったリスクが生じます。
精度を1割上げるために、開発費が倍かかることも珍しくありません。そこで、実務で必要な精度を見極め、担当者の勘より良い結果を出せる水準から始めます。
完璧な予測より、現状より良い判断を素早く出すほうが、多くの場合は業務の価値につながります。KPIは、野心的すぎず、達成可能で測定できる水準に定めます。
運用後は、誰が、どの頻度で、どの数字を見て効果を判定するかを決めておきます。あわせて、導入前のベースラインとなる現状値も、要件定義の段階で記録しておきます。
比較基準がなければ、改善の度合いを客観的に示せません。だからこそ、KPIは設定して終わりにせず、運用中も継続して追える形に設計しておきます。
データ準備とデータ品質の要件化
データは、要件定義の段階で見落とされやすく、費用にも影響します。量や品質を把握しないまま進めると、開発の途中で使えるデータがないと分かり、手戻りが起きます。
データの実態を要件に反映することが、この段階の大事な仕事です。具体的には、発注側がデータの洗い出しと、整備費の予算化を進めます。
使えるデータの量・品質の洗い出し
早い段階で、シミュレーションに使えるデータの実態を洗い出しておきます。確認せずに要件を固めると、開発の開始後に不備が次々と分かります。
- 保管場所：紙やExcelにデータが散在していないか
- データ量：販売実績などが何年分あるか
- データ品質：在庫の正確さや形式の統一状況
データが社内に散らばっている場合は、収集と統合そのものがプロジェクトの大きな部分を占めます。さらに、データ品質が悪いと、開発費は20〜30%上昇するという一次データがあります。実態を早く把握しておくほど、見積りの精度が上がり、後の予算超過を防ぎやすくなります。
データの洗い出しは、見積りの妥当性を支える要件定義の中核となる作業です。RFPに保有データの種類・期間・品質の現状を可能な範囲で記載すれば、ベンダーはデータ整備の工数を適切に見積もれます。
データ整備費の予算計上
社内データの収集やクレンジングには、プロジェクト全体予算の2〜3割を要するとされます。データ整備費を見落とすと、後から予算が足りなくなります。
- 初期整備：収集・前処理の工数を独立項目にする
- 継続費用：更新や品質維持にかかる費用
- 運用体制：データを整え続ける担当と方法
RFPに「データ準備・前処理の工数」の欄を設けておくと、ベンダーはその分を見積もれます。その結果、現実的な予算計画につながります。
データ整備は一度で終わらず、運用中も続くコストです。たとえば、自社で開発を維持する場合、データクレンジングは月5万〜15万円かかります。
モデルのチューニングには、月10万〜30万円といった継続費用がかかります。そのため、初期費用だけでなく、運用時の更新や品質維持も見込んでおきます。
シミュレーションは、データを整え続けることで価値を保つものです。そのため、その前提を要件に含めておく必要があります。
Excel文化からの移行ロードマップ
非IT企業では、シミュレーション導入前の業務をExcelや紙で行っていることが多くあります。そこから一気に移行しようとすると、データの形式や粒度がばらばらで、要件定義の壁になります。
- 現行業務：Excelの試算ロジックを洗い出す
- 初期段階：現行の計算をシステムに載せ替える
- 次の段階：データ連携を自動化して鮮度を上げる
- 発展段階：高度な予測やシナリオ比較を加える
現行業務では、何を入力し、どんな計算をして、どの判断に使うかを言葉にしておきます。これを省くと、システム化の後に現場が「Excelのほうが速い」と言ってExcelへ戻るおそれがあります。
完成形を急がず、段階ごとの移行計画を要件定義に示しておきます。そうすると、各段階の予算と効果が見え、現場も無理なく新しい方法に慣れていけます。要件定義は、最終形の設計図であると同時に、移行の道筋でもあります。
機能要件と非機能要件の整理
目的とデータが固まったら、それを機能要件と非機能要件に落とし込みます。機能要件は「何ができるか」を、非機能要件は「どれだけ速く・安全に・安定して動くか」を定めるものです。
どちらも見積りと品質を左右します。なかでも非機能要件は、見落とされやすい項目です。
必須機能とオプション機能の優先度付け
機能要件は、機能の種類を整理したうえで、優先度を付けます。すべてを同じ扱いの必須要件にすると、見積りが膨らみ、開発も長期化します。
- 必須：最初のリリースに欠かせない機能
- あると望ましい：必要性を見極めて追加する機能
- 将来対応：段階的な追加を想定する機能
整理する対象には、パラメータ入力や計算エンジン、シナリオの保存・比較があります。結果の表示や外部連携も、この中に含まれます。優先度の基準は、先に定めた目的とKPIです。
たとえば、在庫最適化のために発注量を試算するなら、計算エンジンとシナリオ比較は必須です。一方で、凝った表示や多数の外部連携は後回しにできます。
各機能と目的・KPIの関係を要件定義書に記載すれば、ベンダーとの認識のずれを防げます。さらに、開発の途中で要件が増えていく（スコープクリープ）ことにも歯止めがかかります。
機能選定は目的から逆算し、初回は必要な機能に絞ります。残りを段階的に追加すれば、費用と納期を現実的な範囲に保てます。
性能・権限・セキュリティの非機能要件
非機能要件のうち、シミュレーションでは性能、とくに計算速度が使い勝手を左右します。そのため、条件を変えてから結果が返るまでの時間を定めておきます。
- 性能：応答時間と処理量の想定
- 権限管理：アクセス範囲の取り決め
- セキュリティ：マスキングやIdP連携の要否を示す
応答性能を決めないままだと、納品後に「遅くて使えない」という不満が出ます。性能要件は、現場の利用場面を想定して、具体的な数値で定めます。大量のデータやシナリオを扱う場合は、その処理に見合うインフラも検討しておく必要があります。
権限は役職や部門ごとに設計しておきます。シミュレーションは原価や投資計画などの機密データを扱うため、ガバナンスが曖昧なままだと、情報漏えいのリスクが残ります。
非機能要件を後から追加すると、大きな手戻りになります。機能要件と同じくらいの重みで詰めることが、安全で長く使えるシステムにつながります。
RFPに盛り込む項目と見積り妥当性の判断
要件が整理できたら、RFP（提案依頼書）にまとめて、複数のベンダーに提案を求めます。RFPの完成度が、提案の質と見積りの比較しやすさを左右します。そのため、RFPに盛り込む項目と見積りの評価方法を押さえておく必要があります。
RFPの記載項目とPoCの区切り
RFPには、提案に必要な自社の前提と、依頼する内容を記載します。データに依存する案件、たとえばシミュレーションでは、PoCを最初の段階に置く方法があります。
- 目的と前提：目的、KPI、対象業務、保有データの現状
- 依頼内容：機能要件と非機能要件
- 進行条件：希望スケジュール、予算感、評価基準
- PoC：精度を検証し、結果を見て本開発を判断する
段階的な進め方をRFPに示すと、ベンダーも現実的な提案をしやすくなります。とくにPoCは、期間を区切ることが大切です。
PoCの成功率は、3ヶ月以内で65%とされます。一方で、6ヶ月を超えると15%まで下がるため、長期化するほど成果が出にくくなります。
RFPには、PoCを3ヶ月で区切り、その時点で本開発へ移るかどうかを判断する条件を入れておきます。AIプロジェクトでは30%がPoC後に放棄されるという現実もあるため、期限と判断基準を先に定めておくことが、無駄な投資を防ぐ安全策になります。
TCOを前提にした見積りの妥当性判断
見積りは、初期開発費だけでなくTCO（総保有コスト）で評価します。TCOの約80%を運用・教育・データ整備が占め、初期費用は20%だという「TCOの80%ルール」が知られています。
- 初期と運用：初期費用と運用費を分けて示す
- 契約形態：請負と準委任の費用差を見る
- 予算バッファ：超過リスクに備えた余裕
初期費用が安く見えても、保守は月20万〜50万円、インフラは月10万〜30万円、データクレンジングは月5万〜15万円かかる場合があります。そのため、初期と運用を合わせた数年スパンの総額で比較するのが妥当です。
成果を事前に読みにくいシミュレーション案件を請負契約にすると、準委任の1.3〜1.5倍の係数がかかることがあります。たとえば500万円の想定なら、650万〜750万円に膨らむ場合があります。
この差は、リスクをベンダーに負わせる分が価格に転嫁されるためです。また、企業の85%がコストを10%以上見誤り、初年度に30〜40%の予算超過を起こすという統計もあります。
見積りには30〜40%のバッファを見込んでおきます。妥当性は単価の安さだけでなく、TCO、契約形態、バッファを踏まえて判断します。
複数ベンダーの提案の比較条件
複数のベンダーを同じ条件で比べるには、RFPの前提を明確にしておく必要があります。前提の記載が曖昧だと、各社が異なる条件で見積もるため、金額だけでは比べられません。
- 価格：金額と見積りの前提を確認する
- 内訳：費用項目ごとの金額を照らし合わせる
- リスク認識：データ課題やPoCの必要性を見る
機能要件やデータ整備などの費用を分けて提示するよう、RFPで指定しておきます。総額しか示されないと、内訳も妥当性も判断できません。
データに依存する案件では、ベンダーがデータの実態を理解し、現実的なリスクを提案に反映しているかどうかも判断材料になります。極端に安い見積りは、データ整備や運用の工数を読み違えている可能性があり、その場合、後から予算超過につながりかねません。
データ課題やPoCの必要性を率直に指摘するベンダーは、実態をよく理解していると評価できます。こうした観点を同じ基準で比べることが、外注先選定の失敗を防ぎます。
まとめ
シミュレーションシステムの要件定義は、試算の目的とKPIを決め、データと機能要件を整理して、RFPにまとめる流れです。要件が曖昧だと開発費は30〜50%増えるため、効果と実現性のマトリクスで対象を絞り込みます。精度目標は、野心的になりすぎず、達成可能な水準に定めることが出発点です。
データ整備費はプロジェクト予算の2〜3割を見込み、性能・権限・セキュリティも要件に含めます。また、PoCは3ヶ月で区切り、段階的な進め方をRFPに示します。
TCOの約80%を運用・教育・データ整備が占める前提で、初期費用と運用費を合わせた総額を比べます。そのうえで、請負契約の1.3〜1.5倍係数や、30〜40%の予算超過リスクも判断に含めます。
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を創業。