公表資料・広報活動

ホーム > 公表資料・広報活動 > 公表資料 1997年 > コンピューター2000年問題:金融機関および銀行監督機関にとっての課題(日本銀行仮訳)

コンピューター2000年問題:金融機関および銀行監督機関にとっての課題

(日本銀行仮訳)

1997年 9月 8日
バーゼル銀行監督委員会

G-10中央銀行総裁によるプレス声明

コンピューター2000年問題の解決に向けて

本日、9月8日バーゼルで開催された総裁会議において、G-10諸国の中央銀行総裁は、新世紀の到来に先立ち金融機関が全てのコンピューター・アプリケーションをチェックする必要性について討議した。修正・取替を要するアプリケーションは相当数に上るほか、修正後の円滑な稼働を確保するためには入念なテストが必要となる。金融市場の主要参加者は既に問題を十分認識し、行内対応を進めているが、未だ問題に対応していない先にとって残された時間は尽きようとしている。これ以上の対応の遅れはこうした先のみならずその取引相手にも高くつく可能性がある。

規模の大小、銀行・ノンバンクに拘わらず、金融市場の全参加者は、2000年1月1日に十分に先立って金融機関相互間の整合的なテストを実行できるよう、必要なアプリケーション修正を施し、その正常稼働を洩れなく検証するための具体的戦略を既に策定済みであるべき。本件は、単なる技術的な問題に止まらず、トップ経営陣の関心を要するものである。

金融市場参加者の規模・範囲の膨大さに鑑みると、2000年の1月1日に幾つかのアプリケーションが円滑に稼働しない可能性がある。したがって、全ての金融機関及び、特に取引所や清算機関といった取引・決済集中機関は、相手先との取引や支払の中断に対応するための適切なコンティンジェンシー・プランを策定することが重要である。

本件は、G-10総裁会議に報告するバーゼル銀行監督委員会と支払・決済システム委員会の2つの委員会に直接関係する重要な問題である。バーゼル銀行監督委員会では、銀行を対象にテクニカル・ペーパーを作成し、その中でシステム対応策の策定・テスト・実施のための戦略的アプローチを示すと共に、この問題の認識を高め、対応を促す上で中央銀行と他の銀行監督機関が果たすべき役割を明定した。バーゼル銀行監督委員会は世界の銀行監督機関と協力して銀行が適切な対応をとるよう奨励していく予定である。また、支払・決済システム委員会では、世界の支払・決済システムにおける2000年問題対応準備とテストの進捗状況に関する情報を掲載するBISインターネット・ホームページを、他の関連するG-10グループと協調して作成する予定である。

なお、バーゼル銀行監督委員会の上記ペーパーの原文はBISホームページ、http://www.bis.org/(外部サイトへのリンク)で閲覧可能である。

1997年9月8日

コンピューター2000年問題:
金融機関および銀行監督機関にとっての課題

  1. 「西暦2000年」は、金融機関に重大な課題を投げかけている。何故なら、多くのコンピューター・アプリケーションが、従来の日付フィールド処理方法では正常に稼働しなくなるためである。この問題に対する迅速な対応を怠ると、銀行が業務上の問題や場合によっては破綻にすら直面しかねず、金融市場が混乱する可能性がある。したがって、銀行は、問題や混乱を最小限に止めるよう必要な措置を採らなくてはならない。
  2. 本ペーパーは、中央銀行および他の銀行監督機関に対し、コンピューター2000年問題に関する参考資料としてバーゼル銀行監督委員会により起草されたものである1。本ペーパーは4つの部分から構成される。すなわち、まずIで問題の全体像を解説した後、IIで問題解決のため金融機関が採るべき措置を概観する。さらにIIIで問題を成功裡に解決するために取り組む際の主な留意点を論じ、最後に銀行監督機関が問題解決の一助となり得る方法を明らかにする。2000年問題に関するより技術的かつ詳細な検討は別添Aに纏められている。別添Bでは、アクション・プランの成功に結びつく要因を説明する。別添Cは、銀行が2000年問題対応を成功させるために必要な、幾つかのポイントを整理した簡単なチェックリストを示している。
    1. バーゼル銀行監督委員会は、1975年にG10諸国の中央銀行総裁会議により設立された銀行監督当局の委員会である。同委員会は、ベルギー、カナダ、フランス、ドイツ、イタリア、日本、ルクセンブルグ、オランダ、スウェーデン、スイス、英国および米国の銀行監督当局ならびに中央銀行の上席代表により構成される。委員会は通常、常設事務局が設けられているバーゼルの国際決済銀行において開催される。

I.2000年問題の全体像

  1. 銀行は、情報管理のためにコンピューター処理に大きく依存している。コンピューター・アプリケーションが正常に稼働しなくなった場合には、業務遂行が、不可能とはならないまでも困難となろう。2000年問題は、しばしば技術的な問題として捉えられているが、この問題に適切に対応しなかった場合の行内のあらゆる部署に与える影響度を考えると、本件は単なる技術的問題に止まるものではない。全ての管理者は、各部署が2000年適格であることを確保するよう積極的に関与しなくてはならない。経営陣は、この問題の戦略的重要性を認識するのみならず、行内の2000年問題対応計画と進捗状況を積極的にモニターしていく必要がある。
  2. 2000年問題は、銀行にとって単なる行内問題に止まらないため、特に取組みが難しい問題である。銀行は、コルレス先や顧客との間で多くのコンピューター上の接続関係や相互依存関係を持っている。多通貨を取り扱い、世界中の各国で様々な金融商品を提供している大手銀行にとっては、アプリケーションの多くが相互に依存しているため、特に問題が大きい。アプリケーションが全体として正常に稼働しない場合、重大な問題が生じかねない。銀行はこのような相互依存関係の全てに対処し、問題が発生しないようテストしなければならない。同様に、銀行は多くのアプリケーションについて外部のサービス・プロバイダーやベンダーに依存している。こうしたアプリケーションについても、各々を2000年適格とするだけでなく、各行の特殊な状況やアプリケーションのインターフェースに関して、その正常稼働を入念にテストしなくてはならない。
  3. 世界的規模での2000年問題解決を複雑にしているのは、世界の多くの市場・国々で状況が異なる点である。ヨーロッパ市場で活発な活動をしている金融機関にとって、euroの導入が稀少な技術的資源の競合的な需要をもたらしている。その他の市場では、新たな、または改良された金融取引・受渡システムが導入されようとしている。また、他の政策上ないしビジネス上の目的によって、技術的資源が金融部門からシフトしている国もある。金融部門内でも、銀行、証券会社、保険会社によって優先順位が異なる。こうした要因やその他の要因により、2000年問題に対する各金融機関の注意度は各行毎に大幅に異なってくる。
  4. 電子コンピューターの黎明期から、プログラマーは日付フィールドにおける「年」を2桁で表示していた(YY(年) MM(月) DD(日))。こうした仕様が標準となった1960年代には、2桁表示はコンピューターのメモリと保存容量を節約する点で経済的でもあった。1980年代には、当時開発していたアプリケーションが2000年入り後も稼働していると考える人は、殆んどいなかった。残念ながら、こうした考え方は誤っていたことが判明した。最近の新しいアプリケーションの多くは2000年適格となっているものの、適格アプリケーションが依存ないし相互依存関係にある多くの古いアプリケーションは、今後も稼働し続ける。また、アプリケーションの稼働が依存しているソフトウェア・ハードウェア環境は、2000年問題に対応していないかもしれない。いかなるアプリケーションであっても十分な分析・テストを行わずに2000年適格化済と考えるのは、重大なリスクを冒すことになる。
  5. 2000年問題は、日付やプログラムのロジックが修正されない限り、2桁の年表示が、多くのアプリケーションにおいて2000年ではなく1900年として認識されてしまうために発生する。この場合、多くの計算作業において、取引が約100年間期日不定の扱いとなったり、マイナスで表示されてしまう。新しいファイルが最新データとして認識されず、直近のファイルが消去されたり古いデータとして保存されることもあり得る。こうした様々な問題が、債権回収、情報の時系列化、金利計算等においてトラブルを引き起こす可能性があり、正常な業務運営を著しく混乱させかねない。また、日付が比較される計算の場合、顧客への請求書が請求から返金へと変わったり、またその逆の問題が発生するかもしれない。さらに、エレベーターや気温をコントロールするシステム等の建物に関するシステムも、維持管理や運行を円滑化する内蔵ロジックによって影響を受ける可能性がある。
  6. これらの全ての要因によって、2000年問題は厳しい課題となる。日付変更時に銀行業界がこの問題に対処し、深刻な問題の発生を回避できるかどうかは、個別銀行やより一般的には銀行業界が今から2000年までの間に実施する対応次第である。この問題への取り組みが遅れれば、コード修正、テスト、その他の変更全てが間に合わなくなるリスクを冒すことになる。1999年から2000年への移行は確実に到来するという問題の性質上、技術が関連する大半のプロジェクトとは異なり、事態の発生と対応策の完全実施を遅らせることはできない。

II.2000年問題対応に向けたアクション・プラン

  1. 2000年適格化を達成することが、複雑かつ資源投入を伴うものであることは、多方面で指摘されている。2000年までの時間は限られているが、世紀を跨ぐ日付変更が必ず起こる現実である以上、対応の延期はできない。詳細な対応策を策定し、目標達成のための資源を明らかにし、これを確保しなくてはならない。取組みが十分に進んでいない組織にとって、2000年問題はとりわけ難しい問題となるはずであり、より迅速に行動する必要があろう。全ての銀行は、自行およびそのコルレス先や顧客の2000年問題への対応状況を評価し、コンティンジェンシー・プランの検討を開始する必要がある。
  2. 2000年問題に対応するためには、全ての銀行がアクション・プランを持つ必要がある。こうした計画がどの程度複雑なものとなるかは、銀行の規模や、当該先が外部ベンダー、サービス・プロバイダーにどの程度依存しているかによって異なる。しかしながら、行内で開発されたアプリケーションを持たない小規模行でさえ、ベンダーや、チップを内蔵した機器・システムに対処する計画を持たなくてはならない。個々の組織は、自らの計画を策定する独自の方法を持っているかもしれないが、良いアクション・プランを考える際の一つの方法は、アクション・プランを以下の段階から構成されるものとして捉えることである。各段階における具体的行動は、別添Bに詳述する。

(a)戦略的アプローチの策定

  1. この段階には、行内の最高意思決定レベルにおいて2000年問題対応を戦略的目標として確立すること、銀行組織全体に戦略的目標を伝達するプロセスを構築すること、そして非常に高い経営レベルで2000年問題の経営資源面への影響を評価すること、が含まれる。
  2. 現時点では、銀行は本問題への対応に当たって、既にこの段階を十分に終了している必要がある。

(b)組織レベルでの認識を高めること

  1. 2000年問題の戦略的重要性が、経営上の目標として組織全体で確実に理解され、評価されるようにすることは、アクション・プランの最も重要な段階と考えられる。2000年問題が死活問題であることを認識するためには、経営陣が成功裡に問題を解決するため、経営戦略上の優先事項としてその対応に目にみえる形で関与するだけでなく、各階層のスタッフがその重要性を認識する必要がある。各部署の幹部は問題とそのインプリケーションを理解し、問題を共有する必要がある。責任の所在も明確にすべきである。この段階には4つの目的がある。すなわち、2000年問題対応の明確化を期すこと、対応の実施を確実にすること、所要資源を明らかにすること、部署レベルで具体的な戦略的目標を特定化すること、である。
  2. 銀行は自らの2000年問題対応プロジェクトにおいて、この段階も既に終えている必要がある。

(c)行動の評価および詳細な計画の策定

  1. この段階では、プロジェクトをコンセプトから具体的行動へと移すことになる。どのような措置が採られるべきかに関する詳細なリストが、集中型および分散型ハードウェア、ソフトウェア、ネットワーク、およびコンピューター・チップやロジックを組み込んだ機器を網羅して作成されなくてはならない。このリストには、各部署の行内、行外に関わる活動のあらゆる側面を網羅すべきである。リスクが定量化され、こうしたリスクに基づき優先順位が設定されるべきである。
  2. この段階を終了させる目標期限は国により区々であるが、多くの国において、1997年9月までに各銀行がこの段階を終了ないし概ね終了していることが期待されている。

(d)システム、アプリケーション、機器の修正

  1. 本段階は、唯一技術的な対応が中心となる段階である。この段階において、オペレーティング・システム、アプリケーション、ハードウェア、機器について必要な修正が行われる。コンティンジェンシー・プランを策定し、修正が遅延したり失敗した場合の代替的なアプローチを特定することが、本段階の重要な部分を占める。
  2. 現時点で銀行は、この段階にあるべきである。第3者とのテストが必要となる重要なアプリケーションの修正作業は、徹底的なテストを行うため、十分な時間的猶予をもって完了すべきである。2000年問題対応が進んでいる国では、この優先順位の高い作業を1998年央までに完了することを目標としている。また、こうした国々では、通常全ての修正作業を1998年末までに完了することを目標としている。

(e)テストを通じた修正の検証

  1. テストは、2000年問題対応プロジェクトにおける最大の作業である。詳細なテスト・スケジュールを策定し、コルレス先や顧客と調整しなくてはならない。行内や第3者とのデータ・フローは、データの送信側と受信側の双方が2000年の状況をシミュレーションしつつ、徹底的にテストしなくてはならない。
  2. 2000年問題対応が進んでいる国では、少なくとも大手先並びに全ての重要なアプリケーションについて、この検証段階を1998年末までに完了することを目標としている。全ての検証作業は1999年央までに完了すべきである。こうしたスケジュールに従う場合にのみ、十分な時間的猶予をもって全てのコルレス先と顧客が参加する業界を跨る広範なテストを1999年中に行うことができる。

(f)テスト後の適格化システムの実行

  1. 適格化システムの実行に当たっては、相互に関連したアプリケーションをそのリリース開始時期毎に調整する必要があるため、慎重な計画策定が要求される。また、この実行段階では、サービス・プロバイダーやベンダーによる進捗状況のモニターが必要となる。

III.留意点

  1. 2000年問題対応は、重要かつ複雑な案件である。各行が詳細な計画を策定する場合、特に留意すべき一連のポイントが浮かび上ってくる。こうした留意点のうちのいくつかについては、本ペーパーがこれまで2000年問題とその対処法を明らかにしてきた中で既に指摘してきたが、しばしば誤解されることが多く、また注意が不十分な場合もあるため、以下に詳述して強調する。

証明

  1. 2000年適格の証明は、多くの金融機関にとって繰返し浮上しては当惑させられる問題である。多くの金融機関、特に中小先は、ベンダーが特定の製品を2000年適格として証明すれば、心配がなくなるものと信じている。しかしながら、このような考え方には、2つの誤りがある。第1に、ベンダーによっては、実際は適格化されていないにも拘らず、自社製品を適格と説明する先がある。第2に、製品が適格であっても、それが金融機関固有の状況において正しく稼働し、他のアプリケーションと支障なく接続するか否かを、その金融機関がさらにテストしなくてはならない。少なくとも、関連部署による何らかのレベルのテストが、真の適格性を保証するために必要となるであろう。

ベンダーの管理

  1. 個別銀行にとって外部ベンダーは、監督・管理上の影響を及ぼし得る程度が限られているため、特別なリスクを惹起する。このため、銀行は、ベンダーの計画を明確に理解し、ベンダーの説明義務を確保する必要がある。ベンダーによって主要な目標が達成されない場合には、ベンダーを変更する、所要作業を行内で完了する、あるいはベンダーの失敗に対する他の調整策を実施する、等のコンティンジェンシー・プランを実行すべきである。

目標日

  1. テストのための目標日は、行内的にも対外的にも重要である。殆んどの金融機関は行内のテストの目標日を策定しているが、これを必ずしもコルレス先や顧客に積極的に連絡していない。有意義なテストは通例、行内テストと共に対外関係者とのテストを必要とするため、コルレス先や取引が頻繁な大手取引先とのテスト計画の調整は、金融機関にとって極めて重要となる。実際、優先順位や行内テストの目標日の設定は、対外テストがいつ可能となるかという点にある程度依存する。特に、大手行や決済システム、クリアリング・システムおよび同様のシステムにとっては、対外的インターフェースを有するアプリケーションのテスト計画に関する横の連絡が、業界全体の計画策定プロセスにおいて重要となる。
  2. 現在2000年問題対応がやや遅れている金融機関が、テストに関して意味のある目標日を連絡しなくてはならないとなると、ある種のジレンマに陥ることになる。すなわち、現時点で対外テストにつき確たる日付を連絡できない、あるいは遥か先の日付しか示すことができない場合には、金融界に対し当該先が2000年問題対応に遅れをとっていることを即座に明らかにすることになる。一方、許容可能であっても達成不可能と思われる目標日を連絡することは、目標が達成されない場合、信頼性に一層深刻な疑問を抱かせるリスクを冒すことになる。行内的にも、金融機関がテストやその他のプロジェクトの重要な目安として目標日の設定を検討する際には、世紀を跨ぐ日付変更は不可避なものであることを認識する必要がある。かろうじて適格化が図られるような楽観的な目標日の設定は、当該先にとっての現実の問題や論点を隠蔽しているに過ぎないと考えられる。

波及的な(spillover)ビジネス・リスク

  1. 波及的なビジネス・リスクとその可能性は、2000年問題対応の計画を策定する際にしばしば見過される点である。通常、金融機関はまず、適格化に必要な行内対応に焦点を当てる。しかし、2000年問題は顧客にとっての死活問題でもある。顧客が必要な調整を行わないと、当該銀行のビジネス機会の喪失や資産価値の損失を招く可能性がある。一方、強力な2000年問題対応プログラムを有していれば、当該先の準備体制を売込む戦略的機会が開拓できるかもしれない。いずれにせよ、与信担当および渉外担当は、2000年問題対応の進捗状況を常にフォローし、顧客が対応に失敗した場合ビジネス上起こり得る影響を推定し、適切なコンティンジェンシー・プランを構築するなど、顧客の準備体制について予め認識しておくべきである。

合併・買収

  1. 合併・買収は、統合された組織の稀少な技術的資源や経営資源に更に負担をかけることになるため、2000年問題への対応状況が考慮されるべきもう1つの分野である。吸収される金融機関の対応状況や、統合が2000年問題対応のための計画や行動、最終的にはその準備に与える影響を評価するため、2000年問題への準備状況に対し当然の注意をしっかりと払う必要がある。2000年適格化を引き延ばしている組織が他の機関を合併することは、極めてリスクが高いであろう。実際、合併という選択肢は、コンティンジェンシー・プランの中の1つのアプローチかもしれないが、時間が経過するにつれ、2000年対応がなされていない組織を合併し、世紀を跨ぐ日付変更前に必要な変更を行うことの実現可能性は低くなっていく。

衛星型オペレーションおよび海外取引

  1. 衛星型オペレーションや海外取引は、多くの金融機関に対し重大なリスクを与える。メインフレームやその他のアプリケーションを集中型情報システムの管理の下に統括することは比較的容易かもしれないが、集中型オペレーションには知られていない部門別アプリケーションの利用も急速に普及している。こうしたアプリケーションの多くは、リスク・モニタリングや取引決定上の不可欠な手段となっている。それらを特定し、その適格化を確保するには、特別な努力が必要となる。問題を回避するためには、各部署のあらゆる階層のスタッフに対し、2000年問題を認識させることが不可欠である。
  2. 同様に、海外におけるオペレーションや分散型オペレーションでは、その地域の市場取引や通貨固有のアプリケーションを利用している場合が多い。こうした拠点のスタッフは、2000年問題のような企業問題を本店スタッフと同レベルには意識していないことが多い。その結果、アプリケーション−−潜在的に重要なもの−−が2000年問題対応が必要なアプリケーションのリストに抽出されず、適切な対応がなされない可能性が高まる。

セキュリティ問題

  1. 2000年の危急性が高まるにつれ、セキュリティ問題が発生し、より切迫したものとなろう。コンサルタントやその下請けが、銀行システムや記録にアクセスする際にあまり厳密でない経歴チェックを受けることから、通常のセキュリティ・コントロールのレベルが緩和されてしまうかもしれない。また、テストを容易にする目的で、日付に依存したセキュリティ・アプリケーションの稼働を停止するかもしれない。さらに、内部接続問題の解決に終始するあまり、セキュリティ・コントロールに通常振り向けられる資源が流用される場合もあろう。

コスト管理

  1. コスト管理は、多くの金融機関に対し問題を提起している。特に、予算が十分であるか否かが問題となる。多くの先が、ベンダーによるバージョン変更、オペレーティング・システムの操作環境やアプリケーションの変更の際に、多くのテストを何回も実行すべきことを認識せずに、テストのためのコストを過少評価しているように見受けられる。また、各部署の幹部は、テスト負担の大部分が最終的には自らに降りかかってくる問題であることを認識していない場合が多い。
  2. 技術的資源の不足度も時間の経過とともに強まってくる。技術スタッフの給与が市場で競り上げられているため、金融機関は、既に主要スタッフの頻繁な入替えを経験しつつある。多くの機関においてこうしたスタッフ流出問題に対処するため、賞与や特別の慰留措置が用いられている。
  3. 外部コンサルタントの需要も同様に逼迫しており、コスト上昇につながっている。もっとも、問題は、コストのみならず、コンサルタントの質(技術および作業の完全性)や問題に直面した際の当該コンサルタントの信頼度である。こうした要因により、多くの先では、予算見積りを数倍ないし大幅に引き上げる必要性を感じている。

モニタリング

  1. 2000年問題対応の進捗状況のモニタリングは、全ての金融機関にとって最優先事項とすべきである。監査機能がモニタリングの過程において果たす役割が最高意思決定レベルにおいてはっきりと定義され、前向きなものとして明確化されるべきである。監査役からの異議については、注意深くかつ的確に事後フォローすべきである。2000年問題対応の進捗状況をモニターするため特別な管理体制を確立し、上級幹部および役員は、当該機関の最優先事項の1つとして定期的に進捗状況をモニターする必要がある。

潜在的なシステミック問題

  1. 潜在的なシステミック問題を明らかにする必要がある。2000年問題は、同問題を乗り切れない先にとってのみ問題が発生するものではない。大手行や、他に代替のきかないサービスや製品を提供することによって、銀行業界全体をサポートしている業界内のインフラ提供先において、決済が予想どおりにうまくいかなかった場合には、ある一先で発生した問題が急速に他へ影響を及ぼす可能性がある。決済の連鎖関係における潜在的に脆弱な相互依存関係をできるだけ速やかに明らかにするとともに、適切なコンティンジェンシー・プランを必要に応じ策定・採用する必要がある。
  2. 非常に規模の大きい顧客や顧客層がビジネスを遂行できなくなる場合には、システミックなインプリケーションを持つ信用問題が生じる可能性がある。この場合、債務が履行されず、担保価値が急落するかもしれない。2000年問題による信用問題がもたらすシステミックなインプリケーションが顕現化するまでは、やや時間がかかるかもしれないが、これは紛れもない現実の問題である。

外部監査法人および公表報告書

  1. 金融機関の中には、外部監査法人および公表ベースの報告書での扱いをどうするかが今年度末に問題となる先もあろう。米国等の国々では、2000年問題の修正コストを、それが発生した年に報告しなければならないとの会計方針が既に決定されている。企業会計の専門家は、「当該コストを特別費目として公表すべきか否か」について引続き議論しているが、「重要な業務やアプリケーションの2000年適格化が不可能な先は、こうしたリスクを会計報告書に特記する必要がある」旨のコンセンサスが得られつつある。但し、どの時点でこうした情報公開が開始されるべきかについては、まだ確定していない。

IV.銀行監督機関の役割

  1. 銀行監督機関が自ら2000年問題を解決することは、明らかに不可能である。本件は金融機関自体が解決し得るのみである。しかしながら、銀行監督機関は様々な方法で2000年問題対応において建設的役割を担い得る。

注意喚起

  1. 2000年問題について注意を喚起することは、おそらく銀行監督機関の果たし得る役割のうちで最も単純かつ効果的なものである。事実に基づき注意深くバランスをとった警告やその他の公告を発出することによって、問題の深刻さを明らかにすることは、多くの国で成功裡に実施されている。こうした公告には、いかにして各行が効果的に本問題に対処できるか、有益なガイダンスが含まれているケースもある。また、業界団体や個別行との直接的なコンタクトにより、上級幹部の注意喚起を促すこともできる。

業界に対する目標・目安の設定

  1. 業界に対する目標や目安の設定も、2000年問題対応の進展を確実にするために役立つ方法である。異なる市場環境が示すように、こうした目標は国により異なるが、銀行監督機関が明確な期待を持つことは、金融機関が独自の対応を策定することに役立ち、対外テストの機会を増やしていく。自国金融機関に対し、既にこうした目安を提示している国もある。

業界全体の現状評価

  1. 業界全体の2000年問題対応の現状を評価することも、有益であろう。銀行監督機関は、各金融機関の進捗状況を把握できる唯一の立場にある。特定の地域やある種の金融機関に問題が起こりつつある場合、進捗状況の全般的レベルに関して賢明かつ幅広い観察がなされていれば、こうした先における2000年問題対応プロジェクトへの資源の再配分を促すことになるかもしれない。

前向きな監督指導

  1. 特定の問題や金融機関に対して前向きな監督指導を行うことは、銀行監督機関が利用できる最も強力な手段である。自行のアプリケーションの適格化を図ることができるのは当該銀行のみであるが、銀行監督機関は、様々な監督手段によって各行における2000年問題に対する注意度のレベルを高めていくことができる。監督機関のあらゆる努力にも拘らず、銀行や銀行グループが重大な問題を抱える可能性がある場合には、銀行監督機関は、こうした事態に対処すべく、如何なるコンティンジェンシー・プランが必要かを検討する必要がある。

V.要約

  1. 2000年問題は、金融業界がかつて直面した問題の中で、潜在的には最大の課題となるものである。コンピューター・チップ内蔵機器を含む全てのコンピューター・システムが潜在的なリスクに晒されていることから、2000年問題の影響を分析し、必要に応じてこれらの修正・取替を行う必要がある。スケジュールが流動的で、問題に直面した場合に先送りが可能な大半の機械化案件とは異なり、2000年問題対応では、期限を延長することなく全ての重要な修正対応が直ちになされなくてはならない。資源と時間的制約から、さほど重要でないいくつかのアプリケーションの修正ができない場合、その対応繰り延べの影響を徹底的に分析しなくてはならない。さらに、個別アプリケーションへの対応完了後には、テストを実施しなくてはならない。現在は、アプリケーション間の接続関係が広域に及び、金融機関間の相互接続が盛んな時代にあるため、新たに部分的な適格化が進む都度、テストを繰返す必要があることから、テスト過程が膨大なものとなる。戦略的な優先課題として、2000年の日付変更に未だ取組んでいない先は、本問題に直ちに焦点を当てる必要がある。

1997年9月

以上

別添A 2000年問題の詳細

原因と影響

  1. 電子コンピューターの黎明期から、プログラマーは日付フィールドにおける「年」を2桁で表示していた(YY(年)MM(月)DD(日))。最近の新しいアプリケーションの多くは2000年適格となっているものの、適格アプリケーションが依存ないし相互依存関係にある多くの古いアプリケーションは、今後も稼働し続ける。いかなるアプリケーションであっても、十分な分析・テストを行わずに2000年適格化済と考えるのは、重大なリスクを冒すことになる。
  2. 本問題をさらに複雑にしているのは、「このファイルは永久に保存・保管すべきである」といった何らかの特殊処理を示すため、特定の意味を持たせて「99」という数値を年フィールドに入力しているような場合の問題である。こうした場合、アプリケーションによっては、2000年以前にも誤作動を始めるものがあり得る。これは例えば、1999年の記録は特殊ファイルとして扱われ、通常とは別に処理されるためである。さらに、全てのプログラムは、2000年の閏年が正しく処理されるかを確認する必要があろう2
    1. 2現行のカレンダー慣行では、「00」で終わる年は、4で割り切れるにもかかわらず、一般には閏年とはならない。但し、この例外が当該世紀を表わす数が4で割り切れる場合である。したがって、2000は閏年を決定する際の例外の中のそのまた例外となる。
  3. 現行のアプリケーションやデータベースを修正する方法は必ずしも1つではない。最も一般的な方法を2つ挙げると、年フィールドに2桁追加する(CC(紀)YY(年)MM(月)DD(日))か、ウィンドウ手法という技術を用いて2桁の年フィールドを分析し、ある特定の数字(例えば60)未満の年を20yyとして自動的に認識する一方、それ以上の数字の年は19yy年として認識するように設定することである3。この他にも、特定のアプリケーションに対応するため、永久的ないし一時的解決策として適切なものもある。
    1. 3仮に日付の範囲が100年以上に及ぶ場合(例えば誕生日がデータベースの一部である場合)、ウィンドウ化手法は現実的な解決策とはならない。
  4. アプリケーションは、あらゆる業務分野−−フロントオフィス、バックオフィス、顧客受渡システム、経営情報および意思決定サポートシステム−−に影響を及ぼす。アプリケーションは、多くの場合互いに関連しているため、全ての相互依存関係を明らかにし、連鎖関係における1構成部分が修正される都度、徹底的にテストを行わなくてはならない。
  5. 適切な修正実施は、複雑な作業である。置かれている状況に応じて、様々な解決策が要求される。2桁追加は必要とされるメモリや保存容量に影響を与えるほか、大容量の記録処理パフォーマンスに影響を及ぼし得る。一方、ウィンドウ手法は、日付が現れる都度付加的な計算を要し、処理パフォーマンスに影響を与える可能性がある。いずれのアプローチも、アプリケーション間の連動状態に影響を与える可能性がある。例えば、4桁の年表示が選択される場合、2桁表示だけを受付けるアプリケーションとの間で正しい通信を確保するために、更なる修正が必要となろう。アプリケーションが2000年適格に修正される都度、連動している他の全てのアプリケーションとの関係もテストを行わねばならない。こうしたテストは、行内のみならず、相互依存関係の正常稼働を確保するために、コルレス先や顧客との間でも行わなくてはならない。適格アプリケーションの修正は次々と実行されるため、テストは連続的に繰返し実施されるであろう。

影響の及ぶ範囲

  1. 2000年問題の潜在的影響は、事実上金融機関のあらゆる部署に及ぶ。日付に依存するアプリケーションは明らかに脆弱である。しかしながら、一見日付に依存していないと思われる多くのアプリケーションも、ファイル名の仕様など日付がキーの一部となっている場合等、しばしばユーザーにはそれとは分からない方法で日付を利用している。日付が用いられているのであれば、必ずそれを特定し、適格性を判断して必要に応じて適切な修正を行わなくてはならない。
  2. 全てのアプリケーションは、行内開発か外注かを問わず2000年問題に対し脆弱である。第3者によって開発されたアプリケーションは、必要な修正を行うのに他者に依存せざるを得ないため、特に脆弱であるかもしれない。2000年問題対応の修正後、銀行はアプリケーションが独自の環境下で正常に稼働することを確認するために、テストを行わなくてはならない。ベンダーのアプリケーションは、当該アプリケーションが依存しているオペレーティング・システム(OS)やユーティリティの最新ないし少なくとも最近時のバージョンをほぼ常に必要とするため、テストは不可欠である。銀行がOS等の最新バージョンを用いていない場合、適格アプリケーションが正常に稼働しない可能性がある。
  3. コンピューターのOSにおいては、ユーザーから見えにくいファイル維持管理やパフォーマンス最適化の仕組みの中で日付が重要な役割を担っているため、問題が発生しやすい。また、アクセス管理やセキュリティ・システムも2000年問題の影響を受けるため、ユーザーは、論理的にはコンピューター・アプリケーションから、また物理的にも建物や各部局の職場から、それぞれ締め出されることにもなりかねない。
  4. ハードウェアも影響を受ける。メインフレームは、各構成部分の製造年が大幅に異なるうえに、構成部分のひとつが不適格化なだけでもシステム全体に影響を及ぼし得るため、特に脆弱である。小型コンピューターやパソコンも影響を受ける。ATMや通信設備には日付管理が組込まれているが、これを特定してテストを行い、必要に応じて修正しなくてはならない。
  5. 行内通信ネットワークや公共媒体には、日付に敏感な構成部分が多い。全ての問題を明確にし、その適格化を確保するためには、アプリケーションとネットワーク媒体の双方について、注意深く計画されたテストが必要となる。環境システムやその他のシステム(空調、エレベーター、金庫、ファックス等)にも、日付に敏感なソフトウェアや、隠れた所に日付に敏感な部分を含むコンピューター・チップを内蔵したハードウェアがあるかもしれない。

リスクとコスト

  1. 必要な全ての修正作業やシステムの完全なテストを行わない場合には、重大なリスクが存在する。事務処理リスクの存在は明らかである。処理量が大量で情報交換が広範囲に亘る場合、正常に稼働するコンピューター・システムを欠くと、手作業などの代替手段が使えない可能性があり、単純な業務機能でさえ完了できないかもしれない。
  2. いかなる事務処理上の問題も、コルレス先や顧客が取引上の問題として反応すると、即座に評判の面でのリスクや法的なリスクとなる。大規模な銀行が問題に直面すると、そのシステミックな影響は広範囲に及び得る。コンサルタントの見積りによると、問題が業界に広まった場合の法的コストだけでも数千億ドルにも及ぶ可能性がある。このような見積りは、銀行やより一般的には業界全体が直面する戦略的リスクの大きさを明確に示している。
  3. コルレス先や顧客も2000年問題に左右される以上、こうした先も通常通りに業務を遂行するために所要の修正作業を行わなくてはならない。コルレス先や顧客との通常の接続・メッセージ交換テストは必須であるが、それだけで十分ではない。また、これらの先が自らのシステムについて所要の修正を行っていない場合、銀行に対する信用リスクや流動性リスクが惹起されかねない。与信担当者は、自らの顧客が直面する2000年問題のリスクや、顧客がこうしたリスクをどの程度十分管理しているかを理解する必要がある。健全な2000年問題対応策を策定せず、また対応策を実行するための適切な資源を割当てていない組織にとって、現在の財務パフォーマンスは将来のパフォーマンスの証左とはならない。
  4. 銀行業界が2000年問題に対応するために必要となるコストは、莫大である。ガートナー・グループは、所要の修正とテスト実施のコストだけで、全世界で3千億〜6千億ドルを要するという見積りを公表した。あらゆるプログラムの一行一行を、通常一行当たり約1ドルという見積りで見直しを行う必要がある。世界規模の銀行にとって、コストはしばしば数億ドルと推定されている。自行で開発したアプリケーションが殆どない中小銀行においても、他行の修正したアプリケーションを完全にテストするためには相当なコストがかかるであろう。
  5. 熟練した技術的資源は既に少なくなっており、期限が近づくにつれてさらに稀少となるであろう。ある種のスペシャリストの給与は既に上昇しつつあり、主要なスタッフが他社からスカウトされている。評判の高いコンサルタントが重用され、彼等には極めて限定的な新規顧客しか受け容れられていない。時間の経過につれ、銀行は、具体的なパフォーマンスの証明がほとんどない、または全くないような見通しの立たないコンサルタントを利用せざるを得ないであろう。
  6. テストのファシリティも問題である。2000年の日付を用いた実地テストを行う環境を確立するのは簡単ではない。可能であれば、専用システムを利用するべきである。代替手段として、開発用システムを閉鎖し、これを2000年問題のテスト用に再構築することも考えられるが、OSについて将来の日付を巻戻す(例えば、20xx年から19xx年に戻す)作業は、多くの場合、困難かつ時間がかかるプロセスとなるため、こうしたアプローチは重大なリスクを発生させる可能性がある。また、テストを行うための週末や祝日の日数も徐々に減少していく。第3者のサービス・プロバイダーからのコンピューター借用は可能だが、コンサルタントのケースと同様、第3者の資源は急速に予約されていく。
  7. また、テストについても、通常と比べてより困難なものとなろう。第1に、テスト環境に対する競合的な需要が発生するであろう。euro関係や、金融取引における分数から小数への移行のための新アプリケーションは、現在の環境でのテストが必要である。しかしながら、こうしたアプリケーションの重要性や、2000年適格化のテスト実施の必要な他のアプリケーションとの相互依存関係を考えると、現在及び2000年時の双方の環境でテストを行う戦略を構築する必要がある。テスト・データは特別に開発する必要があろう。テストは基本的に各部署で行われる業務であるため、該当部署の資源はかなり逼迫したものとなろう。
  8. 2000年問題対応は、アプリケーションにおけるその他の保守やソフトウェア変更と合わせて行い得ないという点で、非常に複雑な問題である。トラブルに直面した場合、その原因が2000年問題なのか、その他の変更なのかを見極めることは、極めて難しくなることもあり得る。多くの組織では、問題を突き止める際の困難を最小化するため、2000年問題対応がなされるまで、他のプロジェクトを凍結している。もっとも、こうした凍結は、おそらく長期的には現実的ではなかろう。

以上

別添B 2000年問題対応に向けたより詳細なアクション・プラン

戦略的アプローチの策定

  1. 第一段階は、個別金融機関が各々の組織内で、如何にして2000年適格化を最適に実現するかを結論付けることで、適切な戦略的アプローチを確定する局面である。この段階には、皮切りとなる役員レベルでの問題検討と、2000年問題対応プロセスを組織全体に最適な形で導入するための計画作りが含まれる。この段階は、情報システムや情報技術がどのように配備されているのか、各々の業務単位がどのように組織され、関連部署とどのような相互依存関係にあるのか、といった点に関する技術者の知識に大きく依存することが多い。この最初の計画段階で特に注意を払う必要があるのは、組織内部の問題認識を高める次の段階で、各部署が2000年問題を単なる技術的な問題ではなく戦略的な問題として認識し、最終的には自らの問題であることに関する理解の深化を確実にすることである。

組織レベルでの認識を高めること

  1. 2000年問題の戦略的重要性を、行内全体で経営目標として理解し認識することは、アクション・プランにおける最も重要な段階である。この段階には4つの基本的な目標がある。すなわち、2000年問題対応の明確化、対応の実施を確実にすること、所要資源を明らかにすること、部署レベルで具体的な戦略目標を特定すること、である。
  2. 組織全体で2000年問題対応を明確化することは不可欠である。全ての役職員が2000年が提起する潜在的な問題を認識し、問題の対象になりうるアプリケーションに注意を払わなければならない。こうした取組み方によってのみ、分散型も含めた全てのアプリケーションが洗い出され、適切な対応が実施されるであろう。
  3. 2000年問題が企業にとって死活問題であることを認識するためには、経営陣が、問題を成功裡に解決するために戦略的優先事項として関与していく必要がある。役員・幹部は、問題とそのインプリケーションを理解し、進捗状況を定期的にモニターする必要がある。この問題に対する具体的な管理責任を明確に定めるべきである。大手先では、2000年問題に専念する担当部署の創設が望ましい。各部署の管理者が、2000年問題対応を成功裡に終えるための最終的な説明義務があることを、明確に認識すると共に、技術スタッフと各部署の協力関係が築かれなければならない。
  4. 5.2000年問題対応に必要となる経営資源を見積り、予算に計上しなければならない。各部署は、プロジェクトの中でテストが最も経営資源の投入が必要な段階であること4 、テストを計画し、それを実行する責任はビジネスに関わってくるものであることを、認識しなければならない。幹部職員は、2000年適格化の実現について、通常の業務や予算内で達成できることは稀であることを認識しなければならない。2000年問題は、行内のアプリケーション全てについての対応を要するが、一定水準の所要メンテナンスや新規開発をも行う必要があることが多い。
    1. 4コンサルタントの推計によれば、テストは2000年問題対応に必要なコストの45〜70%を占める計算。
  5. 技術部門と各部署の人材再配置も実施する必要があるため、経営戦略上の対応方針決定はこの段階で行わなければならない。アプリケーションについては修正、取替、外部委託および廃棄の選択肢がある。このような決定を行う際、役員レベルの指導が重要である。

行動の評価と詳細な計画の策定

  1. プロジェクトをコンセプトから具体的な行動へと移すのがこの段階である。どのような措置が採られるべきか、その詳細なリストが集中型および分散型ハードウェア、ソフトウェア、ネットワークおよびコンピューター・チップやロジックを組み込んだ機器を網羅して作成されなければならない。各部署レベルで開発ないしは調達されたアプリケーションも、当該リストに盛り込むよう特に注意を払う必要がある。このリストは、各部署の行内、行外に関わる活動のあらゆる側面を網羅すべきである。リスクが定量化され、こうしたリスクに基づき優先順位が設定されるべきである5
    1. 5リスクの測定や優先順位決定の手続きは極めて重要である。何故ならば、金融機関によっては、経営資源の限界やその他の避け難い問題から、世紀を跨ぐ日付変更時に幾つかのアプリケーションが2000年適格化されていないこともあるからである。
  2. 技術スタッフと各部署の行内協力体制が強化されなければならない。各々の責任を明確にしたうえで、作業日程に関する合意が必要である。スケジュールの進捗管理の手続は、役員・幹部に定期的に十分な情報が行き渡るよう行うべきである。
  3. 2000年問題対応におけるベンダーやサービス・プロバイダーの位置付けと計画について、それらの業者と連絡を取り、適宜契約を締結する必要がある。ユーザー・グループは、こうした連絡や情報収集の面で有益であるが、同グループは入手情報を踏まえて最後まで作業を代行するものではない。アプリーションは当該銀行独自の運営環境の中で機能しなければならず、適切なテストが行われているか否かを判断する責任を、ベンダーやユーザー・グループに委託することはできない。現行バージョンのソフトウェアやOSの導入を確保することは特に重要である6 。何故なら、旧バージョンの環境下では2000年適格のアプリケーションが正しく稼働しないこともあり得るためである。
    1. 6機器やソフトウェアの一部または全部に関するメンテナンス契約を持たない組織では、バージョン変更に関する諸問題への対応のために、2000年適格化に必要な経営資源が増大する可能性がある。
  4. 2000年問題プロジェクトでは、一貫してベンダー管理に特に注意が必要であり、これを継続的に行わねばならない。ベンダーが、虚偽の説明による法的責任を懸念するため、製品のリリース、テスト、その他の目安となる事柄について、彼等から意味のある期日を提示してもらうことは極めて難しいのが通例である。こうした困難はあるが、ベンダーとの有効な連絡体制を作ることは不可欠である。
  5. 評価の段階においては、幾つかのアプリケーションの2000年適格化を前倒しで行うことも可能であろう。こうしたパイロット・プロジェクトは、所要の作業に対するスタッフの理解を深め、より良い計画と予算の策定にも役立つ。また、アプリケーションの中で、日付部分を探し出す自動検出ツールについてもその有効性をテストすべきである。
  6. 本段階には、法的義務の見直しも含まれるべきである。特に、ベンダーやサービス・プロバイダーとの契約を、銀行と外部ベンダーの各々の責任の観点から見直すべきである。また、様々な状況でトラブルが発生した際に、2000年問題がどのように扱われるのかに関して、保険契約上の扱いを検討する必要がある。
  7. 評価段階で最終的に行うべきことは、プロジェクト全体の詳細な計画の策定である。この計画では、必要な修正作業のみならず、主要な期限、テスト計画、連絡体制についても定める必要がある。また、計画では、集中型、分散型を問わず、行内で開発されたアプリケーション、サービス・プロバイダーやベンダー、コルレス先や顧客との関係を取扱う必要がある。さらに、計画における各段階の責任、及び説明義務を明確にしなければならない。さらに、共同テストが必要となる多くの相互依存関係を認識し、計画全体の最も重要な柱を決定しなければならない。

システム、アプリケーション、機器の修正

  1. システム、アプリケーション、機器の修正はアクション・プランの各段階の中で唯一技術的な対応が主となる段階である。プロジェクトのために追加的に必要となる経営資源は本段階で確保または契約されなければならない。修正の必要なOS、アプリケーション、ハードウェアおよび機器は、修正、取替、外部委託ないし廃棄されなければならない。この段階においては殆んどの先で、自動検出ツールや外部コンサルタントが期待された役割を果たすことであろう。
  2. 本段階では、ベンダーとの綿密な連絡や、ベンダーの作業進捗状況の注意深いモニタリングが行われる。特に、ベンダーの言う「2000年適格」が何を意味するのかを明確に理解する必要がある。このことには、稼働環境と予定されている情報伝達プロトコルの変更に対する深い理解も含まれる。また、問題が表面化したときに、どの程度のサポートをベンダーから受けられるかについて、合意がなされなければならない。銀行はベンダーに保証や証明を要求したり、それらがベンダーから供与される場合もあるが、そのような証明は他のアプリケーションとのインターフェイスについてまではカバーしないのが通例であり、テストが不要とはならないことを認識しなければならない。
  3. 修正が遅れたり、失敗したときのための代替策を確定することも、この段階では重要である。ここでも、こうしたコンティンジェンシー・プランにおいて、行内の修正作業だけでなく、ベンダーやサービス・プロバイダーの作業、コルレス先や顧客など、当該銀行のシステムが接続されている先の対応が組込まれていなければならない。コンティンジェンシー・プランは、進捗状況を測るための重要な目安や、目標未達時に代替策への切替決断を行うべき期限を、含まなければならない。2000年が刻々と近づくにつれ、全てのアプリケーションの修正を実施することは不可能となってくるため、コンティンジェンシー・プランはアプリケーションの優先度を考慮しなければならない。さらに、幾つかのケースでは、コルレス先との関係が変更されたり、顧客との関係が悪化する可能性があることも、コンティンジェンシー・プランの中で認識されている必要がある。

テストを通じた修正の検証

  1. テストは、2000年問題プロジェクトにおける最大の作業である。週末のテスト機会は減少していくことから、詳細なテスト・スケジュールを策定し、コルレス先や顧客との調整を行わなければならない。2000年適格であることを完全に検証するためには、テストの全要素について2000年のデータ環境に基づいたシミュレーションが実行されねばならない。行内および第三者との間のデータ・フローは、データの送信側と受信側の双方が2000年の状況をシミュレーションしつつ、徹底的にテストしなければならない。銀行は全ての取引量をシミュレーションして行うサービス・プロバイダーとの相対テスト、ないし複数ユーザー間テストの双方に参加する必要がある。特定の期限までの修正作業が完了後、必要に応じてコンティンジェンシー・プランを実行に移す必要がある。
  2. 本段階では、新規もしくは修正されたアプリケーションの正常稼働を支援する仕組みも、整備しなければならない。特に、作業マニュアルを作成ないし修正して配付するほか、研修プログラムの提供、ヘルプ・デスクの設置・再教育が考えられる。

テスト後の適格化システムの実行

  1. 適格化システムの実行に当たっては、相互に関連したアプリケーションをそのリリース時期毎に調整する必要があるため、慎重な計画策定が要求される。調整はインターフェイス部分のファイルのフォーマットが変更される場合に、特に重要となる。調整の必要性を認識する一方、2000年適格のアプリケーションを可能な限り早期にリリースすれば、将来のテストがより簡素化される。
  2. 本段階では、サービス・プロバイダーとベンダーの作業進捗状況をモニターすることも必要である。特にサービス・プロバイダーは、適格化システム実行の様々な段階の銀行のニーズに対応するために、常時2つ以上のバージョンのアプリケーションを保有することとなろう。
  3. 本段階では、必要に応じコンティンジェンシー・プランに立ち返ることも考えられる。

以上

別添C 2000年問題対応に成功するためのチェック・リスト

2000年問題対応に成功するためには、銀行は幾つかの重要なポイントを認識し、適切な対応を採ることが必要である。こうしたポイントとしては以下のものがある。

  • 経営陣が問題を理解し、戦略的優先事項であると了承すること。
  • 単に技術的な問題ではなく、ビジネスの存続に関わる問題であることを各部署が認識すること。
  • 2000年問題対応プロジェクトにおける責任を明確に割当て、その遂行に必要な権限を付与すること。
  • 2000年問題対応の過程の中で、テストに最も経営資源が必要となることを認識した上で詳細な計画を策定すること。
  • 外部とのテストが、2000年問題対応の過程の中でも最も難しい部分になる可能性がある点を認識すること。
  • 外部のベンダーやサービス・プロバイダーが、自行のアプリケーション、機器および稼働環境のもとにおける自社製品の正常稼働を、必ずしも保証出来ないことを認識すること。
  • 外部ベンダーやサービス・プロバイダー、コルレス先や顧客との積極的なコミュニケーションを行うこと。
  • コルレス先や顧客が信用リスクやその他のリスクを惹起し、こうしたリスクの分析が必要である点を認識すること。
  • 戦略的重要性に基づきアプリケーションの優先順位付けを行うこと。
  • 経営上の優先順位に合わせて2000年問題対応のための所要資源を明確に特定すること。
  • 2000年問題対応の各段階に明示的な目標達成期日を設定し、経営陣への定期的な進捗状況報告を行うこと。
  • 2000年問題対応の過程に監査が積極的に関与すること。
  • 実施時期および実施手続を備えた明確なコンティンジェンシー・プランを策定すること。
  • 2000年問題対応の全過程を通じてセキュリティ管理について厳密なモニタリングを行うこと。

以上