自動テストが全部通っていたのに、数字は間違っていた。だから「別の方法」で検算する

業務を自動化するツールを作るとき、

「ちゃんとテストしています」

という言葉は、かなり安心感があります。

私自身も、

作ったツールにはテストを入れます。

想定した入力を入れて、

正しい結果が返るか。

エラーになるべきところで止まるか。

複数の条件を通して、

問題がないか確認する。

ここまでは普通にやります。

でも以前、

自動テストがすべて通っていたのに、計算結果が間違っていた

ことがありました。

今回は、そのときの話です。

勤怠CSVから給与計算用の数字を作るツール

作っていたのは、

勤怠CSVを読み込み、

残業時間。

深夜時間。

休日労働。

拘束時間。

などを計算して、

Excelへ出力する仕組みでした。

計算ルールをコードにして、

複数のパターンをテストしました。

通常勤務。

残業あり。

深夜勤務。

休日勤務。

想定していたテストはすべて通りました。

画面上でも、

数字はそれらしく見えます。

普通なら、

「これで完成」

としてもおかしくありません。

でも、納品前にもう一度疑ってみた

給与や勤怠の数字なので、

なんとなく、

「本当に全部合っているのか」

が気になりました。

そこで、

元のプログラムをもう一度読むのではなく、

Pythonで同じ計算を別に作りました。

最初に作ったコードをコピーしたわけではありません。

仕様書と入力データだけを見て、

ゼロからもう一つ計算を作ります。

そして、

最初のツールが出した結果と、

Python側で計算した結果を、

一つずつ突き合わせました。

そこで、異常な数字が見つかった

すると、

一部の条件で、

拘束時間が明らかにおかしい数字になっている箇所が見つかりました。

自動テストは通っています。

エラーも出ていません。

ファイルも正常に生成されています。

でも、

結果は間違っていました。

これが少し怖いところです。

システムが止まれば、

「何かおかしい」

と分かります。

でも、

正常に動いて、

正常なExcelが出て、

その中の数字だけが間違っている。

これは気付きにくい。

特に給与や勤怠では、

一見もっともらしい数字が出ていること自体が危険です。

なぜテストを通ったのに間違っていたのか

理由は単純です。

テストも、

元のプログラムを作った人が考えています。

つまり、

実装したときと同じ思い込みを、テストにも持ち込む可能性がある

ということです。

たとえば、

私はAという条件で正しいと思っている。

だから、

Aを前提にコードを書く。

そして、

Aを前提にテストも書く。

すると、

コードもテストも、

同じ勘違いをしている場合があります。

その状態では、

テストはきれいに通ります。

同じものを何度見るより、別の方法で答えを出す

そこで現在は、

重要な数字を扱う場合、

できるだけ、

別の方法で同じ答えを出す

ことを意識しています。

Excelで計算したならPython。

VBAで処理したなら別のスクリプト。

OCRで読み取ったなら、

曜日や日付、

人数、

カードの仕様など、

AIとは別のルールで確認する。

重要なのは、

元の処理と同じ仕組みをコピーしないことです。

同じコードをコピーして、

もう一度実行しても、

同じ間違いを2回するだけだからです。

 検算する側も、本当に正しいとは限らない

ここでも、

もう一つ問題があります。

では、

Pythonで作った検算プログラムが正しいことは、

誰が保証するのでしょうか。

これも、

「Pythonだから正しい」

ではありません。

Pythonも、

人が書いています。

そこで、

検算する仕組み自体にも、

わざと間違ったデータを入れたり、

計算結果を故意に変えたりして、

本当に差を検出できるか

を確認します。

つまり、

元のシステムを疑う。

検算するシステムも疑う。

少し面倒です。

でも、

給与や勤怠のように、

数字がそのまま人のお金に関係するものでは、

このくらい疑ってもいいと思っています。

 最近作っている勤怠OCRでも、同じ考え方を使っています

現在、

紙のタイムカードや勤怠表を読み取り、

CSVへ変換する仕組みも作っています。

こちらでも、

単純に、

「AIがこう読みました」

だけでは終わらせません。

たとえば、

カードに印字された曜日と、

日付から計算した曜日が合っているか。

休憩の打刻が、

タイムカードの仕様上あり得る数か。

事業所の想定人数と、

実際に読み取れた人数が合っているか。

前月と比べて、

人が丸ごと消えていないか。

こうした、

AIの外側にある事実

を使って確認します。

AI自身に、

「あなたの読み取りは正しいですか？」

と聞くだけではありません。

間違いを減らすのは、AIの精度だけではない

AIの精度を上げる。

モデルを変える。

プロンプトを工夫する。

もちろん重要です。

でも実務では、

それだけでは足りません。

間違ったときに、

気付けるか。

止められるか。

人へ戻せるか。

こちらも同じくらい重要です。

私は最近、

「正しく動くシステム」より、「間違ったときに分かるシステム」

を意識するようになりました。

これはシステム開発だけの話ではありません

たとえば、

昔から使われている給与計算Excel。

前任者が作った勤怠集計。

外注で作ってもらったVBA。

計算結果は毎月出ています。

だから、

正しいと思って使っている。

でも、

長く使われていることと、

正しいことは別です。

むしろ、

エラーが出ないからこそ、

何年もそのまま使われることがあります。

そこで「独立検算」というサービスを作りました

今回、

この考え方だけを切り出して、

ココナラで新しくサービスにしました。

▼給与・勤怠Excelの計算が合っているか独立検算します

このサービスでは、

元の数式やVBAを読んで、

「問題なさそうです」

と確認するのではありません。

仕様と入力データをもとに、

別の方法で計算を作り直し、

元の結果と突き合わせます。

給与や勤怠については、

1円。

1分。

単位まで比較します。

差があれば、

どこで違ったかを確認します。

 ExcelやVBAそのものを直したい場合

もちろん、

検算だけではなく、

「このExcel自体を改善したい」

という場合もあります。

AkariLabでは、

Excel・VBAを使った業務自動化や、

既存ファイルの改善も行っています。

実際のポートフォリオには、

月160本以上のExcelを自動生成・配布する仕組みや、

全国規模の店舗運用で使っている業務改善事例なども掲載しています。

▼AkariLab プロフィール・ポートフォリオ

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

作ったものだけではなく、

どんな問題があり、

何を残し、

何を自動化し、

どこに安全弁を入れたのか。

そうした設計判断も、

できるだけ残すようにしています。

「合っていると思う」を、一度だけ確認してみる

すべてのExcelを、

毎月検算する必要はありません。

でも、

給与。

勤怠。

請求。

原価。

手当。

こうした、

間違ったときの影響が大きい数字なら、

一度だけでも、

別の方法で確認しておく価値はあると思います。

特に、

「昔から使っているから大丈夫」

「前任者が作ったものだから分からない」

「テストは通っている」

「数字は出ている」

という状態。

これは、

正しい証拠ではありません。

私自身、

テストが全部通ったツールから、

実際に間違いを見つけました。

だから今は、

動いたら完成、ではなく、疑って確かめるところまでを仕事にする。

そんなふうに考えています。