住基ネットの「統一文字仕様書」は「ソフトウェアの世界に対するテロ」？

(注) 住基ネット (住民基本台帳ネットワークシステム) 自体の是非については、この記事では何も言及していないことにご留意ください。

仕事半分、趣味半分で、文字コードに関する次の二つのメーリングリストに登録している。それぞれにおいて、回数はごくわずかだが発言したこともある。

• Legacy-Encoding-talk-ja (ML運営者： ミラクル・リナックス株式会社)
• XMLと文字メーリングリスト (ML運営者： 川俣晶さん)

Legacy-Encoding-talk-ja においては、Windows の機種依存文字を扱えるように ISO-2022-JP を独自拡張した符号化方式 (ISO-2022-JP-MS) をミラクル・リナックス (森山将之さん) が提案している。それに対し、NTTの風間一洋さんは、既存の文字集合にあらたな符号化方式を今から独自に作り出すのは有害無益であり、白紙に戻すべきだと主張している。

今でさえ，レガシーエンコーディングが山のように有ります．それらを使わざるをえないケースというのはあるでしょう．しかし，今更，それらと違う新しいレガシーエンコーディングを作っても，どちらにせよ完全に解決できない問題を，さらに複雑化するだけでしょう．

また，新しいことは，できる限り国際的にやるべきであって，局地的にやるべきではないと思います．局地的にゲリラ的にやるのは，ソフトウェアの世界に対するテロでしかないと思います．としたら，今はISO/IEC 10646に対しておこなうしかない．

風間一洋, "[LE-talk-ja 100] Re: ISO-2022-JP-MS について", 2006年4月30日

このように、NTT の風間さんは「ゲリラ的」「テロ」といった厳しい表現を使って批判している。主張の内容自体は正しいと思うものの、ｉモード (NTTドコモ) の絵文字などのほうが、あえて言うならば別の意味で「局地的」「ゲリラ的」「テロ」だったのでは？(笑) と意地悪な突っ込みを入れたくなるほどに、言葉が過ぎている印象も受ける。念のため繰り返すが、主張の内容自体は正しいと思う。風間さんの2006年3月17日のブログ記事では、もっと穏やかな表現を用いた同様の主張が展開されており、JIS X 0213 対応を意識する重要性にも言及されている。

さて、もう一方のML (XMLと文字メーリングリスト) では、ミラクル・リナックスCTOの吉岡弘隆さんが、住基ネット (住民基本台帳ネットワークシステム) の「統一文字仕様書」という文書の入手方法を誰かご存じないかと質問していた。それについての情報をまとめると、おおよそ以下のようになる。

• 財団法人地方自治情報センターに吉岡さん (ミラクル・リナックス) が問い合わせたところ、以下のような返答だったらしい。
  • 「統一文字仕様書」及び関連資料は、利用範囲を限定して、国及び地方公共団体にのみ提供している
  • 利用範囲に係る国または地方公共団体の業務を受託している場合は、委託元より入手して頂く
• 加除出版、富士通、日立、TRONプロジェクトなどは、この「統一文字仕様書」を入手した上でのビジネスを Web 上で PR している

要するに、文字コードを盾に取った参入障壁が、住基ネットを元にして (住基ネットの外でも) 築かれている。住基ネットの文字コードが情報非公開で、Unicode の漢字以外の領域に勝手な外字追加を実施しているらしいということは、加藤弘一さんの「ほら貝」の「文字コードから見た住基ネットの問題点」という記事でうかがい知ってはいた。あらためて検索してみると、testnodaさんという方のブログ記事「統一文字コード」にも同様のことが記されている。どうやら確かな話らしいが、本当にそうなのか私には確認できない。言うまでもないが、私が悪いのではない。

吉岡さんは以下のようにやりきれなさを表明している。

やはりそうですか？
できない事情があるんでしょうね。

うーん。

いろいろ大人の事情はあるかと思うのですが、
見えない参入障壁があるというのはフェアじゃない
ですよね。

吉岡弘隆, "[XML MOJI 01686] Re: 住民基本台帳ネットワークの文字コード", 2006年4月26日

なんか秘孔をついてしまったのかもしれない。

国または地方公共団体へのオープンソースソフトウェアの導入
推進という意味で、非公開の資料があるという現状は制度的に
導入を阻害している要因だという風に認識いたしました。

吉岡弘隆, "[XML MOJI 01687] Re: 住民基本台帳ネットワークの文字コード", 2006年4月28日

まったくその通りである。

吉岡さんは2006年3月17日のブログ記事やMLにおいて、動くコードをとにもかくにも実装して世に問うオープンソースの「バザールモデル」の利点を、厳密だが時間のかかる公的標準の制定プロセスと対比して主張している。それらの優劣はさておき、バザールモデルにせよ、公的標準にせよ、公開性 (情報や権利を公開し新規参入を妨げない性質) を指向している点では共通しているはずだ。住基ネットの「統一文字仕様書」が非公開であることは、バザールモデルか公的標準かという議論以前の問題である。

住基ネットの活用が拡大し、他のシステムと連携する場面が増加すれば、こうした参入障壁の弊害も拡大し、仕様の公開を要求する声も増加することになる。そして、「統一文字仕様書」への準拠を多くのソフトウェアが求められるような状況となったら、その内容次第では、「ソフトウェアの世界に対するテロ」というような事態に陥ってしまう恐れがある (・・・やはり言葉が過ぎている？)。本当にそうなのか私には確認できない。言うまでもないが、私が悪いのではない。

Comments

[投稿]

トラックバック有難うございます。testnodaと申します。

記事を書いたきっかけは、統一文字で記述された情報を扱うシステムで文字化けが発生したことがあったためです。
例えば、住民への通知の宛名の文字が化けるのは、苦情や事故につながります。

ＪＲ西日本は、福知山線列車事故の反省として公開した「安全性向上計画」（http://www.westjr.co.jp/keikaku/）の中で、「本社と現場との双方向のコミュニケーションはほとんど行われていなかった」ことを事故原因のひとつとしてあげています。
現場の技術者が、統一文字コードの理解が不十分なままに開発作業に従事しているという状況は、「本社と現場」ではないにせよ、これに類似した状況であると考えます。

セキュリティや機密を守ることも重要ですが、過失事故を防ぐためには、情報公開し透明度を高める必要があります。
バグが発覚してから仕様書をぽんと渡されたって、すぐに重要なことはわかりません。

僕も言葉が過ぎてしまったかもしれません。失礼がありましたらお許しください。

[投稿 testnoda]

すみません、上のエントリの名前欄を書き忘れてました…。
過失事故について語りながら、自分が過失を犯していたというオチでした。失礼しました。

[投稿 小川創生]

testnoda さん、それはまた災難でしたね。
つまり、開発当初の現場は「統一文字仕様書」に関する情報を与えられておらず、おおよそ Unicode と同じだと思っていたら、「バグが発覚してから仕様書をぽんと渡された」わけですね (苦笑)。さすがにそれはひどいですねぇ。
結局どのように解決したのでしょうか？知りたいような、知ってはいけないような・・・

[投稿 testnoda]

解決自体は自分ではなく、本社にちゃんと担当がいて、そちらで修正してくれました。

むしろ苦労したのは、発覚した以外の文字が化けてないかをテストしたときかもしれません。
結局全文字確認する方法が思いつかず、当時エンドユーザーから受領していた現行データについてだけ全部テストしてお茶を濁しました…。

ちなみに、仕様書は「ぽんと渡された」わけではなく、後になって「共有サーバから自分で探し出した」のでした。

おかげで、次の問題のときは、ベンダー問い合わせや動作確認が多少ましでした。
しかし、その時は、ベンダーから「特殊な文字コードなので再現テストできません」と怒られたような記憶が…。

[投稿 testnoda]

何度も蛇足申し訳ありません。

>結局全文字確認する方法が思いつかず、

すみません。間違いを書きました。
問題が発覚した部分については、担当のほうできちんと全文字確認していたようです。
なので、自分は現行データの部分だけテストすれば十分だったと思います。

ただし、文字コードを扱う必要のある処理はそこだけではなく、何箇所もありました。
また、文字化けの原因も、自分が知っている範囲でも、何種類かありました。
その種類によっては、自分が確認するしかない場合もあり、その際仕様書が見つからずに苦労したことがあったということです。

[投稿 小川創生]

testnodaさん、遅くなりましたが情報ありがとうございます。
いやしかし、生々しくてアレですね・・・

[投稿 加納正和]

住基ネットの文字コードについてはそのとおりだとおもいます。
が、それを「テロ」と呼ぶのはどうかと思います。言葉の問題でなく。とくに問題ないと私は思います。

そもそも「住基ネット」の文字コード体系を見てどうするのです?
「住基ネット」そのものは外部のネットワークから見られませんよ。

そもそも「見れない」ものを「なんか秘孔をついてしまったのかもしれない。」と言っても相手は聴いてないと思いますが。

ちなみに「公的個人認証サービス」は確認してみましたか。

あれは住基ネットに入っている基本4情報が入ってます。でも「文字コード」問題は発生しません。

>住基ネットの活用が拡大し、他のシステムと連携する場面が増加

意味不明です。利用が拡大しようが「住基ネット」が見れない状況が変わるわけじゃない。
「連携」とは意味合いが違うのは知ってますよね。

「連携」であればインターフェイスをあわせる必要は当然ありますが、その「連携」そのものもシステムであり、
それはそれで仕様書があるはずです。「統一文字仕様書」と同一視は出来ない。

>・・・やはり言葉が過ぎている？)

というか関係ないものに文句を付けてるかと。それは「住基ネット」の文字コードに文句を付ける筋合いではないと思いますが。

コメントに事例を書いた人の場合は「連携」システムを設計した、
無能設計者の問題であって、「統一文字仕様書」の非公開問題でありません。

[投稿 小川創生]

> そもそも「住基ネット」の文字コード体系を見てどうするのです?
> 「住基ネット」そのものは外部のネットワークから見られませんよ。

利用者から見た話ではなく、システムやソフトウェアの開発・運用に参入したい業者から見た話をしています。

> ちなみに「公的個人認証サービス」は確認してみましたか。
> あれは住基ネットに入っている基本4情報が入ってます。でも「文字コード」問題は発生しません。

利用者から見れば、(JIS と共通する文字集合においては) それは当たり前です。システムのどこかで文字コードの変換を施しているのですから。変換のためのソフトウェアを作るには仕様書が不可欠ですね。それを作りたい人から見た話をしています。

なお、『「文字コード」問題は発生しません』というのはどのように確認なさったのでしょうか？ご自身の事例だけではなく、JIS にも Unicode にも存在しない漢字が名前や住所に含まれる人の事例も踏まえた断言でしょうか？

> 「連携」であればインターフェイスをあわせる必要は当然ありますが、その「連携」そのものもシステムであり、
> それはそれで仕様書があるはずです。「統一文字仕様書」と同一視は出来ない。

連携における主要な技術仕様の一つが、まさに (情報交換用の) 文字コードであるはずです。さらに、JIS や Unicode ではなく、「統一文字仕様書」の文字コードのまま連携するならば、連携先にも「統一文字仕様書」自体が開示されないといけません。そうした場合も当然ながら想定しています。(21時45分頃に一部加筆しました)

[投稿 小形克宏]

小形と申します。
利用者の立場からも、公開は必要と考えます。
住基ネットは私企業ではなく行政がつくるものです。
本当に公開された標準（JIS、ISO/IEC等）ときちんと対応がとれているのか、
公開されない限りチェックすることが出来ません。
対応がとれない場合は、自分の住所氏名がまともに管理されていないことになります。

なにも住基ネットに限らず、行政においては透明性の確保が大事と思いますが、いかがでしょうか。

[投稿 小川創生]

小形さんのおっしゃるとおり、そもそもの話として、行政に関する情報は公開され、透明性が確保されるべきだと思います。「業者の立場」「利用者の立場」というように分けて個別に情報公開の必要性を論じていること自体、一種のむなしさを感じています。

元のブログ記事においては、関係するシステムやソフトウェアの業者の立場から見た議論をしていたのですが、加納さんがどうも何か取り違えていらっしゃったので、先のようなコメントとなりました。

利用者の立場から各自治体の説明を Web で閲覧してみると、たとえば大阪府吹田市では
----
住所、氏名に使用可能な文字はJIS第１水準、第２水準およびJIS補助漢字の約1万3千字です。そこに含まれていない文字は別の文字（代替文字）への置き換えが発生します。この場合、住基ネットに記録されている文字と異なることになります。
適当な代替文字がみつからない場合はかな文字にて対応していただきます。
----
と説明しています。文字コード問題は、利用者の立場から見ても存在しています (苦笑)。そりゃそうですよ。小形さんのおっしゃるとおりです。