静岡大学 遠藤研究室

１．2022年11月10日（木）9時~10時に、4年生4名の卒業研究中間発表を行い、それぞれの副査の先生から質疑やアドバイスをいただきました（オンライン8分程度発表、6分程度質疑）。
テーマは以下です。
「外国為替のバイナリーオプション取引でのプロスペクト理論の適用」
「経費精算システムのデジタル化に置ける必要要素の調査・考察」
「PayPayの手数料有料化による加盟店の継続意思の調査と考察」
「ロボアドバイザーを用いた資産運用普及のための戦略の考察」
２．2022年11月12日（土）10時~11時15分に、4年生1名と３年生4名が経営情報学会でポスター発表（オンライン参加）を行い、司会の先生や参加の先生から質疑に加え、多くの励ましとアドバイスをいただきました。（5分発表、10分質疑）（写真）。
テーマは以下です。
「外国為替のバイナリーオプション取引でのプロスペクト理論の適用」（4年生）
「地域金融機関の地域貢献形態の比較研究」
「リスクマネジメント戦略の6観点からみた障害対策の重要観点の考察」
「ロボアドバイザー投資を提供しているFinTech企業の経営戦略」
「路線バス事業者におけるQRコード決済導入についての現状と考察」
どちらのイベントも、学生の皆さんのこれまでの研究の成果をしっかり発表することができ、更なる研究の進展へのモチベーションを高めることができました。質疑やアドバイスをいただいた先生方に感謝申し上げます。

2022年11月9日（水）に4年生の卒業写真用に研究室の集合写真を撮影しました（前列が4年生、後列が遠藤と3年生）。通常のゼミはオンラインで行っており、7月の歓迎会から久しぶりにリアルでほぼ全員が集合しました。4年生は翌日に卒業研究中間発表があり、3年生は12日（土）に経営情報学会2022年全国研究発表大会でのポスター発表を行います。

2021年12月21日（火）に遠藤が、静岡大学・中日新聞連携講座2021「いのちとくらしを守るイノベーション」の第4回でオンライン講演しました。要旨は以下の通りです。
１．金融情報システム
金融情報システムは、銀行系と市場系に分かれ、さらに個別金融機関のシステムと金融機関の相互ネットワークのシステムに分類できるが、いずれも複雑で大規模なシステムである。金融情報システムの特異性は、第一に決済システムであること、第二に情報セキュリティの高さを求められること、第三にレガシーシステムの存在、第四に規制産業だということである。金融情報システムでは、IT要因や金融業務要因という外部環境の変化に対して、組織や経営者という内部要因が適合していないという問題構造がある。
２．リスクマネジメント戦略の6観点
そこで、経営者向けにリスクマネジメント戦略の6観点を提言してきた。それは、１）経営トップのコミットメントと支援、２）組織体制とITガバナンス、３）ITリスクマネジメント、４）拡張性一貫性確保、５）要件定義最適化、６）品質重視の仕組構築である。
３．金融情報システムの障害事例4件
金融情報システムの障害事例として4事例を採り上げて分析した。2011年の銀行振込大幅遅延では、未然防止の観点だけでなく障害発生時の対応にも難があった。2012年の一部銘柄取引停止では、二重化の設計を過信して障害発生時の対応が雑になった。2020年の終日株式売買停止では、二重化設計の確認が不十分で、関係者との発生を想定した調整もできていなかった。2021年2月の銀行の障害では、定期性預金の障害が、システムの防衛機能によって全体に波及し、ATMでの通帳・カードの取込みに繋がった。同じ銀行でその後もハード障害、プログラムのミス等を起因に7件の障害が発生した。他の銀行やQRコード決済でも障害は発生しており、各社でシステム障害管理体制の見直しが求められる。
４．システム障害管理体制の実効性向上の留意点
障害発生を皆無にすることは不可能であることを前提として、システム障害管理体制を構築する必要がある。未然防止の観点だけでなく障害発生時の対応準備の観点も重要で、両面に経営の関与が必要になる。
５．障害にどう向き合うか
事業者は、利用者視点で影響が少ない障害は、事後対処でカバーすると割り切り、それを利用者に伝えることも必要ではないか。利用者も障害が発生しないシステムはないことを理解し、代替手段を用意することや、連絡先を最新化しておくことが望まれる。今後DX進展により、元々別々に作られたシステムが連携して動くことで、より便利なサービスが提供される反面、想定しない障害も一定の割合で発生しうることを理解する必要がある。（文責：遠藤正之）

浜松イノベーションチャレンジは、浜松のクラッチ製造の株式会社エフ・シー・シーさん（東証1部上場）主催、株式会社ブリッジさんのサポートでの4か月にわたるワークショップ型の新事業創出プログラムです。参加者は、エフ・シー・シーさんに加え、浜松の上場企業であるユタカ技研さん、ローランドDGさんそして会場FUSE提供の浜松いわた信用金庫さんの社員の若手精鋭で、新事業アイデアを練り上げ、自社の経営陣に向けてプレゼンするものです。
そこに、若い感性を期待され、静岡大学情報学部遠藤研究室の3年生の学生4名が参加させていただきました。12月17日（金）にその最終ピッチ（経営陣向けプレゼン）が行われました（写真）。学生たちも、各社の経営陣の皆様の前で、堂々とプレゼンテーションを行いました。
更に12月22日（水）にアフターフォローセッションが行われ、各社のメンバーと振り返りを行い、4か月の全日程が終了しました。社会人の皆さんの真剣な議論に触れることで、学生たちにとって、得難い大変貴重な体験となりました。

11月26日にみずほ銀行とみずほフィナンシャルグループに対して金融庁からの業務改善命令が発せられました。そこで、改めて、みずほ銀行の障害に関して、システム関連での原因と今後の対応策を、公開情報をベースに纏めてみました。
Ⅰ．原因
第一に、MINORIのアーキテクチャの複雑性、第二に保守運用フェーズでのリソース削減が急であった事、第三にIT現場と経営のコミュニケーションが不十分だったこと、第四にシステム関連の銀行組織、開発会社、運用会社が連携しにくい体制であること、第五に機器の所有を各ベンダーとしたこと。
１）MINORIのアーキテクチャの複雑性
大規模システムでは、マルチベンダーとなることは不可避である。マルチベンダー自体が問題ではない。むしろ勘定系システムの本体部分が、4つの異なる基盤システムで構成されている点が問題である。
それぞれのOSも異なり、データベース管理システムも異なっている。それぞれの専門家はいても、その相違点を十分に理解できる専門家はほぼいないのではないか。基盤を跨る障害に対応するためには、両方の専門家が参画する必要があり、対応スピードがどうしても遅くなってしまう。特に社内にスキルの高い専門家が常駐していれば良いが、そうでないと更に対応スピードは落ちてしまう。第二の原因によるリソース削減で、スキルの高い専門家は常駐していなかったと推測される。
２）保守運用フェーズでのリソース削減が急であった事
大型プロジェクトの場合、リリース直後に障害が発生する。みずほ銀行のシステムリリースは実質的に2019年2月だった。それから約2年たって、システム障害が発生したことに着目すべきである。有識者であるベンダーの人材をそれまでは引き留めていたが、コスト圧縮策の中で、引き留めができなくなり、十分な引継ぎもできず、障害の予兆能力や障害発生後の対応力が低下したと考えられる。
３）IT現場と経営のコミュニケーションが不十分だったこと
経営者とシステムの開発現場のリスク感覚に関する意思疎通ができていなかったことにあるのではないか。現場の状況を経営トップに伝えるのがCIOの一つの役割だが、CIOがシステムの事情に精通していなかったため、経営トップ側の代弁者の機能のみとなり、現場視点の適切な進言を経営トップにすることができなかったのではないか。その結果、２）のように、現場感覚ではリスクが高まるレベルまで人員やベンダーへの支払いを削減してしまったのではないかと考える。
6月のシステム障害調査報告書でも、114ページから116ページにかけて、アンケート調査やホットラインで受け取った意見がまとめてあり、そのことが裏付けられる。
４）システム関連の銀行組織、開発会社、運用会社が連携しにくい体制や伝達方法であること
みずほ内部が、みずほ銀行と開発子会社の二層構造になっている点や、開発会社（みずほリサーチ＆テクノロジーズ）と運用会社（MIDS）の資本関係が異なる点等、組織的に複雑であり、スムーズな連携を阻害している可能性がある。またIT子会社の再編により、保守体制が弱まった可能性がある。一つは、2020年6月に日本IBMの資本を入れた運用会社を設立したことである。もう一つは、2021年2月から3月の4件の障害にもかかわらず、2021年4月に、システム開発を行う子会社だったみずほ情報総研が合併により、みずほリサーチ＆テクノロジーズを設立した点である。
更に、障害発生時の運用会社でのエラーメッセージの検知体制や、運用会社から開発会社への伝達方法が、印刷したうえで電話での口頭の連絡によるなどアナログ的な手法であったことで、大量のエラーが発生した場合の対応が不十分になる素地があった。
５）機器の所有を各ベンダーとしたこと
機器の故障が多い点と、MINORIは35万人月で4000億円台の投資とされているが、投資に機器のコストがほとんど入っていない点とに注目する。機器については、ベンダーの機器を借りている形態で、毎年使用料を払っている形になっているようである。様々なハード機器関連のテスト、障害訓練を自由に行うためには、基本料金以外の追加の費用が発生するため、開発現場ではそのようなテストや訓練を最小限に絞っているのではないか。そのため、機器の故障に際しては、みずほ内部の人間は全く手も足も出ず、ベンダーにお願いする以外方策がないのではないか。しかし２）で説明したように、ベンダーへの保守コストを削減しており、常駐するベンダー担当者のスキルレベルはあまり高くなく、リカバリーに手間取ったのではないか。
Ⅱ．対応策
第１に、システム部門の現場の構造を改善して、ベンダー・開発会社・運用会社・みずほ銀行、みずほFGの一体運営する体制を策定することが望まれる。
特に、みずほ銀行と開発会社の司令塔の一元化、運用会社から開発会社への情報伝達の自動化や改善が喫緊の課題ではないか。
第２に、システム部門のスキルアップと、MINORIのアーキテクチャへの習熟が必要ではないか。MINORIの機能を修得する研修や、障害を想定した、ベンダー、開発会社、運用会社、みずほ銀行、みずほFG、経営まで巻き込んだ訓練の定期的な実施が望まれる。
第３に、経営陣とシステム部門の現場の意思疎通の活性化策を取る必要がある。
CIOが経営陣の代弁者としてだけでなく、IT現場の代弁者として機能するように、するべきである。内部監査部門もこの点を意識した監査を行ってこれを支援することが望ましい。
第４に、アーキテクチャをレビューする組織や体制を強化することが必要ではないか。
複雑なアーキテクチャをこれ以上複雑にしないように、新規開発のアーキテクチャを計画段階でチェックすることが必要である。
第5に、システム部門に過度のプレッシャーをかけないために、経営陣がATMの限定的な停止のような障害（3月3日事案、8月23日事案、9月8日事案）は、今後も十分起こる可能性があることを宣言してしまうことも必要ではないか。

2021年7月21日に遠藤が講師として登壇した研究会がオンライン開催されました。その内容を報告します。
日時：2021年7月２１日（水）19：00～20：40
テーマ：金融情報システムのリスクマネジメント
■要旨
講演者は、金融情報システムに関して、経営者向けにリスクマネジメント戦略の6観点を著書「金融情報システムのリスクマネジメント」で提言している。2020年から2021年にかけて取引所と銀行で大きなシステム障害事例が発生した。これら事例は、詳細な調査報告書が公表されており、講演者が作成した根本原因分析も参考にして、各組織で他山の石として、障害管理体制の実効性を高める見直しを行うことを推奨する。最後に、2021年に調査報告書が公表されたソーシャルレンディングの事故事例についても解説した。

講演者の紹介（司会より）
1983年三菱銀行に入行し、第三次オンライン開発、東京三菱銀行システム統合、三菱東京UFJ銀行システム統合等の超大規模プロジェクトに、主に推進マネジメントの立場で参画し、その後2015年10月より静岡大学に移り、主に、金融情報システム、FinTech、情報システムのマネジメントを専門としている。

Ⅰ．金融情報システム

本日議論する金融情報システムは、「金融機関等コンピュータシステムの安全対策基準・解説書」の定義から、オンラインサービス、決済、顧客データ取扱という3つの要素を含んだ大規模なシステムとする。様々なバリエーションがあり、銀行部門と市場部門のシステムに分かれ、それぞれが更に個社のシステムと相互ネットワークのシステムに分かれる。銀行システムも証券会社システムも多くのサブシステムから構成された複雑で大規模なシステムである。

金融情報システムに係るリスクは2つのタイプに分かれる。第一のタイプは金融情報システム自体が外部から直接評価されるもので、オペレーショナルリスク、ビジネスリスク、戦略リスク、風評リスク、法務・規制リスクがある。この後説明するシステム障害事例で顕在化したのはこのタイプである。第二のタイプは、金融情報システムが経営判断をサポートするタイプのリスクで、市場リスク、信用リスク、流動性リスクがある。最後に説明するソーシャルレンディングで顕在化したのはこの中の信用リスクである。

金融情報システムの特性は4点ある。第１に、決済システムとして広範囲のネットワークに接続しており、可用性や大量即時処理への要求が高いことである。第２に、顧客の財産情報を扱うことから、情報セキュリティの高さを求められることである。第３に、ホスト系のレガシーシステムが存在しており、保守や開発の難易度が高くなっていることである。第４に、規制産業であり当局の監視下に置かれていることである。2011年の調査では、開発の工期、予算、品質の各面で5割以下の満足度となっている。

金融情報システムに関しては、ITや金融業務という外部要因の変化に対して、システム開発の組織や経営者という内部環境が適合しきれていないという、大きな問題構造が浮かび上がってくる。

 

Ⅱ.リスクマネジメント戦略の6観点

金融情報システムの問題構造に対する改善提言として、リスクマネジメント戦略の6観点（CORE-OQ）を提唱している。6観点とは、以下の6点であり、最初の4点が攻めの視点、残りの2点が信頼性実現の視点での観点である

1）経営トップのコミットメントと支援（Commitment）
2）適切な組織体制整備によるITガバナンス強化（「組織体制とITガバナンス」）（Organization）
3）経営ITリスクの適切な評価と対策の構築（「ITリスクマネジメント」）（IT Risk Management）
4）経営戦略に合致した業務拡張性およびシステムの一貫性の確保による二重投資の排除（「拡張性一貫性確保」）（Extensibility）
5）外部関係者の要請とITのケイパビリティの間をつなぐ要件定義最適化（非機能要件を含む）（「要件定義最適化」）（Optimization）
6）品質重視の仕組構築（Quality）　。

観点1の経営トップのコミットメントと支援について3点を示す。第一に経営戦略の優先順位が経営トップとCIO（最高情報責任者）や情報システム部門と共有されていることである。第二に経営トップが開発組織体制の整備や障害対策へ関与することである。第三に経営トップが情報システムに関して組織内外へ発信することである。
観点2の組織体制とITガバナンスについて３点を示す。第一に、情報システム開発に適した全社的組織体制、プロジェクト体制が構築され、障害発生時の連絡体制が委託先も含めて事前に準備されることである。第二にシステム関連の人材育成が計画的になされることである。第三に、ITガバナンスが高められていることである。
観点3のITリスクマネジメントについては、第一に発生可能性のあるリスクを洗い出したうえで、対処の優先順位決めをすることである。第二に適切な対策を立案し実施、管理することである。第三に環境変化に応じて定期的にリスクの優先順位や対策を見直すことである。
観点4の拡張性一貫性確保について3点を示す。第一に業務やシステムの拡張性を確保できるような設計である。第二にシステム全体のグランドデザインの共有である。第三に障害発生時に影響が特定しやすいようにする仕組みを当初から盛り込むことである。
観点5の要件定義最適化について3点を示す。第一に要件実現にあたり現状のシステムを活かして実現することを考えて具体化することである。第二に機能要件だけでなく処理集中時のレスポンスや障害発生時の対応などの潜在的な要件も明確にしていくことである。第三に業務継続計画も策定することである。
観点6の品質重視の仕組構築について3点を示す。第一に設計品質、開発品質、運用品質の3つを意識することである。第二に標準的なルールや手順を制定して属人的な品質のバラツキを極力排することである。第三にレビュー会議実施のルール化や専門的なレビュー組織を作る等で組織全体の品質を高めることである。

Ⅲ．金融情報システムの障害事例

金融情報システムでの障害事例の中で、2011年に発生した銀行の振込大幅遅延、2012年と2020年に発生した取引所の障害、2021年2月3月に発生した銀行のATMカード通帳大量取込他3件の事例について、根本原因分析の手法で掘り下げていく。

【障害事例1：2011年銀行振込大幅遅延】

障害事例1は、2011年の銀行振込大幅遅延である。経緯概要は以下の通りである。東日本大震災の週明けにテレビ局の義援金口座への大量振込が集中し、1口座当たりの処理可能件数を上回り、夜間バッチが異常終了した。復元作業が難航し、翌日のオンライン開局のためバッチ処理を中断して、手作業での処理を行った結果、二重処理や処理漏れなどが連鎖的に発生した。更に翌朝には、携帯電話事業者の義援金口座への大量振込集中で、対外接続系システムでの受け入れ可能なデータ量を上回ったことで、夜間バッチの異常終了が発生し、再度手作業での対応が大量に発生しATMの利用制限やダイレクトチャネルの利用制限につながった。

この障害の根本原因分析が図１である。直接的な原因である義援金口座への振込集中に加え、為替取引の受入の上限値であるリミット値の見直しがされていなかったことも原因となる。また障害が長期化した原因として、日中オンライン処理と夜間バッチ並行実施を想定していなかったことがある。更に携帯電話のチャネルの考慮が不十分であったこと、システム監査での指摘やリスク評価もなされていなかったこと、夜間バッチ遅延発生時のコンティンジェンシープランの整備が不十分だったこと、障害発生後の連絡体制の不備や、全体のマネジメントをする人材が不足していたことが挙げられる。様々な面での不十分な要素があったことが浮かび上がった。更に、リスクマネジメント不十分、組織間の連携不十分、人材育成視点が希薄などの根本原因があることも推定された。

図1　2011年銀行振込大幅遅延の根本原因分析

【障害事例2：2012年の取引所一部銘柄取引停止】

障害事例2は、2012年の取引所一部銘柄取引停止である。経緯は以下の通りである。2月2日未明1時27分に相場情報を配信する情報通信ゲートウェイサーバー8台のうちの1台でハード障害が発生。運用ベンダー担当者が診断レポートを出力し、保守ベンダーと取引所担当に連絡した。保守ベンダー担当は、携帯電話の小さい画面で情報が不十分な状態でレポートを一人で分析し、予備機に処理が引き継がれると誤判断した。取引所担当も自ら確認することなく、売買業務への影響はないと判断し、エスカレーションしなかった。7時過ぎにオペレーター出勤後、予備機へ引き継がれていないことが判明し、それから復旧を図ったが間に合わず、一部銘柄（241銘柄）の午前中売買停止となった。

この障害の根本原因分析が図2である。保守ベンダーが携帯電話の小さい画面でレポートを分析し一人で判断したことと、取引所担当も予備機への切替ができると過信してしまったこと等、障害発生時の対応に難があった。

図２　2012年取引所一部銘柄取引停止の根本原因分析

【障害事例3：2020年10月1日終日株式売買停止】

障害事例3は、2020年10月1日の終日株式売買停止である。経緯は以下である。朝7時4分に共有ディスク装置（NAS）1号機で障害が発生し、別機への自動切替ができず、手動切替も間に合わず、全銘柄の取引停止となった。その後、午後からの売買再開に向け、証券会社、システム提供ベンダーにヒアリングするも、対応可能取引参加者シェアが50%に満たないため、11時過ぎに終日売買停止を決定した。

この障害の根本原因分析が図3である。共有ディスク装置のメモリカードの故障が直接の原因であるが、製造元が自動切替の初期値を変更していたにもかかわらず、納品ベンダーが初期値を従前の値に変更し、確認のためのテストを実施していなかったため、自動切替が作動しなかった。更に手動切替の手順が整備されておらず、手動切替に時間を要したため、9時過ぎに約定情報が配信されてしまい、取引参加者の了解を取らない限り売買再開が困難になった。売買停止後の売買再開に向けた手続きやルールが用意されていなかったことで、対応できる参加者の売買シェアが38%にとどまり、再開できなかった。

図3　2020年10月1日終日株式売買停止の根本原因分析

【障害事例4：銀行の2021年2、3月の障害4件連続】

障害事例4は、銀行の2021年2、3月の障害4件連続の事例である。

１）2月28日

障害事例4の1件目の2月28日（月末の日曜日）の銀行ATMカード通帳大量取込の経緯は以下である。

朝8時24分にe-口座移行に伴う定期性預金のセンター集中記帳が開始され、9時51分に取引共通システムでのシステムエラーの検知を受け、運用会社から開発子会社へ伝達した。それと並行して10時15分には、AＴＭセンターから銀行にAＴＭエラー430件検知の一報メールが発信した。銀行の指示により10時50分にセンター記帳処理は停止されたが、その後も定期性預金取引でのエラーは検知された。一方、ＡＴＭセンターではエラー1000件超となった。11時14分には開発子会社でCＩＦ排他未解除を検知した。同時刻に、運用会社から開発子会社に対して、定期預金通帳記帳取引禁止が自動設定されていることを報告し、開発子会社から銀行へも報告された。銀行からの指示により、12時2分に定期預金の取引サービス禁止機能の作動条件が緩和された。12時37分には開発子会社で自動機サーバの2000件以上のエラーが検知された（定期預金の取引サービス禁止機能の作動条件緩和によることがこの時点では未判明）。12時47分に銀行内で「障害報告メール」（A2ランク懸念）が発信された。13時40分にATM異常多発での本部参集することが副頭取に報告された。14時から開発子会社で取引共通システムのログ調査が開始された。14時20分には開発子会社で取消情報管理テーブルのINDEXファイル容量拡張作業が開始され14時54分に拡張が完了した。14時25分には、全拠点の部店長職員に出勤指示が開始され、14時30分に関係部長会が開催された。17時10分になってログ調査の結果、AＴＭ処理区画の閉塞を認識し、処理区画の再稼働に着手し、18時39分にようやく処理区画復旧が完了した。さらに23時21分にCIFの排他解除が完了した。

2月28日の銀行ATMカード通帳大量取込の根本原因分析は、図4である。

原因としては、ATMセンターの体制が不十分であったこと、取引サービス禁止策の緩和などの不適切な障害対応策、厳格なキャパシティ管理をすべきであった取消情報管理テーブルINDEXのメモリー容量考慮漏れ、ATMエラー時の通帳カード取込仕様、タイムリーな告知が成されなかったこと、システム本体の閉塞機能の影響の把握が不十分、休日のATM障害への対応体制不備、障害発生後の営業店への連絡体制が遅れたこと、システム全体の影響を熟知する人材やマネジメント人材の不足などがある。様々な要素が重なり、障害が発生し、その後の障害検知、対応の遅れに繋がった。

図4　2021年2月28日銀行ATMカード通帳大量取込の根本原因分析

根本原因分析と対応して主な問題点11点を挙げたのが、図5である。（根本原因分析の①、②、…に対応する。）

図5　2021年2月28日事例の主な問題点

２）3月3日

障害事例4の2件目の3月3日のトラブルの経緯は以下である。

19時58分にデータセンタにおけるネットワーク機器内のネットワークカードの故障で通信の瞬断、接続が、3分間続くが、20時01分に解消した。しかしその間にATMでの通帳・カード取り込みが29件発生した。短期間で自動切替されたにも関わらず、ATMの通帳・カード取込仕様が影響を発生させたものである。

３）3月7日

障害事例4の3件目の3月7日のトラブルの経緯は以下である。

カードローンシステムのプログラムリリース後の6時8分に、総合口座定期預金の集中記帳でエラーが発生した。7時15分にはエラー原因が判明し、9時22分には影響あるATM、ダイレクトの定期預金サービスを停止した。対応後の13時42分にはサービスは復元された。原因はカードローンの追加開発でのプログラムミスであった。具体的は、貸越明細テーブルの定期預金データへの初期化処理の組込み漏れで、開発子会社テストでも検知できなかったものである。

４）3月12日

障害事例4の4件目の3月12日のトラブルの経緯は以下である。

11日深夜23時39分に、統合ファイル接受基盤に係るディスク装置で故障が発生した。これにより、外為システムも影響が発生するため、要員が参集した。

外為の被仕向処理に関しては、統合ファイル接受基盤が短時間で復旧するという想定のもと、本来復旧前は止めておくべきであった、被仕向の集配処理が定刻の4時に0件で自動実行されてしまった。統合ファイル接受基盤は故障発生後7時間後の6時38分に復旧し、6時57分に3月11日の夜間分のバッチ処理が開始された。8時24分に集配処理の後続処理でエラーが発生した。結果的に12時に事前に準備した手順での復旧ができないことが判明し、マニュアルでのリカバリーに着手することになった。16時15分にマニュアルでの通番情報を銀行の事務企画部に還元するも、リカバリーができず、19時の勘定系システムのオンライン締めに至り、761件について当日中の到着案内が未了となった。

外為の仕向処理については、6時57分の夜間分のバッチ処理開始直後に、異常終了が発生したが、開発子会社の担当が被仕向の対応に注力していたため検知できなかった。11時46分の日付変更処理後も、適切な指示が成されず、13時に外貨決済カットオフタイムが経過し、14時55分には円貨決済カットオフタイムも経過した。15時になってようやく仕向の集配処理が0件で実行されていることに気づき、17時40分に外為データ送信処理が実施され、18時31分にようやくセンター集中記帳処理が完了した。

3月12日の外為送金等遅延の根本原因分析は、図6である。

統合ファイル接受基盤の障害後の自動切替が不調で復旧に時間がかかり、更に外国為替システムの対応での手順ミスがあり、遅延が拡大し、国内他行向仕向外為送金263件の送金処理がカットオフタイムから最大6時間遅延し、外為被仕向送金761件の当日中の到着案内処理が未完了となった。復旧手順の全体統括機能や体制の不足や、復旧に精通した人材配置が不十分だった点や障害シナリオの準備や訓練が不十分だったのではないかと推定される。

図6　2021年3月12日外為送金等遅延の根本原因分析

各障害事例をリスクマネジメント戦略の6観点で何が問題だったかと、金融情報システム自体が外部から直接評価されるタイプのリスクのうち、顕在化したリスクが何であったかを纏めた。

障害事例1では、6観点すべてに問題があった。
障害事例2では、6観点のうち、経営トップのコミットメント、組織体制とガバナンスの観点、ITリスクマネジメント、品質重視の仕組で問題があった。
障害事例3では、組織体制とITガバナンス、ITリスクマネジメント、要件定義最適化の各観点が不十分だった。
障害事例4では、6観点すべてに問題があった。

4件の障害事例からの学びとして、金融情報システムの運用の難易度が高まっていて、各システム別に役割が細分化されている環境下で障害発生の影響見極めが困難になっていることを再認識する必要がある。また証券取引所のような、多組織のネットワークのシステムでは、関係組織の障害対応について、事前に情報収集し、調整しておくことが必要だった。これらの障害事例の報告書と根本原因分析を参考にして、他社でもシステム障害管理体制を見直すことが求められていると考える。

Ⅳ．システム障害管理体制の実効性向上の留意点

ここからシステム障害管理体制の実効性向上の留意点を説明する。
2012年に発表された日本銀行の「システム障害管理体制の実効性向上に向けた留意点」は、2011年の障害を契機として纏めている。障害発生の未然防止や、障害発生時の対応準備、障害管理に対する経営陣の関与のそれぞれに関してポイントを示している。
情報処理推進機構でも、2012年に「情報システム障害の再発防止のための組織的マネジメントの調査ＷＧ報告書」及び『「障害管理の取組みに関する調査」調査報告書』で、「障害管理の取組み」、「障害が防止できなかった時の備え」、「障害管理フレームワーク」に関して、事業者への提言を纏めている。「障害管理フレームワーク」の重要項目として、経営者のガバナンス、管理者のマネジメント、障害管理体制の構築、障害管理活動の有効性を高める方策を示している。

障害事例３（2020年10月1日終日株式売買停止）と障害事例4（銀行の2021年2、3月障害4件連続）に関して、システム障害管理体制の観点で分析した。

まず、障害事例3と障害事例4の4件目（3月12日）の障害に共通するのは、2点ある。第一にバックアップでの自動切替ができなかったことである。第二にハードの障害箇所がシステムのハブとも言える重要な箇所であり、影響が拡大しているということである。

次にシステム障害管理体制の3要素である障害発生時の未然防止、障害発生時の対応準備、障害管理に関する経営陣関与に関して、障害事例3と4に関して分析した。

障害事例3に関しての分析は以下の通りである。障害発生時の未然防止の観点では、ハード障害で不可避な面もあるが、初期値変更の影響確認が不十分であった。障害発生時の対応準備の観点では、証券会社等外部接続者へのコンティンジェンシー計画が不十分という課題があった。障害管理に関する経営陣関与の観点では、終日売買停止の判断は経営として妥当であった。

障害事例4に関しての分析は以下の通りである。障害発生時の未然防止の観点では、2月28日障害では、月末の移行処理を強行した点に難があり、3月7日の障害では、影響確認が不十分なまま、開発・リリースをしていた。障害発生時の対応準備の観点では、コンティンジェンシー計画が不十分で、銀行と運用会社、開発子会社との連携が不十分であった。特に2月28日障害では、他の取引に波及し、混乱や顧客影響が拡大した。障害管理に関する経営陣関与の観点では、障害情報の一元的な共有が行われていない等、経営者の関与が不十分であった。

Ⅴ．ソーシャルレンディング

最後に、2021年4月に調査報告書が出ているソーシャルレンディングについて説明する。ソーシャルレンディングの市場規模は2018年まで拡大していたが、2017年から2018年にかけて最大手のmaneoを含む複数事業者の行政処分があり、ファンド募集を中止した事業者が相次ぎ、募集額は激減した。更に2021年5月には、最大手のSBIソーシャルレンディングでも資金流用の不正融資が発生し、同社は廃業に追い込まれた。

投資家から見たソーシャルレンディングのリスクは、以下の3点と考える。第一に借り手の信用リスク、第二にソーシャルレンディング事業者のガバナンスのリスク、第三にソーシャルレンディング事業者自体の倒産リスクである。ソーシャルレンディング事業者は、多数の借り手と多数の投資家をマッチングするのが理想だが、実態は借り手が少なく、借り手や紹介者の意向を無視できない構造があり、借り手や紹介者寄りの運営になりがちである。

【maneoの事例】
2019年まで最大手として営業していたmaneoの事例を説明する。
2018年7月に提携企業の一つであるグリーンインフラレンディングの不適切な融資で行政処分を受けた。2018年9月、10月には、提携企業の一つであるガイアファンディングのファンドで200百万円の延滞が発生した。更にmaneo自身のファンドでも延滞が発生する事態となった。延滞の大量発生理由には、以下3点と考える。第一に不動産案件の個人向け融資姿勢が引き締められたこと、第二にガバナンス強化の中で、ロールオーバーができなくなったこと、第三に大量のファンド組成の中で、審査不十分な案件が発生したことである。
2019年3月29日にmaneoマーケットは経営改善委員会から「経営改善に向けた提言書」を受領し、瀧本代表取締役が退任するなど、経営体制が見直された。2019年7月以降新規募集が停止となった。

【SBIソーシャルレンディングの事例】
maneoに代わって、最大手となったSBIソーシャルレンディングの事例を説明する。SBIグループの一員として2018年に黒字転換された。
ところが、2021年2月5日に、重大な懸案があるとして、第三者委員会を設置するとの発表がされた。その時点では明らかではなかったが、玄海インベストマネジメントアドバイザーとの協働案件で、実質テクノシステム宛融資の資金使途虚偽という案件だった。2月9日には社長は交代し、4月28日に第三者委員会の調査報告が公表され、虚偽表示や善管注意義務違反が指摘され、145億円の損失が明らかになった。5月24日には、自主的な廃業に追い込まれた。その3日後には、テクノシステムの社長が逮捕された。関東財務局からも業務停止命令が下された。
不正事案の構図は、SBIソーシャルレンディングがSPC特定目的会社に貸付し、そこから、地上権者、発電権利者の支払までは行われたが、建築工事代金の支払資金がテクノシステムから下請け業者に支払われず、借入金返済や損失補填等に流用されたということである。

ソーシャルレンディングの課題として、安定的な借入先の確保ができていないこと、金融機関の融資引締め局面での耐性に難があること、制度がいびつで情報開示に難があること、ガバナンスが不十分な企業があることが挙げられる。これに対し、業界全体での情報開示ルールの策定などが有効ではないかと考えられる。

説明は以上である。ご清聴に感謝する。

【質疑応答】

質問：2021年2月28日の障害に関して、これだけ多数のATMの顧客に適切に案内すること自体が難しかったと考えますが、お考えがあればお知らせ下さい。
回答： ATMで通帳カードが取り込まれかつ電話が繋がらない場合は、後日ご連絡の上、ご本人に通帳やカードは返却する旨の掲示や表示があるだけでも違ったのではないかと考える。

質問：2021年2月28日の障害の報告書では、取引制限緩和が問題視されていますが、障害が発生していた定期預金やCIF排他以外の入出金取引が多数動いていたのではないか。障害発生以外の取引の状況に関して、報告書から読み取れることはあるでしょうか。
回答：取引制限緩和がATMのエラー増加に繋がった事は、報告書以前には着目されていなかったが、報告書で初めて指摘されたものである。障害対象以外の取引については書かれていないので不明だが、閉塞の自動化機能が一種のブラックボックスとなっていたのではないかと考える。

質問：リスクマネジメント戦略の6観点（CORE-OQ）について、６つの中での「重みづけ」や「重要度」のようなものがありますか。
回答：最初の経営トップのコミットメントと支援は重要。重みの差はないが、対応する役員レベルが異なる。CEOレベルでは経営トップのコミットメントと支援と組織体制とITガバナンス、CIOレベルでは6項目全部が必要である。

質問：切替に失敗して大トラブルにつながる事例が多いなかで、切替失敗が発生しないように、開発中や運用中に、どのような監査をすべきでしょうか。体系だった監査手法があるのでしょうか。
回答：体系はおそらくないと考える。ただインパクトの大きい機器に関しては、自動切替ができなかったときに、手動切替の手順を準備しているか等を監査しても良いのではないか。

質問：システム全体を理解する有識者の質と量を維持・承継する方法の一つとして、例えば、システム部門（や、対する業務部門）のキーパーソンについて、人事異動サイクルを長くするという方策は、日本の銀行の人事全体からみて整合しうるものでしょうか（公共部門のシステム開発・運用における課題と通じるものがあると感じ）。
回答：キーパーソンを作るには人事異動サイクルを長くすることが必要だと考える。私が在籍した金融機関でも、専門性が蓄積できるように長期間のサイクルになっており、異動もシステム部門内で行われていた。営業店のような3年程度での異動する人事体系とは別の体系となっていた。

質問：エンドユーザのビヘイビアとして休日のATM利用や突発的な振込事例など従来では想定できなかった事象の発生に起因しているのは運用側には厳しい状況とは思いますが、リスクアセスメントを行う際の想定というか発想力を広げる必要があったのではないかと思いますがいかがですか。
回答：その通りと考える。2021年の報告書では、過去に通帳カードの取り込みが発生していたが、その事象を深く分析していなかったことを指摘している。全く起きていない事象を想像することはできないが、起きた事例からの横展開や、そこから想像して対策をすることが必要ではないか。また他社のトラブル事例等も参考になるので、公開された報告書を、そういう視点で一通り見ていただくと良いのではないか。特に2021年の報告書は167ページもの情報量があるので、貴重な資料である。また金融機関では、どうしても外部のベンダーに依存してしまいがちで金融機関内のスキルが高まらない傾向があるが、完全な内製化はできないまでも、重要な点のコントロールを金融機関の人が行うことも必要だという印象である。

質問：今後ますますFinTechサービスが普及されてくる中で、利用者の立場としてFintechサービスを利用する場合、新たなビジネスとしてFinTechサービス事業者と連携する場合について、リスクマネジメント・システム監査の観点から留意する事項等がありますか。
回答：事業者として提携する場合は、API接続のチェックリスト等の記載を参考にしてポイントを押さえて、相互に共有して確認すると良いかと考える。利用者の立場としては、何がリスクなのかをきちんと説明している企業であるかを確認してから利用すると良いのではないか。

質問：2月28日の障害は、「取消情報管理テーブルINDEX」のオーバーフローと関連する自動取消処理の不具合が起因となりましたが、これは構築時から潜んでいたもので、品質を十分管理していた開発プロジェクトでも見逃してしまうような実装上の不具合であり、システム監査が見つけるのは、相当工夫が必要かと思いますが、そのあたりについてはどのようにお考えでしょうか。
回答：2011年の報告書と異なり、2021年の報告書ではシステム監査への期待が書かれていないのが寂しいと考えている。報告書に関しては、実効性ある対策で3点触れていない点があると考える。第一にFG、銀行、開発子会社、運用会社との連携に関しての対策が明示されていないこと。第二に営業店等の現場で自発的に対応している部署もあったが、現場の動きを活用する視点がないこと。第三に監査部門の活用が提言されていないことである。その意味で、監査がシステム部門とは視点を変えて、不具合が発生した際の準備をしているのかを問うだけでも意味があると考える。
以上