■ この資料でわかること
物流・基幹システムの刷新を検討する企業の多くが、RFP(提案依頼書)を「現行機能の一覧表」や「ベンダーへの見積依頼書」として扱ってしまい、結果として比較できない提案しか集まらない、あるいはプロジェクトそのものが頓挫するという事態に陥っています。
本資料では、システム刷新プロジェクトが崩壊に至る典型的な失敗パターンを実例とともに整理したうえで、RFPを書き始める前に社内で決めておくべきこと、そして発注者とベンダー双方の力を引き出し、各社の提案を同じ条件で比較・評価するためのRFPの作り方を具体的に解説します。
■ このような方におすすめ
- 物流・基幹システムの刷新を検討しているが、何から手をつければよいか分からない
- 過去にRFPを出したものの、ベンダーから比較しにくい提案しか返ってこなかった
- 要件定義の途中で現場からの追加要望が止まらず、プロジェクトが膨張した経験がある
- 経営層と現場の意見がまとまらず、システム刷新の意思決定が停滞している
- RFPを作成する前に、社内で何を決めておくべきか整理したい
はじめに
AIの急速な進化や新物流効率化法をはじめとした法規制の強化を背景に、ロジスティクス業界は今、大きな転換期を迎えています。
基幹システムやWMS・TMSの刷新を検討する企業も増えていますが、いざRFP(提案依頼書)を作成しようとした途端に手が止まってしまう、あるいは作成できたはずのRFPに対して集まった提案の質がバラバラで比較できない、という声が後を絶ちません。
「現行機能の一覧表を渡せばベンダーが良い提案を返してくれるはず」という期待は、残念ながら多くの現場で裏切られています。
RFPが単なる見積依頼書やベンダーへの丸投げの書類になってしまった瞬間、プロジェクトはすでに失敗への一歩を踏み出しているのかもしれません。
本資料では、そうした失敗の構造を解きほぐし、RFPを書き始める前に発注者側が準備すべきことを整理します。
RFPは「機能一覧」ではない
RFPを「機能一覧」だと思ってしまう罠
RFPと聞くと、多くの担当者は「現行機能の一覧表」「金額を聞くための見積依頼書」「とりあえず要望を並べた要望集」を思い浮かべます。しかしこの理解のままRFPを作成すると、ベンダーは各社バラバラの前提で提案を作成することになり、発注者は集まった提案を横並びで比較することすらできません。
RFPの本質は機能の網羅ではなく、刷新の目的と成功条件を社内で固め、「決めること」と「提案させること」を切り分け、各社を同じ条件で比較できる土台を作ることにあります。これは単なる書類作成の技術ではなく、社内の意思決定そのものを文書に落とし込む作業なのです。
失敗の多くは書く前の「準備段階」で起きている
興味深いのは、RFPにまつわるトラブルの多くが「文章力やフォーマットの問題」という書き方の話ではなく、書く前の準備段階に根があるという点です。
氷山に例えるなら、水面上に見えている「書き方の問題」はごく一部にすぎず、水面下には「決められない(刷新目的が定まらない、経営と現場の意見が合わない、最終判断者が不明確)」「整理できていない(現行機能をそのまま再現しただけになった、現場要望を全採用し要件が膨張した)」「伝えられない(移行・例外業務・非機能要件が漏れていた)」「評価できる状態にない(ベンダーごとに見積範囲が違い比較できない)」という、はるかに大きな塊が沈んでいます。
RFPを書く技術を磨く前に、この水面下の準備をどれだけ丁寧に行えるかが、プロジェクトの成否を分けています。
プロジェクトを破綻させた、現実の失敗パターン
手段の目的化と暗黙の期待が招いた破綻
実際に起きた事例を見ると、この「準備不足」がどれほど深刻な結果を招くかが分かります。
ある金融機関と大手ITベンダーの勘定系システム開発では、パッケージ導入そのものを前提に話を進めてしまい、自社業務との適合検証が不十分なまま頓挫しました。
教訓は明確です。製品や手段そのものを目的化せず、検証責任の所在と役割分担をRFPの段階で明文化しておく必要があります。
別の医療機関のケースでは、電子カルテ開発において現場の「現行踏襲」への期待があまりに強く、仕様凍結後も1,000件近い追加要望が発生し、開発が破綻しました。
「今と同じようにできるはず」という暗黙の期待ほど曖昧で危険なものはなく、凍結条件や変更管理のルールを厳格に定義しておくことが不可欠です。
スローガンでは要件は決まらない
別のパターンとして、上場準備を進めていたある企業のERP導入では、「業務効率アップ」「見える経営」といった抽象的なスローガンだけを掲げて要件定義に進んでしまい、目的が抽象的すぎるために具体的な要件を導き出せませんでした。
教訓は、経営方針から課題を特定し、明確な業務要件に落とし込める粒度まで「目的」の解像度を上げることです。
また、あるISP企業の基幹システム開発では、機能の記述が「主旨」レベルにとどまったために、発注者とベンダーの間で対象範囲の解釈が大きくズレてしまいました。
要求・境界・範囲を具体化しないまま進めることが、いかに危険かを物語る事例です。
失敗パターンに共通する、たった一つの真実
これらの事例に共通する根源を整理すると、「目的の抽象化」「ルールの未定義」「実現方式の目的化」「認識の齟齬」「当然機能の欠落」という5つの頻出パターンが浮かび上がります。
そしてこれらはすべて、突き詰めれば「目的・スコープ・前提条件の記述不足」という、たった一つの準備段階の甘さに集約されます。
つまりRFPは単なるベンダーへの依頼書ではなく、自社とベンダーの双方をプロジェクトの破綻から守る「防波堤」なのです。
RFPを書く前に、社内で決めておくべきこと
まずは自社の「現在地」を診断する
担当者が抱える悩みは、実は性質の異なる2種類に分かれます。ひとつは「決められない問題」で、意思決定の仕組みそのものが欠如している状態です。もうひとつは「整理できない問題」で、現状業務を可視化し設計する手法が欠如している状態です。
この2つは打ち手がまったく異なるため、まず自社が構想策定(そもそも刷新の目的や範囲が描けていない段階)、合意形成・方針決定(目的は見えるが経営と現場の合意が難しい段階)、あるべき姿の設計(方針は決まるが業務やシステム構成に落とせない段階)、RFP文書化(設計はできるが比較可能な文書として表現できない段階)のどこでつまずいているのか、現在地を診断することから始める必要があります。
※表：決められない問題と整理できない問題の違い
| 決められない問題(意思決定の仕組みが欠如) | 整理できない問題(分析・設計の手法が欠如) |
|---|---|
| 刷新目的が定まらない | 現状業務を可視化できない |
| 経営と現場の意見が合わない | 課題と原因を分けられない |
| 優先順位・標準化方針を決められない | あるべき業務(To-Be)を設計できない |
| 最終判断者が不明確 | 非機能・移行・保守要件が分からない |
| 打ち手:体制と判断権限の明確化 | 打ち手:構造化の手法と専門知見 |
5W1Hは「社内で決める」ための絶対的なフレームワーク
RFPを書く前に社内で整理・決定すべき内容は、Why(なぜ刷新するのか、目的と成功条件)、What(何を変えるのか、対象となる業務・システム)、Who(誰が決め、誰が使うのか、体制とターゲット)、Where(どこまで適用するのか、対象範囲・拠点)、When(いつまでに実現するのか、スケジュールとマイルストーン)、How(どんな方針で実現するのか、標準化・移行方針)という5W1Hに整理できます。
ここでの主役はあくまで「発注者の意思決定」であり、この土台が揺らげば、どれだけ美しい文章でRFPを仕上げてもプロジェクトは崩壊します。
「今をどうシステム化するか」ではなく「次に何を実現するか」を仕分ける
現行業務をそのままシステム化しようとすると、要件は際限なく膨張します。
そこで有効なのが、すべての業務を「残す業務(強み・差別化)」「標準化する業務(製品標準に寄せる)」「廃止する業務(やめる判断)」「個別運用として残す業務(例外)」に仕分ける発想です。
すべてをシステムで解決しようとせず、あえて「運用」や「ベンダー提案」に逃がす領域を意図的に作ることが、要件を現実的な範囲に収める鍵になります。
あわせて、WMS・TMS・OMS・ERPといった周辺システムとのデータ連携についても、マスタデータの正本はどこか、データの発生源と更新責任は誰か、連携方式に必要なリアルタイム性はどの程度かを、RFPを書く前に決めておく必要があります。
ベンダーの力を最大限に引き出すRFPの書き方
優良ベンダーもまた、「本気度のある案件」を選んでいる
RFPは発注者がベンダーを選ぶための書類だと考えがちですが、実際には優良なベンダーほど、提案する案件を慎重に見極めています。
本当に発注される案件なのか、予算は確保されているのか、要求が際限なく増え続けないか、発注者側で意思決定できる体制があるのか。
目的・予算・決裁者が書かれておらず本気度が読めないRFP、全項目がMust要件で提案の余地がないRFP、回答形式がバラバラで比較・評価されないRFP、非現実的な納期や条件を課すRFPは、優良企業ほど静かに手を引いてしまいます。
良いRFPは「5W1H」を「7つの要素」に翻訳した文書
社内で整理した5W1Hを、ベンダーが比較・提案できる形に翻訳・構造化したものが、良いRFPの7要素です。
すなわち、刷新の背景・目的・成功条件、対象範囲と対象外、現状業務・システムと課題、期待する業務・要求事項、要件の優先順位(Must・Should・Could・Future)、制約条件・前提条件・役割分担、そしてベンダーへの提案依頼事項の7つです。
この翻訳作業こそが、社内の意思決定を、ベンダーが公平に比較・提案できる共通言語に変換する工程だといえます。
決めることと、委ねることを切り分ける
RFPにおける基本原則は、「求める成果と責任の境界は具体的に、解決方法は柔軟に」です。
曖昧にしてよいのは実現手段であって、要求や責任範囲ではありません。
対象範囲・対象外、業務ルール、制約条件、性能・非機能要件、インターフェース境界、成果物・完了条件、役割分担、見積条件といった項目は、解釈の差がそのまま費用差・納期差につながるため具体的に記載すべきです。
一方で、実現方式やシステム構成、業務標準化の実現方法、導入・展開方法といった項目は、ベンダーごとに強みが異なり専門知見も求められるため、あえて抽象化して提案の余地を残すべき領域です。
提案内容には自由度を持たせつつ、対応区分(標準機能・設定対応・カスタマイズ・外部製品・運用対応・対応不可)といった回答形式には統一性を持たせることで、初めて横並びの比較が可能になります。
提案の評価にあたっては、初期費用の安さだけで判断してはいけません。「業務への理解と実現性」「システム構成・拡張性・保守性」「導入・保守運用体制」「複数年のTCOと前提条件リスク」という4つの軸で総合的に評価する必要があります。
回答形式を統一する目的は、単に価格を比較することではなく、こうした実現性とリスクを同じ条件で見極められる状態を作ることにあります。
※表：発注者が決めることとベンダーに委ねることの切り分け
| 発注者が決めること(ブレてはいけない絶対的な基準) | ベンダーに提案させること(専門知見と製品の強みが活きる領域) |
|---|---|
| プロジェクトの目的 | 最適な実現方式 |
| 解決すべきコア課題 | 製品・サービス構成 |
| 必須要求(Must要件) | 標準機能による代替案 |
| 制約条件(予算・インフラ等) | 導入・移行方式 |
| 評価基準 | 段階的な導入案 |
社内の合意形成と、外部を活用すべき領域の見極め方
全員一致を目指さない――合意形成の5原則
RFP作成の過程では、意見は広く聞きながらも、決める人は限定するという姿勢が重要です。
合意形成の5原則は、意見は広く聞くこと、決める人は限定すること、未決事項を放置せず可視化すること、決定期限を設けること、そして全員一致を目指さないことです。
合意とは満場一致ではなく、納得して任せることだと捉え直すだけで、意思決定のスピードは大きく変わります。
PJオーナーが最終判断と予算・部門間対立の裁定を担い、PJ責任者が全体推進を担い、業務責任者・IT責任者・現場代表がそれぞれの領域の決定を担うといった体制図を先に作っておくことが、合意形成を機能させる土台になります。
社内で持つべき意思決定と、外部を活用すべき領域
なぜ刷新するのか、何を優先するのか、どの業務を変え何を標準化するのか、どのリスクを許容するのか、最終的にどのベンダーを選ぶのか。こうした社内固有の意思決定は、決して外部に委ねてはいけません。
一方で、現状業務の構造化と課題分析、あるべき業務の選択肢提示、RFPの設計と第三者レビュー、非機能・移行・運用要件の整理といった専門知見が不足しがちな領域には、外部の力を積極的に活用する価値があります。
上流工程の労力を削ることは節約にはならず、単により高額な修正費用として後工程に移るだけです。構想・業務設計・RFP設計に十分な時間とコストをかけたプロジェクトは要件定義の手戻りが小さく開発・移行も計画通りに進みますが、上流を省いて早く安くRFPを出したプロジェクトは、ベンダーとの解釈のズレから手戻りが激増し、総コストがかえって膨らむ恐れがあります。
結びに代えて
良いRFPとは、発注者とベンダーが良いプロジェクトを共に作り上げるための起点です。判断・構想、設計・整理、伝達・翻訳、選定・実行という一連の流れの中で、自社が今どの段階でつまずいているのかを見極めることが、次の一歩になります。
構想の必要性判断や合意形成でつまずいているのか、あるべき業務の設計で止まっているのか、それともRFPという文書への落とし込みに課題があるのか。RFPを機能一覧としてではなく、自社とベンダーの双方をプロジェクトの破綻から守る防波堤として捉え直すところから、システム刷新の成功は始まります。
シーオス株式会社 について
シーオスは、ロジスティクス分野に25年以上特化してきたソリューションカンパニーです。
「ロジスティクス」を単なる物の移動ではなく、企業価値に直結する重要領域と捉え事業を展開してまいりました。
創業以来、ロジスティクス領域に特化した専門チームを擁し、現場理解と戦略立案の双方に強みを持つパートナーとして、製造・小売・ECなど数多くの企業様の課題解決に伴走しております。
戦略コンサルティングからシステム開発、WMS(倉庫管理システム)やTMS(輸配送管理システム)、RFP作成支援や第三者レビューに至るまで、システム刷新プロジェクトの上流工程を支えるフルラインアップのサービスを提供しています。
