デマンドジェネレーション&パイプライン志向で、「測れて、報われる」BtoBマーケティングのために

皇紀を採用した安田生命保険の先見の明

»

実は私、安田生命保険相互会社(今の明治生命保険)に勤めていたことがあります。枝野官房長官が皇紀何年かご存じなかったというニュースがあって思い出して検索していたら、懐かしいことがWikipediaに書かれていました。

皇紀と安田生命保険

安田生命保険(今の明治安田生命保険)は、1970年代個人情報管理のシステムを構築することになった。その際システムの担当者は、20数年後に生じるであろう2000年問題をすでに予測していたのか、あるいはシステム上で都合がいいからなのか、「年」の処理に西暦や元号ではなく皇紀を使用した[6]。そのことにより、安田生命保険は2000年問題を(皇紀の下2桁が00になるのは2040年なので)40年先送りしたとされる。

これだけでは分かりませんね。1940年をゼロとする皇紀を採用してどうして2000年問題を40年先送りできるのか?生保の扱う生まれ年なんて1940年(昭和15年)以前の人も多数いらっしゃるわけで、それだけでは足りません。そして、1900年を起点にするだけでは、生保の必要とする生まれ年で1800年代生まれの生年月日を上手く扱えません。システム構築した1970年代において80代や90代という「現役」のお客様の情報ですから。

実は安田生命は1940年を起点にプラスとマイナス99年を保持していたのです。メインフレームでいうところのパック10進数だと、1バイトで正負2桁の数字を保持できる方式で1841年から2039年まで、199年間の年の情報を持てます。1841年は伊藤博文が生まれた年で、1970年代というシステム化した年からすると十分古い年から、70年近く先まで持つ2039年まで1バイトで扱えるわけです。

膨大なデータを扱える今と違い、メインフレームの希少なDASD(ディスク)やテープのデータを小さくするのにこの年の持ち方は大いに役立ったことでしょう。計算も速くなりますし。

2000年問題が話題になった時に、安田生命の設計の巧妙さと、後にシステムに携わったクレジットカードの西暦下二桁しか券面に印字しない方式の不都合さを感じたものでした。

そして、単に2000年問題を先送りするだけでなく、100歳以上とかの人の寿命に関わるデータを上手く扱い、40年先送り以上に巧妙な設計に感心しています。

Comment(4)

コメント

nido

パック10進数で符号付き2桁の数字は2バイト必要です(符号無しなら1バイト)。
そもそも、入出力で常に西暦や和暦への変換が必要なのだから皇紀である必要は全然無く、
独自フォーマットにした方がまだまし。
パック10進数なら2バイトで4桁持てるのだから素直に西暦使えよと思う。

坂本英樹

nidoさん、
「パック10進数だと」というのは私の推測なんですが、これは間違ってそうですね。 実際のデータの持ち方は 1バイト符号付整数で -128~127 とか、ともかく1バイトに収まる入れ方をしていると考えられます。何しろ70年代でデータ領域は貴重だし、生保で持つ日付データって膨大なので1バイトだけでも削減できたら相当な節約になりました。

また、独自フォーマットでも一緒かもですけど、計算の楽さを考えると規格化されたものとして皇紀がちょうどよかったと思います。

nido

データ領域が貴重だったのに固定長レコード・固定長フィールド・BCD等を使っていたのには
それなりの理由があるわけで、ここで1バイト節約するために特殊フォーマットを使うのは
筋悪設計だと思いますね。
例えば、集計表をRPGで出力するだけの処理でも、年を変換する前処理が必要になります。
あと「安田生命保険の先見の明」ですが、保険会社なら満期日の計算があるので2000年は
未来の話ではなかったはずです。

坂本英樹

nidoさん
ご自身がどれほど内部の情報を御存知かわかりませんが、当事者でない限り「筋悪」というのは的外れの失礼な意見だと思います。
設計された1970年時点と今とでリソースの希少さに差があるし、ともあれ、皇紀で設計した年代のシステムは、年号換算しているから「平成対応」もそれほど大変でなく対応でき生き永らえていると思います。

当時のDASDやらメモリ記憶領域の稀少性を知らずに今の知見のみで論評するのは失礼だと思います。そういう考えからこのスレッドのコメントは閉じます。
あまりに視野が狭いと思ったためです。あしからずご了承ください。

コメントを投稿する