業務の自動化で何を聞けば外さないか｜依頼の言葉どおりに作ると効果が出ない理由
業務の自動化で何を聞けば外さないか｜依頼の言葉どおりに作ると効果が出ない理由
業務の自動化やシステム化を頼むとき、あるいは頼まれたとき、何を聞けば外さないのか。先に結論を書きます。
聞くべき質問はひとつです。「そのデータを受け取った人は、次に何をしますか」。これを、相手の手が止まるまで繰り返します。
依頼の言葉――「このデータをスプレッドシートに自動で入れてほしい」「毎朝レポートを届けてほしい」――をそのまま作ると、たいてい効果が出ません。正確に言うと、動くものはできます。ただ、現場は楽になりません。依頼の言葉は業務の入口を指していることが多く、本当に時間を食っている工程はその先にあるからです。
この記事では、名古屋のWEB制作会社graciautoが実際に手がけたEC受注業務の自動化を例に、依頼の言葉と実際のボトルネックがどうずれるのか、それを見つける質問の重ね方、そして設計をゼロから起こさず既存の帳票をそのまま設計図に使う考え方を説明します。発注する側の経営者・WEB担当者にも、受託する側にも、同じ構造がそのまま使えます。
依頼の言葉は「症状」であって「病巣」ではない
自動化の依頼は、ほぼ必ず「目に見える入口」の言葉で来ます。
- 「受注データを毎朝スプレッドシートに反映してほしい」
- 「問い合わせを一覧にまとめてほしい」
- 「売上を自動で集計してほしい」
依頼者が嘘をついているわけではありません。毎日触っている作業のうち、いちばん説明しやすい部分がそこだった、というだけです。人は自分の業務フローを工程表として頭に持っているわけではないので、「面倒くさい」という体感を、いちばん言葉にしやすい箇所に載せて伝えてきます。
問題は、この言葉をそのまま要件にすると、入口だけが自動化されて、その先の手作業が全部残ることです。データがスプレッドシートに自動で入るようになっても、そのデータを見て検索して、転記して、印刷して、手書きする工程が残っていれば、現場の作業時間は1分も減りません。「システムを入れたのに楽にならない」という結果は、多くの場合ここから生まれます。
実例：「受注をスプレッドシートに」の先に、月76時間の手作業があった
名古屋の革製品製造販売会社の実例です。最初の依頼はこうでした。
「ECサイトの受注を、毎朝8時にスプレッドシートへ自動反映してほしい。できればリアルタイムで」
この言葉どおりに作れば、受注APIを叩いてスプレッドシートに書き込む仕組みで完成です。数日でできますし、依頼の文面には100%応えています。
しかし「そのデータを受け取った人は、次に何をしますか」を繰り返して業務フローを最後まで聞いた結果、実態はまったく別の姿をしていました。
- 受注メールを4つのECサイト分プリントアウトする
- 受注品番で商品マスタ（1万4千件超）を検索する。品番の頭で検索すると候補が複数出るため、目視で特定する。色も目視で確認する
- 特定した品番と商品名を、社内共有のスプレッドシートへコピペする
- 革の使用量管理のため、商品コード・商品名・色・サイズ・革の使用量を別のエクセルへコピペする
- 製造指示書用のエクセルへ、同じ内容をもう一度コピペする
- 古い社内データベースを開いて指示書を印刷する。ただしこのデータベースは壊れかけていて品番しか出力されないため、商品名などは手書きで補っていた
同じデータを4回コピペし、最後は手書き。これを役員2名が担っていて、1人は毎日午前中まるごと、もう1人は毎週月曜の半日を使っていました。合計すると月に約76時間、年間900時間超が、この転記と検索に消えていたことになります。
最初の依頼である「受注のスプレッドシート反映」は、この6工程の1番目の手前しかカバーしていません。言葉どおりに作っていたら、2番以降の手作業は全部残り、効果は実際の1割程度だったはずです。
逆に、フロー全体を対象にすれば、品番の検索・商品名や色の転記・革使用量の引き当て・指示書の出力まで、手作業のほぼすべてが自動化の対象になります。同じ「受注の自動化」という依頼から出発して、設計の範囲がまるで変わるわけです。
質問の重ね方：実務での手順
このずれを見つけるためにやることは、難しいヒアリング技術ではありません。順番に4つです。
1. 「そのデータを受け取った人は、次に何をしますか」を手が止まるまで繰り返す
先の実例では、この質問を4回繰り返してようやく「データベースが壊れていて手書きしている」に到達しました。1回や2回では出てきません。依頼者にとって当たり前になっている作業ほど、聞かれるまで言葉にならないからです。
「次に何をしますか」→「スプレッドシートに貼ります」→「貼ったものは誰が見ますか」→「スタッフが在庫を確認します」→「在庫がなかったら？」→「工場に製造を頼みます」→「どうやって？」――と、データの行き先を最後の一手まで追いかけます。答えが「特に何も」になったところが業務の終点で、そこまでの全工程が設計の対象です。
2. 現物を先に出してもらう
口頭の説明より、実際に使っている帳票・エクセル・印刷物のほうが、桁違いに情報量があります。先の実例では、依頼側から受け取った現物のエクセルに、受注番号から工程管理、発送先、革の使用量まで23列が揃っていて、この1枚を見た時点で設計の大半が終わりました（この点は後述します）。
口頭で「在庫を確認して」と聞くのと、在庫表の現物を見て「在庫数の列がない（＝実は商品マスタだった）」と気づくのとでは、設計の精度がまったく違います。説明してもらうより、見せてもらうが原則です。
3. 作業時間は推測ではなく実測してもらう
「毎日どれくらいかかっていますか」への答えは、たいてい体感の推測です。可能なら1週間だけ、実際の作業時間を記録してもらいます。
これには2つの効果があります。ひとつは、自動化の投資判断が「なんとなく大変」から「月76時間」という事実に変わること。もうひとつは、導入後に同じ計測をすれば効果がそのまま数字で証明できることです。発注側にとっては投資対効果の検証材料になり、受託側にとっては次の提案の根拠になります。
4. 頻度と件数を数字で確認する（リアルタイムは大抵過剰)
「できればリアルタイムで」という要望はよく出ますが、件数を聞くと不要なことが多いです。先の実例では、4つのECサイトを合計しても受注は月70件、1日あたり2〜3件でした。この規模なら1日1回の自動処理で十分で、リアルタイム連携の仕組みは開発コストも保守の複雑さも純増になるだけです。
「リアルタイムがいい」は多くの場合「今は気づくのが遅れて困っている」の言い換えです。何分以内に知る必要があるのか、その根拠になる業務は何か、を数字で確認すると、適正な頻度に落ち着きます。
既存の帳票が最良の設計仕様書になる
ヒアリングで工程が見えたら、次は設計です。ここで新しい管理画面や新しいフォーマットをゼロから設計したくなりますが、現場で何年も使われてきた帳票がすでにあるなら、それをそのまま設計図として使うほうが確実です。
先の実例で受け取った進行表のエクセルは、受注番号・出荷予定日・商品コード・色・サイズ・価格・発注数・製造工場・工程のチェック欄・革の使用量・備考まで、23列で構成されていました。何年も実運用で磨かれてきた帳票は、外部の人間がゼロから設計するどんな画面よりも現場の実態に合っています。抜けている項目があればとっくに列が足されているし、使わない項目は自然に消えているからです。
だから設計方針はこうなります。帳票の形は変えず、いま手入力している列を自動入力に置き換える。 品番から商品名・色・サイズ・価格・革使用量をマスタから自動で引き、通し番号も自動で振り、そこから指示書を直接出力する。現場が毎日見る画面は今までと同じ帳票のままです。
これは導入の成功率に直結します。システム導入が現場に定着しない原因の多くは、機能不足ではなく「見るもの・触るものが変わる」ことへの負担です。帳票が変わらなければ、現場のオペレーション変更コストはほぼゼロになります。
壊れたシステムは、直す前に「そのデータは他にないか」を探す
もうひとつ、この実例から使える判断基準を挙げます。フローの途中に壊れかけた古いシステム（今回は品番しか印刷できなくなったデータベース）があるとき、反射的に「これを直す」を要件に入れたくなります。
その前に、中のデータが他の場所に存在しないかを先に探してください。今回のケースでは、壊れたデータベースから救出が必要と思われた情報のうち、商品情報はPOSレジの商品マスタにすべて揃っていて、唯一心配だった革の使用量も、マスタCSVの中に列として存在していました。つまり修復は一切不要で、壊れたシステムはそのまま引退させられました。
古いシステムの修復は、中身の調査だけで大きな工数がかかるうえ、直しても「古いまま延命する」だけです。マスタ・POS・会計ソフト・過去のCSVエクスポートなど、同じデータの供給源は案外あちこちにあります。修復は最後の手段です。
起こりうる失敗を先回りで潰す
最後に、この種の案件で起こりやすい失敗を、予防の観点でまとめます。
- 入口だけ自動化して「楽にならない」と言われる――依頼の言葉を要件にせず、データの行き先を終点まで確認してから範囲を決める。見積もりの前にフローを聞き切るのが順序です
- 新しい管理画面を作って使われない――既存帳票が実務で機能しているなら、形を変えず手入力列の置き換えに徹する
- リアルタイム連携を作り込んで保守が重くなる――件数と業務上の必要タイミングを数字で確認してから頻度を決める
- 壊れた旧システムの修復に工数が溶ける――修復の前に、同じデータの別の供給源を探す
- 効果が説明できない――着手前に作業時間を実測しておく。導入後の同じ計測が、そのまま効果の証明になる
まとめ：聞き切ってから作ると、同じ依頼が10倍の価値になる
業務の自動化で外さないための要点をまとめます。
- 依頼の言葉は入口を指している。「そのデータを受け取った人は、次に何をしますか」を手が止まるまで繰り返し、業務の終点までを設計の対象にする
- 口頭説明より現物。実際の帳票・エクセル・印刷物を先に出してもらう
- 作業時間は1週間の実測に置き換える。投資判断と効果証明の両方に効く
- 頻度は件数から決める。リアルタイムは大抵過剰
- 既存の帳票は最良の設計仕様書。形を変えず、手入力列を自動化に置き換える
- 壊れたシステムは直す前に、データの別の供給源を探す
発注する側であれば、制作会社やエンジニアがこの聞き方をしてくるかどうかが、良い依頼先を見分ける基準になります。逆に、依頼の言葉をそのまま見積もりにしてくる相手には、この記事の工程分解を自分側から提示してみてください。同じ予算でも、届く範囲がまるで変わるはずです。
graciautoでは、名古屋を中心に店舗ビジネス・中小企業の業務自動化とWEB活用の支援を行っています。「どこから自動化すべきか分からない」という段階のご相談も歓迎です。