毎日何十枚もの伝票を扱っている会社では、ある光景が繰り返されている。「あの伝票、どこに行ったっけ」——そう呟いた誰かが、ファイルの山をめくり始める。記憶を手繰り、同僚に声をかけ、気がつけば30分が消えている。
この「探す時間」を問題だと認識している経営者は多い。だがその原因として挙げられるのは、「担当者が整理できていない」「ファイリングのルールを守らない」といった、人の問題に帰着することがほとんどだ。
だが、本当の問題は人ではない。「探さなければならない構造」が、業務の中に設計されたまま残っていることだ。
本稿では、伝票が消えるたびに誰かの時間が止まる現象を入口に、「探す仕事をなくす」ために経営者が何を決めなければならないのかを整理する。ツールの話は後でいい。先に設計の話をする。
「探す仕事」は、誰も設計していない仕事である
"ある"はずのものが"ない"という状態の正体
伝票が見当たらない。この状況を「紛失」と呼ぶのは正確ではない。多くの場合、伝票は存在している。ただ、どこにあるかを誰も把握していないという状態にある。
置き場所は担当者の記憶の中にあり、その記憶は引き継がれていない。ルールはあっても運用は属人化し、「自分なりのやり方」が現場に分散している。結果として、探す作業が発生する。これは整理整頓の問題ではなく、情報の置き場所が設計されていない問題だ。
「探す時間」はコストとして見えていない
30分の探し作業が毎日1件あれば、月に10時間以上が消える。複数の担当者に同じことが起きていれば、その数倍だ。だがこの時間は、どの経費科目にも現れない。残業代に紛れ込み、「業務の一部」として当然視される。
見えないコストは、削ろうという意思決定が生まれない。 カーネマンが指摘したように、人は目の前に数字として現れない損失を、実際の損失として認識しにくい。「毎日なんとなく忙しい」という感覚は、このような見えないロスの積み重ねである。
「仕方ない」が構造を固定する
「伝票の管理はそういうものだ」「慣れれば探せる」——こうした言葉が現場に定着すると、問題が問題として認識されなくなる。これは正常性バイアスの一形態だ。現状が長く続くほど、その状態が「正常」に見えてくる。
経営者がすべきことは、「仕方ない」を「設計の失敗」として再定義することだ。 探す仕事は、業務ではない。設計の穴から生まれた余分な仕事である。
ツールを入れても、構造が変わらなければ探し続ける
「デジタル化＝解決」という誤解
「スキャンしてクラウドに上げればいい」「システムに入力すればいい」——こうした発想でデジタル化を進めた結果、紙の山がデジタルの山に変わっただけ、という事態は珍しくない。ファイル名がバラバラで、保存場所のルールがなく、「あのPDFどこだっけ」という会話が社内チャットで繰り返される。
デジタル化はツールの導入であって、業務設計ではない。 探す構造をそのままデジタルに移行しても、探す仕事はなくならない。形が変わるだけだ。
「便利なツール」が現場の混乱を深める場合
AIを使った書類検索、自動仕分け、タグ付け——こうした機能を持つツールは確かに存在する。だが、ツールが機能するのは、入力されるデータに一定の秩序がある場合だけだ。
名称の揺れ、日付フォーマットの不統一、登録漏れ——これらが残ったままツールを導入しても、AIは正しく検索できない。むしろ「ツールを使っているのに見つからない」という新たなフラストレーションが生まれる。ツールは構造の代わりにはならない。
AIエージェントは「決まった動き」しかできない
近年、業務自動化にAIエージェントを活用する事例が増えている。伝票の仕分けや転記を自動化する用途も実用段階に入りつつある。だが、AIエージェントが安定して動くためには、「何をどこに、どの形で入力するか」というルールが事前に決まっている必要がある。
エージェントは判断しない。決まったルールに従って動く。そのルールを設計するのは、人間であり、経営者の判断である。「AIに任せれば自動化できる」のではなく、「設計が済んでいるからAIが動ける」という順序を、経営者は理解しておく必要がある。
「探さなくて済む構造」は、3つの決定から始まる
第一の決定：「何が、いつ、どこに存在するか」を定義する
探す仕事がなくなるとは、「聞かなくても分かる状態」を作ることだ。そのためにまず必要なのは、伝票の種類・発生タイミング・保管場所を一覧化し、それを組織の共通認識にすることだ。
これは情報システムの話ではない。「何が業務の中で発生し、それがどこへ流れ、どこに落ち着くか」を言語化する作業だ。多くの中小企業では、この地図が存在しない。経営者が最初に決めるべきは、ツールではなくこの地図である。
第二の決定：「誰が、何を、どの時点で登録するか」を決める
保管場所を決めても、そこに情報が入ってこなければ意味がない。登録のタイミングと担当者を明確にしないと、「後でまとめて入力」という運用が始まり、やがて登録が遅れ、抜け漏れが常態化する。
「受け取った当日中に入力する」「担当者が自分で登録する」——このレベルの具体性で決めなければ、ルールは守られない。抽象的な方針は、現場では機能しない。
第三の決定：「誰でも取り出せる状態」を検証する
構造が機能しているかどうかは、「担当者がいなくても取り出せるか」で確かめられる。属人化が残っている間は、構造はまだ完成していない。
この検証は、システム導入の後ではなく、設計段階でやるべきことだ。「誰でも取り出せる状態」をゴールに設定してから、それを実現するツールを選ぶ。この順序が逆になると、ツールが担当者の記憶を補完するだけで終わる。
「設計する」とは、何を決めることか
業務を言語化することが出発点である
設計と聞くと、フローチャートや要件定義書を思い浮かべる経営者もいるだろう。だが本質はもっとシンプルだ。「うちの会社では、伝票はこう流れる」を、文字にして共有できる状態にすること——それが業務の言語化であり、設計の出発点だ。
この言語化ができていない状態でシステムを導入すると、現場の「なんとなくのやり方」がそのままシステムに移植される。結果として、システムが現場に合わせて使われるのではなく、現場がシステムの隙間を埋めるために動く、という逆転が起きる。
設計は「禁止」ではなく「流れ」を作る
「ファイルを勝手な場所に保存するな」「入力は必ずその日のうちに」——禁止とルールだけで運用しようとすると、守れない人が出た瞬間に崩れる。設計の目的は、正しい行動をしやすくすることだ。守りやすい構造を作ることが、禁止より先にある。
たとえば、伝票を受け取った瞬間に登録画面が開く導線を作れば、後回しは減る。保存場所が一か所しかなければ、迷う余地がない。設計とは、選択肢を絞ることで、正しい動作を「デフォルト」にする技術だ。
経営者の判断が、設計の品質を決める
現場担当者が設計を考えると、どうしても「今の自分の仕事に合った設計」になりがちだ。視点が業務の内側に向く。経営者が関与すべきなのは、「会社全体として、何が誰に見えている必要があるか」という視点を持ち込む場面だ。
「社長がいつでも確認できる状態にする」「引き継ぎ時にゼロから説明しなくて済む状態にする」——こうした経営要件を設計に組み込めるのは、経営者だけだ。ツールの選定はその後でいい。
結論 — 経営者が取るべき次の一歩
「探す仕事」は、担当者の問題ではなく、探さなければならない構造が放置されている問題だ。ツールを入れても、その構造が変わらなければ、形を変えた探し仕事が残るだけである。「何が、どこに、誰によって登録され、誰でも取り出せるか」——この流れを言語化し、決定することが、構造を変える唯一の手段だ。
経営者は、ツールを選ぶ前に、業務の流れを言語化する判断をすべきである。
第一歩は、「今、うちの伝票はどこを通って、どこに落ち着いているか」を紙1枚に書き出すことだ。それが書けない状態こそが、「探す仕事」が生まれ続ける根本原因である。
