元号公表「1カ月前想定」 システム改修準備で菅氏
コメント
注目のコメント
色々な意見が出ていますね。
元号公表に伴う改修作業が1か月というのは、
①前提が帳票や画面に、もっと言うとプログラムそのものに元号の名称を埋め込んでいるケースであれば、まず無理です。
よく言われますが、
②ユニークな情報として西暦で管理し、パラメータで和暦を持っていれば、設定変更で1か月などかからず対応が可能です。
政府のシステムに多いのですが、面倒くさいのは①でシステムを組んでいるケースです。（実際たくさんあります。）
②の改修作業は元号名に関わらず進めていけるものですし、元号が平成からXXに変わった後も、不謹慎ですが、すぐ別の元号に代わるかもしれません。そのために柔軟に対応できるよう②を今から進めておけばよいのではないでしょうか。それでも時間がありませんが。
政府の仕事をしていると、この1か月前想定が、あくまで「想定」であり、政府として方針が明確になっていない以上、上記の②対応だとか、①対応だとか理屈を考えても、そもそも予算執行の承認が下りなくて困っています。
先日もある省の方が言っていましたが、「新しい元号が5月1日から適用されることはメディアからの情報であり、正式決定であるかわからない。そんな状況の中で、我が省の関連システムだけ、この取り組みに着手するのは時期尚早ではないか。」いやいや②を進めるにしてももう時間がありませんが。。。
以上、政府系情報システムの現場の状況です。
現場からは以上です。Web企業やスタートアップであれば毎日・毎週システムのアップデートを行なっているので「1ヶ月前」でも問題ないのでしょうが、それ以外の業界はなかなか厳しいのではないでしょうか。
前職の金融SIの時は、そもそもシステムアップデートのタイミングが月に1回だったり、数ヶ月に1回だった記憶があります。
24時間365日停止できないような性質のシステムだと、それなりの事前準備、申請などが必要になるはずで、中のエンジニアは戦々恐々していると思います。どんな改修だろう。。。
システム内で持つ日付は通常西暦です。それはあらゆるプログラム言語で共通。
つまりそこに和暦が入る余地はありません。
あるとすれば出力時に、わざわざ西暦を和暦に変換するシステムがあるということなのでしょうが、それは当然ながら和暦の変更を想定して変換テーブルでその処理をしています。
だから新たなレコードをその変換テーブル内に作るだけですね。
そもそもこうした変換テーブルを持った仕様になっていないのであれば、今から変換テーブルを持った仕様に改修すべきです。
そうすれば、たとえ1週間前に元号が公表されても間に合います。
