天皇陛下の生前退位について議論がはじまりました。
政府、平成30年譲位を視野…特例法を軸に検討(読売新聞) – Yahoo!ニュース
政府は、現在の天皇陛下に限って退位を可能にするため、皇室典範の特例法制定を軸に検 – Yahoo!ニュース(読売新聞)
出典: http://headlines.yahoo.co.jp/hl?a=20161017-00050157-yom-pol
政府の方針は特例法での譲位を検討しているようですが、報道されている内容を見る限りでは「平成30年」に今上陛下が退位し皇太子殿下が即位する流れになりそうです。
システム開発的には、皇太子殿下が即位をした日をもって発生すると見込まれる改元。─── 現在の『平成』という元号から新しい元号に変わることが、システムに影響を与える可能性がありそうだと危惧しています。
日本のコンピュータシステムにおいて日付の扱いは少し特異で「西暦」と「和暦」の2つの暦を扱います。
たとえば、データの入力や表記(印字)は「和暦」で、データの保管は「西暦」で、処理では必要に応じて「西暦で入力されたデータを和暦で表示する場合…」「和暦で入力されたデータを西暦で保管する場合…」といった変換処理を行っています。
この処理を「和暦・西暦変換」や「和暦変換」(主に表記の変換)、「元号変換」(主に”年”の変換)と呼びます。
改元が発生した場合、この変換処理が正しく行われるか確認を行う必要があります。
また、不具合を発見した場合システムの修正作業を行う必要も生じます。
和暦・西暦変換処理は、大きくわけて3つのパターンで実装されています。
たとえば、下表のような感じです。
元号 | 開始日 | 終了日 |
昭和 | 1926/12/25 | 1989/01/07 |
平成 | 1989/01/08 |
システムがこの方法で元号変換を行っている場合、改元の日が確定した段階で、現在の「平成」の終了日を設定し、元号マスタに新しいデータ(レコード)を追加するだけで改元対応が完了します。
システムの機能として設定画面が用意されているか、あるいは技術者を呼んで設定を行う必要があるのかを確認しましょう。
ただし、下記のような場合は注意が必要です。
古いWindows、あるいはAccessやExcelといったOfficeを、基盤またはシステムの一部として組み込んでいる場合、修正版のプログラムが提供される可能性はほとんどないと思われます。
また、修正版プログラムが提供される場合でも、修正版の提供時期によっては自社のシステム・業務に影響が出る可能性があります。
提供された修正版が自社のシステムに適合するか事前に確認を行っておく必要もあります。
自社のシステムを構築した業者に、対応予定を確認をしましょう。
if (YYYYMMDD >= 19261225 && YYYYMMDD <= 19890107) { // 昭和の処理 } else if (YYYYMMDD >= 19890108) { // 平成の処理 } else { // 未知の元号なのでエラー処理 }
// 処理前提: 昭和より前のデータは入ってこない。入ってきたら破綻。 if (YYYYMMDD <= 19890107) { // 昭和の処理 } else { // 平成の処理 }
この場合、人によってプログラムの書き方がまちまちで、「元号ごとに日付の範囲をきちんと書く人」や「昭和とそれ以外で分けてしまう人」などがシステムの中でごちゃごちゃになって使われていることがよく見られます。
また、システムの中でどのくらい独自の変換ルーチンを使用・依存している箇所が存在するのか、修正した場合どのような影響が発生するのか、すべて調査を行った上で修正を行う必要があります。
「比較的古い時期に実装されたプログラム」と前述しましたが…
実はコレ、割と最近書かれたJavaScriptでもときどき見かけます。「うちは去年作ったシステムだから関係ないな」とせず、一度確認されることをおすすめします。
自社のシステムを構築した業者に、対応を相談しましょう。
システムの再構築を含めた対応計画を立てる必要があります。
いずれのパターンでも、事前に「改元が発生したときにどのような問題が起きるのか」調査を行い、必要な対策を講じておく必要があります。
コンピュータのプログラムは自然治癒的に治る可能性はありませんし、環境の変化に合わせて自動的にプログラムが適合をしていく機能も備わっていないので、技術者が介入した対応は不可欠です。
また、システムの修正作業は、簡単に短時間で終わるものではなく、調査・調査・調査・調査・修正・確認・確認・確認・確認・確認・確認…と、非常に時間がかかる作業です。
2000年問題のときも同様の現象が起きましたが、これから先、改元の時期が確定していくにつれ、調査・対応作業の需要が急増し、技術者の確保が難しくなることが予想されます。
パターン3とパターン4については、調査・修正量が多くなること、そのプログラム・技術を理解し修正できる技術者の確保が不可欠であることの2点から、特に対策に時間を要します。
2000年問題のように「コンピュータシステムがある日突然まったく動かなくなる(可能性がある)」といった致命的な問題は起きにくいと思いますが、なんらかの影響・問題が起きてからの対応では遅いことも…。
できるだけ早い時期から調査と対応の計画をおすすめします。
RIALAB.では、「プログラマと連絡が取れなくなった」「開発した会社がなくなってしまった」システムの改造・改修なども承っております。詳しくは、サービス・製品をご覧ください。
Please give us your valuable comment