政府や自治体の業務は各法律で定義されており、 それら手続きのほとんどは電子(システム)化されている。 しかしながら、システム上の問題が表面化しつつあるのが現実である。 本質的には、データをどう収集して管理するのかということに他ならない。

名寄せ問題

昨今、社会保険庁の年金データの整合が取れていないことが問題になっている。 主な原因は、 基礎年金番号に統一した際に 各自治体で管理していたデータを名寄せが完全でなかったことあるようだ。 そもそも名寄せをするには、個人を特定する必要がある。 一般的には、氏名以外の読み仮名、生年月日、住所、 電話番号などのデータから個人の同一性を特定できることが多い。 確認作業は最終的に手作業での照合(突合)になるので、 照合すべき件数が多いと現実的ではないし、 今回のような古くなったデータの場合には照合が難しい。 それでも、官僚的と揶揄されるように、手続きには必ず提出された書類があり、 その書類は一定期間残されているはずだが、 統一後しばらくして廃棄されているものもあり、混乱を極めている。

結局、突合のためには、全数チェックするのは現実的ではないことから 確認作業を申告してもらった個人に対してチェックするという方針のようだ。 番号を統一した時点でシステムを開発したベンダや職員は気付いており、 その段階で公表すればいくらか被害が少なかった可能性もある。 いずれにしてもシステム上の不備が噴出した結果である。

今後外字も問題に

また、戸籍や住民情報といった漢字表記の氏名には、 通常電子化されたデータでは使われない文字、いわゆる外字が含まれている。 公的データ内で使われている外字の中にも、いくつか種類がある。 提出された書類の誤記によるもの、慣習上使われているもの、異体字、 既にある文字を検索できなかったために新たに作られてしまったものなどがある。 これまでは、自治体ごとに独自にシステムが汎用機で開発、運用されていたが、 昨今のレガシー・マイグレーションの流れに従い、オープン系へ移行している。 オープン系と言えども、過去のデータを移行する際には、 これまでの外字をそのまま使うことになり、 システムごと、あるいは自治体ごとに、 外字エリアに独自に文字とフォント(文字の形状)を定義することで対応している。

一方で、市町村合併や電子自治体・電子政府への対応を考えると、 外字問題は大きな問題になりつつある。 MS-Windowsを含め、多くのオープン系システムの内部では、 UNICODE(ISO/IEC 10646) という文字コードが標準的に使われている。 これは世界中の言語の文字を一緒に扱うための仕組みである。 外字に関しては、外字を扱えるエリア(Private Use Area: PUA)を個々に作ることで、 対応しているケースも多い。 しかしながら、これでは、同じコード番号でありながら、 文字が異なるケースが多数発生することになる。

確かに、普段使っている文字を表示したいというこだわりもあるだろう。 しかしながら、日常的には外字となっている文字を 一般的な文字に変換して使っているはずである。 このことを考慮すると、いわゆる異体字を扱う方法として、 対応するフォントがない場合には、 表示されない、あるいは、おかしな文字が表示されるのではなく、 一般的な文字が表示されるような仕組みが国際標準として検討されている。 一部のソフトウェアでは既に対応している。

なお、住民基本台帳のシステムは、完全に閉じたシステムであるとされており、 全国的に統一された外字を利用しているため、それほど問題にはなっていない。 ただし、文字コードや外字の仕様があまり公開されておらず、 システム開発者、利用者にとっても不安が残る。

公的データの信頼性向上には

名寄せや文字コードの問題は古くて新しい問題である。 そもそも自分のデータが確認できないシステムに問題があるものの、 OSなどの実装の違いにより、複数のOSを使うシステムの場合には影響を受けるため、 特定のシステムから情報を見るだけでは正しいデータであるかどうか、 必ずしも認識できない可能性もある。 このような複雑な利害関係や初期の入力ミスの可能性を考えると、 公的システムの中では文字形状を制限するなどの改革が必要である。

これまでに作った外字や仕様を外部に公開しないベンダや担当部署の姿勢にも問題がある。 公的なデータが扱う上では、 仕様を公開した上できちんと開発することが納税者へのサービス向上、 データの信頼性向上につながるのではないだろうか。