本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 

SE関のノーツ/ドミノ徒然草

第23回 2000年を知っていたノーツの2000年問題


 Lotus Software
（当記事は、ノーツの2000年問題について、私、SE関がまさに徒然なるままに書いたエッセイを集めた極めて個人的意見です。IBMおよびロータスの2000年問題への取り組みや製品の2000年対応状況を記載したものではありません。当記事の内容／表現には、不正確な部分があるかもしれません。製品の2000年対応状況に関する正しい情報は、必ずIBMおよびロータスのホームページで確認してください。当記事についてのお問い合わせは、ts@jp.ibm.com へお寄せください。）

とうとう1999年がやってきました。1999年と言えばコンピュータ業界にとってはまさに鬼門の年。新聞の社会面でも頻繁にコンピュータの2000年問題がとりあげられ、金融、医療などの産業分野を中心にその対策についてかなりの関心が寄せられています。ノーツはお金や命に直接関係するアプリケーションはほとんどないかもしれませんが、逆にそのアプリケーションの裾野は広く、かつ数が膨大で、どんな影響が出るかはあまり想像もつきにくいのが現実です。

今回はそのノーツの2000年問題について技術的な側面を中心に考えてみましょう。

まずロータスはノーツの2000年対応について何と言っているのでしょうか。詳しくはロータスのホームページ上で見ていただくとして、そこでの内容を一言で言えばIBMが採用している2000年の定義と同様の定義に従って製品としてはR4.5から2000年対応されているということです（なお、最新情報は、上記URLでご確認ください）。また、基本的にはR4.5以上への移行を強く推奨しながらも、R4.1以前でも回避できる方法などもロータスのホームページで提示されています。

技術的にはどういうことでしょう。ノーツはまず西暦の格納を日付時間フィールドでR1(日本ではR3からなので出ていませんが)、つまり最初の設計からなんと紀元前4713年を基点に紀元後41247年までできるように設計されていました。これは内部的にはユリウス日というコンピュータで良く使われる方式で行われています。よくユリウス日を使って1900年から200年間ぐらいに対応している製品は見うけられますが、ノーツのようなとてつもない年号を想定していた製品は極めて稀でしょう。これもノーツのシステム自身が日付時間を使って巧みに作られておりそれらを大事にしていた表れかもしれません。

多くのソフトウェアの2000年対応がまずは西暦を2桁から4桁にするという極めて初歩的なところから始まっているのに対して、ノーツの2000年対応は少なくとも格納という観点では合格と言えるでしょう。ただ2000年対応はこれだけではすみません。格納しているものを次に取り出して計算したり表示したりするという部分があります。

日付を取り出したり計算したりするのはシステムでもアプリケーションでも行われます。システム的に計算したり表示する部分は現状では格納とは異なり、4桁の西暦、つまり9999年までは対応して作られているようです。一方アプリケーションでは日付を一度テキストなどに変換さえすればあとはアプリケーションの思うがままです。テキストの日付であればプログラマーは左から2桁とりだして年号にしたり、3桁とりだして月日にしたりと自由きままです。実は私も振り返れば20年近く前にこんな荒っぽいプログラムをCOBOLやFORTRANでどれだけ書いていたか。思い出すだけでも少し不安になります。日付時間フィールドを持っているノーツのアプリケーションとて同じ心配はあります。

先日優秀なノーツエンジニアが書いたアプリケーションを少し眺めてみると、テキストで入力された日付がなんとそのままテキストで格納され、さらには計算まで行われていたのを見つけて、これは他人事ではないと実感できました。

いくらシステムとしてのノーツが2000年対応していても、やはり問題はその上で開発されたアプリケーションにあることはたいへん重要なことです。2000年対応ということでハードウェア、オペレーティングシステム、ミドルウェアと順番に対応をメーカーがやり、それをユーザーが取り込んだとしても、最後に問題になるのはやはりその上で開発されたアプリケーションそのものということでしょう。

ノーツはそのシステムの特長からエンドユーザー開発が盛んです。ユーザー部門が自由きままに必要なものを作る。最初は掲示板やディスカッションのアプリケーションだったかもしれません。ところが最近では情報システム部門が知らないところで、顧客対応のデータベースが作られていたり、場合によっては簡単な請求書処理などのアプリケーションもあったりもします。あるお客様のところではデータベースの数がメールデータベースを除いてもユーザーの数を越えているというところもあります。これだけのアプリケーションがいったいどれだけ2000年にお行儀よく対応しているのでしょう。また対応していないとしたら、それはどうやったら対応できるのでしょう。

まずは現実的に行える第一歩はアプリケーションの棚卸でしょう。どこに誰がどんなアプリケーションを作って使っているか。意外にエンドユーザーが開発したアプリケーションまで棚卸して管理されているところは少ないものです。この2000年対応を機にアプリケーションの棚卸をし、会社全体としてどんなアプリケーションがあるかをまとめるのも一石二鳥と言えるでしょう。

しかしユーザー数よりも多いアプリケーションが見つかって、それらを全て2000年対応にしなければなどと言ったらどうしたらいいのでしょう。もちろん時間的にはあと一年もないですからかなり厳しいと言えます。2000年はもう目の前にやってきています。棚卸をしたアプリケーションを、その重要度、もしアプリケーションが2000年に対応していなくて使えない時間が1時間を越えたら、1日を越えたら、1週間を越えたらとその影響度によって分類することが一つの現実的な方法です。そしてそのランクづけで最も高い緊急度のものは今すぐ2000年対応を実施し、緊急度の最も低いものは最後は2000年を越えて問題が出たら対応する、という対処が考えられます。

ノーツのアプリケーションの2000年対応は、日付の格納に関しては日付時間フィールドを使っているかぎり、基幹系アプリケーションでの2桁を4桁にするためにプログラムを大改造すると言った大袈裟なものとはならないでしょう。中にはビューの日付の表示の幅が足りないのでビューの列の幅を変えると言った極簡単なものも数多くあります。緊急度の小さいものは2000年を迎えてからゆっくり変えるという対応も十分現実味を帯びてきます。

最後にアプリケーションを2000年対応したら実施しなければならないのがアプリケーションのテストです。日付をユーザーが入力する部分に関してはそのように手で入力してみればテストが済みます。ただシステムの日付からの処理が有る場合はノーツサーバーの時間、つまりオペレーティングシステムの時間を変えなければならなくなります。このときノーツのシステムで複製などを中心に日付がたいへん重要な意味を持つことに注意が必要です。複製の履歴が複製時間を短くするために日付と時間を記憶していたりするのです。もしオペレーティングシステムの時間を未来に変えてしまったらどうなるでしょう。その後に現在に時間を戻しても、複製で言えば全ての履歴を消さないかぎり複製がその未来の時間まで止まってしまうのです。本格的な2000年テストはこのようなことからテスト専用の別システムを使わなければならないことも頭に置いておく必要があるでしょう。

2000年まであと1年をきりました。膨大なアプリケーションの数やエンドユーザー開発など、ノーツは基幹システムの2000年対応とは別な意味で2000年対応をユーザーに迫っているように思えます。
T. Seki, ts@jp.ibm.com


上に戻る