言い伝えでしか聞いていないのだが、1999年から2000年に変わる時、システム開発の現場は修羅場を超えて戦時中のような状態だったらしい。

システム開発案件の中で最もキツいのは法律に関するもので、締切が絶対的に動かせない上に、社会的な要請によって施行時期が決まるので、開発的に無茶なスケジュールで定まったりすることがあるのだ。

こうなると取りうる選択肢は一つ。大量の人手を用意して、短期集中開発による力技で間に合わせることである。

すると、企画を考える人間の負担が猛烈に高まる。なぜかというと、方針が定まらないことによって溶ける人員の工数が大きくなるからだ。

方針決定が1日伸びると10人の労働力が無駄になるのと、100人の労働力が無駄になるのでは、かかってくるプレッシャーが全く異なる。

指示を待っている側も、ただでさえ厳しい締め切りがますます圧迫されると、普段は優しい人でもやはり穏やかではいられないだろう。

ギスギスする空気の中で死に物狂いで働かなくてはいけないという、ブラックな要素が揃っていたのが俗に「2000年問題」といわれた当時の開発環境だったのである。

似たような話に元号対応がある。平成から令和への変更は天皇の意思表示により計画的な改正がなされたが、そうはいっても「令和」と決まったのは1ヶ月前。

下準備をしていたとはいえ、この1月はシステム担当者もテストの追い込みがあったはずだ。

天皇の逝去により元号が変わっていた時はもっとバタバタで決まっていただろうし、その分システム担当者の負荷も相当なものがあったはずだ。

システムは時間の経過とともにどんどん機能追加されていくので、元号対応で手を加えなくてはいけない箇所は膨らみ続けている。

「だったら全部西暦にすれば良いのでは？」と思う人間もいるだろうが、行政文書の多くは元号で表示されている。

提出された行政文書を見ていちいち西暦に変換するのは、事務ミスの温床になるし非効率である。

だからといって行政の文書システムを全部西暦に変えようとするのは政治的にもコストの面でも現実的ではない。

行政文書も紙を極力廃止して電子システムに移行すれば、デジタルデータ内での西暦⇄元号の変換が容易になるので、今の仕組みをそこまで変えずに日本全国のシステム担当者の働き方改革につながる。

元号は日本の文化であって否定するものではまったくないのだが、それを運用面にどこまで組み込むかは全く別の話だ。

提供サービスが何も変わらないアップデートのために社会全体で何千億円もコストをかけますか、という問題であり、エンジニア目線からすれば答えは明らかである。

という訳で、社会的なコスト削減のためにも、システム運用における元号の切り離しを切に願うばかりである。