直前になって慌てないための「改元対応虎の巻」
リスク山盛りで情シスは大丈夫か “改元システム対応”の近道とは?(2/3 ページ)
一目で分かる改元対応の「いつまでに何を」
新元号に変わることで、「2000年問題」のような深刻なトラブルにつながることは考えにくいが、2019年は、4月末までが平成で5月から新元号と、1年間で2つの元号が混在する年となるため、システムの処理によっては不具合が発生する可能性もある。例えば、多くのシステムでは「2018年=平成30年」と、西暦と元号を1対1のテーブルで持つが、2019年は、「2019年=平成31年」と「2019年=新元号1年」の2つのテーブルを持ち日付によって判定する、もしくは「2019年4月=平成31年」「2019年5月=新元号1年」とするなど、何かしらの変更を加えなければデータの不整合が起こり得る。
このようなリスクを回避するためには、まず何から始め、そして、2019年5月1日までにシステム対応を間にあわせるにはどう対応計画を考えればいいのか。新元号対策のソリューションを提供する富士通と、元号改正におけるテストコンサルティングサービスを提供するデジタルハーツに、対応開始から運用までに必要な作業項目と平均的な対応期間を尋ね、まとめた内容が以下の図だ。
まず、確認したいのが、契約管理や受発注管理、人事管理、会計系のシステムといった業務システムだ。Webサービスを提供する企業であれば、生年月日など会員データに和暦を使用していないかも確認する必要がある。また、業務系システムだけでなく、自社のコーポレートサイトに和暦を使用する箇所がないかどうかも忘れずに確認したい。
また、図を見ると分かるように、対応作業の多くを占めるのが、事前の影響範囲調査とテストだ。対応箇所さえ正確に洗い出しができれば、あとは該当箇所に必要な手直しを加えればよい。西暦和暦の自動変換処理を実装する場合は、パラメータを追加するだけで対応できるケースもある。だが、スムーズな対応を行うには事前の影響範囲調査と事後の検証(テスト)には時間をかけることが不可欠だ。ここからは2つの行程を深掘りして見ていく。
まず影響範囲調査のフェーズでは、「和暦を使用する箇所がどこにどれくらいあるか」など使用箇所の確認だけではなく、「元号の出力処理にどのようなプログラムが記述されているか」といったソースコードレベルの内部処理についても調査し、把握する必要がある。和暦を西暦に自動変換して処理するシステムもあれば、「平成30年」を「昭和93年」としてデータを持つシステムもあり得るからだ。このように内部処理の違いによって、対応方法や工数が大きく変わる場合もあるため、影響範囲を全て洗いだすためにも、最も調査期間を要するフェーズだ。もちろん、システムの規模によってもこの期間は大きく変わる。
和暦使用箇所の洗い出しにおいて盲点となりやすいのが、「平成31年2月~平成31年7月」など、元号をまたいだ期間を動的に表示する箇所だ。2019年5月1日より元号が変わるため、サービスの利用可能期間やキャンペーンの有効期間表示など、元号をまたぐ期間を表示する箇所がないかどうかも確認したい。
対応後のテストも長く見積もる必要がある。広範囲にわたって対応が必要なものはテストだけで1カ月以上を要する場合もある。対応箇所が少ないシステムであっても子会社やパートナー企業とデータを連携させるシステムの場合は、連携先のシステムで不整合が起きないかどうかもテストフェーズで確かめる必要がある。連携先のシステム担当者と新元号対応の方法についてよく確認を取り合い、矛盾が起きないようなデータ形式やプロトコルで連携を図る必要がある。
このように、事前の影響範囲調査と対応後の確認(テスト)には多くの時間を要するため、情報システム担当者やエンジニア、部門責任者などスタッフのスケジュールを事前に押さえた上で、綿密に対応計画を組むことが肝要だ。本稿執筆時点では2019年5月1日が「新天皇即位に伴う祝日」となる可能性が高い。法が成立すれば2019年4月27日から5月6日は10日間の大型連休とする企業もあるだろう。それを踏まえた対応計画が必要だ。
新元号の対応は影響範囲が限定的だと考える企業もあるだろうが、実際には、これだけの項目を残り数カ月で考える必要がある。
平成の改元を経験していないエンジニア
創業してまだ間もない企業や、最近、合併した企業のシステムは、和暦を使うシステムはそう多くないだろう。和暦を使用する箇所があったとしても、変換処理の仕組みを実装し対応するシステムが多い。こうした、比較的新しいシステムには、パラメータ変更などわずかな修正で事足りるケースが多いだろう。
ただし、最近のWeb系システムは、「昭和」から「平成」への改元を経験したことのないエンジニアが中心となって開発するシステムも少なくない。先輩エンジニアから過去のノウハウが引き継がれていない場合も考えられなくはないため、その点もフォローが必要だ。
こうした、目には見えない部分も配慮する必要があるため、広い側面で対応を考える必要がある。
改元対応で一番“厄介”なケースとは
最も問題なのがシステム規模の大小ではなく、仕様書や設計書が残されていないケースだ。スクラッチで開発したシステムの中には、古くから改修を重ね使い続けてきたものや、ソースコードが継ぎ接ぎ状態となり、中身がブラックボックス化していたり、和暦算出処理がハードコーディングされていたりするものもあるだろう。システムの処理を知ろうにも、開発を担当したエンジニアが退職し、システム設計が引き継がれていない場合や、仕様書や設計書などのドキュメントが残されていない場合もあり得る。システムインテグレータ―(SIer)など外部に委託した場合も同様だ。そうなると、調査フェーズでは手探りで当たりを付けるしかない。そのため、自社開発のシステムやSIerに開発を委託した場合は、仕様書や設計書の有無をまず確認したい。この問題は、パッケージソフトをカスタマイズした場合も同様だ。
Copyright © ITmedia, Inc. All Rights Reserved.
直前になって慌てないための「改元対応虎の巻」
政府は、2019年5月1日の新天皇即位に伴う新元号の公表時期について、改元の1カ月前を想定して準備する方針だ。本特集では、改元対応について、民間企業のシステムへの影響や留意すべき点、いつまでに何をする必要があるのかを解説する。
この記事の著者
こんなメディアも見られています
キーマンズネットに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
SpecialPR
アクセスランキング
-
1
ニンテンドーシステムズ開発者が明かす、通信「低遅延・安定運用」のコツ【事例集】
-
2
「Gemini Notebook」で利用者10倍 シニア社員をAIヘビーユーザーにした首都高の考え
-
3
スクエニ開発陣が「ドラゴンクエストX」の世界観を守るのに「Gemini」が必要だったワケ
-
4
「新しいOutlook」って使ってる? 移行で変わるメール誤送信対策
-
5
「情シスやめます」と言われたら――ある日突然「ゼロ情シス」になった企業のその後
-
6
「脱Excel」しても、いちばん働いているのはExcel 給与計算の調査に見る実態
-
7
使わなくなったPCを、企業が処分したくてもできない理由
-
8
千代田区、Copilot全庁導入で月2000時間削減 10カ月でAIを根付かせた定着の仕掛け
-
9
“壊してもいい”が現場を変えた 岩塚製菓、生産性1.3倍を生んだDX定着の条件
キーマンズネット SNS
インフォメーション
注目情報をチェック
キーマンズネットをフォロー