ROI事件ファイル No.414『見積書という名の迷宮』
見積書という名の迷宮
第一章：終わらない転記
「毎朝9時、私たちは見積書の送信作業に追われています」
TechInnovate社の業務部長は、机の上に積まれた見積書の束を指差した。それぞれに、顧客名、製品名、数量、金額が手書きで記入されている。
「当社は製造業向けの部品を販売しており、毎日約30件の見積依頼が来ます。営業が手書きで見積書を作成し、それを私たち業務部がシステムに転記し、PDFを生成し、メールで送信する。この一連の作業に、毎日約3時間かかっているのです」
業務部長の声には、疲労が滲んでいた。
「さらに問題なのは、転記ミスです。製品番号の入力ミス、数量の桁間違い、単価の転記漏れ——月に5〜6件は、顧客から『金額が違う』と指摘されます」
彼が取り出した資料には、過去半年間のミス発生件数と、その対応にかかった時間が記録されていた。
「ミスが発覚すると、営業が謝罪に行き、見積書を作り直し、再送信する。この一連の対応に、一件あたり2時間はかかります」
「つまり」とClaudeが計算した。「月に5件のミスで、10時間が失われている、と」
「ええ」と業務部長が頷いた。「そこで、RPAによる自動化を検討しています。しかし、以前も別の業務で自動化を試みて、うまくいかなかった経験があるのです」
彼の表情には、失敗への恐れが浮かんでいた。
「何が問題だったのですか」と私は尋ねた。
「自動化そのものは成功しましたが、その後のメンテナンスができませんでした。システムに少し変更があると、RPAが動かなくなる。しかし、開発を依頼した会社は既に対応してくれず、結局手作業に戻したのです」
それは、自動化における典型的な失敗パターンだった。
第二章：三つの視点
「この案件には、KPTモデルでのアプローチが有効ですね」
Geminiがホワイトボードに、三つの円を描いた。Keep、Problem、Try——振り返りと改善のフレームワークだ。
「KPTモデルとは」と私は説明を始めた。「現状を三つの視点から整理し、次の行動を決める手法です。Keep——続けるべきこと。Problem——解決すべき問題。Try——試すべき新しい取り組み」
「多くの改善活動が失敗するのは」とClaudeが続けた。「問題点だけに注目し、うまくいっている部分を見落とすからです。KPTモデルは、良い点も悪い点も両方を可視化します」
業務部長が尋ねた。「しかし、私たちの業務に、続けるべき良い点などあるでしょうか」
「それを見つけるのが、最初のステップです」と私は答えた。
[Keep：続けるべきこと]
「まず、現在の見積書作成プロセスで、うまくいっている部分を洗い出しましょう」とGeminiが提案した。
業務部長が考え込んだ。「うまくいっている、ですか……」
「例えば」とClaudeが促した。「営業が手書きで見積書を作るプロセスは、何か利点がありませんか」
「ああ」と業務部長が気づいた表情を見せた。「営業の手書き見積書には、顧客との会話の中で生まれた情報が、メモとして残されています。『急ぎ』『特別割引希望』『納期厳守』といった注記です」
「それは重要な情報ですね」と私が指摘した。「自動化する際も、この情報を失わないようにする必要があります」
「他には」とGeminiが尋ねた。
「見積書のフォーマットは、長年の改良で完成度が高いです。顧客からの評価も良い」
「つまり」とClaudeが整理した。「Keep——営業の手書きメモに含まれる顧客情報の記録。そして、現在の見積書フォーマットの維持。これらは自動化後も続けるべき要素です」
[Problem：解決すべき問題]
「次に、問題点です」と私が続けた。
業務部長が即座に答えた。「転記作業に時間がかかること。そして、転記ミスが発生すること」
「それだけですか」と私は尋ねた。
業務部長が少し考えてから答えた。「実は、営業の手書き文字が読みにくいことも問題です。業務部が判読に迷うことがあり、その度に営業に確認の電話をかけています」
「他には」とGeminiが促した。
「以前の自動化で失敗したのは、メンテナンス体制がなかったことです。RPAが止まった時、誰も直せなかった」
「つまり」とClaudeが整理した。「Problem——転記作業の工数。転記ミスの発生。手書き文字の判読困難。そして、メンテナンス体制の欠如。これらが解決すべき課題です」
[Try：試すべきこと]
「そして最後に、Try——新しく試すべきことを定義します」と私が説明した。
「RPAによる自動化は、当然Tryに入りますね」と業務部長が言った。
「ええ」とGeminiが答えた。「しかし、KPTモデルの重要な点は、Tryを『実験』として位置づけることです。うまくいくかどうか分からない。だからこそ、小さく試す」
「具体的には」と私が提案した。「最初の一ヶ月は、一日5件の見積書だけをRPAで処理します。残りの25件は、従来通り手作業で行う」
業務部長が驚いた表情を見せた。「全てを自動化するのではないのですか」
「いいえ」とClaudeが答えた。「最初から全てを自動化すると、問題が起きた時に業務が止まります。並行運用することで、リスクを最小化できるのです」
「そして」とGeminiが付け加えた。「一ヶ月後、再びKPTで振り返ります。自動化のどこがうまくいき、どこに問題があったか。それを基に、次の一ヶ月のTryを決める」
「つまり」と私が強調した。「KPTモデルは一度で終わりではありません。振り返りと改善のサイクルを、継続的に回していくのです」
第三章：螺旋階段を登る
業務部長が尋ねた。「では、最初のTryで試すべきことは、具体的に何でしょうか」
「三つあります」と私は答えた。
「一つ目、RPAによる転記自動化。営業の手書き見積書をスキャンし、OCRで文字認識し、システムに自動入力する」
「二つ目、手書き文字の判読問題への対処。OCRで認識できなかった部分は、RPAが自動的に業務部に確認アラートを出す」
「三つ目、メンテナンス体制の構築。RPA開発会社との保守契約に加えて、社内で簡単な修正ができる担当者を育成する」
Geminiが補足した。「この三つのTryを、一ヶ月間試します。そして、月末にKPTで振り返るのです」
「振り返りでは、どんなことを確認すればよいですか」と業務部長が尋ねた。
Claudeが答えた。「Keep——今月うまくいったことは何か。例えば、RPAの処理速度は期待通りだった、OCRの認識精度は思ったより高かった、など」
「Problem——今月発生した問題は何か。例えば、手書きの『3』と『8』を誤認識した、RPAが特定の製品番号で停止した、など」
「Try——来月試すべき新しいことは何か。例えば、OCRの学習データを増やす、営業に手書き文字の書き方ガイドラインを配布する、自動化対象を一日10件に増やす、など」
「このサイクルを回すことで」と私が説明した。「螺旋階段を登るように、少しずつ改善が積み重なっていきます」
業務部長の表情が明るくなった。「つまり、完璧を目指すのではなく、少しずつ良くしていく、ということですね」
「その通りです」と私は答えた。「KPTモデルの本質は、完璧主義を捨てることです。今月よりも来月、来月よりも再来月——常に前進し続けることが重要なのです」
第四章：振り返りの力
業務部長は、ホワイトボードに描かれたKPTの三つの円を見つめていた。
「これまで、自動化は『成功か失敗か』の二択だと思っていました。しかし、KPTモデルでは、『今月はここまで進んだ、来月はもう少し進もう』という考え方なのですね」
「ええ」と私は答えた。「多くのプロジェクトが失敗するのは、最初から完璧を目指すからです。しかし、現実には、やってみなければ分からないことが無数にあります」
Claudeが静かに言葉を添えた。「KPTモデルは、『失敗』を『学び』に変えます。うまくいかなかったことも、次のTryのヒントになる」
Geminiが付け加えた。「そして、定期的に振り返ることで、小さな問題が大きくなる前に対処できます」
業務部長が立ち上がり、深く頭を下げた。「ありがとうございます。来週、最初のKPTミーティングを設定します」
彼が去った後、Claudeが感心したように言った。「KPTモデルは、シンプルですが実践的ですね」
「ああ」と私は答えた。「しかし、KPTの真価は、単なる振り返り手法ではない。『変化を恐れず、小さく試し、学び続ける』という文化を組織に根付かせることだ」
窓の外では、午後の陽光が事務所を照らしていた。
三ヶ月後、TechInnovate社から報告が届いた。
最初の一ヶ月で、5件の自動化に成功。OCRの認識精度は92%で、8%は人の確認が必要だったという。
二ヶ月目、営業に「数字は楷書で書く」というガイドラインを配布し、OCR精度が97%に向上。自動化対象を10件に増やした。
三ヶ月目、自動化対象を20件に拡大。転記ミスはゼロ。業務部の作業時間は、3時間から1時間に短縮された。
そして、最も重要な発見は、月次のKPTミーティングが「改善を語る場」として定着したことだった。業務部だけでなく、営業も参加し、「もっとこうできるのでは」というアイデアが次々と生まれていた。
螺旋階段は、確実に登られていた。
「改善とは、一度の大きな変革ではなく、小さな前進の積み重ねである。Keep・Problem・Tryの三つの視点で振り返り、学び、次の一歩を踏み出す。このサイクルを回し続けることで、螺旋階段を登るように、確実に高みへと到達できる」
関連ファイル
