リーダーは「平らに成る！」と叫んだ――平成元年回顧録：あるエンジニア、かく語りき2（5）

次の元号は「元気モリモリご飯パワー」だって？　それだけはやめてください。文字数が多いとエンジニアが苦労するんです。

[ひでみ（エンジニアライフ），＠IT]

「あるエンジニア、かく語りき2」は、エンジニア参加型メディア「エンジニアライフ」から、＠IT自分戦略研究所編集部が独自の視点で選んだ“良”コラムを転載するものです。

　市井のエンジニアが人生の節目節目で考えたことをつづる本連載。シーズン1（2013年10月〜2014年5月）は、“一介の職業エンジニア”松坂高嗣さんがエンジニアのキャリアを解説した。シーズン2は、複数のエンジニアたちが、エンジニア生活のリアルをお届けする。

仕様が決まらない案件

　日本のシステム業界における三大改修案件というと「消費税導入対応」「平成追加対応」「2000年問題対応」ではないでしょうか。三大案件全てに携わったプログラマーって、どれくらいいるんだろうなあ（私は消費税導入対応には関わってないので、数に入りませんよ！）。

　「平成」が追加された時、私はまだ下っ端でした。平成30年現在51歳なので、平成追加対応にぎりぎり引っ掛かった最後の世代です。

　昭和メイドのシステムで元号の切り替えが必要なデータは「生年月日」くらいしかありませんでした。そのため、ほとんどのプログラムで元号は「昭和」でベタ打ちされていたように記憶しています。

　プログラム的な難易度でいえば、平成追加対応はそれほど難しいものではありません。

　1番の問題は、仕様（＝新しい元号とその切り替え日）が決まらないことでした。それが決まるのは明日かもしれないし、10年後かもしれません。

　しかし、仕様が決まらないことに対する文句を聞くことはありませんでした。仕様が決まるためのトリガーが何であるのか、みんな分かっていたからです。

リーダーは叫んだ！

　私が関わっていたシステムの発注元は、「もし元号が変わっても、しばらくは昭和のままでいいよ。切り替わってから考えよう」というスタンスだったので、「一応、修正箇所をリストアップしておくか」程度の対応ですみました。

　しかし、知人が関わっていたシステムは「元号が変わったその日から新しい元号が帳票に出力されていないと困る」というオーダーがあり、かなり大変だったようです。だってそれ、実質的に即日納品じゃん。

　それでどうしたかというと、