実際に使ってもらったら、想定していなかった穴が見つかった。勤怠OCRを作り直した話

これまでの記事では、

「人がやらなくていい仕事を減らす」

「仕事の受け渡しを整える」

「例外を見つけてから自動化する」

「最初から完成品を作らず、小さく現場で育てる」

という話を書いてきました。

今回は、その続きです。

少しだけきれいではない話をします。

実際に作った勤怠読み取りツールを、社労士の方に使っていただきました。

すると、作っている側では見えていなかった問題が、いくつも出てきました。

でも私は、これこそテスト運用をする意味だと思っています。

「動いた」と「業務で使える」は違う

今回作っているのは、紙のタイムカードやPDFの勤怠表を読み取り、出勤・退勤などをCSVへ整理する仕組みです。

画像を読み取る。CSVが出る。数字も入っている。

ここまで見れば、「動いている」と言えます。

でも給与や労務に関係するデータでは、それだけでは足りません。

実際のデータを使っていただいたところ、いくつか問題をご指摘いただきました。

さらに調べていくと、指摘されていなかった問題まで見つかりました。

一番危なかったのは、別の会社のデータが混ざること

最初に見つかったのは、A社の勤怠を変換したあと、続けてB社を処理すると、A社のデータまでB社の処理に入ることがある問題でした。

原因を調べると、前に選んだファイルが画面の中に残っており、次の処理に持ち越されていました。

さらに事業所名も、ファイルを選んだ瞬間ではなく、変換するときの入力内容を使っていました。

この2つが重なることで、前の会社のファイルまで次の会社の名前で処理される状態になっていました。

勤怠データなので、これは「少し使いづらい」という種類の問題ではありません。

会社をまたいで情報が混ざる。絶対に残してはいけない問題です。

そこで、ファイルを追加した時点で事業所を確定し、処理が終わったら、成功していても失敗していても選択されたファイルをすべて解除するようにしました。

失敗時にもう一度ファイルを選ぶ手間は増えます。

でも、「もう一度選ぶのが面倒」と、「別会社の勤怠が混ざる」なら、比較するまでもありません。

「日付は読めている」のに、1ヶ月間違っていた

別の問題も見つかりました。

タイムカードには、17日、18日、19日……と続いたあと、翌月の1日、2日、3日……と、一枚のカードの中で月をまたぐものがあります。

以前の処理では、1日と読み取れれば、指定された月の1日として処理していました。

つまり、7月17日から8月15日までのカードなら、8月1日を7月1日として出してしまう可能性がありました。

文字そのものは、「1日」と正しく読めています。

でも、業務データとしては間違っています。

ここがOCRの難しいところです。

文字を正しく読むことと、正しい勤怠データを作ることは同じではありません。

そこで、カード上の日付の並びを見て、31日のあとに1日へ戻るなど、月が変わったと判断できる場合だけ、翌月として扱うようにしました。

逆に、日付の並びがおかしい場合は、AIに勝手に判断させません。

「要確認」として人へ戻します。

事業所によって締め日も違う

さらに調べると、システムの中に暗黙の前提がありました。

勤怠表の期間がある特定の締め日を基準に作られていたのです。

でも実際の会社では、15日締め。20日締め。月末締め。などがあります。

そこで、事業所ごとに締め日を設定できるようにしました。

ただし、ここでも設定だけを信用するようにはしていません。

設定された締め日と、実際のカードの日付の並びが合わなければ、自動で日付を書き換えず、「設定かデータを確認してください」と人に戻します。

設定ミス一つで、1ヶ月分の日付を全部ずらす方が怖いからです。

「読み間違い」より怖いものがあった

今回調べていて、もう一つ大きな問題を見つけました。

1ページに複数人のタイムカードが写っている資料です。

過去の読み取り結果を調べると、同じ画像を読み込んだのに、あるときは1人。別のときは3人。という結果が残っていました。

つまり、時刻を1文字読み間違えるのではなく、一人分の勤怠そのものが丸ごと消える可能性がある。

これはかなり危険です。

CSVだけを眺めていると、存在しない人には気付きません。

そこで現在は、変換後に「この取り込みでは○人読み取りました」と表示します。

さらに、事業所に想定人数が登録されていれば、その人数と比較する。

登録がなくても、前月の読み取り人数があれば比較する。

資料上のカード枚数と読み取れた人数が食い違った場合も警告する。

何か怪しいときだけ、同じ資料をもう一度読み、1回目と2回目を比較する。

という仕組みを追加しました。

それでも完全ではありません。

新しい会社の初月など、比較する情報がない場合は最後は人が見る必要があります。

ここは現在も残っている限界です。

AIの精度を上げるだけでは解決しない

今回の修正で改めて感じたのは、AIの精度を上げればすべて解決するわけではないということです。

曜日と日付が合っているか。

休憩打刻が機械の仕様上あり得る数か。

想定人数と一致しているか。

前月と人数が大きく違わないか。

こうした、AIとは別のルールで結果を検算することが重要です。

これは今回初めて考えたことではありません。

以前、勤怠CSVから残業・深夜・休日割増などを計算するExcel/VBAツールを制作した際にも、自動テストはすべて通っていました。

それでも納品前に、Pythonで別の計算を組んで結果を突き合わせたところ、拘束時間が異常な数字になる不具合を見つけました。

「テストが通った」よりも、別の方法で同じ答えになるか。を見る。

この考え方は、現在の勤怠読み取りにも引き継いでいます。

AkariLabのポートフォリオでも、「テストが通っていた給与計算の不具合を納品前に発見」という事例として掲載しています。

▼AkariLabの実績・ポートフォリオ

https://coconala.com/users/102148/portfolios

もう一つの実例は、月160本以上のExcel

別の案件では、全国80〜100店舗規模の飲食チェーンで使うExcelファイルを月160本以上生成し、各店舗へ配布、店舗からの報告を集め、本部の判定結果を再び店舗へ戻す仕組みを作りました。

ここでも、単純に「自動で動くこと」だけを目的にはしませんでした。

再計算に失敗した場合は、古い数字をそのまま全店舗へ配らないよう処理を止める安全弁を入れています。

自動化すると、人が毎回見なくなる分、間違った処理も高速で大量に広がる可能性があります。

だから、自動化する処理と同じくらい、「止める仕組み」が重要だと考えています。

この事例も、現在ポートフォリオに掲載しています。

今回、まだ完成したわけではありません

ここは正直に書いておきたいところです。

今回いろいろな修正をしましたが、勤怠表そのものの読み取り精度改善はまだ途中です。

実際に誤読したカードを集めながら、日付の問題なのか。行がずれているのか。文字認識そのものなのか。一つずつ切り分けていく必要があります。

休憩の打刻についても、実際のカードでさらに確認する必要があります。

つまり、まだ育てている途中の仕組みです。

だから、最初から完成品を作らなかった

前回の記事で、「最初から完成品を作らない」という話を書きました。

今回の出来事は、まさにその理由です。

もし、仕様書だけを見て、数ヶ月かけ、完成したつもりで大きなシステムを作っていたら、今回の問題はもっと後になって見つかったかもしれません。

まず作る。実際の資料を通す。使ってもらう。違和感を教えてもらう。原因を調べる。直す。そして、また使う。

私はこの繰り返しの方が、現場で使える仕組みに近づけると思っています。

小さな業務改善からご相談いただけます

AkariLabでは現在、紙のタイムカード・勤怠表のCSV化だけでなく、Excel・VBA・Pythonを使った業務自動化、LINE Botを使った報告業務の整理、既存ツールの検証、「そもそも何を自動化すべきか」という段階からのご相談も受けています。

現在のココナラでは、紙のタイムカード・勤怠表のCSV化は20人月まで4,000円（税抜）で提供しています。

毎月ご依頼いただく場合は、定期購入の2ヶ月目以降15％OFFです。

▼紙のタイムカード・勤怠表をCSVへ転記します

「うちの勤怠表でも読めますか？」という場合は、まずサンプル1枚から確認できます。

一方、勤怠に限らず、「毎月このExcelを作るのが大変」「同じ数字を何度も転記している」「システムを作るほどなのか分からない」という段階なら、業務改善そのものの相談サービスも用意しています。

必要なら作る。既存ツールで済むなら、それを使う。Excelを少し直すだけなら、それで済ませる。

そして、自動化するなら、「動く仕組み」だけでなく、間違ったときに止まれる仕組みまで考える。

実際の現場で使ってもらったからこそ、最近はそこを、以前より強く意識するようになりました。