業務改善という言葉は、多くの場合「今の作業を楽にすること」と同じ意味で使われています。
現場にヒアリングして困りごとを聞き、時間のかかっている作業を洗い出し、転記を自動化するスクリプトや、チェックを肩代わりするバッチや、チャットから起動できる便利コマンドを作ります。
どれも喜ばれますし、成果もすぐに見えます。
この種の取り組みを、この記事ではツール作りと呼びます。
ただ、ツール作りで作業を楽にすることは、業務改善の半分でしかないと考えています。
今ある作業が速くなることと、これまでできなかったことができるようになることは、別の話です。
そして後者への道は、ツールをいくら積んでも開かず、業務データが発生源から構造化されて集まっている状態を作ったときに開きます。
この記事では、手作業の多くがデータの整っていないことの帳尻合わせとして発生していること、だから根本の改善はデータが発生する入り口の設計であることを、構造の話として書きます。
ツール作りは、積み重ねても行き止まりになる
ある作業に 10 の労力がかかっているとしましょう。
ツールを作れば 7 に、うまくいけば 5 にできるかもしれません。
ただしツールには開発、運用、改修、引き継ぎのコストがかかり続けるので、浮いた分の一部は維持の労力として払い戻されます。
そして 10 が 7 になっても、その作業を誰かがやるという構造は変わりません。
そもそも、ツールで楽にする対象の手作業を並べてみると、その多くは三つの型に収まります。
- 転記：情報がメールや口頭や自由記述で届くため、誰かが構造化された置き場所へ写している。
- 突き合わせ：同じ情報の発生源が複数あるため、誰かが見比べて食い違いを探している。
- 集計のやり直し：データが人の手元に散らばっているため、報告のたびに誰かがかき集めている。
三つに共通するのは、作業の原因が担当者の手際ではなく、データのあり方にあることです。
情報が最初から構造化された形で発生していれば転記は存在せず、発生源が一つに定まっていれば突き合わせは存在せず、発生した瞬間から一箇所に集まっていればかき集める作業は存在しません。
つまりこれらの手作業は、データが整っていないことの帳尻を人間が毎日合わせている姿であり、ツールにできるのは帳尻合わせを速くすることまでです。
見た目のきれいな文書は、データではない
三つの型には、もう一段根の深い変種があります。
情報がそもそも、データではなく文書として作られている場合です。
社内の申請書や報告書には、スライド作成ソフトや、セルを方眼紙のように使った表計算ソフトで、レイアウトの整った様式が使われていることが多くあります。
人が読むときの見た目に最適化されていて、様式としての完成度は高いのですが、この完成度は機械に対しては逆に働きます。
どこに何が書かれているかを機械が特定できず、記入された内容を後から集計する手段がありません。
見た目に最適化された文書は、提出されて読まれた時点で役目を終える、一回きりの読み物になります。
これは一部の組織の癖ではなく、「ネ申 Excel」という呼び名で情報教育の分野から指摘されてきた問題で、行政でも、機械が判読できる統計表の表記ルールをわざわざ定める必要があった程度には広く見られます。
判定の目安は単純で、「この様式に記入された内容を、あとで機械が集計できるか」と問うことです。
印刷して紙にしても失われるものが何もないなら、それは電子化された紙であって、データではありません。
紙の代わりに過ぎない様式は、記入の手間が大きいうえに、何百枚集まっても分析には使えません。
データが整うと、できなかったことができるようになる
ここからが、この記事で一番言いたいことです。
データが整うと、転記も突き合わせもかき集めも発生条件を失って消えます。
ツール作りが 10 の労力を 7 にする改善だとすれば、こちらは 10 を 0 にする改善です。
そして、話は 0 で終わりません。
データが発生源から構造化されて溜まり始めると、これまで不可能だった使い方が視野に入ります。
推移を眺めて戦略を立てる。
予兆をデータから拾う。
通知や案内を、相手の状況に合わせて正確に出し分ける。
部門をまたいだ数字の突き合わせを、月次の集計作業を待たずにいつでも行う。
どれも、揺れのない構造化されたデータが揃っていることを前提にした能力であり、誰かの作業が楽になる話ではなく、業務にできることが増える話です。
裏を返せば、この前提を欠いた業務では、打ち手を思いついても補助ツール止まりになります。
たとえば契約のような期限のある情報が、担当者の手入力による明細の自由記述だけで管理されていて、商品や料金のマスタと結びついていないとします。
この状態でも、期限が近そうなものを拾って案内を送るツールくらいは作れます。
しかし表記が揺れていて、明細の文字列からはどの商品のどのプランなのかを機械が確定できないので、最後は人が明細を読んで判断する工程が残ります。
案内の先にある更新データの生成のような、人手を挟まない自動化には進めません。
機械が確定できないデータの上では、どんな仕組みも人間の確認を前提にした補助止まりになります。
できないのは技術が足りないからではなく、データが機械に扱える形で存在していないからです。
ツールをいくら並べても、この場所には到達しません。
入力を楽にするツールを作っても、入ってくるものが自由記述である限り、機械が扱えない状況は変わらないからです。
業務改善の到達点を「作業が減った状態」に置くか、「データが揃っていて、次の打ち手を選べる状態」に置くか。
楽にすることと良くすることの分かれ目は、ここにあると考えています。
データ整備とは、入り口を設計し直すことである
では、データを整えるとは何をすることでしょうか。
すでにあるデータを掃除することだと思われがちですが、中心になるのはデータが発生する入り口の設計です。
先に、「乱れたデータでも、ツールで補正すればよいのではないか」という反論に触れておきます。
発生源が複数あるデータの食い違いを機械で検出しようとしても、差分があることが正しい場合（意図的な例外や個別の事情）を機械は判定できませんし、定期実行のチェックでは誤りが生まれる瞬間には間に合いません。
自由記述の解釈を機械に手伝わせても、揺れた入力が届き続ける限り、解釈の誤りはゼロになりません。
乱れたデータの上に載せた対策は、どこまで行っても近似です。
品質管理には「検査に依存して品質を達成しようとするな」という古典的な教えがあります。
誤りを後工程で拾うのではなく、誤りが生まれない工程を設計せよという意味で、データの話も同じ構造をしています。
だから、直すのは入り口です。
人がやり取りの中から確定事項を拾って入力するのではなく、依頼者や顧客自身が型の決まったフォームから申請する形に置き換えます。
様式が要るなら、見た目から作るのではなく、集計できる項目の定義から作り、見た目はその後に整えます。
判断の根拠になる情報はマスタとしてデータベースで管理し、各所に散らばった写しを参照させません。
構造化しきれない例外は、無理にシステムに載せず、自由記述で受けて人が確認するフローに逃がします。
データ品質の分野には、発生時点で誤りを防ぐコストを 1 とすると、後から見つけて直すコストは 10、放置したまま業務が誤って動くコストは 100 になる、という経験則が広く引かれています。
この数字は実測された固定比率ではなく、後工程に行くほど修正のコストが膨らむ傾向を示すものですが、入り口で防ぐことが遠回りに見えて安くつく、という方向を裏付けています。
過去のデータには割り切りが要ります。
表記の揺れた既存データを正規化して載せ替えるのはコストに見合わないことが多いので、既存分は参照できるだけにとどめ、自動化は新規分に限ります。
データ整備が「終わりの見えない掃除」に見えるのは既存データを全部直そうとするからで、入り口さえ変えれば、整ったデータは日々勝手に増えていきます。
手を付ける場所は、反復の頻度が高く、扱う情報が構造化しやすい業務（月に何十件も発生する定型の手続きなど）が狙い目です。
それでもツール作りばかりが選ばれる理由
ここまでの話に、理屈の上で反対する人は少ないと思います。
それでも現実の業務改善がツール作りに向かい続けるのには、力学があります。
第一に、データ整備は成果が見えるまでが遅いことです。
設計と移行のあいだ、現場の目に見える変化はほとんどなく、一方でツールは作ったその週から「楽になった」という声が返ってきます。
短いサイクルで見える成果を求められる環境では、後者が選ばれ続けるのは自然です。
第二に、歓声の大きさが指標になってしまうことです。
自動で何かが始まる仕組みは、導入すると驚きとともに歓声が上がりやすいものです。
しかし驚きは体験の新しさへの反応であって、業務が良くなったことの証明ではありません。
第三に、「できるようになるはずのこと」は困りごととして語られないことです。
現場の困りごとは「この作業がつらい」という形で語られ、「データが揃っていないから打ち手が作れない」という形では語られません。
まだ誰も体験していない能力の不在は、誰にとってもつらくないからです。
見た目の整った様式が「きちんと作られたもの」として受け取られ、集計できないことが欠点として認識されないのも、同じ理由によります。
三つの力学は、どれも誰かの怠慢ではありません。
だからこそ、放っておけば業務改善は必ずツール作りの側へ流れます。
「良くする」を、独立した目標に置く
ツール作りが無意味だと言いたいわけではありません。
今つらい作業を放置すれば現場の信頼を失いますし、短期の成果は長期の取り組みを続けるための燃料でもあります。
応急処置の類は、私自身も作る側として何度も作ってきました。
ただ、ツールを作るときには「この作業は、データが整っていたらそもそも消えるのではないか」と、様式を作るときには「記入された内容を、あとで機械が集計できるか」と、一度は問いたいところです。
「データが全部揃っていたら、何をしたいか」は、現場に聞いても答えは出てきません。
能力の不在は困りごととして語られないからです。
この問いはヒアリングの項目ではなく、改善する側が自分に向けて考え続けるものであり、考えるたびに、改善の対象は今ある作業から、まだ存在しない能力へと広がります。
そして組織としては、個別の効率化とは別に、「データが揃っていて、次の打ち手を選べる状態」自体を独立した目標として持つことが必要です。
そうしないと、前節の力学に押されて永遠に後回しになります。
地味で、遅くて、成果が見えにくい。
それでも 10 を 0 にするデータ整備の仕事は、10 を 7 にするツールを何十個積んでも代わりになりません。
この記事が、同じ問題意識を持つ誰かの後押しになれば嬉しいです。
参考
- 奥村晴彦「“ネ申 Excel”問題」（情報処理学会 情報教育シンポジウム、2013）：見た目の整形を優先した Excel 文書が、データの再利用を妨げることを論じた発表資料。
- 総務省「統計表における機械判読可能なデータ表記ルールの運用開始について」（2020）：e-Stat に登録する統計表の機械判読性を高める表記ルールの運用開始の告知。ルール本体はその後改訂されており、最新版は e-Stat で公開されています。
- W. Edwards Deming『Out of the Crisis』（MIT Press、1986）：経営のための 14 原則の第 3 条として「検査に依存して品質を達成することをやめよ」を挙げた書籍。
- George Labovitz、Yu Sang Chang、Victor Rosansky『Making Quality Work』（1992）：予防、修正、失敗の相対コストを示した「1-10-100 の法則」を紹介した書籍。データ品質管理の文脈で広く引用される経験則です。
