見積AIの導入検証(PoC)|先に決める4つの判定
結論:見積AIの導入検証は、始める前に4つの判定の条件を書いておく
デモで見積の草案が出ることと、自社の業務で使えることは別です。見積AIの導入を検証するときは、次の順で進めます。
- 始める前に、「採用」「範囲を限って採用」「直して再検証」「見送り」の4つの判定と、それぞれの条件を書いておく
- 案件は、過去の案件と、これから来る依頼の2本立てで用意する
- これから来る依頼は、いつもどおり人が見積を作り、AIの草案は提出に使わずに横に並べる
- 案件ごとに記録表を埋め、空欄は「問題なし」ではなく「未検証」と書く
結果を見てから条件を決めると、「慣れれば使えそう」「惜しかった」という感想で線が動きます。条件は先に、業務の責任者が決めます。
検証の範囲は「依頼から承認まで」
本記事が扱うのは、依頼を受けてから見積を承認するまでの業務全体での検証です。範囲の狭い検証は、それぞれ別の記事で解説しています。
- 図面から数量を出す工程だけを比べる方法:AI積算・拾い出しソフトの選び方
- 製品のデモで自社の過去1案件を操作してもらう方法:見積システムの選び方
- 検証で測る3つの観点(総所要時間・根拠の追跡・承認の再現性):見積AIとは
この3つで「使えそう」と分かったあとに、実際の業務の流れに入れて確かめるのが本記事の検証です。
4つの判定と条件を、先に書いておく
判定ごとに、満たす条件と次にやることを決めておきます。条件の中身は架空の例で、自社の業務に合わせて書き換えてください。
| 判定 | 条件の例 | 次にやること |
|---|---|---|
| 採用 | 許容できないエラーが0件。確認と修正を含めた短縮が損益分岐を超えた。承認者が数字の根拠をたどれた | 対象の工程と案件の種類を決めて使い始める |
| 範囲を限って採用 | 一部の工程や案件の種類だけで、採用の条件を満たした | 条件を満たした範囲だけで使う。ほかは手作業のまま |
| 直して再検証 | 条件を満たさなかった原因が、入力の側(単価マスタの未整理、依頼の聞き取りの漏れなど)にある | 原因を直してから、同じ案件でもう一度試す |
| 見送り | 許容できないエラーが繰り返し出る。情報管理の条件が合わない。短縮が損益分岐に届かない | 見送った理由を記録して終える |
損益分岐は、利用料と立ち上げ・維持の作業から「見積1件あたり何分短くなれば元が取れるか」を逆算した値です。計算のしかたは見積AIの費用対効果で解説しています。
「許容できないエラー」と「直せる課題」も、始める前に分けて書いておきます。
| 許容できないエラーの例 | 直せる課題の例 |
|---|---|
| 搬入・撤去の費用が抜けている | 品目名の表記が自社と違う |
| 会場が指定する業者の費用が抜けている | 明細の並び順が違う |
| 日数と数量を取り違えている | 見積書の書式が違う |
| 根拠をたどれない金額が入っている | 端数の扱いが自社のルールと違う |
合計の金額が近くても、左の列が1件でもあれば採用の条件を満たしません。どこで漏れが起きやすいかは見積漏れを防ぐチェックリストで工程別に整理しています。
案件は「過去の案件」と「これから来る依頼」の2本立てにする
検証に使う案件には、性質の違う2種類があります。
| 案件 | 良い点 | 気をつけること |
|---|---|---|
| 過去の案件 | 確定した見積があり、正解と比べやすい。すぐに始められる | 依頼のときには無かった情報が、最終の見積に混ざっている。設定の調整に使った案件は、最後の判定には使わない |
| これから来る依頼 | 依頼のときの情報だけで草案を作るので、実際の力が分かる | 件数がそろうまで時間がかかる。作業が二重になる |
過去の案件だけで判断すると、最終の見積を正解にして「依頼の時点では誰にも分からなかったこと」まで当てさせる評価になります。過去の案件で設定を調整し、最後の判定はこれから来る依頼で行うと、結果を読み違えにくくなります。
どちらも、得意そうな案件だけを選ばないようにします。ふつうの案件、途中で条件が変わった案件、依頼の情報が足りない案件を混ぜてください。
これから来る依頼は「並行運用」で試す
これから来る依頼で試すときは、担当者はいつもどおり見積を作って提出し、AIの草案は提出に使わずに横に並べます。提出する見積は人が作ったものなので、検証中に顧客へ誤った見積を出す心配がありません。
並行運用で測る時間は、AIの草案を「そのまま提出できる状態」まで直すのにかかった時間です。同じ担当者が先に自分で見積を作ると、答えを知った状態で草案を直すことになり、時間が短く出ます。草案を直す人と、見積を作る人を分けるか、分けられない場合は記録にその旨を残します。
並行運用の間は、作業が二重になります。その工数も、検証の費用として見込んでおきます。
案件ごとに記録表を埋める
1案件ごとに、次の項目を記録します。
| 項目 | 記録すること |
|---|---|
| 案件の種類 | ふつう/条件変更あり/情報不足、過去の案件/これから来る依頼 |
| 入力した資料 | 依頼文・図面・過去の見積など、何を渡したか |
| 草案までの時間 | 資料を渡してから草案が出るまで |
| 確認と修正の時間 | 草案を提出できる状態まで直すのにかかった時間 |
| 許容できないエラー | 件数と中身 |
| 直せる課題 | 件数と中身 |
| 根拠の追跡 | 承認者が、数量と単価の出どころをたどれたか |
| 情報管理 | 入れた資料が、事前に決めた範囲に収まっていたか |
空欄を「問題なし」と扱わないでください。確かめていない項目は「未検証」と書き、その状態で本番に進めてよいかを判定のときに決めます。
検証の途中で止める条件も決めておきます。たとえば「同じ種類の許容できないエラーが2件続いたら、いったん止めて原因を確かめる」のように書いておくと、原因が入力の側にあるのか、ツールの側にあるのかを早く切り分けられます。
情報管理と費用の確認は、検証の前に済ませる
顧客の図面や協力会社の単価を検証に使う前に、データがどこへ送られ、どう保存され、誰が見られるかを確かめます。確かめる項目は見積AIのセキュリティ確認にまとめています。
損益分岐の計算も、検証の前に済ませておきます。終わってから計算すると、結果に合わせて前提を動かしたくなります。
検証の対象にする工程を決めるときは、イベント業界の見積・発注DXガイドの現在地チェックリストで、自社の見積業務のどこに時間がかかっているかを先に整理しておくと絞り込みやすくなります。
よくある質問(FAQ)
Q. デモで良い結果が出ました。それでも検証は必要ですか? 必要です。デモの資料は、ベンダーが選んだものか、設定を調整したあとのものであることが多いためです。自社の案件、特に条件が途中で変わった案件や情報が足りない案件で、同じ結果になるかを確かめてください。
Q. 何件くらい試せば判断できますか? 件数より、案件の種類がそろっているかが大切です。ふつうの案件・条件変更のあった案件・情報不足の案件を、それぞれ複数件入れてください。少ない件数の結果を、全社の効果として一般化しないようにします。
Q. 判定が「直して再検証」になりました。どこを直せばよいですか? 記録表の「許容できないエラー」の中身を見ます。単価の取り違えが多いなら単価マスタ、条件の抜けが多いなら依頼のときの聞き取りの項目が原因です。単価マスタの整え方は見積の単価マスタで解説しています。
Q. 検証は誰が判定すればよいですか? 見積業務の責任者が判定します。ベンダーの担当者は設定や操作の支援に入ってもらいますが、判定には加わりません。判定の条件を事前に書いておけば、誰が判定しても同じ結論になります。
次のステップ
導入検証の前に、見積業務の現状を社内で同じ観点で整理する場合は、イベント業界の見積・発注DXガイドを確認してください。見積書テンプレート(Excel・自動計算式入り)、見積業務の隠れコストの試算、自社の現在地チェックリスト10項目を収録しています。