元号変更で思い出した2000年対応の記憶

先日、平成の元号が2019年4月30日で終了し、翌5月1日からは新しい元号に切り替わるという報道が大々的になされました。新しい元号は2018年秋頃に発表されるということを報じているメディアもあります。5月1日からというのはキリが悪いだの、この前後で10連休になるのではだの、様々な意見がネット上を賑わしていますが、ITに関わるものとしてはやはり、システム面ではどういった影響があるのかが気になります。

NTTデータや日立ではこの対応はさほど難しくないと見ている、という記事があります。基本的には日付は西暦で管理しているでしょうから、西暦と和暦のテーブルに変更を加えることで対応が可能ということでしょう。今回は半年前には元号の変更が発表されるので、事前の準備に時間が掛けられるということもあるでしょう。そうは言っても、当日は対応が問題なくできているかを見届けるための待機を求められることも想像され、システム担当者は連休を堪能したり(連休になるかわかりませんが)、新しい時代の幕開けへの高揚感を感じたりするゆとりもないのかもしれません。

こうした出来事にかつての2000年対応を思い出す方も多いのではないでしょうか。私自身は営業という立場ではありましたが、入社4年目にこの2000年対応に遭遇しました。
もうだいぶ記憶が薄らいでいるのですが、社内にプロジェクトオフィスが設置されて、すべてのお客様で問題なく年を越せるように準備する体制は1年以上前から整えられていたように思います。私が担当していたお客様は、IBMがアプリケーションパッケージを提供していたお客様と、システム構築はお客様自身であるもののIBM製のハードウェアとソフトウェアを利用いただいているお客様と、両方のパターンがありました。

前者のケースでは、初めから2000年対応が完了したバージョンのパッケージを納品していたので、問題ないと分類されていました。また後者のケースでは、対応すべき項目をIBMの技術担当者がお客様担当者と長い間かけて確認してきて、こちらもリスクはほぼないと考えられるという判断をしていました。
その観点では、年が変わる際に何かが発生することはまずないと私としてはあまり心配していませんでした。
ただ、当日は担当するお客様サイトで待機し、問題がなかった場合には2000年プロジェクトオフィスに報告することとなっていましたので、それ相応の緊張感はありました。

私の担当はパッケージを導入されていた栃木県の医療機関と、自社構築の埼玉県の一般企業でした。医療行為に関係するシステムではありませんが、病院ですので病棟に関わるシステムは休日も稼働させる必要があり、こちらの優先順位が高いと判断し、日付またぎはこちらで待機することとしました。おそらく夜11時頃にお客様先に入ったと思います。この時点で、すでにシステムがシャットダウンされていました。いつもは落とす時間ではありませんが、特別に落としていたのです。お客様担当者とは「多分何もないよねぇ。でも確認しないとねぇ」という感じでほとんど緊張感はありません。病院内には、他にもIT関連や医療機器メーカー関連と思われる担当者を見かけました。日付が変わった数分後、システムを再起動します。再起動完了後、管理端末や院内設置の端末から正常に動作するかどうをお客様が確認していきます。私はただ待つのみです。小一時間ほど経過した後でしょうか、お客様から「問題ないですね。もういいですよ」との声がかかりました。会社のプロジェクトオフィスに連絡を入れて次のお客様に移動します。

真夜中に栃木から埼玉に移動するので、このときばかりは事前に許可を得てマイカーでの移動です。埼玉の一般企業に着いたときには朝4時くらいになっていました。すでにお客様とIBM技術担当者による確認が済んでいて、穏やかな空気が流れていました。「中山さんもご苦労さんだね。何もないよ」という言葉をいただき、こちらは1時間にも満たない滞在でその場を辞しました。プロジェクトオフィスに連絡してすべての任務完了です。
その後自宅に帰り、昼過ぎまで熟睡しました。

システム担当者ではないので、事前テストでの苦労、なんていうことはありませんでしたが、2000年対応はいまでも覚えている一大イベントでした。

そういえば、Y2Kなんてキーワードもありましたね。

IBM 中山貴之のWeb Page (平日は毎日更新中)