配送管理システム刷新のアセスメント/要件定義/RFPについて

配送管理システムの刷新が失敗する原因の多くは、開発の腕前ではなく、その手前のアセスメントと要件定義、そしてRFP（提案依頼書）の甘さにあります。現行システムがブラックボックス化したまま要件をあいまいに発注すると、ベンダーごとに提案の前提がバラバラになり、見積りも比較できず、稼働後に「思っていた配送業務が回らない」という事態に陥ります。経済産業省のDXレポートが指摘したように、刷新失敗の大きな要因は「要件定義の不十分さ」であり、事前の資産棚卸しと現状分析の徹底が成否を分けます。

本記事では、配送管理システム刷新のアセスメント・要件定義・RFPについて、とくにRFPに盛り込むべき項目とベンダーの評価観点に焦点を当てて解説します。進め方そのものの全体像は配送管理システム刷新の完全ガイドに体系的にまとめていますので、あわせてご覧ください。本記事では、完全ガイドでは触れきれない「現状をどう可視化し、RFPに何をどう書き、提案をどんな観点で採点するか」という実務の勘所に踏み込みます。発注側が主導権を握り、フェアにベンダーを比較するための具体的な指針をお伝えします。

▼全体ガイドの記事
・配送管理システム刷新の完全ガイド

アセスメント：現状を可視化し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で表現します。配送管理であれば、配車計画の作成時間、誤配・誤出荷率、車両稼働率、保守費、伝票処理の工数などが代表的な指標です。製造業の事例が夜間バッチ8時間→90分、保守費年2,400万円→850万円という具体値で語られたように、刷新の成果は数値で握ってこそ評価できます。

機能要件は、前段で仕分けた優先度に従って「必須（Must）」「あると望ましい（Want）」を明確に区別します。すべてを必須にすると見積りが膨らみ、提案の幅も狭まります。逆に優先度を示さないと、ベンダーはどこに力を入れるべきか分からず、的外れな提案を返してきます。要件に優先度のラベルを付けることが、フェアな提案を引き出す前提になります。

配送管理システムは止まると即座に荷主や消費者へ影響が及ぶため、非機能要件の明示が欠かせません。求められる稼働率（可用性）、ピーク時の処理性能、障害時の復旧目標時間、データのバックアップとセキュリティ、そして繁忙期の負荷に耐えるスケーラビリティなどを具体的に定義します。これらをRFPに書いておかないと、提案の前提が揃わず比較できません。

あわせて、データ移行の要件も要件定義の段階で固めます。どのマスタ・履歴をどこまで移すか、移行時の業務停止をどれだけ許容できるか、新旧並行稼働の期間をどう設けるかといった点です。江崎グリコの基幹システム切り替えで移行計画の不備がチルド商品の全品出荷停止を招いたように、移行要件の甘さは事業停止に直結します。移行は「おまけ」ではなく、要件定義の主要テーマとして扱うべきです。

非機能要件で見落とされやすいのが、運用・保守の要件です。刷新後に誰がどの範囲を運用し、障害時の連絡体制や対応時間をどう取り決めるかを、要件定義の段階で明文化しておきます。配送は深夜や早朝にも稼働するため、24時間に近い保守体制を求めるのか、平日日中のみで足りるのかによって、ベンダーの提案も費用も大きく変わります。稼働後の運用像を具体的に描いておくことが、後の保守費の妥当性を判断する物差しにもなります。要件定義は「作るための仕様」であると同時に「使い続けるための仕様」でもあるのです。

RFP：盛り込むべき項目と提案依頼の書き方

アセスメントと要件定義が固まったら、いよいよRFP（提案依頼書）の作成です。RFPは、複数のベンダーに同じ条件で提案を求め、横並びで比較するための共通の物差しです。ここで情報を出し惜しみすると、提案の前提がばらつき、結局は比較できなくなります。本章では、配送管理システム刷新のRFPに盛り込むべき項目を整理します。

配送管理システム刷新のRFPには、少なくとも次の項目を盛り込みます。
・プロジェクトの背景と目的、刷新で達成したいKPI
・現行システムの構成図と業務フロー（アセスメント結果）
・機能要件（Must/Wantの優先度付き）と非機能要件
・データ移行の対象範囲と移行方針、新旧並行稼働の前提
・想定スケジュールと予算レンジ、契約・保守の条件

とくに重要なのが、現行構成図と業務フローを添付することです。ベンダーは現状が見えなければ正確な見積りを出せず、安全側に倒した高い金額を提示するか、リスクを見落とした安すぎる金額を出すかのどちらかになります。アセスメントで作った資料をRFPに添付することで、提案の精度と比較可能性が一気に高まります。予算レンジを示すことも、現実離れした提案を防ぐうえで有効です。

RFPを出す前に、提案をどう採点するかの評価観点を決めておくことが、フェアな選定の鍵です。金額だけで選ぶと、後から追加費用が膨らんだり品質が伴わなかったりします。配送管理システム刷新では、次の5つの評価観点を採点表に落とし込むことをおすすめします。

(1)同業界・同規模の配送・物流システムの刷新実績があるか
(2)新旧並行稼働など段階的な移行を設計できる力があるか
(3)移行時のダウンタイム（業務停止時間）を具体的に見積もれているか
(4)24時間365日に近い保守・運用体制を提供できるか
(5)ISO9001/27001など品質・セキュリティの認証や管理体制があるか

これらの観点に重み付けをして点数化すれば、複数ベンダーの提案を主観に頼らず比較できます。とくに配送は止められない業務であるため、(2)の段階移行の設計力と(3)のダウンタイム見積りは重く評価すべきです。提案の安さに飛びつくのではなく、移行を安全に倒せるかどうかを採点の軸に据えることが、刷新の成否を分けます。評価観点を事前にRFPへ明記しておけば、ベンダー側もそこに応える提案を出してくるため、提案の質そのものが底上げされます。

RFPを配布したら、提案を受け取って終わりではありません。提案内容を正しく見極めるためのプロセス設計も、発注側の重要な仕事です。まず、各ベンダーからの質問を受け付ける質疑応答の期間を設け、寄せられた質問と回答は全ベンダーへ共有します。一部のベンダーだけが追加情報を持つ状態をなくすことで、提案の前提を揃え、公平な比較を担保できます。

提案を受領したら、採点表に沿って評価し、上位候補に対しては提案内容のプレゼンテーションと質疑の場を設けます。書面だけでは分からない実装方針や移行の考え方、担当者の力量を確認できるからです。配車最適化のように要となる機能については、小規模な検証（PoC）を依頼し、自社の実データで期待どおり動くかを確かめる方法も有効です。机上の提案と実際の動きには差が出やすいため、重要機能ほど動かして確かめる姿勢が失敗を防ぎます。

最終選定では、金額・機能・移行設計・保守体制・実績を採点表で総合し、社内の関係部門が納得する形で意思決定します。配送現場の代表を評価に加えると、「現場で本当に使えるか」という視点が選定に反映され、稼働後の定着リスクを下げられます。RFPからベンダー選定までを一貫したプロセスとして設計することが、刷新を成功へ導く上流工程の総仕上げになります。

まとめ

本記事では、配送管理システム刷新のアセスメント・要件定義・RFPを、発注側が主導権を握るための実務の観点から解説してきました。アセスメントでは資産と配送固有のルールを可視化し費用感を見立てること、要件定義では達成すべきKPIと非機能・移行要件を数値と優先度で固めること、RFPでは現行構成図を添付し5つの評価観点で提案を採点することが、それぞれの肝でした。これらは一連の流れとしてつながっており、上流の精度が下流の品質を決めます。

刷新の失敗の多くは要件定義の甘さに起因します。逆にいえば、現状を丁寧に可視化し、KPIと評価観点を明確にしたRFPを用意できれば、ベンダー選定でつまずくリスクは大きく下がります。本記事のアセスメント観点とRFP項目、評価採点の枠組みを自社の刷新計画に当てはめて準備を進めてください。進め方の全体像や費用相場をさらに確認したい場合は、完全ガイドもあわせて活用いただくと、上流工程の解像度がいっそう高まります。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。