一括検証のワークフローは、一件ずつの検証を単純に繰り返す作業ではありません。入力の揺れを吸収し、制度ごとに振り分け、結果を分類し、あとから追える形で報告する、という段階を持つ工程です。この記事では、その段階を順に整理し、どこでつまずきやすいかを見ていきます。
なぜ一括検証は一件ずつの検証と違うのか？
一件ずつの検証では、利用者と対話しながら進められます。おかしな入力があれば、その場で聞き返せます。一括の場合は、聞き返す相手がいません。
この違いから、次の性質が生まれます。
- 入力の揺れがすべて同時に現れます。表記の違いが混在し、同じ制度の番号が複数の書式で並びます。
- 誤りの原因が一つとは限りません。書式の問題と、値そのものの問題が混ざります。
- 全体の傾向が見えます。失敗が特定の制度や特定の列に集中していることが分かります。
- やり直しの費用が大きくなります。手順を後から変えると、それまでの結果を捨てることになります。
したがって、一括検証では工程を分けて設計することが重要になります。どの段階で何が分かったのかを保つことで、後から原因を追えるようになります。
最初に洗浄を行うのはなぜか
最初の段階は、値の中身を判断せずに、形をそろえる作業です。ここを飛ばすと、後続のすべての段階が影響を受けます。
洗浄で行うことは、おおむね次のとおりです。
- 前後の空白と、見えない文字を取り除く。
- 区切り記号を取り除く。空白、ハイフン、点、斜線が対象になります。
- 全角の数字と英字を半角にそろえる。
- 英字の大文字と小文字をそろえる。
- 空の行と、値が一つも入っていない行を識別する。
重要なのは、洗浄の前の値と後の値を両方保持することです。後の値だけを残すと、報告のときに「元は何だったのか」を示せなくなります。利用者は、自分が入れた値と表示された値が違うと、どこで何が起きたのか分からなくなります。
また、値を上書きせずに別の列として持つ設計にしておくと、洗浄の規則そのものを後から見直せます。規則を変えて再実行したときに、元の値が残っていれば、結果の変化を比較できます。
制度ごとに振り分ける段階
洗浄が済んだら、どの制度の番号として扱うかを決めます。ここは一括処理で最も設計の余地がある部分です。
振り分けの考え方は、大きく二つあります。一つは、入力の列や出所によって制度が決まっている場合です。たとえば、ある列が特定の制度の番号であると分かっていれば、そのまま適用します。もう一つは、値の形から候補を絞る場合です。桁数と文字種を手がかりに、該当する可能性のある制度を並べます。
二つ目の場合、候補が一つに絞れないことがあります。そのときは、無理に絞らず候補をすべて記録します。一括処理では、一件ごとに人間が選ぶわけにいかないため、自動で決められないものを別の一覧として切り出す設計が有効です。
この切り出しを設けておくと、自動処理の結果と、人間の確認が必要な結果が混ざりません。混ざったまま先へ進むと、後になって「これは自動で決まったのか、人が決めたのか」が分からなくなります。制度ごとの規則の持ち方はチェックディジットのアルゴリズムで扱っています。
結果をどのような区分に分類するのか
一括検証の結果は、成功と失敗の二つに分けるのではなく、判断の種類ごとに分けます。少なくとも次の四つが必要です。
- 有効。公開された算法に合格したもの。
- 無効。形式は合うが、算法に合格しなかったもの。
- 形式のみ。算法が公開されておらず、形式だけを確認できたもの。
- 規則なし。対応する制度が見つからなかったもの。
この四つは、利用者が取るべき行動が違います。有効はそのまま進められます。無効は入力の見直しが必要です。形式のみは、その先の確認を別の手段に委ねます。規則なしは、番号そのものではなく制度の一覧を見直す必要があります。
二つに分けてしまうと、形式のみと規則なしが「失敗」にまとめられます。すると、本当に直すべき行が、直せない行に埋もれます。大量の行を扱うとき、この埋もれ方は致命的です。
報告に必ず含めるべき情報
一括処理の報告は、集計だけでは足りません。行ごとの情報が必要です。
- 行番号。ファイル内の位置が分からないと、利用者は該当行を探せません。
- 元の値。洗浄前の文字列をそのまま示します。
- 判定した制度。どの規則を適用したかを示します。
- 結論。上記四つのどれに当たるかを示します。
- 理由。形式のどこが合わなかったのか、算法のどこで成立しなかったのかを示します。
集計の数字だけを出す報告は、一見すると整っていますが、行動につながりません。「無効が三百件」と知っても、利用者はどこから直せばよいか分かりません。行番号と元の値があれば、そのまま修正作業に入れます。
また、結論ごとの件数を制度ごとに分けて出すと、傾向が見えます。特定の制度だけ失敗が多いなら、規則の側に問題がある可能性があります。特定の入力元だけ失敗が多いなら、洗浄の側に問題がある可能性があります。
再実行できる形にしておくには？
一括処理は、一度きりで終わらないことがほとんどです。入力が追加され、規則が更新され、洗浄の仕方を見直すことになります。そのたびに最初から設計し直すのは無駄です。
再実行しやすくするための要点は次のとおりです。
- 洗浄、振り分け、判定、報告を別の段階として実装し、途中の結果を保存できるようにします。
- 判定に使った規則の版を記録します。同じ入力でも、規則が変われば結論が変わります。
- 同じ入力に対して同じ結論が出ることを確かめる手段を用意します。
- 途中で失敗しても、処理済みの範囲が分かるようにします。
三番目は、地味ですが最も効きます。同じ入力で結論が揺れる実装は、原因の追跡を不可能にします。
本文で述べたのは一括処理の進め方に関する一般的な整理であり、例として想定した値はすべて説明のための作り物です。実在の番号や利用者に対応するものではなく、個々の番号の真偽を示すものではありません。
次の一手
手元の一括処理が、四つの結論を区別して返しているかを確認してください。区別していない箇所があれば、そこが最初に手を入れるべき点です。番号検証ツールで個別の値を試し、番号検証の仕組みで段階の分け方を押さえてから、API の境界で検証するへ進むと、一括処理と境界での検証を同じ考え方で設計できます。