オルタナティブ・ブログ > 代替案のある生活 >

ITの技術や方向性考え方について別の選択肢を追求します

三菱東京UFJ さんの件に寄せて 個人的な懸念

»

「ああ、半角カタカナかぁ。」と、三菱東京UFJ銀行さんの件でニュースを見ていて、そう気がついた。どうも、このブログ、後出しじゃんけんみたいで、MUFJ関係者の皆様も含めて、みなさんに失礼な気がするが、気になることがあるので、書いておきたい。

銀行の口座情報は、ご承知のように半角カタカナのコードページになっている。たとえば、鈴木一郎さんの口座情報は、

1000 3 987 1234567 1 スズキイチロウ

といった感じである。口座名義は「スズキイチロウ」でも「鈴木一郎」でもない。コンピュータは無論「 1 」と「 0 」しか判断しないので、「スズキイチロウ」は、別のデータになのだ。

まだ、ダブルバイトが一般化されていないメインフレームの時代、1980年代初頭に、電子化された口座データを作成し、各金融機関と利用者の間でコンピュータを使ったオンライン接続を実現するために、こういった口座情報や付帯情報が作られた。現在でも、日本の銀行の口座システムはメインフレームで稼働している。

これは全銀協標準プロトコル、全銀手順と呼ばれている。ベーシック手順と呼ばれている標準が作られたのはメインフレームの時代なので、コードページは、EBCDICだ。通信制御はBSC手順、アナログの公衆回線では 2400 bps (なんと!)、ISDNなら64 kbps だ。専用のルーターなどもある。この標準が出たのが、1983 年だが、いまだに現役である。また、1997 年には、「新しい」標準として全銀TCP/IP 手順が出ている。これは、PPP(Point to Point Protocol)である。懐かしいでしょう。

いずれにせよ、銀行口座が半角カタカナのコードページである以上、銀行間の接続では、半角カタカナのコードページと考えるのが普通なのだと思う。銀行の人が、こんな事を忘れるはずはない。今回のように、漢字(ダブルバイト)での情報送信は、口座情報以上のさまざまな付帯情報を追加する、将来を見据えた接続を、MUFJの方々は目指されていたのだろう。

銀行のエンジニアの方々も、それをサポートしているベンダーの方々も、私の知る限り、世界のトップレベルだと思う。したがって、テストしてませんでした、とか、想定外でした、という発言は私にとっては、どうも疑問が湧くところだが、こういうのを「げすの勘ぐり」と言うので、ここでは追求しない。

私が懸念していることは、日本の経済基盤である全銀手順や口座情報が 30 年前の技術の上で稼働し続けていることだ。世の中、クラウド・コンピューティングとか騒いでいる中で、新しい半導体や、OS、インフラがどんどん成長していく中で、成長の止まった技術をいつまで使うのか、疑問だ。

しかし同時に、これら古い技術を最新に置き換えることも、経済的に難しいほどに大きな出費となる。何兆円規模の置き換えになるだろう。さらには、現在のインターネットの可用性では、年間 5 分程度止まるが、今のメインフレームでは、技術が成熟(枯れている?言い過ぎ?)ので、何年止まることがない。

一秒たりとも銀行口座は止まってはいけない、というのが、日本国民の合意のようなものであるから、弊社サンの技術を持ってしても、現状では、これに答えることはできない。第一、皆さんの口座データは全て EBCDIC なので、そのすべてをASCIIに変換するのは大事だ。

日本にしかない、この複雑な構造と問題を解決していくことは、容易ではなく、今後のシステム統合や新しいサービス構築で、銀行口座との連携が必要な時は、ずっとこの問題が追いかけてくるのだ。最上流の工程から、常にこの点に留意することが、現在出来うる最良の手段だろう。

Comment(4)

コメント

高橋さん、こんにちは。連休のしわ寄せで外資の5月はめちゃくちゃ忙しいですよね。

さて、
> 全銀手順や口座情報が 30 年前の技術の上で稼働し続けている
という懸念は杞憂だと思っています。というのも、データ連携の仕様部分「枯れて触らない」という状態で用が足りるのならそのままでよくて、別のスーパーセット規格とかをつくって拡張していけばいいし、裏で動く技術は連携の仕様とは独立して進歩できると思うからです。

名寄せのためには漢字情報は必須で、信用情報の相互提供とかでは20年前から漢字でやり取りがされていますし、今後の拡張としてたとえば、外国人対応のためにアルファベットも追加するとか、漢字をUTF-8対応していうのも必要となってくるでしょう。(マネーロンダリング対策では深刻なボトルネックとか聞きます。)

また、口座情報のアグリゲーションサービスとか便利なのですがそこでは、OFX 2.0とかの金融データの電子取引を定めた統一国際規格が使われているとか聞きます。
枯れたところはそのまま、進んでいるところも増えているのでそんなに悲観することもないかと思う次第です。

坂本さん、コメントありがとうございます。
 
銀行情報の漢字化は、名寄せもそうですし、今後は金融サービスの多角化の基本条件でしょうね。電子取引の統一国際規格もありますが、こちらについても、非常に速い速度で進んでいます。要注意です。
私が言いたかったのは、現在、100Mbpsなんか当たり前、今後は、Gbps の世界に進んでいくネットワークのバンド幅の動向があります。パソコン通信の世界はすでになく、この全銀手順のために存在しており、高価なままです。早く安くて便利な新しい環境・基盤を使用すべきだよな、と思っています。
メインフレームも、いまとなっては高価すぎます。銀行がメインフレームを捨てられないので、流通業の一部も、いまだにメインフレームを使っている傾向にあります。年間、何億円もの経費がかかるメインフレームはもうやめるべきだと思っています。
私自身がメインフレームの拡販に大いに関連していたので、なおさら、なのです。

とおるさん、こんにちは。
ちなみに、私はメインフレームでのクレジットカードシステムの開発をやったあと、Windowsの世界へ移ったという経歴です。1990年カットオーバーのメインフレームシステムでもフル漢字対応だったし、そのシステムへのオープン系リプレースで大変な泥沼にとか漏れ聞くと一概に悪いところばかりでは無いとは思っています。

でも、日本は残りの世界と比べると確かにメインフレーム依存度が高く、某社の新製品は北米を差し置いて日本でやったとか聞くに、コントロールを奪われているな とか感じています。

結局のところ一番の問題はユーザー企業がITを比較優位の戦略的コア領域だと認識して自社で主体的に取り組むという意識が比較的に薄く、ベンダー任せになっているところに問題があると思います。

メインフレームの良さのかなりを今や、RISCおよびx86系で実現できるわけで、先例を踏襲するとかいうのではなく新しい良いものを主体的にどんどん取り入れていけば、いいものを安く使えるようになるのにと思います。

そういうわけで想いは多分似ていると思うのですが、そういう啓蒙をやるのに切り口をちょっと変えたほうが伝わりやすいと思った次第です。

> メインフレームでのクレジットカードシステムの開発
おお。ご苦労されたでしょうけど、そういった体験って重要ですよね。1990 年ごろだと、メインフレームの最後の大きな転換(半導体がバイポーラから CMOS に変更された)時期ですね。

オープン系と呼ばれる UNIX / Linux ですが、私個人的には、Solaris でなくとも、とにかく進化を続ける OS であれば良いと思っています。現状を考えると、Web / インターネットを活用して、スケーラビリティがムーアの法則を軽く越えるような、いわゆる「クラウド・コンピューティング」に進んで行きたいなあと思っています。
処理能力に比較して高価についてしまうメインフレームは、元メインフレームの推進者であった私ですが、IT関係者として、リプレースしていきたいな、と思っています。

コメントを投稿する