ROI事件ファイル No.515『見積もりが、いつもどんぶり勘定で出ていた』
見積もりが、いつもどんぶり勘定で出ていた
第一章：売値の根拠が、誰にも説明できない
「見積もりは出ているんです。ただ、売値の根拠が誰にも説明できない」
GlobalTech社の経営企画部長、戸塚航司氏は、そう言いながら過去の見積もり書を並べた。OEM受託製造業。中国の工場で部品加工を行い、日本国内で組立販売を行う。「中国工場から届く見積もりをドル建てで受け取り、日本円に換算し、諸経費と関税を加算する。この作業が手作業で、担当者ごとに方法が違う」
「原価計算の現状は」とClaudeが尋ねた。
「Geminiで試験的にやっています」と戸塚氏が答えた。「ドル円換算、関税率の適用、間接費の按分——AIで自動化しようとしているが、精度が不安定。さらに、間接費（人件費、設備減価償却、品質管理コスト）の配賦ロジックが定まっていない。結果、見積もりの精度がバラバラで、案件によっては赤字受注している可能性がある」
「課題は原価計算の精度だけですか」と私が確認した。
「もう一つあります」と戸塚氏が答えた。「現状の売値が適正なのか、誰も検証できていない。十年前の価格設定をベースに、なんとなく利益が出る数字で見積もっている。製造原価が高いのか、売値が安いのか、構造が見えない」
「やりたい仕事は何ですか」と私が尋ねた。
「適正な売値を、根拠を持って提示できる体制です」と戸塚氏が答えた。「営業が顧客に説明できる、経営が判断できる、現場が改善できる——三層で使える原価情報が欲しい」
「では、JTBDで分解しましょう」と私が応じた。
第二章：JTBDが問う、本当に進めたい仕事は何か
「この案件には、JTBDが必要です」
Claudeがホワイトボードに「J・T・B・D」と書いた。
「JTBD、Jobs To Be Doneとは、顧客や利用者が達成したい『進捗』を分解し、その進捗を阻む障害を特定するフレームワークです」と私が説明した。「クリステンセンが提唱した理論ですが、社内業務の設計にも本質的に有効です。原価計算という機能を作るのではなく、『見積もりに根拠を持たせ、判断を進める』というJobを起点に設計すると、必要な機能が自然と決まります」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。戸塚氏から提供された見積もりデータを入力する。
「月間の関連コストが出ました」とGeminiが読み上げた。「見積もり作成工数が月平均百六十時間、時給三千八百円で月六十万八千円。間接費按分の手計算工数が月平均八十時間、月三十万四千円。原価精度不足による赤字受注リスク期待値が月平均百四十万円——案件単位の損益検証ができていないため発生確率が高い。適正売価設定ができないことによる利益機会損失が月平均百八十万円。経営判断材料の作成工数が月平均六十時間、月三十六万円。見積もり提示遅延による失注機会損失が月平均六十万円。合計で月五百七万二千円。年間換算で約六千九十万円」
戸塚氏が数字を見つめた。「赤字受注リスクと利益機会損失の数字が一番大きいですね。今までは見積もり工数だけを見ていました」
「では、JTBDで設計します」と私が続けた。
[Job定義——本当に進めたい仕事は何か]
「最初に、達成したいJobを定義します」とClaudeが言った。「『原価計算を自動化する』はJobではなく機能です。本当のJobは『見積もりに根拠を持たせ、案件単位で適正な売価判断を進める』こと。さらに上位のJobは『製造業として持続的に利益を確保する』ことです。Jobの階層を意識すると、機能の優先順位が変わります」
[Job阻害要因——進捗を止めている障害を分解]
「次に、Jobの進捗を阻んでいる障害を特定します」とGeminiが続けた。「障害一、ドル円換算と関税適用の手作業による誤差。障害二、間接費按分ロジックが標準化されていないこと。障害三、案件単位の損益が事後検証できないこと。障害四、過去データが分析されておらず売価適正値の判断材料がないこと。障害五、見積もり提示までの時間が長く、商機を逃すこと。五つの障害を一気に解消する設計が必要です」
[現行AI（Gemini）の位置づけ]
「現在試験運用しているGeminiの位置づけです」と私が続けた。「Geminiは換算と計算の補助には有効ですが、Job全体を担う設計にはなっていません。AI単体ではなく、原価データベース・案件管理システム・経営ダッシュボードと連携した『原価ジョブを進める基盤』として位置づけ直します」
[Job中心の設計——五つの障害をつぶす]
「Jobを起点に、五つの障害をつぶす設計を組みます」とClaudeが続けた。「ドル建て見積もりは取得時に自動で円換算・関税適用。間接費按分は標準ルールをシステムに組み込み、案件特性に応じて自動算出。案件完了時に実績原価が自動集計され、見積もりとの差分が経営ダッシュボードに表示される。過去案件の利益率分析から、適正売価レンジが算出される。見積もりは過去類似案件をベースに、Geminiが初期ドラフトを生成し、担当者は確認のみ」
[投資回収を試算する]
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
- 初期費用：原価計算基盤・間接費按分エンジン・案件損益ダッシュボード・Gemini連携・経営判断レポート機能・現場研修費用合計九百六十万円
- 月次費用：システム運用・AI利用料合算月三十二万円
- 月次削減効果：見積もり作成工数削減＝月四十二万円、間接費按分工数削減＝月二十一万円、赤字受注リスク低減＝月百十万円、適正売価設定による利益向上＝月百二十万円、経営判断材料作成削減＝月二十五万円、見積もり提示速度向上による失注削減＝月四十二万円、合計月三百六十万円
- 月次純削減：三百六十万円－三十二万円＝月三百二十八万円
- 投資回収期間：九百六十万円÷三百二十八万円＝約二・九ヶ月
「三ヶ月以内です」とGeminiが整理した。「最大の削減項目は適正売価設定による利益向上です。原価が見えるようになると、低利益案件の値上げ交渉や、高利益案件への営業集中という意思決定ができるようになる」
戸塚氏が数字を確認しながら言った。「原価計算という機能の議論をしていました。Jobの階層で見ると、利益確保という上位目的が見えてくる」
「JTBDは、機能の議論を目的の議論に戻す道具です」と私が応じた。
第三章：Jobを起点に進める設計計画
「進め方を整理します」と私がホワイトボードの前に立った。
「第一・二ヶ月——過去三年分の見積もりと実績原価のデータ整理、間接費按分ルールの標準化議論。第三ヶ月——原価計算基盤の要件定義、Geminiとの連携設計。第四・五ヶ月——システム開発、案件損益ダッシュボード構築。第六ヶ月——試験運用、過去案件で精度検証。第七ヶ月——本番運用開始、見積もりプロセスへの組込。第八ヶ月以降——蓄積データをもとに適正売価レンジの精緻化、経営判断への活用拡大」
「Geminiは置き換えますか」と戸塚氏が確認した。
「Geminiは中核として残します」とClaudeが応じた。「自然言語での見積もり初期ドラフト生成、過去案件との類似検索、経営層への要約レポート作成——これらの領域でGeminiの強みが活きる。連携基盤として組み込み直すイメージです」
戸塚氏がメモを取りながら言った。「『AIを入れる』が目的だったプロジェクトが、『Jobを進める』設計に変わりましたね」
第四章：根拠ある見積もりが、当たり前になった日
十ヶ月後、戸塚氏から報告が届いた。
見積もり作成時間は、新基盤稼働三ヶ月後に従来比で六十五パーセント減少。過去類似案件をベースにGeminiが初期ドラフトを生成し、担当者は確認と微調整のみで完成するようになった。「以前は一案件あたり半日かかっていた見積もりが、一時間で出る」と戸塚氏は記していた。
最も大きな変化は、案件単位の損益が事後検証できるようになったことに表れた。実績原価が自動集計され、見積もりとの差分が見えるようになったことで、赤字受注の発見・対応が早期化。「以前は四半期決算で初めて『この案件は赤字だった』と気づいていた。今は案件完了時点で見える」と報告書にあった。半年間で発見された赤字案件への対応により、年間で約二千百万円の損失回避を実現した。
適正売価レンジの議論も始まった。過去案件の利益率分布が可視化されたことで、営業部と経営層の間で「この製品群は値上げ余地がある」「この顧客は他社と比べて低単価で受けすぎている」という具体的な議論が成立。「値上げ交渉の根拠が、感覚論からデータに変わった」と戸塚氏は記していた。
Geminiの活用範囲も広がった。経営層向けの月次原価レポート、営業部向けの案件別損益コメント、製造部向けの原価改善提案——同じ原価データから三種類の要約が自動生成される運用が定着した。「同じデータでも、見る人が違えば必要な要約も違う。AIがその差を埋めた」と報告書にあった。
副次効果として、現場の意識も変わった。製造現場が原価の動きを自分の業務と紐づけて見るようになり、改善提案が増加した。「以前は『原価は経理の仕事』だった。今は『自分の作業が原価にどう響くか』を考えるようになった」と戸塚氏は記していた。
中国工場との交渉力も変化した。詳細な原価内訳が見えるため、工場側からの値上げ要請に対して具体的な根拠で反論できるようになった。「以前は言われるがままに受け入れていた値上げが、数字で議論できるようになった」と報告書にあった。
戸塚氏の報告書の最後にはこう書かれていた。「『AIで原価計算を自動化したい』という相談で始まったプロジェクトが、JTBDで分解した結果、利益確保の経営課題に変わった。Jobの階層を見れば、機能の議論は目的の議論に変わる」
どんぶり勘定で見積もりを出していた朝が消えた日、原価データが経営判断の土台になっていた、と記されていた。
「AIで自動化したい、という依頼の多くは、機能の議論で止まる。JTBDが問うのは、本当に進めたい仕事は何か、だ。Jobの階層を一段上げれば、原価計算は利益確保の話になり、見積もり自動化は判断スピードの話になる。機能を作る前に、Jobを定義する。進捗を阻む障害を特定し、それをつぶす設計に変える。どんぶり勘定で見積もりが出ていた工場で、Jobの言語化が進んだ日、変わったのは計算速度ではなく、利益への向き合い方そのものだった」
関連ファイル
使用ツール
- ROI Polygraph — 見積もり工数・赤字受注リスク・適正売価機会損失の可視化
- ROI Proposal Generator — Jobを起点とした原価基盤の投資回収シミュレーション
