コンピュータ西暦2000年問題の概要

　コンピュータ西暦2000年問題は、1995年末の時点では、本当にそのバグで多くのシステムが停止するほどの大問題になるかどうか、多くは、今後４，５年のリプレースの間に解消されるし、たいしたバグではなく都度修正すれば足りる程度のものだという見立てにありました。業界団体の専務（通産省）が、狼少年になってもいいから、警鐘を鳴らしておくべきだと決断されて、なんと技術に疎い私がIT業界での担当者第一号に任じられました。
　この担当業務を通じて、コンピュータ産業の歴史を勉強しなさいと部長から申しつかりましたので、私のOJTとセットというくらい全く本気度のない取り組みからスタートしたわけです。
　実際、予算もつかず、他の通常業務を抱えながらの一人きり担当ですから、できる範囲で細々と調査を開始しました。報告書を作る予算もないので、手控え的に概要をとりまとめていたところ、上司の目にとまって業界の会報に掲載されたのが、これです。
　おぼろげな記憶ですが、米国のDatamation誌の1996年1月号にY2Kの特集が組まれたことを知り、また日本IBMをお訪ねして、アメリカ本社の下にY2K対応のセンターが開設され、Y2K対応のマニュアルが冊子にまとめられて社内に配布されていることを知りました。
　これは、日本のIT業界もY２K対応に本腰をいれねば大変なことになるかもと思ったことを覚えています。
　そのうちに社会問題として認識されるようになってきたことから、他の業界誌と電波新聞にも転載されることになり、結果的に本邦初の報告書となりました。
　その後、担当は技術系のベテランに交代し、私はY2Kバグによるシステム障害の法的責任を検討する担当になりました。そして通産省が担当し、最後は官邸の問題になって、1999年にはワイドショーなどメディアに広くとりあげられるようになりました。

　当時の状況を知る参考になるかもしれないので、ここに再掲することにしました。

（追記）
　私は、本件業務を通じて、システム開発契約のデフォルトルールが民法では、何も決まらない。メーカーやベンダーの一方当事者のモデル契約では、商慣行というには弱い、建築業界の四会連合約款のような、ユーザ・ベンダ双方の業界団体で合意したモデル契約から、米国UCC２Bなどをモデルに商事特別法を作るところを目指すべきではないかと、問題提起をはじめたわけです。
　その後、ITアウトソーシングモデル契約を作る仕事や、人月単価による報酬ではなく、バリューベースド型の契約を志向すべきだと、北米調査でアメリカIBM等から資料をいただいて、サービスレベルアグリーメントの導入を提言する仕事をしておりました。その間はSOFTICの先生らに大変お世話になりました。

　その一部は、この書籍に反映されています。
　（社）情報サービス産業協会 法的問題委員会契約深い 編
　『新しいソフトウェア開発委託取引の契約と実務』（商事法務、2002年）
https://www.amazon.co.jp/dp/4785710101/

　その後は、経産省のモデル契約やSLAの取り組みにつながりますが、IT開発契約の商事特別法でデフォルトルールを整備していくまでには至っておりません。デジタル社会に向かう今日、再検討してみてもいいかもしれません。

　

------------------------------

西暦2000年問題の概要
1996.5

鈴木 正朝

初出：鈴木正朝「西暦2000年問題の概要」 JISA会報No.43 (社)情報サービス産業協会（1996年9月）
転載：鈴木正朝「西暦2000年問題の概要」 JASA Techno Board Vol.33 (社)日本システムハウス協会（1996年11月）
転載：鈴木正朝「特別企画 西暦2000年問題の概要」 電波新聞 1996年12月19日、 22～24面

目　次

１　西暦２０００年問題とは

1.1　定　義
1.2　「西暦２０００年問題」の概要
1.3　「西暦２０００年問題」が発生が予想される範囲
1.4　情報システム上の誤処理の具体例
1.4.1　過去に起きた誤処理
1.4.2　予想される誤処理
1.5　社会的な影響
1.5.1　産業社会全般への影響
1.5.2　行政情報システムへの影響
1.5.3　中小企業経営への影響

２　「西暦２０００年問題」の背景

2.1　「西暦２０００年問題」が発生した背景
2.1.1　欧米コンピュータ文化の継承
2.1.2　プログラム言語の規格準拠
2.1.3　ハードウェア資源の有効活用と処理速度向上の要請
2.2　「２桁年数処理」のプログラムが利用され続ける理由
2.2.1　資金的・時間的問題
2.2.2　ソフトウェア及びデータ資産の継承
2.2.3　旧システムの使用期間延長と仕様の継承
2.2.4　その他

３　「２０００年対応」の方法

４　「２０００年対応」を阻害する要因

4.1　ユーザー側の阻害要因
4.1.1　経営トップの認識不足
4.1.2　予算確保の遅れ
4.1.3　情報システム関連資産の管理状況の問題
4.1.4　開発現場における先送り意識
4.2　メーカー及びベンダー側の阻害要因
4.2.1　要員（対応できるソフト技術者）の絶対数の不足
4.2.2　要員確保（動員計画）の困難性
4.3　その他の阻害要因
4.3.1　サポートすべき責任主体の消滅（オフコンの場合）
4.3.2　その他

５　「西暦２０００年問題」の主要論点

5.1　ユーザーの主要論点
5.1.1　経営トップの「西暦２０００年問題」の認識と決断
5.1.2　対応予算（資金）確保の問題
5.1.3　その他
5.2　メーカー及びベンダーの主要論点
5.2.1 要員計画立案の問題
5.2.2　その他
5.3　全体の主要論点
5.3.1　需給ギャップの問題
5.3.2　企業間のインターフェースの問題
5.3.3　法務上の問題
5.3.3.1　ベンダーの法的責任
5.3.3.2　２０００年対応ビジネスの契約問題
5.3.4　２０００年対応を施すべきリソースの多様性の問題

６　業界団体の対応

6.1　ＪＩＳＡの対応
6.1.1　２０００年対応研究会の設置
6.1.2　講演会の実施
6.1.3　実態調査（アンケート）の実施
6.2　その他の団体の対応　（略）

７　行政への要望　（略）

=========　本文　============

１　西暦２０００年問題とは

1.1　定　義

(1) 「西暦２０００年問題」　
　西暦年を下２桁で表記していることに起因する情報システム上の誤処理、ならびに当該誤処理を直接の原因とする社会的な影響をいう。

(2) 「２０００年対応」　
　情報システムの「西暦２０００年問題」に関する調査・診断、保守、テスト等の対応作業をいう。

(3) 「２桁年数処理」　
　情報システムにおいて、西暦年を下２桁で表記し処理することをいう。

1.2 「西暦２０００年問題」の概要

　コンピュータ・システムの日付は、従来、yy／mm／dd（年／月／日）と「年」を下２桁で表記してい る。従って、西暦2000年以降の日付については「00」年、「01」年、「02」年....、で処理することを要求することになり、多くのコンピュータ は、2000年代か1900年代かの判断ができなくなる。その結果、日付に関係するソフトウェアやデータベース等を中心に誤処理が頻発し、情報システム全 体が正常に機能しなくなる危険性がある。

1.3　「西暦２０００年問題」が発生が予想される範囲

　メインフレーム、オフコン、ワークステーション、パソコンなどあらゆるレベルのハードウェア、マイクロコードからＯＳ、アプリケーションに至るソフトウェア、ファイルやデータベース等で問題が生じる可能性がある。

＊ 十数年前につくられたレガシーシステムだけとは限らない。２桁年数処理であるならばクライアント・サーバー・システム等分散型システムやパソコンのシステムについても同様の問題が生じ得る。

1.4　情報システム上の誤処理の具体例

1.4.1　過去に起きた誤処理
　2000年の日付を要求するケースは、2000年１月１日以降とは限らない。例えば、金融業界などでは、30 年間の利息や償還等をコンピュータによって計算している関係から、1970年代はじめにおいて、すでに「２桁年数問題」が発生している。このほかにも長期 の保険、自動車ローン等、「将来の日付（先の日付）」が要求されるソフトウェアは社会に多数存在しており、一部においては問題が顕在化していた。

　最近の例としては、有効期限５年間（2000年まで有効）の磁気カードが端末で認識できなくなり、カードの有効期限を４年間（1999年まで有効）に短縮して対応するといった事例等が報告されている。

＊ カードの発行量、端末の設置台数等を考えた場合、情報化の進展した今日における２０００年対応の費用は1970年代に比べ格段に増大している。また、多数の会社において同様の問題が発生した場合、社会に与える影響は計り知れない（社内問題から社会問題へ）。

1.4.2　予想される誤処理

　ハードやプログラム等環境によって異なり、まさにケース・バイ・ケースであるが、一般には2000年以 降の日付を指定することによって、日付をキーとした大小比較や期間計算結果等で誤処理が発生することが予想されている。具体的には、請求明細や支払明細、 利息計算、滞納処理等の誤処理、有効データの消失、日付の帳票印刷等での誤処理などが考えられる。
　例えば、次のような問題が発生する。

(1) 入力処理関係の誤処理＊
・日付が入力できなくなる。（例えば、「00」年と入力すると「過去日」や「未入力」もしくは「スペース」と判断され、入力不可となる。）
・2000年以降を範囲選択できなくなる。（例えば、日付をFROM－ＴＯで範囲選択する場合、2000年を選択するとFROM＞TOとなり入力エラーとなる。）
・正 しく日付を認識してくれなくなる。（例えば、西暦に、例えば65以下の数字を入力すると和暦として認識される。データベースのファイルは４ケタ対応でも、 入力が２ケタ対応の場合、自動的に「19」がセットされ、「00」年が「1900」年として認識される。最新のデータがデータベースの奥深くに格納されて しまう。）
・他社から送られてくる西暦データに自動的に「19」がセットされる、など。

(2) 出力処理関係の誤処理＊
・帳票出力処理で、西暦から和暦変換する際に、適切に変換されなくなる。（例えば、西暦2000年に平成-88年と計算され「平成88年」と表記される。）
・他社に送るデータの日付に「19」をセットしてしまう。（例えば、2000年4月3日に納入するように注文したつもりでも、1900年4月3日でデータが送られてしまう）など。

(3) 主処理関係の誤処理＊
・2000年代の新しいデータ（「00」年,「01年」,「02」年,....）が1900年代の古いデータ（「69」年,「70」年,...「99」年）以前のデータとして格納され、西暦順に正しく並ばない。
・日付（受注日、出荷日等）の処理順序に誤処理が発生する。ある日付以降に適用されるべき処理が2000年以降適用されなくなる。
・ある年以降のデータを抽出する場合、2000年以降のデータが漏れる。
満期日を待つデータ処理で2000年になると即満期日となる。
・西暦→和暦、和暦→西暦の変換ロジックに誤処理が発生する。
・古いデータを削除する処理で2000年代のデータが消える。
・期間計算（経過日数計算、稼働日計算、年齢計算、金利計算等）のロジックに誤処理が発生する。
・閏年計算ロジックに誤処理が発生する（2000年は閏年だが、年下２桁で1900年と判断した場合、閏年にならない）。
・日付の年を人名コードや注文No等に使用している場合、コード体系にも影響が及ぶことがある、など。

(4) その他の誤処理＊
・ＯＳ、言語プロセッサ、ＪＣＬ、ジョブネット関係等の誤処理
・基幹業務外のシステムでの誤処理
・他社の２０００年対応（４桁対応）によるデータ送受信の誤処理　など。
・その他、オフコン、ワークステーション、パソコン等ハード別、もしくはメーカーや機種別、ＯＳのバージョン別、アプリケーション別等様々な類型ごとに２０００年未対応による誤処理の例があるものと思われる。

＊以上、（株）レスキュー2000の資料を参照して作成。

1.5　社会的な影響

　２０００年対応を施していない情報システム（２０００年未対応システム）を放置した場合、社会にどのような影響を与えるか。
　２０００年未対応システムが社会のどこにどの程度存在するかによって、その影響度は大きく異なる。最悪の場合は、情報基盤の機能の一部が滞ったり、中小企業の多くのシステムが停止する等日本経済及び国民生活全般に影響が及ぶことが予想される。

1.5.1　産業社会全般への影響

　ネットワーク化が急速に進展している今日、情報システムが１社ないし１部門に閉ざされていることはもはや稀であり、多くのユーザー間において頻繁にデータのやりとりが行われている。トラブルは１社内だけにとどまらず、産業界全体に波及することが予想される。
　例えば、交通、物流、金融、通信など社会の基幹となる情報システムにおいて、２０００年未対応によるトラブルが起きた場合は、人、物、金、情報の流れ に少なからぬ影響を与えることになる。ことに大手企業の情報システムのトラブルは社内問題から社会問題へと発展することがあり得る。

1.5.2　行政情報システムへの影響

　税金、戸籍、公共料金等行政関連の情報システムの一部に２０００年に未対応のプログラムが残っていた場合、行政活動ないし公共サービスに影響を与えることも予想される。

1.5.3　中小企業経営への影響

　中小企業においては、資金的事情等から多くの２０００年未対応システムが放置されるのではないか、という問題も指摘されている。中小企業といえどもシステムを止め、手作業に戻ることは事実上不可能であり、システムの停止は営業活動ないし経営に深刻な影響を与える。

　２０００年対応は、基本的に情報システムの現状維持に過ぎず、ここでの情報化投資は経営効率の向上に直結しない。現在の経営環境下では、中小企業に過大な負担となることが十分に予想される。
　また、日本経済全体から見た場合、景気回復への活力低下の要因となりかねない。

＊ 中小企業の場合は、メインフレームよりもオフコンやパソコンの２０００年対応について問題になるものと思われる。

２　「西暦２０００年問題」の背景

2.1 「西暦２０００年問題」が発生した背景

　西暦年下２桁処理のソフトウェアが作成されるようになった背景として、大きく次ぎの３点を挙げることができる。

2.1.1　欧米コンピュータ文化の継承

　情報産業は、ハードウェア、ソフトウェアともに欧米文化の中で育成された背景がある。例えば、単位の表記にお いて、メモリの大きさはM（メガ）・K（キロ）byte（バイト）、長さはinch（インチ）、通信速度はbps、処理速度はMIPS等が用いられている。特に日付については、 mm/dd/yy形式等で表記したり、西暦年の下２桁で処理するのが一般的であった。西暦を「'96」のような省略形で表示する欧米文化をコンピュータの 世界に引き継いだものと思われる。日本はこうしたコンピュータ文化を継受してきた経緯がある。

2.1.2 プログラム言語の規格準拠

　ISO、JIS等のコンピュータ処理向けの規格においても当初の規格に関する仕様は年号を西暦の下２桁で扱うものが多かったという背景がある。西暦４桁が規格化されたのは、最近（1990年前後）のことである。
　例えば、COBOL言語は、1960年にCODASYLで言語仕様として制定され、1968年にANSIで、1972年にISOで、それぞれ「２桁年 数処理」の規格が制定された。その後、1989年になってANSI、ISOで西暦年を４桁で処理する規格が制定され、これを受けて1992年にJISでも 同様に西暦年の４桁処理が規格化（JIS X 3002）されたという経緯がある。２桁年数処理は、長らく世界的標準であった。

2.1.3　ハードウェア資源の有効活用と処理速度向上の要請

　コンピュータが普及してきた1960年代から1980年代当時は、ハードウェアが非常に高価であり、メモリ使用量やディスク使用量の削減、処理速度の向上は、ユーザー側、メーカー及びベンダー側ともに重要な課題の一つであったという背景がある。

2.2.2　「２桁年数処理」のプログラムが利用され続ける理由＊

　「２桁年数処理」のプログラムが現在もなお利用され続けている理由として大きく次の３点を挙げることができる。

2.2.1　資金的・時間的問題

　情報システムの急速な拡大によってユーザーのソフトウェア資産は急速に増加しており、それに伴ってシステムの一斉変更のコストも上昇し続けてきたという理由がある。つまり、資金的、時間的に困難であるという問題があった。

2.2.2　ソフトウェア及びデータ資産の継承

　初期に導入したソフトウェアが「２桁年数処理」の仕様であったことから、次世代のソフトウェアへの移行 に際して、２桁のデータ資産を如何に円滑に継承するか、という問題が生じた。この場合は、次世代のソフトウェアにおいても「２桁年数処理」の仕様を継続するという対応が一般的であった。
　なお、今日においてもデータの更新、追加によって２桁のデータ資産が増え続けているという問題がある。

2.2.3　旧システムの使用期間延長と仕様の継承

　実際のシステムを更新する場合、既存システムと互換性を持った新しいソフトウェアに順次変更していく方法がとられる。その際、一部のソフトウェアにおいて当初予想されていた使用期間を延長して使われるというケースが少なからず存在した。従って、新しいソフ トウェアも旧来の仕様を引き継ぐことになったという理由がある。

　ハード、ソフト共に急速な技術革新の中にあって、陳腐化の速度も著しい状況の中では、ソフトウェアが2000年まで使用され続けることについて、開発当時のユーザーもソフト技術者も想定していなかった場合が多いものと思われる。

2.3.4　その他

　企業間のオンラインないしネットワーク上のデータ交換に際して、西暦を下２桁で扱うことが標準化しているという現状においては、１社のみ４桁処理等の２０００年対応を行うわけにはいかなかったと考えられる。

＊（社）日本情報システム・ユーザー協会（JUAS）、（社）日本電子工業振興協会（JEIDA）、（社）情報サービス産業協会（JISA）の３団体（以下「３団体」という）では、平成８年５月に同趣旨の統一メッセージを公表した。

３　「２０００年対応」の方法

　２０００年対応の具体的方法は、ハードウェアや各種ソフトウェアごとに述べられるべきであるが、一般論として、４桁対応のみが唯一の方法ではなく「２桁年数問題」を回避すべき技術的方法はいくつか存在している。
　基本的には、次の２つの方式に大別できる。

(1) ４桁年化方式
　外部装置上も、データファイル上も４桁で表現する。
(2) ２桁年Window方式
　２桁という外部表現のまま、内部的なロジックで４桁に対処する。（ただし、100年を越えるデータは扱えない。）

　どのような方法を選択すべきかを考慮するにあたっては、まず、ユーザーのシステムがいかなる状況にあるか調査、診断することが必要となる。ベンダー側 としては、その上でユーザー側に対して、採りうる方法と料金、期間等を数パターン用意し、サービス・メニューとして提示していくことになると考えられる。 最終的には、ユーザーの判断において選択されることになろう。

４　「２０００年対応」を阻害する要因

4.1　ユーザー側の阻害要因

4.1.1　経営トップの認識不足

　情報化の進展は一方で情報システムのブラックボックス化という現象を招いており、経営トップの「西暦 ２０００年問題」の認識を妨げる大きな要因の１つとなっている。どのようなトラブルが発生し、どのような事態に発展する危険性があるのかについて事態の深 刻さを認識しておく必要があるが、経営トップにまで十分な情報が到達していないのが現状であろう。
　社内での関心度については、現在（社）日本情報システム・ユーザー協会（JUAS）と（社）情報サービス産業協会（JISA）においてアンケート調査を行っているところである（資料１「西暦2000年問題に関するユーザーアンケート」質問７参照）。

4.1.2　予算確保の遅れ

　ユーザーの情報システム部門において西暦２０００年問題を過小評価していること、もしくは、２０００年 対応という現状維持的な保守作業に多額の予算を請求することにためらいを感じていること、経営トップに説明する資料が不足していること、西暦２０００年問 題がそれほど社会問題化していないので説得する環境ができていないこと等の理由で社内における予算確保の動きが鈍っているものと考えられる。　　なお、過 小評価の例は次の通りである。

・一般的保守作業と同程度の対策で十分である。
・「平成」改元対応と同程度の対策で足りる。
・トラブルが発生したプログラムから順次対応すればよい。
・メーカーの対応を待てばよい。
・時間は十分ある、など。

4.1.3　情報システム関連資産の管理状況の問題

　開発当時の責任者、担当者が不明となっている、急速な情報化の進展による情報システムの肥大化等で情報 システムの資産を正確に管理しきれていない、といった問題がある。特に、開発時期が古いプログラムにおいては、仕様書・ソースコード等ドキュメント類の未整備・欠如といった問題が発生している場合がある。

4.1.4 　開発・保守現場における先送り意識

　日々の仕事に追われていて、手が回らない。社内の全システムに影響が想定され、現場だけでの着手が不可のため問題の提起を避けた。問題提起を積極的に行うことで２０００年対応の担当者になることは避けたい、などといった意識があることも指摘されている。

4.2　メーカー及びベンダー側の阻害要因

4.2.1　要員（対応できるソフト技術者）の絶対数の不足

　COBOL、PL/1、アセンブラ等の技術者は、一般に高齢化が進んでおり、他部門や管理職等への人事 異動、他産業への転職等、開発現場から離れる傾向にあり、絶対数が日々減少している。すでに開発言語の環境が変化した今日では新人の研修内容からも除外さ れている場合が多く、新たに供給されることも比較的少なくなってきている（COBOL、PL/1の技術者数については、ＪＩＳＡ「西暦２０００年問題にお けるベンダーアンケート」Ｑ４(1)参照）。

4.2.2　要員確保（動員計画）の困難性

　COBOL、PL/1、アセンブラ等の技術保有者は、一方で現在の開発環境に応じて新たな言語を修得し たり、責任者として様々なプロジェクトに関与している。従って、２０００年対応についてのみ優先的に振り向けることは困難である場合が多い（ＪＩＳＡ「西 暦２０００年問題におけるベンダーアンケート」Ｑ４(2)参照）。また、２０００年対応で動員した要員は、２０００年の経過によって行き場を失う。古い開 発言語中心の技術者で構成しているため、２０００年対応終了後の振り向け先に苦慮することは目に見えており、人事担当者ないしプロジェクト管理者の動員計 画は、非常に困難であることが指摘されている。

4.3　その他の阻害要因

4.3.1　サポートすべき責任主体の消滅（オフコン等の場合）

　オフコンやパソコンを取り扱う比較的小規模なディーラーないしベンダーの中には、倒産、転廃業によって現在、消滅し ているところがある。オフコンやパソコンの導入時における契約の相手方が消滅したことによって、サポートすべき第一次的窓口がなくなり、サポート体制が未 整備のまま放置されているユーザー（特に中小企業）の存在が予想される。
　こうした小口のユーザー企業の実態は捕捉し切れていないのが実状である。

4.3.2 その他

　ＯＳやＤＢ／ＤＣ等のソフトウェアでバーション・アップを控えていた場合には、２０００年対応を保証するバージョン まで引き上げることが必要になる。２０００年問題固有の対応作業の他にバージョン・アップによる一般的対応作業及びバージョン・アップによる派生的な作業 の増加が考えられる。

５　「西暦２０００年問題」の主要論点

5.1　ユーザー側の主要論点

5.1.1　経営トップの「西暦２０００年問題」の認識と決断

「西暦２０００年問題」の深刻さを如何に経営トップに認識させるか。
　各ユーザー企業の情報部門（担当責任者）において積極的に提言していくことが重要であるが、担当責任者自身が楽観視していること、不況期の現状維持的 投資であること、2000年の到来は当然のことだけに未対応であることが理解されにくいこと等の理由でユーザー内部における問題提起は概して低調である。
　メーカー・ベンダー側における啓蒙活動ないし広報活動を通じて経営トップ及びユーザー情報部門に充分な判断材料を提供していくことが重要であり、その効果的な方法が問題になる。

5.1.2　対応予算（資金）確保の問題

　２０００年対応のための予算（資金）を如何に確保すべきか。
　特に中小企業において深刻な問題となり得る。場合によっては、行政に対して何らかの対策を要望することが必要となる。
　また、資金確保の困難性を背景にユーザーとメーカー（ベンダー）間で２０００年対応の費用負担問題が発生する可能性も指摘されている。

5.1.3　その他

5.2　メーカー及びベンダー側の主要論点

5.2.1　要員計画立案の問題

　技術者を如何に動員し、２０００年対応終了後、如何に人事異動すべきか、要員計画の問題が指摘されている。

5.2.2　その他

　オフコン・ユーザーの２０００年対応のサポート体制を如何に構築すべきか。

5.3　全体の主要論点

5.3.1 需給ギャップの問題

　ＪＩＳＡの「西暦２０００年問題に関するベンダー・アンケート調査」（平成８年５月実施）の結果とＪＩＳＡ、 ＪＵＡＳ共同で実施する「西暦２０００年問題に関するユーザー・アンケート調査」（平成８年５月実施）の集計結果を待って、需給のバランスの状況がおおよ そ明らかになってくると思われるが、一般的に、２０００年対応における全作業量（のべ工数）と２０００年対応に動員できる技術者の総数（及び、のべ工数） を比較した場合、技術者の不足により２０００年以前に全ての企業について対応を終えることは困難であることが予測される。かかる需給ギャップを如何に解消 していくことができるか、が重要な論点になると思われる。

5.3.2　企業間のインターフェースの問題

　２０００年対応を施す手法は幾通りか考えられるが、各社がそれぞれの手法を選択することによって、企業間のデータ交換のインターフェースが不統一になることが予想され、電子商取引等を支える今後の情報基盤の環境整備に課題を残すことになる。

5.3.3　法務上の問題

5.3.3.1 ベンダーの法的責任

　ソフトウェアに西暦２０００年問題が発生した場合、ユーザーはベンダーに対して何らかの法的責任を追及できるか。ソ フトウェアが保証期間内であれば、瑕疵担保責任を追及できるか。また、保証期間経過後であれば債務不履行責任を追及できるか。もしくは、西暦２０００年問 題について不法行為責任ないしは製造物責任を追及できるかどうか等が問題になる。
　具体的には、次のような法的問題が発生することが考えられる。

(1) ユーザーは、２０００年対応のための調査・保守・テストを無償で行うこと、２０００年対応費用（の全額もしくはその一部）を負担すること、もしくは、ソフトウェア開発委託契約を解除すること、をベンダーに請求できるか。

　ユーザーが例えば２桁年数処理を指図していた場合はどうか。
　仕様書の通りに開発すれば、西暦２０００年問題が発生することを知っていたが、ベンダーがそれを告知しなかった場合はどうか。また、西暦２０００年問題についてベンダーとして知り得て当然であったのに気がつかずに告知しなかった場合はどうか。
＊当該ソフトウェアの使用目的、使用期間、時期（契約時、仕様書作成時、納入物の検査合格時、代金の受領時）、開発時の背景、料金の額、規格との関係（ＪＩＳ規格の４桁対応を定めた時期）等も問題になる。
(2) ２０００年未対応のソフトウェアを使用したことによる誤処理が原因で損害が発生した場合、 その損害もベンダーに請求できるのか。ベンダーが、西暦２０００年問題の存在について速やかに告知していれば、損害を最小限にくい止められたのに告知が遅 れたためにその分ユーザーの被害が拡大した場合はどうか。
(3) 当該ソフトウェアについて別途「保守契約」を締結していた場合、２０００年対応も当該保守の範囲となるか。
(4) 「アウトソーシング契約」の場合は、ベンダーが２０００年対応に要する費用を全額負担しなくてはならないのか。

5.3.3.2　２０００年対応ビジネスの契約問題

(1) ユーザーの情報システムの２０００年対応を受託する場合は、通常の保守契約等と同様の標準契約書を用いてよいかどうか、特に「ベンダー側の責任・保証の範囲」について検討しておく必要がある。
　例えば、次のようなことに留意しなければならない。

　実際上、年号関連のプログラムを完全に拾いきることは困難であること。
要員不足から充分な人材を投入できない状況であると考えられていること。
稼働中のシステムをテストすることが困難であること。特に2000年目前の駆け込み発注が多いと考えられ、充分なテスト期間を確保できないこと　等である。
　つまり、対応を施したとしても2000年経過後に何らかの誤処理が発生する蓋然性が高いということであり、 ２０００年対応の契約にあたっては、通常の保守契約ないし受託開発契約より，ベンダー側の責任・保証の範囲を限定する等の対処が必要となる（準委任契約と 構成する方法もある）。
　契約の内容については、ユーザー・ベンダー間で良く確認するよう努め、2000年経過後の紛争を予防しなくてはならない。

＊ ベンダー側のリスクが不当に拡大する場合は、２０００年対応に取り組むベンダー側の意欲が損なわれると同時にリスクの高さがコスト及びサービスの対価に反 映し、ユーザーの対応意欲もまた減退するということが考えられ、ビジネスの成立範囲が縮小すると共に社会全体の２０００年対応が遅れるおそれがある。ユー ザー・ベンダー（メーカー）間で適切な責任の範囲を確定しておくことが重要である。

(2) 対応を施したとしても2000年経過後に何らかの誤処理が発生する蓋然性が高いのであるから、2000年経過後の保守についてどうするか、費用負担の問題についても事前に確認しておく必要がある。

(3) ２０００年対応を施している最中に2000年が到来してしまった場合、すなわち履行遅滞の場合は如何に対処すべきかも事前に考えておくべきである。

(4) ２０００年対応ビジネスにおける料金体系についても問題が発生し得る。
　特に、２０００年対応にＯＳのバージョン・アップ等が伴う場合は、２０００年対応とＯＳのバージョンアップ等に伴う保守との切り分けが難しく、２０００年対応の料金体系についてユーザーの理解が得られにくいといった問題が発生する。　

5.3.4　２０００年対応を施すべき資源の多様性の問題

　ユーザー企業においては、１社で複数のメーカーのハードを利用するケースも多く、メーカーごとに２０００年対応の方針に違いがあった場合、対応作業の能率に大きな影響を与えると思われる。
　その他、ＯＳ、自社開発のアプリケーション・ソフト、第三者開発のアプリケーション・ソフト等多くの資源についてし かもそれぞれのヴァージョン等を管理しながらプロジェクトを進めていく必要がある。それぞれの資源ごとに対応すべき責任の主体と責任の範囲等を明確にして いく必要があることから、メーカー、ベンダー各社の自社製品（ハード、ソフト）の情報提供のあり方が重要になる。

６　業界団体の対応

6.1　ＪＩＳＡの対応

6.1.1　２０００年対応研究会の設置

　平成７年11月に２０００年対応研究会の設置を決定、12月に60社の参加を得て第１回２０００年対応研究会を開催した。同研究会の下に運営委員会を設置し平成８年１月より月１回のペースで開催、各種アンケートの設計と実施、講演会の企画、法的問題の検討等を行った。
　なお、２０００年対応研究会及び運営委員会は平成８年５月をもって解散し、平成８年度より「２０００年問題委員会」に発展的に改組することとなった。６月より委員公募を行い、７月より活動を開始する予定である。

6.1.2　講演会の実施

　平成８年３月25日、ＪＵＡＳと共催で、中央大学駿河台記念館において、日本電気㈱、日本ＩＢＭ㈱、日本ユニシス ㈱、㈱日立製作所、富士通㈱の５社を招き、講演会「メインフレーマの西暦２０００年対応について」を開催した（参加者350名）。なお、本講演会のプレゼ ン資料は、ＪＩＳＡニュース速報No.282（平成8年4月10日）号p.35～55に掲載した。

6.1.3　実態調査（アンケート）の実施

　２０００年対応研究会では、平成8年5月に「西暦２０００年問題に関するベンダー・アンケート調査」を実施、同じく５月にＪＩＳＡ、ＪＵＡＳ共同で「西暦２０００年問題に関するユーザー・アンケート調査」を実施した。

6.2　その他の団体の対応　（略）

７　行政への要望　（略）

資料　（略）
・JISA「西暦2000年問題に関するベンダー・アンケート調査」（平成8年5月）
・JISA、JUAS「西暦2000年問題に関するユーザー・アンケート調査」（平成8年5月）

-------------------
法的問題については、その後、「ベンダからみた西暦2000年問題と企業法務」法律のひろば1999年6月号（通巻52巻第6号）30-35頁を書いた。
https://note.mu/rompal/n/nc2bb676df52e
なお、この当時作った「西暦2000年問題とソフトウェア委託開発契約の契約責任（請負契約型）」の表はここを参照。
https://note.mu/rompal/n/n0f68604dbdcd