全銀ネット、使用言語はC言語だった件
障害発生当初、言語がCobolで書かれているためコボラー招集されてると言われていましたが、はっきりとC言語が使われていると会見では答えていました。その部分から始まるように下記の動画をセットしています。
障害発生当時の様子は下記のNoteにまとめていますので合わせてご覧ください。
障害が発生したシステムの「生成プログラム」の開発言語
C言語で開発されていると言う発言は質問に対する回答でされました。下記の様なやり取りがありました。
記者会見では、NTTデータの担当者が質問に答えています。
記者（インプレスの川さん）は、障害が発生したシステムの「生成プログラム」の開発言語について尋ねました。これに対し、担当者は「C言語」（注01）であると答えています。
また、担当者は、テーブルのサイズ拡張が行われたことを説明し、これが再コンパイルのみによるものでなく、特定のデータ型のサイズが64ビット環境によって増加したためであることを明らかにしました。
金融機関名テーブルの全体のサイズがどれだけ増えるかを確認し、プログラム上で適切な作業領域を割り当てたことを説明しています。
最終的に、コード自体は変更されず、再コンパイルのみが行われたと述べています。
※注01：C言語とCOBOLの両方が使われている可能性は十分にあります。特に、金融機関のような大規模なシステムでは、異なる部分に異なる言語が使われることは珍しくありません。
このため、NTTデータのシステムにおいては、C言語が新しい機能やシステムの開発に使われ、同時に既存のCOBOLシステムが維持・運用されている可能性があります。記者会見の内容によれば、最近の問題の解決や改善にはC言語が用いられたようですが、システム全体としてはCOBOLが一部に使用されている可能性があります。
では今回の【ノーカット】NTTデータ＆全銀ネット 共同会見全体の要約をまとめていきます。
NTTデータ＆全銀ネット 共同会見要約
全銀ネットのシステム障害詳細説明
システム障害の発生: 10月10日に、RC（リレーコンピューター）と呼ばれる新機種に関連するシステムダウンが発生し、10校中14校で業務が全面的に停止しました。
障害の原因: 問題は、RCのアプリケーションで発生したエラーによるものでした。特に共有メモリテーブルの欠損が原因とされています。
環境構築の問題: システムの環境構築において、共有メモリを運用する仕組みに問題がありました。OSのバージョン変更（32ビットから64ビット）に伴い、金融機関名テーブルのサイズ拡張が必要になりましたが、これが原因で作業領域の超過が発生しました。
対応策: 当初の復旧対応は効果がなく、システム営業再開に間に合わず、その後の対応策として、RCが参照するインデックステーブルを使用せずに取引種目を判別するプログラムへの変更が行われました。
影響: このシステム障害により、金融関係のデータ送受信に遅延が生じ、入金処理にも影響が出ました。
件数の変動: 当初報告された件数と比較して、影響を受けた件数が増加しました。
今後の再発防止策に関する詳細な説明
件数の修正: 総件数が修正され、詳細な分析が行われました。
発生原因分析と再発防止策: NTTデータによる原因分析と再発防止策が示されました。主な問題点としては、OSバージョンの非互換対応、試験プロセスの課題、復旧対応プロセスの課題などが挙げられています。
復旧対応プロセス: 暫定対処の検討着手が遅れたことや、優先順位の考え方、作業時間の見積もりの問題点などが指摘されています。
システム総権タスクコースの立ち上げ: システムの全体的な問題を分析し、再発防止策の妥当性を評価するための組織が設立されました。
全銀ネット側の発生原因分析と再発防止策: 委託者としてのマネジメントの不足、リスクを前提とした移行計画の妥当性判断の拡大、復旧対応優先順位の整理、BCP（事業継続計画）の実効性不足などが挙げられています。
今後の見通しと対応方針: 直近で取り組むべき対策、RC23シリーズへの移行対応、ABIゲートウェイおよび関連システムの開発プロジェクトの見直しなどが含まれています。
システム総点検タスクフォースの設立: 11月6日にNTTデータにより設立されたタスクフォースが、システム障害の分析と再発防止策の評価を行っています。
全銀ネットの体制見直し: システム障害を受けて、全銀ネットは体制の見直しを行い、外部からの専門家を含む再発防止の検証委員会を設けています。
発生原因の分析: システム障害は、生成プログラムにおけるメモリ領域の確保ミスに起因していました。金融機関名テーブルが予定されていた領域に収まらず、他のアプリケーションが利用するメモリ領域と重複したことが問題となりました。
再発防止策: NTTデータは、影響調査プロセスの変更、試験工程の見直し、復旧対応プロセスの改善などを含む再発防止策を提案しています。
質疑応答: 会見には質疑応答の時間も設けられ、具体的な質問への回答が行われました。質問の中心は、システム障害の原因とその解決策に関するものでした。
NTTデータ＆全銀ネット 共同会見質疑応答要約
一人目質疑応答：ミスは組織的な見落とし
テーブルの破損と原因: 今回のシステム障害は、金融機関名テーブルの破損に起因していました。この破損は、製造工程におけるメモリ領域の確保ミスによるものであり、金融機関名テーブルが想定された領域に収まらず、他のアプリケーションが利用するメモリ領域と重複したことが原因でした。
製造過程の勘違い: プログラムの担当者が、金融機関名テーブルが正しく配置されていると誤認したことが問題でした。この誤りは、製造段階のレビューでも見落とされ、システム障害の原因となりました。
原因の性質: この問題は初歩的なミスではなく、組織的な見落としによるものでした。詳細設計書には必要な情報が記載されていましたが、製造段階での見落としにより問題が発生しました。
テーブルの統合理由: 金融機関名テーブルとインデックステーブルは、検索効率を高めるために統合されていました。これは、多数の金融機関名を効率的に検索するための設計上の選択でした。
文書に残された情報: 問題の根本原因は、詳細設計書に記載された情報が製造段階で見落とされたことでした。この見落としにより、金融機関名テーブルのサイズだけが考慮され、作業領域の配置ミスが発生しました。
２人目質疑応答：作成されたテーブルが他のプログラムが使用している領域に侵入
テストの有無とその性質: 単体テストは実施されていましたが、このテストではプログラム単体で問題なく機能することが確認されていたものの、実際の統合環境や総合試験環境においては、他のプログラムとの相互作用により問題が発生していました。
プログラムの実行領域との問題: 生成プログラムによって作成されたテーブルが、予定された作業領域を超えて、他のプログラムが使用している領域に侵入してしまったことが問題でした。この侵入がシステム障害の原因となった。
32ビットから64ビットへの移行: システムの32ビットから64ビットへの移行によって、特定のデータ型のサイズが増加し、その結果、テーブルのサイズ拡張が必要になりました。
インデックステーブルのサイズ変更の有無: 64ビット化に伴い、インデックステーブルのサイズが変更する必要はなかったが、結果的にはサイズ変更が行われなかったことが明らかにされました。
３人目質問：具体的な責任の取り方の具体的な目安はない
個人と組織の責任について: 質問は、今回のシステム障害に対する両組織の責任と、具体的な処分について尋ねています。NTTデータの辻氏は、現在原因分析と再発防止策の取り組みを進めており、責任に関しては今後検討すると回答しています。また、システム上の直接の原因がNTTデータの責任であると認識しており、これに対してお詫びを述べています。
責任の取り方: 鈴木さんは、責任の具体的な取り方について尋ねていますが、辻氏はまだ具体的な目安はないと答えています。
暫定対処と復旧のタイミング: 現在は暫定対処を続けており、具体的な復旧のタイミングについては、来週の前半にテストが終了する予定であり、12月以降に順次復旧していく予定であると説明しています。ただし、これは相手銀行のスケジュールや、万が一の失敗に備えた代替処理が適切に行えるかの確認が必要であるとも述べています。
４人目質疑応答：800万円の損害の内訳
システム障害の回収スケジュール: システム障害の回収は12月以降に順次リリースされる予定であるが、具体的なスケジュールはまだ確定しておらず、1月以降にずれ込む可能性もあると説明されています。
時期前金システムの開発プロジェクト: 関連する開発プロジェクトは現在停止しており、その再開の時期については未定であると述べられています。
保証に関する情報: 11月1日時点での保証金額と件数については、約8000件、約800万円であると報告されています。これらの数字は変わる可能性があるとされ、主に手数料の部分が中心であると説明されています。
損害ケースの詳細: 800万円の損害の内訳については、主に手数料関連の損害が中心であるとされています。
５人目質疑応答：次期全銀システム開発再開の予定無し
RC23シリーズへの移行延期: 一部金融機関がRC23シリーズへの移行を延期したことについて、その金融機関は自ら延期を要望したと説明されています。この延期は、システム障害の影響と、金融機関が予定しているシステムレベルアップに対応するための措置であるとされています。
開発プロジェクトの進行状況: 次期全銀システムの開発プロジェクトについて、現在は停止しており、その再開の時期は未定であるとされています。
製造関係者と詳細設計関係者の役割: システム障害の原因となった製造関係者とは、プログラマーやシステムエンジニアを指し、これらの人員がプログラムの修正方針を決定していました。今回の問題は、詳細設計関係者（主にベテランのシステムエンジニア）がプロセスに参加していれば、問題の発見が可能だったとされています。
修正方針の見直し: プログラムの修正方針を決定する際に、詳細設計者を含む有識者の参加を強化することが、再発防止策の一環として検討されていることが示されました。
６人目質疑応答：メモリー不足はプログラムの設定ミス
作業領域の不足: メモリ上でプログラムが確保する領域の不足についての質問に対して、物理的なメモリーが不足していたわけではなく、プログラムが作業のために宣言するメモリーサイズが不足していたことが説明されました。これはプログラムの設定ミスによるものであるとされています。
損害賠償の責任と負担: 8000件、800万円の損害に関連する費用負担について、現時点では引き続き検討中であり、具体的な責任の取り方や対応については決定されていないとされました。
情報公開の方法: 今後の対応や責任に関する情報公開については、今後の決定や知らせの方法についてはメールなどを含む複数の方法が考えられているとのことです。
７人目質疑応答：CIOには1名を選定
CIOの役割と位置付け: 資料に記載されたCIO（Chief Information Officer）についての質問に対し、全銀ネットではCIOという役職が具体的に定義されていないが、一般的に情報システムを所管する最高責任者として理解されていることが説明されました。CIOは理事会や委員会に出席し、リスク管理を含むシステムに関する専門的な知識を持つ役員クラスの人物が想定されています。
CIOの選定プロセス: CIOの選定については、現在候補者を選定中で、内部および外部からの候補者が検討されているとされました。現時点では1名を選定する予定です。
故障に関する費用負担の責任: 先ほど言及された800万円の故障に関連する費用負担の問題については、まだ具体的な解決策が決定されておらず、原因究明後に責任と費用の負担に関する決定を行う予定であると説明されました。
８人目質疑応答：外部有識者によるアドバイスを受け入予定
顧客対応に関する問題と再発防止策: 障害発生時の顧客対応に関する問題点が認識されています。具体的には、顧客への情報開示の遅延、情報更新の頻度不足、BCP（Business Continuity Plan：事業継続計画）の不十分な実施が反省点として挙げられています。今後は、より迅速な情報提供、効果的なBCPの実行、故障時の迅速な復旧対策を強化することが考えられています。
CIOの役割と責任: 新しく設置されるCIOに関しては、現在候補者選定中で、内部または外部からの選出が検討されています。CIOは理事会や委員会に出席し、リスク管理を含むシステム関連の専門知識を持つ役員クラスの人物が想定されています。
顧客の定義: 顧客とは、直接的な金融機関だけでなく、その先のエンドユーザー（本来の顧客）を指しています。
体制見直しと外部有識者会議: 体制の見直しについては、外部有識者によるアドバイスを受け入れる形で行われ、報告書の作成は予定されていないとされました。バランス、システム、顧客視点からの意見を得ることが目的です。
今後のフォローアップと再発防止策の検証: 今年度中に再発防止策の整理を行い、来年以降の実施過程でその効果が期待通りかどうかを検証する予定です。
９人目質疑応答：東京と大阪の共通のテーブルが破損
再発防止策に関する質問: 東京と大阪のデータセンターが二重化されており、バックアップが取られている状況についての質問です。障害発生時に旧バージョン（RC17）にロールバックする可能性や、二重化システムが機能しなかった理由について尋ねています。
障害発生時の対応に関する問題: 東京と大阪のデータセンターで共通のテーブルが破損したため、障害が両方で発生し、理論上は考えられない状況だったと回答されました。また、どちらか一方のデータセンターが倒れた場合の運用シナリオは検討されていたが、両方が倒れるケースについての対応は不十分だったことを認めています。
RC17に戻せなかった理由: RC17へのロールバックが不可能だった理由については、10月の移行作業中に副作用が発生し、その際には問題が発見されなかったため、移行が進められたと説明されました。RC17に戻すためには、接続先の変更や相手様金融機関のシステム接続情報の変更が必要であり、その実施が現実的に不可能だったことが理由として挙げられています。
10人目質疑応答：来年の移行は1金融機関が本格対応
システム更新計画についての確認: 2023年から2029年にかけて24回に分けてRCシステムの更新作業を進める計画について、この計画が基本的に変わらないかどうかを尋ねています。NTTデータからは、保守期限があるため基本的に6年間のスケジュールで進めること、しかし今回の件を受けて、可能な金融機関ではスケジュールの変更を検討することが回答されました。
更新作業の安全性に関する懸念: 来年1月からの更新作業が安全に進められるかどうかについて尋ねています。NTTデータは、障害の不安を一つ一つ潰していきながら、本格対応の性能を高めていくと答えています。
来年の移行計画に関する金融機関の不安: 来年の移行を計画している3金融機関のうち1金融機関が本格対応を予定しているが、これに対する不安の声があるかどうかについての質問です。NTTデータは、顧客からの相談があったと回答し、今後金融機関との相談を進める予定であると述べています。
11人目質疑応答：他の銀行を利用て発生した手数料の保証
事故に関する保証について、約8000件で約800万円という数字が報告されているが、これが金融機関の顧客に対するものなのか、または銀行の利用者に対するものなのかを尋ねています。回答は、障害の影響を受けた銀行の利用者が主で、主に手数料の増加に関連する問題であると説明されています。例として、通常使っている銀行が利用できなかったために他の銀行を利用し、その結果として手数料が増えた事例が挙げられています。
12人目質疑応答：C言語を使用
冒頭に書いた、インプレスの川さんの言語に対する質疑応答がされました。
13人目質疑応答：タスクフォースと有識者会議の設立時期
質問内容:
前金ネットに関する質問で、17ページの改正メジに関する内容について質問されています。
新たに設立されたタスクフォースと有識者会議の設立時期、メンバー構成と人数、それらの役割についての質問です。
また、プロパー出品の育成に関する方針についても問われています。
回答内容:
タスクフォースと有識者会議は、今回の障害を受けて再発防止策を取りまとめるために設立されました。
タスクフォースは、企画部門のメンバーとシステムの専門家が参加し、合計15名で構成されています。これらのメンバーは、再発防止策の実効性を検証します。
有識者会議は、ガバナンス、システム、業者設定の専門家から構成され、銀行以外の第三者の観点で見てもらうことを目的としています。この会議は、対策の検証と実行の適切性を定期的に検証する役割を持ちます。
14人目質疑応答：開発プロセスの見直しと再発防止策の確認
質問内容:
アジャイルエリアの取り扱いとマルチベンダー体制について、NTTデータはどのように対応していくのかという質問。
開発に関わるベンダーに対する品質強化の要求と、その体制についての質問。
システムの再発防止策と下請け体制について、どのようにチェックが行われているのかという質問。
回答内容:
アジャイルエリアとミッションクリティカルエリアの扱いに変更はなく、オープン化を目指している。
NTTデータ以外のベンダーにも品質強化を求めていく方針。
下請け体制に関しては、再委託先をしっかり把握し、進捗管理や品質管理を委託先に求めている。しかし、今回の障害を踏まえて、開発プロセスの見直しと実効性のある再発防止策の確認が必要。
NTTデータグループの社員がプロジェクトにどれだけ関与するかはケースバイケースであり、定量的な答えは難しい。
プロパー人材の育成については、研修を含む様々な方法で進めている。
15人目質疑応答：優先順位をつけて260のシステムの点検進行
質問内容:
NTTデータが2023年度中に200程度の大規模システムの総点検を行う方針を発表していたが、その進捗状況や再発防止策を踏まえた点検についての更新情報。
地方銀行のシステムが点検対象に含まれているか、及び稼働時期に影響があるかどうか。
回答内容:
システム総点検は品質確保、障害影響の最小化、運用フェーズでのトラブル対策を含む約50の点検項目に基づいて進められている。
現在、優先順位をつけて260のシステムの点検を進めており、年度末までの完了を目指している。
地方銀行のシステムも点検対象に含まれており、基本的には稼働時期に影響はないが、重大な問題が発見された場合は調整が必要になる可能性がある。
16人目質疑応答：具体的なOSのバージョンはLinux系
質問内容:
NTTデータに対し、使用しているオペレーティングシステム(OS)の種類とバージョンについて質問。
また、1月のシステム公開が東西一体で行われるかどうかについての確認。
回答内容:
具体的なOSのバージョンについては顧客のシステムに関わるため明言できず、リナックス系であることのみ明らかに。
1月のシステム公開については、東西の国別に実施する計画であったが、東西の国が分けられない状況となり、同時に行われることになる。
17人目質疑応答：集約化は保守が素早くできる
質問内容:
RC17とRC23のシステム構成の変化についての確認。
これらの変更による障害対応のメリットやデメリットについての質問。
銀行間手数料が現在0円に設定されているが、これに関する質問。
回答内容:
RCが銀行システムに近く配置されていたが、現在は全金センターに集約化されていることの説明。
集約化によるメリットは、保守や商用時の対応が素早くできること。
現在の手数料0円設定については、障害があった銀行に対する対策。元々銀行から受け取る費用が現在受け取られていない状態で、これを再生産する計画。
10月の正規分については、近く発信して生産を進める予定。
本格対処が終わるまでは、月ごとにまとめて生産を行う計画。
保証の件は、直接損害に関するものであり、銀行間の準備するもの。
18人目質疑応答：APIの整備については2025年7月を目標
質問内容:
5ページ目の内容について、13日に判明したというメモリ割当の話についての確認。
APIの整備と将来的なRCの配信に関する銀行の対応状況について。
回答内容:
13日に発表されたメモリ割当の問題についての確認。その日に結論が出たと認識している。
APIの整備については2025年7月を目標に進んでいる。現状では、銀行はAPIへの移行に慎重に検討しており、状況は変わることが予想される。新規参加の銀行や資金業者にとっては、API経由の接続が好まれている。既存の銀行は現状のRCからの移行を検討している。
RC23は2035年頃にはAPIへ移行する必要があるため、銀行は遅くともその時期にはAPIに対応する必要がある。
19人目質疑応答：インデックステーブルの破損率は2%程度
質問内容:
影響の小さい件数について数字の確認。以前は500万件とされていたが、566万件が正しいかどうか。
BCP（ビジネス継続計画）のリスクに関する内容と、技術的なリスクとビジネスリスクの両方に対するリスク管理の基本的な考え方。
インデックステーブルの具体的な破損の割合とテストパターン数について。
NTTデータが会見を主催する理由とその背景、及び会見を通じて社会的な影響を与えたと考えているか。
回答内容:
以前の発表での影響件数は566万件が正しい。
BCPのリスクについて、特定のリスクを想定した上での対応が行われている。技術的なリスクとビジネスリスクの両方に注意を払いながらリスク管理を進めている。
インデックステーブルの破損率は2%程度だった。テストパターン数は6000弱のパターンで、その中で生じる可能性のあるリスクを考慮していた。
会見の主催はNTTデータとして行われており、事実を正しく伝えることが重要だと考えている。社会的な影響を考慮して、事案に関する正確な情報を提供することが目的であり、その他のシステム運営者にとっても新たな指針になることを期待している。
20人目質疑応答：金融庁報告の詳細は述べることができない
質問内容:
NTTデータと金融庁に対し、金融庁に報告した際の反応について詳しく聞きたい。
回答内容:
回答者は金融庁への報告についての詳細なリアクションは述べることができないと答え、具体的な内容には触れず。
その他の発言:
今回の反省を踏まえ、再発防止策を速やかに実行に移し、組織内に根付かせて、実効性の高い状態を維持することが重要だとの認識。
日本の内国化取引制度における核心システムとして、信頼される決済ブラシステムを目指し、全員教およびNTTデータと協力して取り組む意向。
この記事が気に入ったらサポートをしてみませんか？