ハセガワークスCTOの佐藤です。顧客参加型の見積システム「SASATTO」の導入・要件定義・開発を担当しています。

現在、私は見積の仕組みを作っている立場ですが、見積自体を作る業務もそれなりに経験があります。

当時、自社に見積のためのシステムは既に入っていました。使い方が分からなかったわけでもありません。それでも、一日が見積で終わる日は減りませんでした。

長い間、自分の段取りが悪いのだと思っていました。システム開発をする時と同様に、見積には見積の勘所というものが存在するのだと。そうではないと分かったのは、自分が何に時間を使っているのかを、改めて工程ごとに書き出してみたときです。

短くなっていたのは、見積書を「作る」時間だけでした。

早くはなった。でも、楽にはならなかった

システムを使って、確かに変わったことがあります。

  • 過去の見積を探せるようになった
  • 書式が揃い、担当者ごとのばらつきが減った
  • 承認がどこで止まっているか見えるようになった
  • 似た案件を複製して作れるようになった

効果を疑ったことはありません。実際、見積書1枚を仕上げるまでの時間は、目に見えて短くなりました。

それでも、朝の始まり方は変わりませんでした。

メールを開くと依頼が並んでいて、そこから処理を始める。エンドユーザーや問屋さん、様々なお客様から直接電話をいただくことも多々ありました。そして夕方になってようやく、その日やるはずだった仕事に手をつける。

早くはなった。でも楽にはならなかった。この差が何なのか、しばらく分かりませんでした。

何に時間を使っているのか、書き出してみた

ある日ふと、見積1件が終わるまでに自分が何をしているのかを、順番に書き出してみたことがあります。

工程システムが触れているか触れていない理由
① 依頼を受け取り、内容を読み解くいいえ電話・メール・FAX・チャットなど、届く経路は相手が決めている
② 足りない情報を聞き返すいいえ何が足りないかは案件ごとに違い、判断できるのは人だけ
③ 取引先ごとの価格・取扱条件を確認する一部データは整理されるが、参照できるのは社内に限られる
④ 明細を入力するはい―
⑤ 書式を整えて送付するはい―
⑥ 修正依頼を受けて作り直す一部作り直しは速くなるが、修正依頼が発生する回数は変わらない
⑦ 進捗を聞かれる、催促するいいえ相手側から進捗が見えないため、聞くか答えるかしかない

書き出して分かったのは、システムが触れていたのは主に④と⑤、それに⑥の後半だけだということでした。

そして④と⑤は、7つのなかで一番短い工程でした。明細の入力そのものは、慣れていれば数分で終わります。時間を奪っていたのは、その前後にある聞き取りと、やり取りの往復と、注文前後のやり取りでした。

速くしても、総量が減らない

入力の起点が社内にある限り、往復は消えない

型番が省略されている。数量が「一式」と書かれている。納入場所が空欄になっている。そして「いつものアレ」と言われる笑

こうした必要項目は、受け取ってから気づき、聞き返してようやく埋まります。

システム側の入力欄をどれだけ整えても、②には効果がありません。②は入力の前段にあるからです。何を入力すべきかを知っているのは、最初から相手だけでした。

条件が社内で閉じているので、確認は結局その人に戻る

取引先ごとの価格や取扱条件をシステムに集約すると、社内では確かに探しやすくなります。ただ、それを見られるのは社内の人間だけです。

結果として、「あの取引先の条件は、あの人に聞けば正確」という状態が残ります。

効率化は「1件あたり」にしか効かない

1件10分の作業が7分になったとします。日に8件あれば24分の削減で、数字としては悪くありません。

ただ、8回の中断は8回のまま残ります。依頼が届くタイミングを決めているのは相手で、こちらではないからです。手を止めて、内容を読んで、元の作業に戻るまでの立ち上げ直し。この時間は、どの効果測定にも計上されません。

「切替負荷」と私は定義しています。

システムが悪いわけではない

しばらくして、これはシステムの問題ではないと考えるようになりました。私が過去に使っていたサービスを例に出してみます。

「kintone」は業務アプリを自分たちで組み立てるためのプラットフォームで、見積は標準機能ではなく、アプリやプラグインを組み合わせて構成します。「楽楽シリーズ」も、楽楽販売は販売管理、楽楽精算は経費精算、楽楽明細は帳票発行と、製品ごとに対象領域が分かれています。

共通しているのは、いずれも「社内で発生した情報を、記録し、統制し、蓄積する」ことを中心に設計されている点です。そして、その目的については実際に機能していました。

私が困っていたのは、そこではありませんでした。見積依頼に対応する時間を決めていたのは、社内で発生した情報ではなく、社外から、こちらの都合と関係なく届く依頼です。

設計の対象が違うものに、対象外の効果を期待していた。「入れたのに変わらない」と感じていたことの正体はこれだったのです。

入力の起点は、もともと社外にあった

必要なものを最もよく知っているのは、発注する側です。何を、いくつ、いつまでに欲しいのか。その情報は、最初から相手の中にあります。

にもかかわらず、最初の入力をしているのは受け取る側でした。相手の頭の中にある情報を、電話とメールで聞き出して、こちらが代わりに入力する。見積業務の時間の多くは、この転記のために使われていました。

そう考えると、①②③⑥⑦は「速くできる作業」ではありませんでした。起点が違うところにあるせいで発生している作業です。これを何とかできないか、と考えました。

だから、そこを動かすものを作っている

いま開発しているSASATTOは、この起点を動かすためのものです。取引先ごとの価格や取扱条件をあらかじめ反映したうえで、取引先自身が必要な見積を作成・確認できるようにしています。

作る時間を短くするのではなく、受ける回数そのものを減らす。そして、見積を作る側と依頼する側、どちらにもメリットを提供できるようにする。方針として置いているのはこれだけです。

はじめは、私と代表の長谷川をペルソナに置き、私たち自身の見積業務がゼロになるように構築しました。結果本当に楽になったので、同じような課題を抱えている方や企業にも展開できればと思っていたのですが、お客様に話を伺っていくと、そのままSASATTOを当てはめられないというパターンがほとんどでした。

そこで、「SASATTOをお客様の課題に合わせて設計する」「システムが業務に合わせる」という発想で、ご要望に沿ったカスタマイズをお客様毎に実装する方針に舵を切りました。

このあたりについては別途、記事として公開できればと思います。

見積を営業が作らないという考え方については、こちらの記事でも触れています。