札幌の1月は例年よりも暖かく、月末には雪もかなり溶けていましたが、今週から始まったさっぽろ雪祭りに合わせるかのように、ここ数日でまた積もりました。
私のサイバコでの業務にはバックオフィス関係の仕事が含まれており、1月は源泉徴収票等の法定調書の作成と役所への提出を行っていました。日本の行政機関のデジタル化の状況を認識しておきたいということもあり、電子提出用のCSVファイルを自分で用意したのですが、支払対象者のフリガナは半角カタカナ、控除対象配偶者・扶養親族のフリガナは全角カタカナというように、CSVファイルの仕様に一貫性が無く、非常に骨が折れました。そもそも、半角カタカナと全角カタカナの変換などは役所の側のシステムで適当に対応して欲しいところです。
データを手打ちしていて一番気を遣うのがマイナンバー(個人番号)や法人番号です。マイナンバーは12桁、法人番号は13桁の数字の並びを正確に打ち込まなければなりません。人間のすることですから、当然、一定の頻度で入力をミスします。桁数の間違いであれば目で見て分かりますが、数字の入力ミスやズレなどは何度も見比べなければなりません。マイナンバーはランダムに見える数字の並びなのですが、法人番号については0の並びがあるため、0の数を間違えそうになります。
日常生活でも、支払い手続きで銀行の口座番号やクレジットカードの番号を入力する際、長い数字をコンピュータに打ち込む必要があります。このような場面で入力ミスを即座に検知し、入力した番号の確認を求める機能があれば便利ですが、ちゃんと情報学はチェックディジット(検査数字)というテクニックを用意してくれています。
法人番号を例に挙げて説明します。会社を設立して法務局で登記すると会社法人等番号という4桁+2桁+10桁の全12桁の番号を割り当てられます。最初の4桁は法務局に割り当てられた番号、次の2桁は株式会社などの法人の種類を表す番号、最後の10桁は登記所ごとの登記をした順番を表す番号となっています。サイバコの場合4300-01-089216となっており、最初の4300が札幌法務局を、次の01が株式会社を示しています。ここにはチェックディジットが無いため、特に最後の方の桁の数字を間違えると存在する違う法人に当たってしまい、番号だけからは間違いを判別できません。データベースから会社法人等番号に対応するレコードを取り出し、社名が違うなどの不整合を検出したとき、はじめて間違いが判明します。
そこで、税務署はチェックディジットの1桁を法人番号の左に加えた13桁を法人番号として各法人に付与しており、一般的に、会社を表すIDとしては、こちらの番号が使われています。税務署でのチェックディジットの計算方法は会社法人等番号12桁の内、下から偶数番目の桁を2倍、奇数番目の桁を1倍して、その総和を取り、9で割ったときの余りを9から引くという手順です。サイバコの例で言えば、"4x2 + 3x1 + 0x2 + 0x1 + 0x2 + 1x1 + 0x2 + 8x1 + 9x2 + 2x1 + 1x2 + 6x1 = 48"を9で割った余りが3なので"9-3=6"となります。よって、法人番号は6430001089216となるわけです。
しかし、このチェックディジットの計算法は役所にありがちな、僕の考えた最強のチェックディジットとでも言うべきもので、情報学で提案されるような手法ではありません。情報学で一般的な手法であれば、どこか1桁の数字のみを間違った場合には誤りを検出することができますが、法人番号の場合、各桁に決められた数字をかけた後の総和を9で割った余りが同じであれば間違いが検出できないので、どの桁においても0と9の間の書き間違えは検出できないということになります。
マイナンバーについても簡単に説明します。今では陰が薄くなっていますが、かつて、住民票コードが話題になったのを覚えていますでしょうか?住基ネット(住民基本台帳ネットワークシステム)ができた際に全国の住民票の記載者に11桁の割り振られた番号のことです。実は右端の1桁を除く10桁がランダムに割り振られた番号で、右端の1桁がチェックディジットになっています。そして、マイナンバーは住民票コードから11桁の数字を生成し、さらに右端にチェックディジットの1桁を加えた12桁の番号となっています。チェックディジットの計算方法は法人番号と異なりますが、こちらもお手製のようで、似たような問題があります。
日本の行政におけるチェックディジットの問題点については、立命館大学の上原哲太郎教授の記事(「マイナンバーのチェックデジットについて」、「法人番号の検査用符号の設計ミスと、公共で使われるチェックデジット」)が詳しいです。
ここまでは情報学の問題ですが、そもそもチェックディジットが必要となる場面を考えれば、番号を最初に取引先などに提出するときや転記するときでしょう。そして、一度電子的に入力した数字は目で転記するのでは無く、機械的なプログラムで転記すべきです。しかし、マイナンバーの場合、本人確認のためにマイナンバーカードの写真送付が求められたり、厳格な管理が求められたりしているため、番号を手打ちする場面が発生してしまいます。また、せっかくIDとして個人と1対1対応する番号を用意したにも関わらず、住所・氏名・生年月日などの入力が省略されるわけでも無く、利用者にとってメリットが感じられません。この辺りは法人番号でも同じことです。
プログラマーに必要な能力として、よく怠惰が挙げられます。デジタル化においても、まずは、面倒な作業を如何にして楽にするかという怠け者の発想で進めることが大事だと思います。先のチェックディジットの技術も、数字を繰り返し確認する手間を省くという意味で仕事を楽にしてくれます。当然、STSの視点から、安全性などの副作用に注意を払う必要がありますが、結果的に楽にならないのであればデジタル化の大きなメリットが失われてしまいますし、場合によってはデジタル化しない方がましかもしれません。
日本の行政や金融機関等の手続きのデジタル化は、今後も遅々として進まないのではないかと思いつつも、人手不足の中、デジタル化による業務の効率化は避けられません。その際には、生半可な知識で四角い車輪の再発明をするのではなく、情報学の専門家等と連携して、セキュリティに万全を期すと共に、怠け者の発想でシステムの運営側も利用者側も楽ができるシステムを目指して欲しいものです。
Comments