平成元年回顧録
最近、「元号が追加された場合のシステムへの影響調査をして欲しいと依頼された」的な話をちらほらと聴きます。
日本のシステム業界における三大改修案件というと「消費税導入対応」、「平成追加対応」、「2000年問題対応」ではないかと思うんですが（異論は認める）、この三大案件にすべてひっかかったプログラマって、どれくらいいるんだろうなあ、とふと思いました（あっ、わたしは消費税導入対応にはかかわってないので数に入りませんよ！）。
そんなきっかけでいろいろと思い返したことがあったので、ちょっとした昔話でも書いてみるか、という気になりました。あっ、2000年問題については書いたことがあるので、おヒマでしたら読んでいただけるとわたしがうれしいです（←ダイレクトマーケティング）。
「平成」が追加された時、わたしはまだ下っ端でした。現在、平成28年でわたしが50歳なので、わたしたちが平成追加対応にぎりぎりひっかかった世代になるかと思います。
昭和だった頃のシステム業界で扱われているデータで、元号の切り替えが必要なものなんて生年月日くらいしかなく、ほとんどのプログラムで元号は「昭和」でベタ打ちされていたんじゃないかと思います。
平成追加対応は、プログラム的な難易度は低いです。一番の問題は仕様（＝新しい元号とその切り替え日）が決まらないことでした。それが決まるのは、明日かもしれないし、10年後かもしれないという状況です。
しかしながら、仕様が決まらないことに対する文句をきくことはありませんでした。仕様が決まるためのトリガが何であるのかはみんなわかっていたからです。さすがに、そんな誰にもどうにもできないことで愚痴るわけにもいきません。「もう西暦で統一しろよ」とこぼしていた人はそこそこいましたけど。
元号が切り替わる可能性が高い、という雰囲気になってきた頃、わたしがかかわっていたシステムの発注元は、「もし元号が変わっても、しばらくは昭和のままでいいよ。切り替わってから考えよう」というスタンスだったので、「一応、修正箇所をリストアップしておくか」程度の対応ですみましたが、知人がかかわっていたシステムは「元号が変わったその日から新しい元号が帳票に出力されていないと困る」というオーダが出ていて、かなり大変だったようです。いや、だってそれって実質的に即日納品じゃん。
それでどうしたかというと、事前にダミーの元号と切り替え日でプログラムを修正してテストを行い、メンバに修正対象のソースを割り振り、新元号が発表になる時間にメンバが開発室に集結して、リーダークラスはテレビがある部屋で待機、そして、小渕さんが「平成」の額をかかげると同時に開発室にダッシュして「平成！ 平らに成る！」と叫んで、みんながそれをきいて一斉に担当分のファイルを修正、徹夜でテストとリリース作業を行い、平成の最初の日のシステム稼働に間に合わせた、ということをやったそうです。
絵を想像するとちょっと笑えますが、失敗できない仕様変更をそんな短納期でリリースさせられた当人たちは、さぞひやひやしたことでしょう。
昭和しか知らないプログラマしかいなかったあの頃と違って、今はさすがに元号をベタ打ちとかしているシステムはないと思います。元号が切り替わっても、定義ファイルかDBに1行追加すれば対応完了ってとこじゃないですかね（←そうだといいよね）。
でも、新元号が漢字3文字になったらダウンするシステムはあるかも（←本当にありそうでヤだな）。
コメント
仲澤＠失業者
元号はあまり関わりがありませんでしたが、20年前当時にやっていた、
カレンダー機能を搭載したシステムでは祝日の扱いが結構大変でした。
国ごとに違いますし、日本ではハッピーマンデー法の導入で演算がさらに複雑になりました。
今年は山の日が追加になったりしたし。
増えすぎた休日を減らすのではないか、という憶測もあるそうですね。
今はまぁあんまり関係ないですが。
elcaminoreal255
257文字とかだったらかなりヤバイでしょうね。
ひでみ
こんばんわです。ひでみです。
仲澤＠失業者さん
そういえば、ハッピーマンデー対応というのもありましたね。
私にはふりかかってこなかったので忘れてました。
子供の頃に、国民の祝日をせっかく暗記したのに、ハッピーマンデーのおかげでわけわからなくなりました。
いまだに「体育の日」はいつかときかれると「10月10日」と答えてしまいます。
elcaminoreal255さん
元号が257文字になったら、システム以前に人間がダウンしてしまいます（笑）。
あずみ
いつも楽しく拝見しています。
コメントは初めてです。
読んでおられる方の何割が該当するかわかりませんが、
私はひでみさんの「三大改修案件」すべてに関わり、
かつ、現在もＣＥ兼ＳＥ・ＰＧです(笑)
（汎用機のエンジニアから始めて、現在はＰＣのエンジニアです）
業務アプリ専門なので、顧客ありきでシステム開発していましたが、
個人的には２０００年問題がいちばん大変でした。
システムに関しては、検証も十分でしたし、万一の備えもできていたのに
周りの空気が半端なくピリピリしてまして・・・
やはり、メンバーや顧客の気持ちに余裕がないプロジェクトは、
やっかいだと、感じたのを覚えています。
それでは、次の投稿も楽しみにしています。
おーまさ
消費税対応と言えば複数税率対応・・・・
まだ、対応できてないシステムもあるんでしょうねぇ。
ひでみ
こんばんわです。ひでみです。
あずみさん。
はじめまして。いつも読んでくださってるそうでありがとうございます。
「三大改修案件」すべてにかかわった方って、やっぱりいらっしゃるんですねえ。
これまで出会ったプログラマさんでは、私と同じ2つが最高だったので、3つともひっかかった方ってどれだけいるのかなあ、と思ってました。
2000年問題の時は、どこに何が隠されてるのかわからないって感じで、確かにピリピリしてましたね。
やってもやってもまだ何かあるんじゃないか、と疑心暗鬼な感じで。
平成追加対応は隠れているものがなかっただけマシでしたけど、あの時は日本全体がピリピリしてる感じがしてて、それがなんとなくキツかった記憶があります。
おーまささん。
複数税率対応というのもありましたね、そういえば。
やはりシステム業界に大きな影響が出るのは、ほとんど法令関係なんですね（2000年問題はちょっと違うけど）。
今はマイナンバーが燃え上がってるとききますが、あれには関わりたくないです。怖いから。
匿名
＞ 昭和しか知らないプログラマしかいなかったあの頃と違って、今はさすがに元号をベタ打ちとかしているシステムはないと思います。
それが恐ろしいことにあるんだな。
一応、マスタから元号をとってコレクションに入れるのだが、
平成一レコードだけ、さらに、マスタから取れなかった用？かなぜか、
クラスのコンストラクタで、平成の内容をコレクションべた打ち追加している。
なので、そのコレクションを追加機能で元号コンボで使おうとしたとき、
コレクションをそのまま使うと平成が2レコードになるというお粗末な既バグが
元号クラスに存在し、仕方がないので、コンボ設定メソッド側で、
マスタ0件ならデフォルトレコード削除の無駄なロジックを追加せざるを得なかった。
平成以降に開発したシステムで、設計者がアホだと、
昭和と同じことは起こりうるのです。
ていうか実際に起きてしまっている。