· CrossPath Works · Procurement Lab  · 19 min read

見積が比べられないのは、値段のせいじゃない ― 明細の「形」を自動で作る

3社の見積を並べても比べられないのは、値段ではなく明細の形が揃っていないから。POのカテゴリ体系から想定仕様を定義し、査定項目に翻訳して、見積明細ブランクを機械に書かせた話。

3社の見積を並べても比べられないのは、値段ではなく明細の形が揃っていないから。POのカテゴリ体系から想定仕様を定義し、査定項目に翻訳して、見積明細ブランクを機械に書かせた話。

3社から見積を取る。1社は「一式 800万円」。1社は工程ごとに10行。1社は月額と初期費用だけ。——この3枚を並べて、どこが高いか説明できるだろうか。比べられない原因は値段ではなく、明細の「形」が揃っていないことだ。だから私は、値段の交渉より先に、見積書の形そのものを機械に書かせることにした。

「あるべき原価」を積み上げる手法は、昔からある

調達には should-cost 分析(クリーンシート原価分析)という確立した手法がある。買うものの価格を材料費・労務費・設備費・間接費・利益に分解し、「本来いくらであるべきか」をゼロから積み上げる。米国防総省の調達から発展して連邦調達規則に組み込まれ、大手コンサルティング会社もツールとして商品化しているくらい、考え方としては枯れている。

にもかかわらず、多くの現場で使われていない。理由は手法の欠陥ではなく、「1カテゴリ分の明細を設計する」作業が重すぎることにあるとされる。調達ソフト各社の解説でも、詳細なクリーンシート分析は時間と人員の要求が高く、それ自体が経済効率を損ないうること、年間購入額がある程度大きくないと採算が合わないことが指摘されている。結果として、適用先は金額が大きく、材料と工数に分解しやすい直接材の部品に偏る。

私が興味を持っているのはその逆側、間接材だ。マーケティングの制作、物流、BPO、IT ——部門ごとに買い方が違い、仕様が標準化されておらず、カテゴリが際限なく枝分かれする。「共通の見積フォーマットを1枚作って全社に配る」が最も効かない領域で、だからこそ明細設計の人手というボトルネックが決定的になる。ならば、明細の設計そのものを機械が吐けばいい。

作ったもの:カテゴリ体系から、見積明細を組み立てる

入力に使うのは、どの会社にもある発注データ(PO)のカテゴリ体系だ。大分類・中分類・小分類まで降りていくと、「この中分類なら、だいたいこういう仕様のものを買っている」という像が立つ。そこから想定される仕様を定義し、その仕様を査定するための項目に翻訳して、見積明細の1行1行に落とす。やっているのはそれだけで、難しいことはしていない。

カテゴリ体系から見積明細を作り、ベンチマークして仕様へ返す流れ。上段は、POのカテゴリ体系から想定仕様を定義し、査定項目に翻訳して見積明細ブランクを生成する流れ。下段は、返ってきた明細を取り込み、単位あたり価格に正規化してベンチマークし、その結果を仕様の定義へ返す流れ。実線は動かして確かめた範囲、破線はこれから作る範囲。

入力は PO のカテゴリ体系。出力は「そのカテゴリの見積明細ブランク」。回収した明細を単位あたり価格に直して仕様へ返すループが、この設計の本命。

明細の項目を、3種類に分けた

ここが設計の肝で、明細に並べる項目をドライバー・価格・取引条件の3種に分類している。いま手元にあるのは 5つの大分類と、その下の50中分類ぶん、合わせて354項目。内訳はドライバー146・価格149・取引条件59。たとえば「デジタル広告」という中分類なら、こうなる。

種別項目単位
ドライバー配信媒体(例:検索/SNS/DSP)媒体区分
ドライバー配信形式(例:リスティング/ディスプレイ/動画)形式区分
ドライバー目標 CPC(クリック単価)円/click
ドライバー目標 CPM(1,000imp 単価)円/1,000imp
価格月間広告予算(媒体費)円/月
価格運用手数料率(媒体費比)%
価格初期設定・アカウント構築費
条件最小月額予算
条件契約最低期間ヶ月

ドライバーは、価格が何に比例して動くかを決める項目だ。デジタル広告ならクリックとインプレッション、物流なら距離と重量、BPO なら人数と処理件数、店頭プロモなら店舗数と派遣回数。ここを先に握るのが一番大事で、ドライバーが決まれば「単位あたりいくら」という共通言語ができる価格はその上に乗る金額そのもの、条件は最低ロットや契約期間のような、金額には出ないが後で効いてくる約束事。この3つを混ぜて1枚の紙に書かせるから、見積は比較不能になる。

出てくるのは、ただのブランク Excel

項目定義から実際に配る書式を作るのは、コマンド1本にした。大分類を指定すると、記入要領・見積ヘッダ・見積明細の3シートを持つ Excel が出てくる。

$ python scripts/generate_quote_template.py --list
利用可能なコモディティ:
  - マーケティング
  - ビジネスサービス
  - リテールプロモ
  - SCM
  - IT

$ python scripts/generate_quote_template.py --all
[OK] マーケティング -> output/marketing_quote_template.xlsx
[OK] ビジネスサービス -> output/bpo_quote_template.xlsx
[OK] リテールプロモ -> output/retail_quote_template.xlsx
[OK] SCM -> output/logistics_quote_template.xlsx
[OK] IT -> output/it_quote_template.xlsx

明細シートの列は2階建てになっている。前半はどのカテゴリでも同じ共通コア列が30本。RFQ 番号、サプライヤー名、明細番号、数量、単位、単価、金額、納期、支払条件——後で機械が読むために必要な骨格で、必須のセルには色が付いている。

生成された見積明細シートの左側。列名の英字行、日本語ラベル行、必須表示行の3段ヘッダーが並び、必須列は黄色、任意列は青で塗り分けられている。

共通コア列。1行目が機械用の列名、2行目が人間用の日本語ラベル、3行目が必須表示。人が読む列と機械が読む列を同じ表で兼ねるための3段ヘッダー。※ 生成された空のブランク書式。

後半がそのカテゴリ固有の拡張列で、カテゴリごとに9〜11本。ここに、さっきのドライバーが物理的な列として並ぶ。マーケティングなら媒体費・制作費・運用費に加えて、見込みリード数、見込みインプレッション数、想定 CPA。物流なら距離帯・重量帯・容積、BPO なら FTE 数・処理件数・稼働時間。共通部分は共通に、違う部分だけカテゴリで差し替えるという構造にしてある。

同じ明細シートを右へスクロールした部分。緑色で塗られたマーケティング固有の拡張列が並び、媒体費・制作費・運用費・キャンペーン期間・見込みリード数・見込みインプレッション数・見込みクリック数・想定CPA・レポーティング頻度・クリエイティブ本数の列が見える。

同じシートの右側。緑がマーケティング固有の拡張列で、価格の分母になる項目(見込みリード数、期間、本数)が明示的に列になっている。※ 生成された空のブランク書式。

なぜドライバーを分けるのか ― 発注後に世界が動くから

ここが、この設計をやった一番の動機だ。調達の現実として、発注した後に前提が動く。数量が半分になる、期間が延びる、仕様がひとつ増える、原材料が上がる。そのたびに「じゃあいくらですか」を最初から交渉し直すのは、買う側にとっても売る側にとっても消耗でしかない。しかも先に言い出した方が損をしやすい。

ドライバーを最初に握っておくと、これが変わる。合意しているのが総額ではなく**「1リードあたり◯円」「1店舗あたり◯円」「1トンキロあたり◯円」だから、数量が動いたときに再計算の基準が最初から共有されている**。売る側は「安く受けた仕事が量だけ増える」事故を避けられるし、買う側は値上げ要求に対して「どの分母が動いたのか」を聞ける。透明性は、買い叩くための道具ではなく、公正で公平な取引を変動の中で維持するための道具だと思っている。価格を決着させるまでの時間が短くなるのは、その副産物だ。

だから生成される書式には、記入要領のシートにベンチマークの計算式まで書いてある。分子と分母を、実在する列名で指定する形で定義しているので、埋まった見積が返ってくれば、そのまま単位あたりの価格が出る。

生成されたExcelの記入要領シート。記入ルール7項目に続き、ベンチマーク指標の表があり、リード単価はline_amount÷expected_leads(円/件)、1週間あたり費用はline_amount÷campaign_period(円/週)、クリエイティブ単価はline_amount÷creative_count(円/本)と定義されている。

記入要領シート。ベンチマーク指標を分子の列 ÷ 分母の列という形で定義してある。「リード単価 = 金額 ÷ 見込みリード数」。人が電卓を叩く前提の指標ではなく、機械が回す前提の指標にしておく。※ 生成された空のブランク書式。

この書式は、見積依頼(RFQ)を出すときにカテゴリを見て自動で添付されるようにしてある。バイヤーが「どのフォーマットを使うんだったか」を思い出す必要はない。返信された Excel から明細行を読み取って比較表に並べる処理も書いてあるが、ローカルで実際に往復を確かめたのは「依頼を送って、見積が返ってくる」ところまでだ。

ここから先 ― PDCA を「回数」で回す

ただし、正直に書いておくと、ここから先はまだ構想だ。いま取り込めているのは品名・数量・単価・金額といった共通コアの部分で、ドライバー列を取り込んで単位あたり価格を自動で出すところは作っていない。でも、そこが本命だと思っている。

明細の形が揃うと、「どこにどうコストが乗っているか」が初めて見える。見えると、仕様の側を直せる。この項目は要求しすぎだったんじゃないか、この条件を外すといくら下がるのか、この分母は本当にこれでいいのか。仕様を直せば、次の見積の形が変わる。それがまた明細として返ってきて、またベンチマークできる。データを持った PDCA が回りはじめる。

そして、これは人間だと数回しか回せない。一人のバイヤーが担当するカテゴリの数と、1年に取れる見積の回数を考えれば当たり前だ。ここに AI を載せる意味があると思っている。同じ検証を何十回・何百回と回して仕様を寄せていく作業は、決定論的な形が定義されていれば機械が得意な種類の仕事になる。前回書いた「土台を先に作る」という話の、土台にあたるのがこの明細の形だ。

そして中分類を横に見ると、統廃合の話になる

もうひとつ、明細の形が揃うと効いてくることがある。ひとつの仕様の中で最適化するだけでなく、中分類の単位で横に並べられるようになることだ。同じ中分類の中に単価が大きく散らばる品目があるなら、それは仕様がバラけているサインかもしれない。似たものを何社からも買っているなら、仕様の統廃合サプライヤーの集約が議論できる。ここまで来ると、値引き交渉ではなく戦略の話になる。

中カテゴリ別の平均単価と取引件数を散布図にした画面。横軸が取引件数、縦軸が平均単価、バブルの大きさが支出額、色が大カテゴリを示し、同じ大カテゴリの中でも平均単価が大きく散らばっている。

中分類まで降ろして、平均単価と取引件数で散らす(バブル=支出額)。同じ大分類の中でも単価はこれだけ散らばる。「なぜ散らばっているのか」を明細で説明できる状態を作りにいっている。※ ダミーデータの実画面。

全部はやらない

最後に、範囲の話をしておきたい。間接材のカテゴリは際限なく枝分かれするので、全カテゴリを埋めるつもりはないし、それは現実的でもない。いまあるのは5つの大分類とその下の50中分類で、これは網羅ではなく着手点だ。支出の大きい大分類から始めて、効きそうな中分類へ順に降りていく。書式が1枚できるたびに、そのカテゴリの見積は比較可能になり、ベンチマークが1本増える。

夢は大きく、アクションは確実に。最適なサプライマップも、AI が回す仕様の PDCA も、そこへ行くための最初の一段は「見積書の形を1つ決める」という、ずいぶん地味な作業だった。

自分のカテゴリならこの項目が要る、この分母では現場が書けない、そもそもこの設計は違う ―― そういう意見をぜひ聞かせてほしい。


Connect — ご感想、似た課題に取り組む方との情報交換、記事への意見を歓迎します。
[email protected] までお気軽にどうぞ。

※ 現在、業務の受託やサービスの申込・相談は受け付けていません。

Back to Blog

Related Posts

View All Posts »