先日、私宛に一通の郵便物が届きました。「ねんきん特別便」です。「年金の加入記録がきちんとされてるか確認してねー、確認したらお返事ちょうだいねー」というアレです。

何度も転職したとか言うならばともかく、卒業して就職してずっと同じ会社に勤務している私です。何らかの手続きミスがないならば全く面白くない通知でしかありません。実際、書面には「二十歳になってから就職するまで国民年金、就職してからずっと厚生年金に加入」とあります。学生時代は親の財布から納付され、そして就職してからは給与天引きなので払っているという感覚は全くありませんが、とにもかくにも未納期間や手続きミスのようなものはありませんでした。確認してミスが無い旨を記入し、返送しておしまい。全く問題が無さそうなデータに対してもこうやってわざわざ書面で確認を求めなければいけないとはご苦労な話です。

何故こんな面倒な事をしなければいけないのか。そもそも年金の記録を管理する際に、氏名と性別、生年月日などで個人を特定していたそうです。と言われると「名前と性別と生年月日がたまたま同じ人がいたらデータがごっちゃにならね？」と考えるのですが、実際にごっちゃになってしまったために自分の記録が無いとかこの記録は誰の物だなんて事になっているようです。ある特定の日に産まれた全く同じ名前の人が存在する確率というのは0ではありませんし、結婚して苗字が変わった結果、同じ生年月日の人と同じ名前になる可能性もこれまた0ではありません。

システムを構築する場合においては、そのような「混ざったり孤立したりするデータ」が存在しないように注意しなければなりません。例えば携帯電話のシステムであれば、契約者の名前だとか生年月日なんかではなく電話番号で管理できます。名前や生年月日だと重複する可能性がありますし、改名や改姓の結果孤立する可能性もあります。しかし、電話番号だと重複する可能性はありません。うっかり同じ電話番号が複数人に割り当てられたとしたら、それは見事な欠陥システムです。記者会見してごめんなさいどころでは済みません。電話番号が孤立する場合は、これは「将来的に割り当てられる予定がある番号」であれば全く問題ありません。ですが、「以前誰かに割り当てられていて今でも使われているんだけど、しかし誰が使っているのか分からない」というのは問題です。「請求書送らなきゃいけないんだけど、誰に送ればいいの」という事態になります。

「一人の契約者につき一つの電話番号」という前提であれば、システム全体において電話番号単位で管理すればよくなります。ですが、実際には契約者一人で複数の電話番号というのも珍しくありません。仕事用、プライベート用、浮気用などと用途に合わせて違う電話が必要な場合もあるでしょう。家族割引等のサービスを利用するために、一人で家族分の電話を契約する事もあるかもしれません。そもそも法人であれば一台二台どころか二桁三桁なんて単位で契約する事もありえます。その他、様々な理由のために実際には電話番号単位ではなく、契約者単位で割り振られる「契約者番号」みたいなものを使用します。こうする事により特定の契約者単位で管理する事が可能となります。複数台の利用料金の請求を一つにまとめる事ができますし、個人情報保護の観点からもそちらの方が望ましいとされます。「あの人の電話番号はコレ」なんてのは、そう簡単に結びつかない方がいいのです。

この場合の契約者番号のようなものを、「キー」と呼びます。個人なり団体なりを特定するための鍵です。「特定の人の電話番号」だとか「特定の人の料金延滞状況」なんかを簡単に抽出するためには適切にキーを設定していなければいけません。契約者番号があれば簡単に分かりますが、名前と性別と生年月日なんかで管理していた場合は他の人の情報が混ざる恐れがあります。適切なキーを設定する事は利用者のためであり、そして管理する側のためでもあります。まあ実際の年金のシステムは、キーが適切じゃなかったとか、字が汚くて名前が読めないとか、手書きで登録する時に生年月日書き間違えたとか、もうなんか色々とぐだぐだなようです。あれ、適切な状況にしろって言われても無茶ですよ。何が正しいデータでどれが間違ってるのかが分からないんですから。

数年前より、私はとある会社のシステム運用と開発に携わっています。勿論、このシステムではちゃんとキーを設定してあります。代表的なものは個人を特定するための「個人番号」と、部署を管理する「部署番号」でしょうか。ある部署に所属する人たちの色々なあれこれを管理するシステムです。企業秘密とかセキュリティとかそういうあれこれがあるんであやふやな表現ですがご勘弁を。

個人番号は入社の段階で割り振られます。基本的にこれは変更される事はありません。名前が変わろうが苗字が変わろうが、性別が変わろうが住所が変わろうが、個人を特定するための個人番号は変わりません。個人を特定したその先にあるデータを更新することで対応する事ができます。これは良いキーの設定例です。個人が確実に特定でき、そしてその個人の情報が変わっても依然として特定できます。

問題は部署番号です。部署が一つや二つならばなんて事ないのでしょうが、このシステムは何百もの部署の情報が管理されています。で、業務の都合とか経済の流れとか経費削減の一環とかで部署なんてものは増えたり減ったりします。いや、別にそれは問題ないんですよ。新しい部署には新しい番号を割り振りますし、無くなった部署は関連データも削除します。問題はちょっと名前が変更になる部署。名前が変わって心機一転するのはいいんですが、わざわざ部署番号まで変更する必要は無いだろう、と。キーである部署番号というものはそう簡単に変わったりするようなものではいけないのです。変わったりするようなものでは無いはずなので、システムを開発する側もそういう前提でプログラムを書いているのです。なのに実際は、それこそ毎週どこかで部署番号の変更が行われます。「名前が変わるだけならば、番号は変える必要ないではないか」と疑問を呈した事もありましたが大人の事情との事です。大人の事情だかなんだか知らんが、そんなよく分からない理由でころころ変えられても困ります。

つまり何を言いたいのかというと、キーをいい加減に扱うと関係者がムキーとなる、というお話。年金は受給者がムキーとなり、部署番号は私がムキーとなるのです。