「見積を出せるのが一人しかいない」「その人が休むと問い合わせへの返事が止まる」——工事・製造・印刷・設備など、 案件ごとに条件が変わる仕事をしている会社では、見積と積算の業務がよく悩みの種になります。 長年使ってきたエクセルの見積表があり、担当者はそれを使いこなしている。けれども、表のどこに何の意味があるのかを説明できるのは、その担当者だけという状態です。
こうした状況でシステム化を考えると、「ベテランの頭の中を全部システムにしたい」という期待と、 「うちの見積は特殊だから無理だ」というあきらめの間で、話が止まってしまいがちです。 この記事では、システム開発とAI活用を手がけるCoconutWorksが、見積業務を段階に分けて、どこまでを仕組みにし、どこを人に残すかを決める考え方を整理します。 費用の相場は業種や規模で大きく変わるため、数字は出さずに判断の筋道に絞ります。
結論: 見積業務を段階に分け、計算と判断を切り離す
| 段階 | 仕組みに任せやすいこと | 人に残すこと |
|---|---|---|
| 依頼を受け取る | 受付の項目をそろえ、一か所に記録する | 曖昧な依頼の意図をくみ取り、聞き返す |
| 数量を拾う | 拾った数量の記録・集計・単位の換算 | 図面や現場を見て、何をどれだけ見込むか決める |
| 単価を当てる | 単価表の管理と、決まった計算式の適用 | 単価表にない品目・作業の値付け |
| 調整する | 過去の似た見積を探して並べる | 値引き・難易度の上乗せ・受けるかどうかの判断 |
| 書類を作る | 見積書の作成・版の管理・承認の記録 | 条件や前提の書き方の最終確認 |
| 結果を残す | 受注・失注と実際にかかった原価のひも付け | 外れた理由を振り返り、次の判断に活かす |
見積業務は「見積を作る」という一つの作業ではなく、性質の違う段階の集まりです。 決まったルールで回せる計算や記録は仕組みに任せやすく、条件を見て見込む・値を決めるといった判断は人に残すほうが無理がありません。 システム化がうまくいくかどうかは、この計算と判断の境目をどこに引くかで大きく左右されます。 以下、なぜ属人化するのかから順に掘り下げます。
見積業務が一人に集まってしまう理由
見積が属人化する会社では、エクセルの見積表の中に二種類のものが混ざっていることがよくあります。 一つは、数量に単価を掛ける、諸経費を一定の割合で乗せるといった決まった計算。 もう一つは、「この現場は搬入がしにくいから手間を多めに見る」「この取引先には前回これで通したから合わせる」といった担当者の判断です。 後者は、セルに直接打ち込まれた数字や、計算式を上書きした値として表の中に紛れ込みます。
表を見ただけでは、どのセルが計算でどのセルが判断なのか区別がつきません。 そのため、新しく担当になった人は表の使い方は覚えられても、「なぜこの数字なのか」が分からず、結局ベテランに確認することになります。 確認が集まるほど、ベテランは見積以外の仕事ができなくなり、教える時間もなくなる。 属人化は、本人のやり方の問題というより、計算と判断が同じ場所に混ざっている構造から生まれることが多いのです。
単価表の管理も、属人化を進める原因になります。仕入れ値が変わるたびに誰かが手で表を直し、 直した版がメールで回り、古い版を使った見積が出てしまう。こうした「どれが最新か分からない」問題は、 判断の難しさとは関係なく、仕組みで比較的解決しやすい部分です。
仕組みに任せやすい部分: 単価・計算・書類・記録
最初に仕組みにするのに向いているのは、ルールが言葉や式で書ける部分です。 単価表を一か所で管理して版を残す、数量と単価から金額を出す、諸経費や端数処理を決まった規則で計算する、 見積書を決まった書式で出力し、誰が承認したかを記録する。これらは担当者が変わっても答えが変わらない作業で、 仕組みにしたときの効果が分かりやすい部分です。
たとえば、営業担当が外出先から問い合わせを受け、事務所に戻ってから見積表を開き、 単価表の最新版を探して計算し、書式に貼り付けて上長にメールで確認してもらう——という流れがあるとします。 この中で、単価を探す・計算する・書式に整える・確認の記録を残す、の部分は仕組みで短くできます。 残るのは「何をどれだけ見込むか」を決める部分で、担当者はそこに時間を使えるようになります。
もう一つ見落とされやすいのが、結果を残す仕組みです。 出した見積が受注になったか、失注したか、受注した案件で実際の原価はどうだったか。 これが見積とひも付いて残っていると、次の見積で「似た案件ではどうだったか」を確かめられます。 多くの会社でこの記録はばらばらの場所にあり、見積の精度を上げる材料として使われていません。 見積書を作るだけのシステムより、作った後の結果まで残るシステムのほうが、時間とともに価値が増していきます。
人に残す部分と、AIが手伝える範囲
一方で、何をどれだけ見込むか、単価表にない作業をいくらと見るか、値引きにどこまで応じるか、そもそも受けるか—— こうした判断は、無理にルール化しないほうが安全です。条件の組み合わせが多く、例外が当たり前に出てくるため、 ルールで書こうとすると条件分岐が増え続け、作る費用も直す費用も膨らみます。 そのうえ、ルールにない案件が来たときには結局人が判断することになります。
ここで役に立つのは、判断そのものではなく判断の材料を集める部分を手伝う発想です。 AIを使える場面としては、たとえば次のようなものがあります。
- 依頼内容の整理 — 問い合わせメールや依頼書から、品目・数量・納期・場所などの項目を抜き出し、受付の形にそろえる下書きを作る。
- 過去の見積の検索 — 依頼内容に近い過去の見積と、そのときの条件や結果を探して並べる。
- 前提条件の書き漏れの確認 — 見積書の条件欄に、通常書いている項目が抜けていないかを指摘する。
どれも、AIの出力を担当者が確認して直す前提の使い方です。金額そのものをAIに決めさせることは、 社外に出て契約に直結する数字であるため、慎重に考えたほうがよいと私たちは考えています。 また、図面や写真からの数量の拾い出しをAIに任せたいと考える方もいますが、図面の書き方や品質によって結果が大きくぶれるため、 まず小さく試して、確認にどれだけ手間がかかるかを見てから判断するのが現実的です。 AIの使いどころの見つけ方は業務の棚卸しからAIの使いどころを見つける手順でも整理しています。
人に残す判断にも、仕組みで支えられることはあります。値を調整したときに「なぜそうしたか」を一言残す欄を設けておくと、 判断の理由が少しずつ蓄積され、後から振り返ったり、新しい担当者に伝えたりする材料になります。 ベテランの知見は、一度に聞き出してルールにするより、日々の見積の中で少しずつ記録していくほうが残りやすいものです。
よくある失敗: 全部をルールにする、エクセルをそのまま画面にする
「ベテランの判断を全部ルールにしようとする」 — 最初の打ち合わせで、ベテランの担当者に見積の考え方を聞き取り、 それをすべて条件分岐として組み込もうとするケースです。聞き取りの段階では整理できたように見えても、 実際の案件では「この場合は例外」が次々に出てきます。そのたびに改修が必要になり、 やがて担当者はシステムを使わずにエクセルに戻ってしまう。判断は人に残すと決めておけば、例外が出てもシステムは止まりません。
「今のエクセルの形をそのまま画面にする」 — 使い慣れた表の形を変えたくない気持ちは自然ですが、 表の形をそのまま再現すると、計算と判断が混ざった構造もそのまま移ってしまいます。 画面は新しくなっても、「なぜこの数字か」が分からない問題は残ります。 表の見た目より、表の中で何を決めているかを洗い出し、計算はシステムが持ち、判断は入力欄として明示する形に整理し直すことが大切です。
「見積だけを切り離して考える」 — 見積の金額は、受注後の発注・原価管理・請求とつながっています。 見積だけを独立したシステムにすると、受注後に同じ内容を別のシステムへ打ち直す作業が残ることがあります。 最初から全部をつなぐ必要はありませんが、後でどこにつなぐ可能性があるかは、作り始める前に確認しておくと手戻りが減ります。
システム化を進める順序とチェックポイント
見積業務のシステム化は、次の順序で進めると、どこまでを仕組みにするかを無理なく決められます。
- ①今の見積を数件集める — 実際に出した見積書と、そのときの見積表を、典型的な案件と迷った案件の両方から集めます。
- ②セルを「計算」と「判断」に色分けする — 見積表のどの値が式で決まり、どの値を担当者が考えて入れているかを担当者と一緒に確かめます。
- ③段階ごとに困りごとを書く — 冒頭の表の段階に沿って、どこで時間がかかり、どこで間違いや確認待ちが起きているかを書き出します。
- ④最初に仕組みにする範囲を決める — 単価表の一元管理と見積書の作成など、効果が分かりやすく判断が絡まない部分から始めます。
- ⑤結果の記録を加え、判断の支えを広げる — 使い始めてから、受注・失注や原価のひも付け、過去の見積の検索などを足していきます。
②の色分けは、地味ですが効果の大きい作業です。担当者本人も、どこまでが決まった計算でどこからが自分の判断なのかを 意識していないことが多く、色分けしてみると「ここは実は毎回同じ値を入れていた」「ここは毎回悩んでいた」といった発見があります。 前者は仕組みに移せる候補、後者は人に残す候補です。この作業は外部に頼む前に社内で始められますし、 やっておくと相談したときの話が具体的になります。
判断に迷ったときのチェックポイントとしては、「担当者が変わっても同じ答えになるか」を問うのが分かりやすい基準です。 同じ答えになるならルールにでき、人によって答えが変わるなら判断として残す。 この線引きを関係者で共有しておくと、開発の途中で「これもシステムでやってほしい」という要望が増え続けるのを防げます。 要件をまとめる前の準備については要件定義の前に発注側が準備することもあわせてご覧ください。
既製の見積ソフトか、自社に合わせて作るか
見積書の作成や単価表の管理だけが目的なら、既製の見積ソフトやクラウドサービスで足りることも少なくありません。 業界でよく使われる計算の仕方に沿っているなら、まず既製品を試すほうが早く始められ、費用も抑えやすくなります。
一方で、自社独自の積算の考え方が多い、既存の販売管理や原価管理とデータをつなぎたい、 過去の見積と結果を自社の見方で探せるようにしたい、といった事情がある場合は、自社に合わせて作る選択肢が出てきます。 どちらが合うかは、前の節の②③で整理した内容を既製品の画面に当てはめてみると見えてきます。 既製品で表現できない部分が判断を支える肝心な部分なのか、なくても困らない部分なのかが、分かれ目になります。 選び方の考え方は業務システムはSaaSと自社開発どちらを選ぶかで詳しく扱っています。
よくある質問
まとめ
見積・積算の業務が一人に集まるのは、多くの場合、決まった計算と担当者の判断が同じ表の中に混ざっているためです。 業務を段階に分け、担当者が変わっても同じ答えになる計算や記録は仕組みに任せ、何をどれだけ見込むか・いくらで出すかといった判断は人に残す。 AIは判断そのものではなく、依頼の整理や過去の見積探しといった材料集めで手伝ってもらう。 この線引きから始めると、例外が出ても止まらず、使い続けるほど判断の材料が蓄積されていくシステムに近づきます。 今の見積表や見積書をお持ちいただければ、どこまでを仕組みにするかの整理からご相談いただけます。システム開発サービスのページもあわせてご覧ください。相談・お見積もりは無料です。
