配送管理システム刷新は、アセスメント、要件定義、RFPの順に進めます。経済産業省のDXレポートも、要件定義の不足を失敗の要因に挙げています。特に、現状分析の徹底が成否を分けます。
発注側が主導する進め方を、段階ごとに説明します。全体像は配送管理システム刷新の完全ガイドもご覧ください。
▼全体ガイドの記事
・配送管理システム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント：現状の把握とRFPの土台づくり
RFPを書く前に、現状（AS-IS）のアセスメントを行います。現行システムの処理内容やロジック、利用データを客観的に洗い出すのが目的です。
現状が曖昧なままだと、RFPの要件もぼやけ、ベンダーは正確な見積もりを出せません。そのため、アセスメントの質がRFPの質を左右します。
従業員約1,200名の製造業では、COBOL基幹系の刷新にあたり、資産の洗い出しを起点にしました。この事例では、夜間バッチを8時間から90分に短縮し、保守費を65％削減できました。
配送管理システムのアセスメントで押さえる観点を、順に見ていきます。
資産の可視化と複雑度の把握
アセスメントでは、まず現行システムの資産を洗い出します。プログラムの本数、データベースのテーブル構成、外部システムとの連携I/Fを整理し、全体の規模と複雑さをつかみます。
- 処理ロジック：配車や運賃計算の仕組み
- 配送固有のルール：荷主別ルールや方面別の運賃テーブル
- 制約と連携：ドライバー資格、車格の制約、EDIのフォーマット
資産の複雑度や依存関係を可視化するツールもあります。たとえば、富士通の「ソフトウェア地図」を使うと、属人的な調査より網羅性を高められます。
配送固有のルールは仕様書に残っていない場合があり、ベテラン担当者の知識に限られることもあります。そのため、ヒアリングで暗黙知を文書化しておかないと、RFPに書けない要件が稼働後に表面化します。
アセスメントは、社内だけで完結させなくても構いません。現行システムが複雑で、自社に評価のノウハウがない場合は、専門コンサルタントや第三者へ分析を依頼できます。
要件定義・業務棚卸しだけなら、一般に200万〜500万円程度が相場です。この費用は一見無駄に見えても、手抜きで数千万円規模の手戻りが起き得ます。刷新全体の精度を高める先行投資として、元が取れる場合があります。
課題の優先度と費用感の見立て
資産を可視化したら、次に課題へ優先度を付けます。配車に時間がかかる、保守費が高い、データが分断されているといった課題を洗い出しておくと、後の判断材料になります。
課題は「効果の大きさ」と「現場への影響度」で順位を付けます。この順位が、RFPで求める要件の強弱につながります。
費用感をつかむには、刷新の規模や方式ごとの目安も見ておく必要があります。要件定義・業務棚卸しだけなら、一般に200万〜500万円程度です。
- 棚卸し・要件定義：刷新全体とは別の見積もり項目
- システム規模：単一業務か、周辺システムを含むかで幅が変わる
- 刷新方式：クラウド移行型か再構築型かで期間も異なる
単一の業務システム刷新は3,000万〜1.5億円が目安で、そのうち6〜7割をシステム構築費が占めます。基幹システムに複数の周辺システムを含める場合は、1.5億〜5億円が目安です。
クラウド移行型は数百万〜1,000万円台で、期間は3〜6ヶ月が目安です。一方、再構築型は2,000万円以上で、期間は12〜18ヶ月以上とされます。
アセスメントの段階でこうした相場感を持っておくと、RFPで現実離れした要望を出して提案がばらつく事態を防げます。さらに、後の比較も公平に行えます。
要件定義：刷新で実現するKPIと優先順位の確定
アセスメントで現状を把握したら、要件定義で刷新後の姿を決めます。機能を並べるだけでなく、達成したい成果をKPIで数値化しておくことが大切です。
KPIが明確であれば、RFPでベンダーに求める内容も絞り込めます。逆に「使いやすく」「全部新しく」といった要望では、提案や見積もりがばらつきます。
達成すべきKPIの数値化
刷新後に到達したい状態を、KPIで表現します。配送管理なら、配車計画の作成時間や誤配・誤出荷率が指標になります。
- 車両と費用：車両稼働率や保守費の目標値
- 業務工数：伝票処理の作業時間などの目標値
- 機能の優先度：前段で付けた順位に沿った、必須（Must）と、あると望ましい（Want）の区分
製造業の事例では、夜間バッチを8時間から90分に短縮し、保守費を年2,400万円から850万円に削減しました。こうした数値があると、刷新の成果を後から評価できます。
すべての機能を必須にすると、見積もりが膨らみ、提案の幅も狭まります。一方で、優先度がなければ、ベンダーは何に注力すべきかを判断できません。要件に優先度のラベルを付けることが、公平な提案を引き出す前提になります。
非機能要件と移行要件の明示
配送管理システムが止まると、荷主や消費者にすぐ影響が及びます。そのため、非機能要件を具体的に定めておく必要があります。
- 稼働と性能：稼働率とピーク時の処理性能
- 障害とデータ：復旧目標時間、バックアップ、セキュリティ
- 繁忙期対応：負荷に耐えるスケーラビリティ
- 移行と運用：切り替えの範囲、停止許容時間、保守体制
RFPに非機能要件を書かなければ、提案の前提がそろわず、比較もできません。また、データ移行では、移すマスタや履歴の範囲も決めておきます。
移行時に許容する業務停止時間や、新旧システムの並行稼働期間も定めておく必要があります。たとえば、江崎グリコでは基幹システムの移行計画に不備があったため、チルド商品の全品出荷停止を招きました。
移行要件が甘いと、事業停止に直結します。移行は、要件定義の主要テーマとして扱います。
運用・保守では、刷新後に誰がどの範囲を担うかを明文化します。障害時の連絡体制と対応時間も、あらかじめ決めておきます。
配送は深夜や早朝にも稼働するため、保守体制の範囲が問題になります。24時間に近い体制か、平日日中のみかで、提案と費用は大きく変わります。
運用の姿を具体化しておくと、稼働後の保守費を見通せます。要件定義では、作るためだけでなく、使い続けるための仕様も定めておきます。
RFP：盛り込むべき項目と提案依頼の書き方
アセスメントと要件定義が固まったら、RFP（提案依頼書）を作成します。RFPは、複数のベンダーに同じ条件で提案を求め、比較するための共通の物差しです。
情報が不足すると、提案の前提がばらつき、比べられなくなります。配送管理システム刷新のRFPでは、どの項目を盛り込むかを事前に決めておく必要があります。
RFPに必ず含めるべき項目
RFPには、プロジェクトの前提と依頼条件を記載します。次の資料や要件をそろえておくと、提案の比較にそのまま使えます。
- 目的とKPI：プロジェクトの背景と、達成したい成果の指標
- 現状資料：現行システムの構成図と業務フロー、アセスメント結果
- 要件：Must/Wantの優先度を付けた機能面と非機能面の内容
- 移行条件：データを移す範囲と方針、新旧並行稼働の前提
- 依頼条件：想定スケジュール、予算レンジ、契約と保守の取り決め
現行の構成図と業務フローがなければ、ベンダーは正確な見積もりを出せません。その結果、安全側に倒して高めの提示になるか、リスクを見落として安めの提示になるおそれがあります。
アセスメントで作成した資料を添付すると、提案の精度と比較のしやすさが高まります。また、予算レンジを示すことも、現実離れした提案を防ぐうえで有効です。
提案を採点する評価観点の事前設定
RFPを出す前に、提案の評価観点を決めておきます。金額だけで選ぶと、追加費用が膨らんだり、品質が伴わなかったりするおそれがあります。
配送管理システム刷新では、次の5つの観点を採点表にまとめます。
- 刷新実績：同業界・同規模の配送・物流システムの導入経験
- 移行設計：新旧並行稼働など、段階的な進め方を組み立てる力
- 停止時間：移行時のダウンタイム（業務が止まる時間）の具体的な見積もり
- 保守体制：24時間365日に近い運用対応の態勢
- 品質とセキュリティ：ISO9001/27001などの認証や管理体制
観点に重みを付けて点数化すれば、複数ベンダーの提案を主観に頼らず比べられます。配送業務は止められないため、段階的な移行の設計力と、停止時間の見積もりを重く評価します。
安さだけでなく、安全に移行できるかを採点で重視します。また、評価観点をRFPに明記すると、ベンダーの提案内容にも反映されます。
提案比較とPoC・質疑応答の進め方
RFPを配布したら、提案内容を正しく見極めるための進め方を設計します。これは発注側が担うべき重要な仕事です。最初に、ベンダーからの質問を受け付けます。
- 質疑応答の期間を設け、寄せられた質問と回答を全ベンダーへ共有する
- 採点表に沿って提案を評価し、上位候補にプレゼンテーションと質疑の場を設ける
- 必要に応じてPoCを依頼し、実データで重要機能の動きを確かめる
- 関係部門と配送現場の代表を交えて、評価結果をもとに最終選定する
質問と回答を全ベンダーに共有すると、一部のベンダーだけが追加情報を持つ状態を防げます。提案の前提がそろい、公平な比較ができます。
プレゼンテーションでは、書面だけでは分からない実装方針や移行の考え方、担当者の力量を確かめます。
配車最適化などの重要機能は、小規模な検証（PoC）を依頼できます。自社の実データで期待どおりに動くかを確かめる方法です。
机上の提案と実際の動きには差が出やすいため、重要機能ほど動かして確認します。最終選定では、採点表の結果を総合して判断します。金額や機能だけでなく、移行設計や保守体制、実績も見ます。
社内の関係部門が納得できる形で、意思決定を行います。配送現場の代表を評価に加えると、現場で使えるかという視点が入るため、稼働後に定着しないリスクを下げられます。
RFPの作成からベンダー選定までを一貫して設計することが、刷新を成功へ導く上流工程の仕上げになります。
まとめ
ここまで、アセスメント、要件定義、RFPを、発注側が主導権を握るための実務の観点で見てきました。
配送管理システム刷新では、アセスメントで資産と配送固有のルールを可視化し、費用感を見立てます。要件定義では、KPIや非機能要件、移行要件を数値と優先度で定めます。
RFPには現行の構成図を添付し、5つの評価観点で提案を採点します。上流工程で現状と条件をそろえておくことが、ベンダー提案の比較につながります。
アセスメント、要件定義、RFPは一連の流れでつながっており、上流の精度が下流の品質を左右します。
刷新の失敗の多くは、要件定義の甘さに起因します。現状を可視化し、KPIと評価観点を明確にした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を創業。