生産管理システムのRFP2026｜見積差3倍は前提の差である

「同じ内容で3社に見積もりを頼んだのに、金額が3倍も違うんです。どこを信じればいいんでしょうか」。タイの日系工場でシステム更新の相談を受けるとき、最初に出てくるのはたいていこの質問です。ただ、話を聞いていくと、3社が受け取った「同じ内容」は、ほとんどの場合まったく同じではありません。違っていたのは価格ではなく前提です。この記事では、生産管理システムのRFP（提案依頼書）を作ることで、見積差が何によって縮むのかを、アユタヤ工場のモデルケースで追いかけます。

生産管理システムのRFPがなぜ後回しにされるのか

生産管理システムの刷新を検討し始めた工場に「RFPは作りますか」と尋ねると、多くの場合、返ってくるのは「そこまでの体力はない」という答えです。理由を掘り下げると、だいたい3つに集約されます。

ひとつ目は、書ける人がいないことです。タイの拠点でIT専任者を置けている工場はそう多くありません。生産管理課長や工務担当が他業務と兼務でベンダー対応をしているのが実情で、要件を文書に落とす作業は、日々の生産に直接紐づかない仕事として後ろに回ります。締め切りがある仕事ではないので、いつまでも着手されません。

ふたつ目は、ベンダーが要件を整理してくれるという期待です。実際、経験のあるベンダーは現場をヒアリングし、提案書の形で要件を提示してくれます。これは親切な対応ですが、構造としては「発注側の要件を、受注側が定義している」状態です。その定義が正しいかどうかを、発注側は検証する材料を持っていません。しかも各社が独自にヒアリングすれば、各社が違う要件を持ち帰ります。

みっつ目は、RFPという文書のイメージが重すぎることです。数十ページの分厚い仕様書を想像し、あんなものは書けないと最初から諦めてしまう。しかし実務上のRFPは、何を実現したいか、どこまでを見積もりに含めてほしいか、どういう基準で選ぶかを揃えるための文書であり、システムの設計書ではありません。分量よりも、全社が同じ紙を見ているかどうかが本質です。

そして、この3つの理由はどれも「RFPを書かないことのコスト」を勘定に入れていません。書かなかった結果として何が起きるかは、見積もりが返ってきた瞬間に、金額の混乱という形で表面化します。導入そのものがつまずく典型的な経路については生産管理システムの導入が失敗する理由でも整理していますが、その入口の多くは選定段階にあります。

RFPとRFI・要件定義書の違い — 何を、いつ、誰が使う文書か

RFPの話をすると、要件定義書との違いが曖昧なまま議論が進むことがあります。この2つは似た内容を含みますが、使うタイミングと目的がまったく違います。

コンピュータマネジメントの解説によれば、RFPはベンダー選定の前に発注側が作成し、複数のベンダーへ提示する文書です。これに対して要件定義書は、ベンダーが決まった後に、発注側とベンダーが一緒に作り込んでいく文書です。前者は「比較のための文書」、後者は「実装のための文書」だと考えると整理しやすくなります。

さらにその前段階として、RFI（情報提供依頼書）があります。市場にどんな製品があり、どんな実現方式が取れるのかを知るために、情報提供を依頼するものです。生産管理システムの刷新を何年ぶりかに検討する工場では、そもそも選択肢の地図を持っていないことが多いため、RFIを挟む価値があります。

3つの文書の関係を整理すると次のようになります。

同じ解説では、複数のベンダーに同一内容のRFPを提示することで、提案内容の比較がスムーズになる点も指摘されています。当たり前のことのようですが、相見積もりの現場ではこの「同一内容」が守られていないケースが圧倒的に多いのです。A社にはメールで概要を送り、B社には工場に来てもらって口頭で説明し、C社には前任者が作った古い資料を渡す。この時点で、3社は違う課題を解こうとしています。

RFPなしの相見積もりで何が起きるか — 前提はベンダーが決める

RFPを用意せずに相見積もりを依頼すると、ベンダーは見積もりを作るために足りない情報を自分で補います。悪意ではなく、そうしないと数字が出せないからです。ここで補われる代表的な項目が、データ移行、カスタマイズ、教育、そして保守年数の4つです。

データ移行は、含めるかどうかで金額が大きく動きます。既存システムの品目マスタ、BOM、取引先マスタ、過去の実績データをどこまで新システムへ持ち込むのか。この範囲が示されていなければ、あるベンダーは「移行は別途」と判断し、別のベンダーは「当然含む」と判断します。どちらも間違いではありません。判断の根拠が発注側から示されていないだけです。

カスタマイズも同じです。多階層のBOMを扱うのか、ロット管理が必要なのか、既存の会計システムと連携するのか。示されなければ、ベンダーは自社の標準機能の範囲で見積もります。標準機能の範囲は製品によって違うので、同じ「標準の範囲内」という言葉が、まったく違う金額を意味します。

教育と保守も見落とされがちです。導入後にオペレータへ何日間のトレーニングを行うのか、保守契約は何年分を見積もりに含めるのか。これらは初期費用として計上されることもあれば、運用費として別枠になることもあります。

結果として起きるのは、金額の比較ができない状態です。安いベンダーは含んでいる範囲が狭いだけかもしれないし、高いベンダーは丁寧に見積もっただけかもしれない。この状態で価格だけを見て決めると、稼働直前になって「データ移行の費用は含まれていません」と言われ、追加見積もりが発生します。製品同士の比較軸そのものについては生産管理システムの比較2026で整理していますが、比較軸が揃っていても、見積もりの前提が揃っていなければ結論は出ません。

モデルケース｜アユタヤ工場の生産管理システム更新

ここから具体的なモデルケースで見ていきます。以下は独自試算によるモデルケースであり、実在する企業の数値ではありません。金額そのものより、どこで差が生まれ、何を揃えると差が縮むのかという構造をご覧ください。

前提はこうです。タイ・アユタヤ県にある日系の自動車部品組立工場、従業員300名。10年前に導入したオンプレミスの生産管理システムが老朽化し、サポート期限も近づいてきたため、刷新を検討し始めました。IT専任の担当者はおらず、生産管理課長が他業務と兼務でベンダー対応にあたっています。タイの日系工場では、非常によくある構成です。

この工場が最初に取った行動は、付き合いのあるベンダーと、日系の展示会で名刺交換したベンダーを含む3社に声をかけ、見積もりを依頼することでした。依頼の材料は、工場に来てもらった際の口頭説明と、社内で作った簡易資料2ページだけです。資料には現行システムの画面構成と、困っていること（実績入力が二重になっている、在庫が合わない、月次の集計に時間がかかる）が箇条書きで並んでいました。

この依頼の仕方に、明らかな手抜きはありません。困りごとは共有していますし、現場も見てもらっています。むしろ丁寧な部類です。それでも、次に見るとおり、返ってきた見積もりは比較のできない3枚になりました。

初回相見積もり（RFPなし）｜3社の見積額とその前提

3社から返ってきた見積額と、それぞれの見積もりに含まれていた範囲が次の内容です。金額はTHB建てです。

最高額であるC社の3,450,000は、最安額であるA社の1,150,000の3.0倍です。同じ工場の、同じ困りごとに対する見積もりで、金額が3倍開いています。

この3枚を最初に見た担当者の反応は、たいてい「A社が安すぎるのか、C社がぼったくりなのか」というものです。しかし、含まれていた範囲の列を横に読むと、そのどちらでもないことが分かります。A社は依頼された内容を最も狭く解釈し、既存機能をそのまま新しい基盤に載せ替えることだけを見積もっています。C社は最も広く解釈し、移行も教育も保守も、さらに多階層BOMへの対応まで含めています。B社はその中間です。

つまり、3社は3つの違う工事を見積もっていました。価格を比べているつもりで、実際には解釈の広さを比べていたのです。

ここで注意しておきたいのは、A社の見積もりが不誠実ではないという点です。A社の見積書には「データ移行・教育・保守は別見積り」と明記されています。読めば分かるように書かれている。ただ、金額欄の数字は他社と並べられる形で提示されるので、比較表を作った瞬間に、この注記は視界から消えます。相見積もりの比較表は、範囲の違いを表現する欄を持っていないことがほとんどです。

見積差が生まれた4つの前提差

3社の見積もりを分解すると、差を生んでいた前提は4つに整理できました。以下の相場は独自試算による目安です。

この表を作るところまでは、発注側でもできます。各社の見積書の内訳を並べ、含まれている項目に印をつけていくだけです。ただし、実際にこの作業をやってみると、多くの見積書は内訳の粒度が揃っていないことに気づきます。ある社は「システム構築一式」とだけ書き、別の社は工程ごとに分けて書いている。粒度が違うと、印をつける作業自体が成立しません。

ここで重要なのは、この4項目のうち3つは、発注側が決めるべき事柄だということです。データを何年分移行するのか、多階層BOMに対応する必要があるのか、保守を何年契約するのか。これらはベンダーが決める話ではなく、工場側の業務要件と予算方針で決まります。教育日数も同様で、何人のオペレータに、どの機能まで教える必要があるかは、工場の人員構成の話です。

発注側が決めるべきことを決めないまま見積もりを依頼すると、その空白はベンダーが埋めます。埋め方は各社の営業戦略に依存するので、揃うはずがありません。見積差3倍という数字は、ベンダー間の実力差ではなく、発注側が示さなかった前提の数だけ発生した解釈の幅なのです。

なお、この段階で「A社の金額に足りない項目の相場を足せば実質価格が出るのではないか」と考えたくなりますが、これはお勧めしません。相場はあくまで目安であり、実際にA社がその範囲を引き受けたときにいくらになるかは、A社に聞かなければ分かりません。前提差は差として認識するに留め、正確な数字は再見積もりで取りに行くのが実務的です。

RFPを作成し要件をMust/Want/Betterで揃える

この工場が次に取った行動が、RFPの作成です。ゴールは立派な文書を作ることではなく、3社が同じ範囲を見積もれる状態を作ることでした。

作業の中心になったのは、要件の優先順位付けです。RFP作成ガイドを提供しているGeNEEは、要求事項をMust（必須）、Want（希望）、Better（あれば望ましい）の3段階で優先順位付けする手法を紹介しています。この3段階の効果は、単に整理されて見やすくなることではありません。ベンダー側が、どこまでを見積もりに含めるべきかを判断できるようになることです。

実際、この工場のケースでは、初回見積もりで最大の差を生んでいた多階層BOM対応をMustに置きました。現場を確認したところ、実際にサブアッセンブリを持つ製品が生産されており、これに対応できないシステムは選択肢から外れると判断したためです。データ移行もMust、教育は3日をMust、保守は1年をMustとしました。

一方で、Wantに置いたものもあります。スマートフォンからの実績入力、経営層向けのダッシュボード、他拠点への横展開を見据えた多拠点対応。いずれもあれば嬉しい機能ですが、なくても今回の課題は解決します。Wantに置くことで、ベンダーは「対応可能かどうか」と「対応する場合の追加費用」を分けて提示できるようになります。

Betterには、将来的な設備データの自動取り込みや、AIによる需要予測といった項目を置きました。今回は見積もりに含めなくてよいが、製品の方向性として持っているかどうかは知りたい、という位置づけです。

この3段階を守ると、ベンダーの提案書の形が変わります。Must未達なら辞退する、Wantは別枠で提示する、Betterはロードマップで答える。判断のルールが共有されるので、提案の粒度が揃うのです。

再見積もりの結果｜価格差は3.0倍から12.8%へ

RFPを提示し、データ移行込み、多階層BOM対応（Must）、教育3日（Must）、保守1年（Must）でスコープを統一したうえで、同じ3社に再見積もりを依頼した結果が次の内容です。

最高額のC社2,460,000と最安額のA社2,180,000の差は280,000 THB。最安値に対する差の比率は12.8%です。初回の3.0倍から、比較可能な範囲まで縮みました。

この結果の読み方には、注意すべき点が2つあります。

ひとつは、安くなったわけではないということです。A社の金額は初回の1,150,000から2,180,000へ上がっています。これは値上げではなく、初回に含まれていなかった範囲が加わった結果です。RFPの効果は価格を下げることではなく、実際に必要な金額を見えるようにすることにあります。もし初回のA社の金額でそのまま発注していれば、稼働までのどこかで追加見積もりが発生し、最終的な支払額は予算超過という形で現れていたはずです。

もうひとつは、12.8%の差にこそ意味があるということです。同じ範囲で見積もった結果として残った差は、実装方式の違い、パッケージのライセンス体系の違い、タイ国内の技術者単価の違いなど、実際の実力差や条件差を反映しています。この段階でようやく、価格を判断材料として使えるようになります。3.0倍の差は比較の材料になりませんが、12.8%の差は、サポート体制や実績と天秤にかけて判断できる差です。

そして実務的には、この12.8%という幅を、価格だけで決めないことをお勧めしています。280,000 THBの差は、長期運用で発生する対応品質の差に比べれば、決して大きくないからです。

RFP作成にかかった工数とスケジュール

「RFPを作れば揃うのは分かったが、どれくらいかかるのか」という点が、次の関門です。このモデルケースで実際にかかった期間の目安が次の内容です。

GeNEEはRFP作成を5つのステップに整理しており、RFP本文の作成自体(現状分析からドキュメント化まで)は1〜1.5ヶ月、ベンダーへの提示から提案書の受領までを含めた全体では約1.5〜2.5ヶ月を目安として挙げています。このモデルケースの7週間は、ベンダー提示・質疑応答対応まで含めた全体の目安の範囲に収まる水準です。特別に速くも遅くもない、標準的な進み方だと考えてよいでしょう。

工程ごとの中身を見ると、最も時間がかかっているのは最初の「現状課題の洗い出し」です。ここで実施したのは、生産管理課だけでなく、購買、品質保証、製造、経理の担当者から、現行システムで困っていることを聞き取る作業でした。兼務の担当者が他業務の合間に進めるため、2週間という期間の多くは待ち時間です。

逆に、実際の執筆にあたる「ドキュメント作成」は1.5週間で終わっています。書く材料が揃っていれば、文書化そのものはそれほど重い作業ではありません。RFPが書けないと感じる原因の多くは、文章力ではなく、材料が集まっていないことにあります。

最後の「ベンダー提示・質疑応答対応」の2週間も省略できません。RFPを渡した後、ベンダーからは必ず質問が来ます。この質問への回答を全社に同じ内容で共有することが、スコープを揃える最後の仕上げになります。1社だけに追加情報を伝えると、そこでまた前提がずれます。

7週間という期間を長いと感じるか短いと感じるかは立場によりますが、比較の土台がないまま進めた場合に発生する追加見積もりの調整と、稼働後の認識違いの是正にかかる時間を考えれば、前倒しで払っておく時間だと捉えるのが実務的です。

RFPに書くべき3部構成

RFPの中身をどう組み立てるかについて、GeNEEは3部構成を提示しています。概要、提案依頼内容、選考の進め方の3つです。この枠組みは、生産管理システムの案件にもそのまま使えます。

第1部は概要です。 自社が何をしている会社で、今回なぜシステムを刷新するのかを書きます。工場の所在地、生産品目、従業員数、生産方式（個別受注か見込み生産か、ロット生産かライン生産か）、そして現行システムの構成と課題。ここが薄いと、ベンダーは工場の実態を想像で補うことになります。タイ拠点の案件では、日本本社との関係、会計システムとの連携有無、現地スタッフの日本語対応可否まで書いておくと、提案の精度が上がります。

第2部は提案依頼内容です。 RFPの本体にあたる部分で、機能要件、非機能要件、体制、スケジュール、そして予算の考え方を書きます。ここでMust/Want/Betterの整理が効いてきます。加えて、見積もりに含めてほしい範囲を明示することが決定的に重要です。データ移行の対象と期間、教育の日数と対象人数、保守契約の年数。この3点を書くだけで、初回相見積もりで起きた差の大半は消えます。

第3部は選考の進め方です。 いつまでに提案を提出してもらい、いつプレゼンテーションを行い、いつ結果を通知するのか。そして何を基準に評価するのか。評価基準を事前に開示することに抵抗を感じる方もいますが、開示したほうが提案の質は上がります。ベンダーは限られた時間で提案を作るので、どこに力を入れるべきかが分かれば、そこに資源を集中できるからです。

3部構成のうち、日系工場のRFPで最も抜けやすいのは第3部です。機能の話は書けても、選び方の話は書かれないまま、提案を受け取ってから評価表を作り始める。この順番だと、評価基準が手元の提案に引きずられます。

機能要件をMust/Want/Betterで整理する

Must/Want/Betterの整理は概念としては簡単ですが、実際にやると必ず詰まります。詰まる原因は、現場の誰もが自分の要望をMustだと考えるからです。

この壁を越えるために有効なのが、判定の質問を決めておくことです。実務では、「この機能がなかった場合、業務は回るか」という一点で判定します。回らないならMust、回るが手間が増えるならWant、あれば将来役に立つならBetterです。回るかどうかは事実の問題なので、立場の違う部門でも合意しやすくなります。

アユタヤ工場のケースを例に整理すると、次のような分類になりました。

もうひとつのコツは、Mustを増やしすぎないことです。すべてをMustにすると、対応できるベンダーが1社に絞られるか、あるいは全社が高額なカスタマイズを積むことになります。Mustは「これを外したら発注しない」という条件なので、実際に発注を左右する項目だけを置きます。

逆に、Wantを丁寧に書くことには大きな価値があります。ベンダーの標準機能でWantが満たされる場合、追加費用なしで実現できます。Wantを書かなければ、標準機能に入っているのに使われないまま終わる機能が出てきます。安く手に入る可能性のある要望こそ、書いておく意味があるのです。

そして、この整理表はRFPを出した後も使い続けます。提案を評価する際に、各社がMustをどう満たし、Wantをどう扱ったかを同じ軸で並べられるからです。整理表そのものが、後の評価表の骨格になります。

非機能要件は数値で書く — 形容詞は比較にならない

機能要件の整理に比べて、非機能要件は圧倒的に手薄になりがちです。そして、稼働後のトラブルの多くは、この非機能要件の曖昧さから生まれます。

GeNEEも、非機能要件は数値や規格を用いて具体的に書く必要があると指摘しています。理由は明快で、形容詞は比較にならないからです。「レスポンスが速いこと」と書かれたRFPに対し、ベンダーAは1秒を想定し、ベンダーBは5秒を想定するかもしれません。どちらも自社の基準では「速い」のです。

生産管理システムで数値化しておきたい非機能要件は、おおむね次の領域です。

性能については、同時接続するユーザー数、ピーク時に処理する必要のあるトランザクションの件数、画面の応答時間、月次締め処理の完了までに許容できる時間。これらは現行システムの実測値をベースに書くのが最も確実です。実測が難しければ、現場が「これ以上待たされると作業が止まる」と感じる時間を聞き取って設定します。

可用性については、稼働時間帯（タイの工場は2交替や3交替が多いため、日本の基準をそのまま持ってこないこと）、計画停止の許容頻度、障害時の復旧目標時間。データ保全については、バックアップの取得頻度と保管期間、障害発生時にどこまで戻せるか。

そして、しばしば抜けるのが保守の応答条件です。障害の連絡を受けてから一次回答までの時間、対応の受付時間帯、対応言語。タイ拠点では、対応言語の指定が実務上きわめて重要になります。現地スタッフがタイ語で連絡でき、日本人管理者が日本語で状況を確認できる体制が組めるかどうかで、稼働後の運用負荷が変わります。

なお、非機能要件を厳しく書けば書くほど金額は上がります。常時稼働と即時対応を求めれば、その体制分の費用が乗ります。数値で書くことの目的は要求を吊り上げることではなく、必要な水準を明示して各社を同じ土俵に乗せることです。開発費用の構造そのものを確認したい場合は業務システム開発の費用とERP連携も参考になります。

タイ・ASEAN拠点特有の論点

日本国内のRFP解説には出てこない、タイ拠点ならではの論点があります。実務で効くものを挙げます。

現状データの整備状況。 newsclip.beは、タイでの生産管理システム導入にあたり、各部門が個別にExcel等で管理してきた顧客情報・製品情報・原材料情報のコード体系が、部門によってバラバラなケースが多いと指摘しています。これはRFPの「現状課題の洗い出し」段階で必ず確認すべき論点です。コード体系が部門ごとに揃っていない状態を把握せずにRFPを書くと、データ移行のスコープを過小に見積もることになります。モデルケースでデータ移行費用を独立した項目として扱ったのも、この前提差が価格に直結するからです。

言語とドキュメントの範囲。 画面の表示言語、マニュアルの言語、トレーニングの言語を、それぞれ分けて指定します。画面はタイ語と英語、マニュアルは日本語と英語、トレーニングはタイ語というように、実態に合わせて組み合わせる必要があります。まとめて「多言語対応」と書くと、ベンダーによって含む範囲が変わります。

本社との連携要件。 日本本社の会計システムやグループ標準のERPと連携する必要があるかどうかは、初期段階で確定させておくべき事項です。後から連携要件が追加されると、パッケージの選定そのものをやり直すことになりかねません。

サポート拠点の所在。 タイ国内に技術者がいるのか、シンガポールや日本からのリモート対応になるのか。オンサイト対応が必要になったときの出張費が見積もりに含まれるのか。RFPで明示的に質問しておかないと、稼働後に判明します。ベンダーの体制そのものの見極め方についてはタイのシステム開発会社の選び方も併せてご覧ください。

税務・法務の要件。 タイの会計制度や税務要件に対応した帳票が出せるか、電子インボイスの動きに追随できるかといった点も、機能要件として書いておく領域です。日本の基準で作られたパッケージをそのまま持ち込む場合、ここが後から追加開発になることがあります。

相見積もり比較でRFP以外に見るべきポイント

RFPで金額の比較ができるようになった後、最終的な判断は何を見て行うのか。ここで価格だけに戻ってしまうと、RFPを作った意味が半減します。

アスピックは、生産管理システムを比較する際のポイントとして、対応業務の範囲、小規模事業者への対応有無、スケジューラー機能の充実度の3点を挙げています。対応業務の範囲は、RFPのMust要件がそのまま比較軸になりますし、小規模事業者への対応やスケジューラー機能の要否も、自社の規模や運用方式によって重みが変わる論点です。これに加えて、相見積もりの実務では次の3点も価格と並ぶ判断材料になります。

拡張性については、今回のWantとBetterに対する回答を見るのが実務的です。今回は見積もりに含めない機能について、追加できるのか、追加する場合はどういう形になるのか。標準機能の設定変更で済むのか、追加開発が必要なのか。この答え方に、製品の設計思想が出ます。

カスタマーサポートについては、体制の説明ではなく、具体的な運用の質問で確認します。担当者が交代したときの引き継ぎはどうなるのか、問い合わせの窓口は個人かチームか、過去に同規模の工場で対応した事例はあるか。タイでは技術者の転職が一般的なので、個人に依存した体制はリスクとして見ておく必要があります。

料金については、初期費用だけでなく、複数年にわたる総額を比較します。ライセンスが買い切りか年額か、ユーザー数の増減で費用がどう動くか、保守費が何年目からいくらになるか。初期費用が最も安い提案が、長期的には最も高くなることは珍しくありません。

そして、RFPを提示した後にしか分からない観点がもうひとつあります。質疑応答の質です。RFPを読み込んだうえで的確な質問をしてくるベンダーは、案件を理解しようとしています。質問がまったく来ないベンダーは、読んでいないか、あるいは自社の標準提案をそのまま出す前提で動いています。質問の内容そのものが、評価の材料になります。

RFP作成でよくある失敗5パターン

RFP作成の実務では、次のような失敗パターンがよく見られます。生産管理システムの案件に当てはめて整理します。

目的が曖昧なまま書き始める。 「システムが古いから」は目的ではなく、きっかけです。在庫差異を減らしたいのか、月次締めを早めたいのか、実績入力の二重作業をなくしたいのか。目的が定まっていないと、Must/Want/Betterの判定基準が持てず、要件が現場の要望の羅列になります。

要件を詰め込みすぎる。 各部門から集めた要望をすべてMustとして載せると、対応できるベンダーが消えるか、見積額が跳ね上がります。RFPは要望の集積場ではなく、優先順位を示す文書です。落とす判断を含めて書くのがRFPの仕事です。

曖昧な表現を使う。 「使いやすい画面」「安定した稼働」「柔軟な拡張性」。いずれも各社が自社に有利に解釈できる言葉です。前述のとおり、非機能要件は数値と規格で書きます。機能要件についても、「在庫管理ができること」ではなく「ロット単位で入出庫を記録し、指定日時点の在庫を照会できること」といった粒度まで落とします。

予算と納期を示さない。 予算を伏せると良い条件が引き出せると考えがちですが、実際には逆です。予算感が分からないと、ベンダーは自社の標準的な提案を出すしかなく、予算に合わせた構成の工夫が出てきません。範囲での提示でも構わないので、示したほうが提案の実用性は上がります。

社内の合意を取らずに出す。 RFPを情報システム担当だけで書き、現場や経営層のレビューを経ずにベンダーへ出してしまうケースです。提案が返ってきた段階で「その機能はうちの工程では使えない」という指摘が出ると、選定がやり直しになります。モデルケースで「ドキュメント作成・社内レビュー」に1.5週間を充てているのは、この工程を飛ばさないためです。

内製で進める部分と外部に依頼する部分の線引き

RFPをすべて自社で書ける工場は多くありません。かといって全部を外部に任せると、要件が他人事になり、稼働後に「聞いていた話と違う」が発生します。線引きが必要です。

実務的に機能しているのは、目的と優先順位は社内、文書化と技術的な妥当性の確認は外部という分け方です。

社内で持つべきもの。 まず、今回のシステム更新で何を解決するのかという目的です。これは経営と現場の判断であり、外部が決められません。次に、Must/Want/Betterの優先順位付けです。判定の材料になる業務知識は社内にしかありません。3つ目に、予算の枠と決裁のプロセス。いつまでに誰の承認が必要かは、社内の事情そのものです。

外部に任せてよいもの。 ひとつは、集めた要件を文書の形に落とす作業です。RFPの構成に沿って整理し、抜けている項目を指摘する作業は、複数の案件を見た経験があるほど速くなります。もうひとつは、非機能要件の数値設定です。応答時間やバックアップ要件をどの水準に置くのが現実的かは、相場観がないと決められません。3つ目は、ベンダーからの質疑への回答支援です。技術的な質問への回答を誤ると、後の見積もりがずれます。

線引きを機能させる条件が2つあります。ひとつは、外部に依頼する場合でも、社内側で内容を読んで理解できる状態を保つことです。読めない文書でベンダーを選ぶと、稼働後の判断も外部依存になります。もうひとつは、RFP作成を支援する会社と、応札するベンダーを分けることです。同じ会社が両方を担うと、RFPがその会社に有利な形になりやすく、相見積もりの意味が薄れます。

なお、RFPを一から書く体力がない場合でも、初回は簡易な形から始めて構いません。目的、Must要件、見積もりに含めてほしい範囲の3点だけを1枚にまとめて全社に同じものを渡す。それだけでも、前提のばらつきは大きく減ります。完璧なRFPを目指して着手が遅れるより、範囲を揃えた1枚を早く出すほうが実利があります。

よくある質問

生産管理システムのRFPは何ページくらい必要ですか？

ページ数に決まった正解はありません。重要なのは分量ではなく、全社が同じ範囲を見積もれる情報が入っているかどうかです。最低限として、会社と工場の概要、システム更新の目的、Must要件、見積もりに含めてほしい範囲（データ移行の対象、教育の日数、保守の年数）、選考のスケジュールと評価基準が入っていれば機能します。GeNEEはRFPを概要、提案依頼内容、選考の進め方の3部構成で整理しており、この骨格に沿って書けば必要な項目は網羅できます。分量を増やすより、曖昧な表現を数値に置き換えることに時間を使ってください。

RFPと要件定義書は何が違うのですか？

使うタイミングと作る主体が違います。コンピュータマネジメントの解説によれば、RFPはベンダー選定の前に発注側が作成して複数社に提示する文書で、要件定義書はベンダー決定の後に発注側とベンダーが一緒に作り込む文書です。RFPは比較のための文書、要件定義書は実装のための文書だと考えると整理しやすくなります。RFPの段階で実装レベルの仕様を固める必要はありません。むしろ固めすぎると、ベンダーが持っている実現方式の知見を提案として引き出せなくなります。

相見積もりで金額が大きく違うとき、どう判断すればいいですか？

金額を比べる前に、各社の見積もりに含まれている範囲を1枚の表に並べてください。モデルケースでは、3社の見積額が1,150,000から3,450,000まで3.0倍開いていましたが、差を生んでいたのはデータ移行、多階層BOM対応、教育日数、保守年数という4つの前提差でした。範囲が揃っていない見積もりは、価格の比較になりません。前提を揃えて再依頼した結果、価格差は12.8%まで縮み、そこで初めて価格が判断材料になります。安い提案を疑うのではなく、何が含まれていないかを確認するのが順序です。

RFPを作るとどれくらい期間がかかりますか？

GeNEEはRFP作成の所要期間の目安として、文書作成自体は1〜1.5ヶ月、ベンダー提示から提案書受領までを含めた全体では約1.5〜2.5ヶ月を挙げています。モデルケースでは、現状課題の洗い出しに2週間、要件の優先順位付けに1.5週間、ドキュメント作成と社内レビューに1.5週間、ベンダー提示と質疑応答対応に2週間で、合計7週間でした。最も時間がかかるのは最初の課題の洗い出しで、兼務の担当者が他業務の合間に各部門から聞き取るため、実作業より待ち時間が長くなります。逆に文書化そのものは、材料が揃っていれば長くかかりません。

要件をMust/Want/Betterに分ける基準はどう決めればいいですか？

「この機能がなかった場合、業務は回るか」という一点で判定するのが実務的です。回らないならMust、回るが手間が増えるならWant、あれば将来役に立つならBetterです。回るかどうかは事実の問題なので、立場の違う部門の間でも合意しやすくなります。注意点として、Mustを増やしすぎないでください。Mustは「これを外したら発注しない」という条件なので、実際に発注を左右する項目だけに絞ります。一方でWantは丁寧に書く価値があります。ベンダーの標準機能で満たされる場合、追加費用なしで実現できるからです。

まとめ

要点を整理します。

生産管理システムの相見積もりで価格が大きく割れるのは、機能や品質の差ではありません。ベンダーごとに前提スコープの解釈が違うからです。口頭説明と簡易資料だけで見積もりを依頼すると、データ移行、カスタマイズ、教育、保守年数の含み方が各社でばらつき、比較のできない見積書が並びます。

モデルケースの試算では、アユタヤ県の日系自動車部品組立工場（従業員300名）が3社に依頼した初回見積額は、A社1,150,000 THB、B社2,300,000 THB、C社3,450,000 THBで、最高額は最安額の3.0倍でした。差を生んでいたのは、データ移行費用400,000、多階層BOM対応550,000、1日あたり60,000の教育日数の違い（A社0日・B社2日・C社5日）、保守契約1年延長300,000という4つの前提差です。RFPを作成し、データ移行込み、多階層BOM対応、教育3日、保守1年でスコープを統一して再依頼した結果、再見積額はA社2,180,000、B社2,340,000、C社2,460,000となり、最高額と最安額の差は280,000 THB、比率にして12.8%まで縮みました。これは独自試算であり実在企業の数値ではありませんので、金額そのものではなく、何を揃えると差が縮むのかという構造をご覧ください。

読み違えてはいけないのは、RFPは価格を下げる道具ではないという点です。A社の金額は上がっています。RFPが変えたのは、実際に必要な金額が見えるようになったことと、残った差が実力差として比較できるようになったことです。

RFPは概要、提案依頼内容、選考の進め方の3部で構成し、機能要件はMust/Want/Betterで優先順位を付け、非機能要件は形容詞ではなく数値と規格で書きます。タイ拠点では、現状データの整備状況、言語とドキュメントの範囲、本社との連携要件、サポート拠点の所在、税務・法務の要件を明示的に書いておくことで、稼働後の想定外を減らせます。

作成にかかる期間の目安は7週間。長く感じられるかもしれませんが、揃っていない見積もりで進めた場合に発生する追加見積もりの調整と、稼働後の認識違いの是正にかかる時間を前倒しで払っている、と捉えるのが実務的です。

まずは、目的、Must要件、見積もりに含めてほしい範囲の3点を1枚にまとめ、全社に同じものを渡すところから始めてみてください。それだけでも、返ってくる見積書の顔つきが変わります。

RFPを一から書くのは難しい、という段階でも構いません。TOMAS TECHはタイの日系工場向けに生産管理システムの導入と運用を手がけており、いまの課題を棚卸しして要件の優先順位を整理する段階からのご相談も承っています。ベンダー選定の前に、何を決めておくべきかを一緒に確認したいという方はお問い合わせからお声がけください。

参考情報

• GeNEE — 【サンプル・テンプレート付】RFP（提案依頼書）の書き方ガイド（RFP作成ガイド）
• コンピュータマネジメント — RFP（提案依頼書）とは？RFI・要件定義書との違いや作成までの流れを解説（RFP解説記事）
• アスピック — 生産管理システム比較17選。規模や業種・生産方式別の選び方（生産管理システム比較記事）
• アイ・オーシステムインテグレーション — 【2026年最新版】生産管理システム比較22選（2026年1月）
• newsclip.be — タイで生産管理システム導入のコツ① 失敗しないための事前準備（タイ拠点でのシステム導入解説）