次の元号は「元気モリモリご飯パワー」だって? それだけはやめてください。文字数が多いとエンジニアが苦労するんです。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
「あるエンジニア、かく語りき2」は、エンジニア参加型メディア「エンジニアライフ」から、@IT自分戦略研究所編集部が独自の視点で選んだ“良”コラムを転載するものです。
市井のエンジニアが人生の節目節目で考えたことをつづる本連載。シーズン1(2013年10月〜2014年5月)は、“一介の職業エンジニア”松坂高嗣さんがエンジニアのキャリアを解説した。シーズン2は、複数のエンジニアたちが、エンジニア生活のリアルをお届けする。
日本のシステム業界における三大改修案件というと「消費税導入対応」「平成追加対応」「2000年問題対応」ではないでしょうか。三大案件全てに携わったプログラマーって、どれくらいいるんだろうなあ(私は消費税導入対応には関わってないので、数に入りませんよ!)。
「平成」が追加された時、私はまだ下っ端でした。平成30年現在51歳なので、平成追加対応にぎりぎり引っ掛かった最後の世代です。
昭和メイドのシステムで元号の切り替えが必要なデータは「生年月日」くらいしかありませんでした。そのため、ほとんどのプログラムで元号は「昭和」でベタ打ちされていたように記憶しています。
プログラム的な難易度でいえば、平成追加対応はそれほど難しいものではありません。
1番の問題は、仕様(=新しい元号とその切り替え日)が決まらないことでした。それが決まるのは明日かもしれないし、10年後かもしれません。
しかし、仕様が決まらないことに対する文句を聞くことはありませんでした。仕様が決まるためのトリガーが何であるのか、みんな分かっていたからです。
私が関わっていたシステムの発注元は、「もし元号が変わっても、しばらくは昭和のままでいいよ。切り替わってから考えよう」というスタンスだったので、「一応、修正箇所をリストアップしておくか」程度の対応ですみました。
しかし、知人が関わっていたシステムは「元号が変わったその日から新しい元号が帳票に出力されていないと困る」というオーダーがあり、かなり大変だったようです。だってそれ、実質的に即日納品じゃん。
それでどうしたかというと、
こうやって、平成初日のシステム稼働に間に合わせたそうです。
絵を想像するとちょっと笑えますが、失敗できない仕様変更をそんな短納期でリリースさせられた当人たちは、さぞ冷や冷やしたことでしょう。
昭和しか知らないプログラマーしかいなかったあのころと違い、今はさすがに元号をベタ打ちしているシステムはないと思います。元号が切り替わっても、「定義ファイルかDBに1行追加すれば対応完了」というところではないでしょうか(そうだといいよね)。
でも、新元号が3文字以上になったら、ダウンするシステムはあるかもしれないな(本当にありそうでヤだな)。
1989年4月1日
日本で初めて消費税(3%)が導入され、コンピュータシステムの改修が必要となった。
なお、消費税は2019年10月に10%へ引き上げられる予定。初めての「税率2桁対応」の他、同時に導入される「軽減税率」への「複数税率対応」「商品副税率対応」「請求書対応」などが予想される。
どんなシステムでも、金額入力は、「税込み金額」か「税抜き金額」かです。大半の会社は売り上げや仕入れを税抜き金額で計上します。そのため、最も影響が大きくなるのは「税込み←→税抜き」の変換部分です(お茶でも飲みながら会計入門「消費税の増税が、ITシステムに与える影響範囲を考える」)。
1989年1月7〜8日
昭和天皇崩御に伴い元号が「昭和」から「平成」に変わったため、コンピュータシステムの改修が必要となった。初めての改元対応であること(大正から昭和への移行時にはコンピュータシステムがなかったため)、変更のタイミングと変更後の元号名が事前に分からなかったこと、元号表記に使う「合字」対応など特殊な作業が必要なことなどから、当時のITエンジニアたちは、特殊な対応を強いられた。
なお、現天皇生前退位に伴い、平成は、2019年5月1日に新元号に変わる予定。これについてITベンダー大手各社は、「元号改正による修正は限定的」(NTTデータ)、「平成から新元号への対応は比較的容易」(日立製作所)、「個別開発したアプリケーションの影響を特定する洗い出し作業に手間が掛かる。元号改正による修正作業そのものよりもテストの工数が増えそうだ」(富士通)とコメントしている(日経 xTECH 「2019年5月1日に新元号、NTTデータや日立は「対応難しくない」」「新元号は2019年5月1日からの見通し、富士通は「洗い出しとテストの負荷が大きい」」)。
1999年12月31日〜2000年1月1日
古いコンピュータシステムの多くは、「年」表記の西暦の上2桁を省略し下2桁のみだったため、2000年を認識できなかった。これによるシステムのトラブルが予想され、修正対応のために、多くのCOBOLプログラマーが招集された。
日付情報が間違って処理されることから、ファイルが間違って消去される、システムが誤動作したり停止したりするなどの問題が起こる可能性があった(Insider's Computer Dictionary 「西暦2000年問題(Year 2000 problem)」)
Copyright © ITmedia, Inc. All Rights Reserved.