a.4. 2000年問題其の肆

ここに、会社のトップに提出した、レポートを載せます。要は、これは大変だ、と思わせるのがねらいです。まあ、ちょっと読んでみてください。

2000年問題について

なぜこんな問題が出たのか?

巷で騒がれている、2000年問題とは、どんなもので、どうのように変更して行くのかを説明いたします。そもそも、システム開発で、日付が出てきたら、年は２桁にするのはごく自然なことで、むしろ４桁にするほうが異常と考えられていました。それは、無駄に２バイトも使ったり、帳票や画面に99/99/99と出せばいいものをわざわざ9999/99/99とすれば余白が減ってしまうし、何よりも年２桁で十分間に合っていたのです。これらはコンピュータが作成された当初からの、いわば慣習であったともいえます。これらの背景には、きわめて高価なディスクやメモリを無駄に使用しないことが、「美徳」とされた考えがあったのです。

このままだと、どうなるというのか?

コンピュータの処理は、データの保管、並べ替え・分類、抽出、計算などが主なのですが、年の桁数はすべてに関連します。コンピュータでは、並べ替えをする必要があるために、ディスク上ではたいてい年月日（YYMMDD）の形式にしていて、ディスク上の日付を、人間が見る帳票や画面で表示するときに形式変換をしているだけです。

たとえば、日本系と外資系では、日付の扱いが異なります。つまり、日本では元号があり、コンピュータでは表示印刷を元号で表わし、そのデータはディスク上では西暦で保管することが多く行われています。また、西暦でも年月日、月日年、日月年と３つ形式があります。9/6を9月6日と読むか、6月9日と読むかは、会社で本来は、基本的ガイドを出しているはずです。ただの決め事なのです。この会社では、基本的にYY/MM/DDの形式で、西暦年を2桁で保管しています。YYMMDDの形式にしないと（MMDDYYなどにしてしまうと）、きちんと古いものから新しいものへ、並ばないのです。この保管データは、以下のように加工したり利用されたりします。

たとえば、曜日計算、年齢計算、や未来の一点を指し示す（売り掛けなど）。これら、すべてに2000年問題は現れます。

2000年問題の核心（今のままでいくと、どうなるのか）

2000年を含むデータを、年2桁のままで、古いものから並べようとすると、

※最後に来るべき年が、最初に来ています。これでは、年代順（日付順）に処理するジョブ(FIFOやLIFOにより処理するもの等)が無茶苦茶になってしまいます。

また、売上のレポートなどで1999-2000年のデータの範囲を画面から指定しようとすると、99～00と入力して、開始値より終了値のほうが小さいという算数的矛盾も発生します（00～99なら算数的には正しいが、00,01,02,03,04...97,98,99を選択してしまい、99,00のみではなくなる。）。

さらに、年齢計算では、60年生まれの人は 97 - 60で37才ですが、西暦2000年には00 - 60で - 60才となり、生まれる60年前？になります(マイナス60歳と言う概念はこの世にない。)
日付関連の演算は、売掛の締め日や、来年度の予算などで関係してきます。銀行では何年にもわたる長期貸付の日付計算で、早くから2000年問題に気づいていたようです。

これとは別に、年以外の部分、「月」や「日」を示す、日付数字列内の「位置」にも影響がでます。つまり、日付6桁のうち月を意味する数字は頭から数えて3桁目と4桁目です。しかし、日付8桁では、月は頭から数えて5桁目と6桁目です。（後ろから数えることはできません。念のため。）この取出し方法はたいてい、日付から月を取出す場合に使われています。

これはプログラム特有の問題ですが、このように判定する部分は、すべてのプログラムではないですが、かなり多く、これを探し出し、修正す作業も大きな負荷となります。年４桁にして、この部分に何もしないと、97月とか98月が出てきて、ユーザーを驚愕させます。

どうやって、修正するのか?

では、どのように修正して行くのでしょうか？パソコンのように、少量データを扱うデータ処理では、簡単に変更できますが、オフコンクラスの大量データとなるとそうはいきません。同時に何人もの人が、別々のプログラムで、同じファイルを参照しているのです。

このステップを踏んで変更して行きます。ここで「修正」とは、古いものを削除して、新しいものを作成すると言う意味で、つまり、一旦削除しなくてはならないのです。

沈んだり、潜ったり

以下に、ある修正担当者の独り言を挙げます。あくまで架空の話です。

1999年8月10日
今月から3ヶ月以内で、2000年に関するデータが出てくるのは、予算と売掛くらいかな。未来を扱う業務が少ないからよかった。さて、今日は、売上のファイルに含まれる日付の年2桁を年4桁に変換しよう。今みんな使っているので、当然、ファイルは削除できない。別ライブラリー(別ディレクトリー；フォルダーのこと)に新ファイルを作成して、それに合わせてプログラムを修正して、作成する。まず、オーダーファイルを修正して、オーダーから売り上げファイルを作成する部分を修正した。うーん、このファイルを画面照会するプログラムで、画面に年4桁は入りきらない。仕方ない、あんまり見てなさそうなこのフィールド画面からとっちゃえ。えーと、ああ、帳票もマックスまで使っているから、うーんこれもとっちゃえ。この売上ファイルは年4桁に変更なので、旧データの日付のフィールドをすべて、+19000000しなくては。ああ年月日でなくて年月だけの部分もあるや。危うく見逃すところだった。おや、このファイルは、売掛のシステムも参照しているな。売掛も修正しなくては。まてよ、売掛のファイルのほとんどはまだ年2桁のままだ。仕方ない。売掛も修正対象にしよう。やれやれオーダー確定日から締め日の計算か。この売掛の画面は、年月日を入力指定するから、ここは、絶対年4桁にしないとだめだな。おや、この売上ファイルは日ごとの売上集計でも参照されているな。うーん、まあいいか。売上の集計プログラムの修正もやろう。おや? あっ！この売掛けファイルの元になるオーダーファイルは売上報告の納入数の取出しで参照されている。これも直さなくては。ああ、売上報告のプログラムの中で、年4桁にしたファイルと、まだ２桁のままの別ファイルの日付とを比較をしているぞ。19970101と970101はコンピュータでは違う日付になるな。じゃあこれも修正するか。まてよ、売上の条件ファイルやら明細ファイルやらでも、日付処理があるからこれもか．．．ああ日別売上開始日の指定部分がある。日別売上のファイルも日付を年4桁にしなくてはデータが抽出できない。これって今、一年で200万件あるんだよな。AS/400のディスク足りるのかな。あ、日別売上のコントロールエリアのキーは年2桁だ。これほとんどの日別売上のプログラムが参照してる。めんどうくせえなぁ！あれ?え！、待てよ！これを始めたら、成績管理や日別売上の集計や、あああ顧客のフォローアップも修正しなくちゃ．どうすりゃいいんだ...時間が無い。あ！QRYとDFUやってないや。テストは全部するのか? えー気が狂うよ。この連鎖反応は終わりがないのか? オーダーや日別売上のコンピュータ処理、半年くらいストップできないかなぁ。無理だよなぁ。ああ疲れた。今日はやめて帰ろう。

1999年8月11日
朝来たら、みんなばたばたしている。え？あっ、日締め処理がストップしてる！...しまった！！昨日間違えて、テストファイルを本番に作成しちゃったんだ。この修正を終わらなきゃオーダー入力できないや。じゃ、オーダー入力も、たった今、修正しなければ! う? 伝票は?！いいや、あれは午後印刷だから、後だ。え、なに、在庫が狂った? あーこれ、本番データをテストデータに書き換えちゃったんで、めちゃめちゃなデータで在庫更新してる！あ、じゃ売上も狂ってるな。売上報告ファイル壊れたの? あっ! 倉庫への出荷データも止めなきゃ。うーん、もーぐちゃぐちゃだな。あれ、ネットワーク受信がエラーになっている。え? 何でこんなとこでエラーになるの? ああ!いけね！忘れてた。ネットワークの受信でファイルに入るから、受信プログラムも修正しなきゃ。あそうだ、受信管理ファイルも日付順に表示するから狂ってしまう。おや、売り上げ報告書がおかしくなってる。えーなんで?? ............あ、そうか、昨日見つけた以外にも日付の比較をしてるところがある。これ気づくのに2時間かかってしまった。関連するプログラムがおおすぎるんだよな。ああ、ネットワークの受信は、オーダーだけでなく、売上げのプログラムも調べなきゃ。あ、そうか、くそ、ネットワークと新ネットワークの両方やらなきゃ。あ、集計ファイル作成プログラム以外に、ダウンロードデータ作成のプログラムも修正しなきゃ。これは、後々やるか。ああ、今日は業務止められないかな？もうだめだ、元に戻そう！バックアップをもどすか。まてよ、最新のバックアップはデータが狂ってからのものだから、おとといのデータにするか。オーダー再入力は困るだろうなぁ。待てよ，オーダーだけバックアップ戻していいのかな? 在庫や売掛も戻すのか? 昨日の仕事は何だったの？あーもうこの会社やめようかな．．．

と、こんな感じになります。
これは、この会社に限ったことではありません。全世界共通の問題です。やることは簡単ですが、膨大な数の修正と、どれだけやり残しが無いか、が問題です。テスト計画なんて立てられません。そんな暇はもうないのです。日本人の危機管理の下手なことは世界中で有名だそうですが、それどころではないのです。

それでも、地球は回る...

正直言って、こんな作業したくありません。どんなに苦労して、うまくいったとしても、結局は今と同じになるというだけです。しかしながら、今のところ、これらの後ろ向きの作業をやるしか解決方法がありません。現代の科学では、地球の公転を止めてはくれません。その対象となるものは、全部で3000個くらい。2000年まで1000日なくなりました。崖っぷちです。

郵便番号の桁がかわっても、売上は狂いませんが、2000年でいまのままだと、売上は変になります。それどころか、売掛やさらに年齢計算を条件に含むDM印刷まで、すべておかしな結果になってしまいます。へたをすれば、連鎖的にすべておかしくなり、プログラマーは家に帰れないかもしれません。おかしい結果の目の前にしても、その原因はすぐには分からないのです。そして、原因が分かっても、絶望的に多くのプログラムの修正もありえます。これは、目に見えない時限爆弾と似ています。どうしても、その爆発は避けたいのです!

何から、はじめようか?

修正は、どのシステムから始めればいいでしょうか。本当は、システム全体にインパクトが強いプログラムから修正をして、テストをしたいのですが、では、インパクトが強いとは、何を根拠にして判断して、どのように見つけ出すのでしょうか。この会社は売上が大事なのでしょうか？それよりマーケティングが大事なのでしょうか。はたまた、デパートからのオーダーを受信してBTS業務を楽にしてあげるのが大事なのでしょうか? どうやら、この会社ではどれも大事らしいです。午前はオーダー、3時までは日別売上,その後、ネットワーク受信送信と一日を３つに分けて毎日修正処理していたら、脳みそ三つにして、腕は６本あっても、間に合わないでしょう。必ず、優先順位はあるはずです。おかしくなっても仕方ないで諦められる業務と、ミッション・クリティカルな業務とに分けるだけでも、テストの際には、後者を念入りにテストできます。
ただ、修正作業中には、優先順位は不確かなものとなるかもしれません。つまり、優先順位１番の修正をしているうちに、連鎖反応を解決しようと追いかけて、いつのまにか優先順位99番を修正していることはありえます。

こうしたら、どうか?

具体的に、どうのように進めるのが、もっとも安全でしょうか。一台の機械上で修正テストをすると、誤って、本番データを破壊してしまう可能性が高くなります。１台でメンテしょば代込みで数億円のコンピュータの大型機になると、どうしようもないのですが、オフコンレベルならば、もう一台手に入れて、開発修正専用にするのがベストです。これが、もっとも安全な環境で、テストも十分に可能な体制です。なぜならば、同じライブラリー名で同じプログラム名で（つまり全く同じ環境で）完全なテストが、修正用コンピュータの上で可能だからです。

修正準備

修正作業の開始

本番へ戻す

多分、どのファイルを修正し、関連するプログラムを洗い出し、きちんと計画と立てるだけで、2～3ヶ月くらい必要でしょう。その次に、今、存在しているシステムを一括して、修正用コンピュータに移します。データ量は本番環境よりずっと少なくてもいいはずです。修正とテストだけに使用するのですから。
そして、そこで、計画順に修正を開始します。つまり、この時点でプログラムは、現行コンピュータと修正用コンピュータに別れ、２つ存在します。ここで、本番プログラムの修正依頼や作成依頼があると、現行コンピュータで修正して、更に同じことを修正用コンピュータにもしなくてはなりません。ことによれば、やっと2000年の修正が終わったものを、新しい修正依頼に基づいて、そっくりはじめからまた直す必要もあるかもしれません。できれば、仕様変更によるプログラムの修正は一切受け付けたくありません。

この修正が終わると、こんどは、年2桁のデータを年4桁にする変換プログラムが、修正したファイル単位に必要となります。つまり、データで00970505となっているものを19970505にしなくてはなりません。さらに、簡単にテストして、元の現行コンピュータに戻しますが、これも、ひとつひとつやってしまうと、古いままの関連するファイルやプログラムがバンバンとエラーを起こしてしまいます。ある程度一括して戻します。時期は、1998年末年始か、３日以上の連休を利用するでしょう。その休日の移行の真っ最中には、実行できない業務が出てくるはずです。たとえば、ネットワークへの入庫データは送信できないでしょう。（入庫送信は無人で土日も送信しています）。
また、1999年の年末年始では間に合いません。1999の11､12月には2000年の売掛金が既に、発生しているからです。

この後、本番のデータを年2桁から4桁へ移行します。これも、1000件の場合は旧から新へ移行するので、一時的に新旧２つのファイルが存在するため、倍の2000件がディスク上に存在することになります。400万件ならば800万件、となりディスクも結構いっぱいになって行きます。これらは一時的に跳ね上がるだけで、移行が終われば、古いファイルはバックアップして削除できます。しかし、この移行をしている最中に、業務は動かせないと思います。これも休日中にせねばなりません。

アナタハ、カミヲ、シンジマスカ？

これで、すべてではなく、プログラムの修正済み、修正完了などのバージョン管理や、DFU,QRYといった、ユーティリティや、修正できないパッケージなどの対応、どうしても画面に入りきらない場合の対応策や、はたまた、修正用コンピュータのOSのバグ対応やバックアップ及びハードメンテナンス、また、外注を使った場合、彼らへの説明や管理や検収などなど。

これら、作業はInformation systemsだけの問題ではなく、日本本社からネットワークそしてフランス本社にも影響がでるものです。これほど神経を使い、膨大な量の細かい作業を伴う処理は、今までありませんでした。

また、私の勘では、修正後、これらすべてが本当に落ち着くのは2000年に入ってからです。1999年内はエラーがあっても表面化せずに、潜伏する可能性があります。完璧を目指すのは「神業」以外のなにものでもありません。神頼みをしたい心境です。

絶望と向き合う

多くのツールが出回っていますが、完璧なものは無く、最後は自力でやるしかないのが現状です。やらずに放っておくわけにもいきません。この2000年問題に関して、今後、様々なトラブルがあると思いますが、何卒ご理解の上、ご協力をお願いします。

SEO		[PR] 爆速!無料ブログ無料ホームページ開設無料ライブ放送

a.4. 2000年問題 其の肆