コンピュータシステムの暦のこと

火曜日 , 18, 10月 2016 Leave a comment

天皇陛下の生前退位について議論がはじまりました。

政府、平成30年譲位を視野…特例法を軸に検討(読売新聞) – Yahoo!ニュース

政府は、現在の天皇陛下に限って退位を可能にするため、皇室典範の特例法制定を軸に検 – Yahoo!ニュース(読売新聞)

出典: http://headlines.yahoo.co.jp/hl?a=20161017-00050157-yom-pol

政府の方針は特例法での譲位を検討しているようですが、報道されている内容を見る限りでは「平成30年」に今上陛下が退位し皇太子殿下が即位する流れになりそうです。

システム開発的には、皇太子殿下が即位をした日をもって発生すると見込まれる改元。─── 現在の『平成』という元号から新しい元号に変わることが、システムに影響を与える可能性がありそうだと危惧しています。

日本のコンピュータシステムにおいて日付の扱いは少し特異で「西暦」と「和暦」の2つの暦を扱います。
たとえば、データの入力や表記(印字)は「和暦」で、データの保管は「西暦」で、処理では必要に応じて「西暦で入力されたデータを和暦で表示する場合…」「和暦で入力されたデータを西暦で保管する場合…」といった変換処理を行っています。
この処理を「和暦・西暦変換」や「和暦変換」(主に表記の変換)、「元号変換」(主に”年”の変換)と呼びます。

改元が発生した場合、この変換処理が正しく行われるか確認を行う必要があります。
また、不具合を発見した場合システムの修正作業を行う必要も生じます。

和暦・西暦変換処理は、大きくわけて3つのパターンで実装されています。

  1. 元号マスタで変換をしている
    システムの中に「元号マスタ」と呼ばれる「この元号は何年何月何日から何年何月何日までである」といった定義を行っているシステムがあります。
    (「マスタ」 とは、「台帳」と呼ばれることもある、大元のデータを記したファイルまたはデータベースのことです。)

    たとえば、下表のような感じです。

    元号 開始日 終了日
    昭和 1926/12/25 1989/01/07
    平成 1989/01/08

    システムがこの方法で元号変換を行っている場合、改元の日が確定した段階で、現在の「平成」の終了日を設定し、元号マスタに新しいデータ(レコード)を追加するだけで改元対応が完了します。

    システムの機能として設定画面が用意されているか、あるいは技術者を呼んで設定を行う必要があるのかを確認しましょう。

  2. ライブラリで変換をしている
    プログラミング言語や開発環境が提供しているライブラリ(便利なプログラムの集合体)に含まれる変換ルーチンを利用し、処理を行っているシステムがあります。
    一般的に、そのライブラリを供給しているソフトウェアベンダ(開発・販売元)が、新しい元号に対応した修正版プログラムが提供されることが見込まれます。

    ただし、下記のような場合は注意が必要です。

    • ソフトウェアのサポート期間(契約)が終了している
    • ソフトウェアを開発したベンダ(メーカー)が倒産や合併などで存在しない

    古いWindows、あるいはAccessやExcelといったOfficeを、基盤またはシステムの一部として組み込んでいる場合、修正版のプログラムが提供される可能性はほとんどないと思われます。
    また、修正版プログラムが提供される場合でも、修正版の提供時期によっては自社のシステム・業務に影響が出る可能性があります。
    提供された修正版が自社のシステムに適合するか事前に確認を行っておく必要もあります。

    自社のシステムを構築した業者に、対応予定を確認をしましょう。

  3. 独自の変換ルーチン(プログラム)で変換をしている
    元号マスタやライブラリに依存せず、すべてを自前のプログラムで処理しているケースもあります。
    日付は、8桁の数値として見ることもできる(例: “2016/10/18” → 20161018)ので、単純な条件判定文の集合体で処理をすることも可能です。
    ライブラリが充実していなかった比較的古い時期に実装されたプログラムでは、 このような実装を行っているケースがあります。

    if (YYYYMMDD >= 19261225 && YYYYMMDD <= 19890107) {
    // 昭和の処理
    } else if (YYYYMMDD >= 19890108) {
    // 平成の処理
    } else {
    // 未知の元号なのでエラー処理
    }
    
    // 処理前提: 昭和より前のデータは入ってこない。入ってきたら破綻。
    if (YYYYMMDD <= 19890107) {
    // 昭和の処理
    } else {
    // 平成の処理
    }
    

    この場合、人によってプログラムの書き方がまちまちで、「元号ごとに日付の範囲をきちんと書く人」や「昭和とそれ以外で分けてしまう人」などがシステムの中でごちゃごちゃになって使われていることがよく見られます。
    また、システムの中でどのくらい独自の変換ルーチンを使用・依存している箇所が存在するのか、修正した場合どのような影響が発生するのか、すべて調査を行った上で修正を行う必要があります。

    「比較的古い時期に実装されたプログラム」と前述しましたが…
    実はコレ、割と最近書かれたJavaScriptでもときどき見かけます。「うちは去年作ったシステムだから関係ないな」とせず、一度確認されることをおすすめします。

    自社のシステムを構築した業者に、対応を相談しましょう。

  4. その他
    比較的最近構築されたシステムでは、入力・表記は和暦。データの格納は西暦というパターンがほとんどだと思います。
    しかし、まれに昭和期に構築されたシステムで、「昭和nn年」といった昭和形式でデータの格納をしているシステムがあります。
    このようなシステムの場合、既に平成対応(「nn-63」で昭和を平成に変換)が施されている可能性が高く、新しい元号にどのような修正を施せばよいのか、過去に蓄積されたデータ変換を行う必要があるのか、十分な調査と対策の検討を行う必要があります。
    平成30年に見込まれる改元を平成対応と同様の対応で乗り切った場合、「昭和100年問題」と呼ばれる問題をはらんでいる可能性が非常に高く、2025年時点でシステム上でデータの取り扱いができなくなる可能性があります。

    システムの再構築を含めた対応計画を立てる必要があります。

いずれのパターンでも、事前に「改元が発生したときにどのような問題が起きるのか」調査を行い、必要な対策を講じておく必要があります。
コンピュータのプログラムは自然治癒的に治る可能性はありませんし、環境の変化に合わせて自動的にプログラムが適合をしていく機能も備わっていないので、技術者が介入した対応は不可欠です。

また、システムの修正作業は、簡単に短時間で終わるものではなく、調査・調査・調査・調査・修正・確認・確認・確認・確認・確認・確認…と、非常に時間がかかる作業です。
2000年問題のときも同様の現象が起きましたが、これから先、改元の時期が確定していくにつれ、調査・対応作業の需要が急増し、技術者の確保が難しくなることが予想されます。
パターン3とパターン4については、調査・修正量が多くなること、そのプログラム・技術を理解し修正できる技術者の確保が不可欠であることの2点から、特に対策に時間を要します。

2000年問題のように「コンピュータシステムがある日突然まったく動かなくなる(可能性がある)」といった致命的な問題は起きにくいと思いますが、なんらかの影響・問題が起きてからの対応では遅いことも…。
できるだけ早い時期から調査と対応の計画をおすすめします。

RIALAB.では、「プログラマと連絡が取れなくなった」「開発した会社がなくなってしまった」システムの改造・改修なども承っております。詳しくは、サービス・製品をご覧ください。

Please give us your valuable comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください