銀行勘定系システム刷新、大規模障害で揺らぐ選択

銀行勘定系システム刷新、大規模障害で揺らぐ選択
https://www.nikkei.com/article/DGXZQOUC155500V10C21A7000000/

 ※ 残念ながら、システム開発にも、プログラミングにも、コーディングにも、仕事として関わった経験は無いんで、確たることは言いかねる…。

 ※ しかし、「システムの改変・進歩」と言ったことは、「5G」については、随分と文献も調べたんで、その観点から感想を語っておく…。

 ※ それは、「システムの進歩」と言うものは、「日々の業務の遂行・執行の中にこそ、そのタネがある。」ということだ…。

 ※ 「5G」の場合は、明確に「10年単位で、通信データの級数的な増大」というものが有り、関係者一同「その爆発的な増大に対処するための、「仕様」の改変・策定」という共通認識があって、それが「新ジェネレーション策定」の原動力となっているような感じだった…。

 ※ そして、その「問題意識」「改変のタネ」は、「現在のジェネレーション」「現在の規格」の中にこそ、潜んでいる…。

 ※ 絶えず、「ここをこう改変したら、もっと速く、もっと大量に、もっと多接続で、データを送信できるのではないのか。」と考え続け、「新規格を提案する」ことが、「次のジェネレーションの規格」を形作って行く…。

 ※ そういう「日々の改変への志向・ベクトル」が無いところに、いきなり「システムを全面刷新」したところで、「木に竹を接ぐ」と言うものだろう…。

『銀行業務の基幹である勘定系システムの刷新を巡り、銀行間で明暗が分かれている。全面刷新に踏み切ったみずほ銀行などで大規模システム障害が起きた一方、アプリケーションの刷新は一部にとどめ、システム基盤の更改を進めた銀行で目立ったトラブルは起きていない。移行コストやリスクを抑えるため「勘定系システムは塩漬けでいい」という声も強まるなか、その選択肢は果たして持続可能なのか。

みずほ銀行と静岡銀行に共通点

2021年に入り、銀行で大規模なシステム障害が2件起きた。1つがみずほ銀行だ。2月28日、定期性預金システムのトラブルがATMに波及し、4000台以上のATMが稼働を一時停止した。しかも、それから2週間あまりで立て続けに別の3件ものシステム障害を起こした。

もう1つが静岡銀行だ。1月4日に他金融機関から同行宛ての振り込みの一部が遅延したり、セブン銀行のATMで同行口座の入出金ができなかったりするシステム障害が起きた。その後も二重振り込みなどトラブルが続発した。

実は両行には共通点がある。勘定系システムを全面刷新したことだ。

みずほ銀行は19年7月、4000億円台半ばを投じて、新勘定系システム「MINORI」を本格稼働させた。新システムは旧みずほ銀行の勘定系システムである「STEPS」や旧みずほコーポレート銀行の「C-base」、みずほ信託銀行の「BEST」からソースコードを一切引き継がず、新規開発した。

静岡銀行は21年1月、日立製作所と共同開発した勘定系システムを稼働させた。旧システムは富士通製メインフレーム上で動作していたが、オープンソースソフトウエアであるLinux(リナックス)ベースの新システムに置き換えた。

当初は17年中の稼働を見込んでいたが、業務分析や現行システムの解析などに手間取り、稼働時期を2度延期した。産みの苦しみが大きかっただけに、新システムの稼働は悲願だった。

問題の先送りではないのか

両行の大規模トラブルは、今後の勘定系システム論議に大きな影響を与えそうだ。勘定系システムのアプリケーション部分に極力手を加えず、オープン化やクラウド移行などシステム基盤の更改にとどめる銀行が増える可能性がある。

事実、両行の大規模トラブルに前後する形で、こうした方針を打ち出す銀行も出始めている。横浜銀行や北陸銀行、北海道銀行、七十七銀行、東日本銀行の5行は24年1月にも、共同利用システム「MEJAR」について、富士通製メインフレームからLinuxベースのオープン基盤に移行する。ただし、アプリケーション部分はNTTデータの勘定系パッケージ「BeSTA」を温存する。

三井住友銀行は25年度までに勘定系システムを刷新するが、既存のプログラム資産にほぼ手をつけず、システム基盤の更改とアーキテクチャーの見直しを主体にする。移行コストとリスクを限定するためだ。投資額は約500億円で、みずほ銀行がMINORIの開発に投じた金額の9分の1程度の水準だ。

勘定系システムを手掛けるNTTデータや日本IBMといった主要IT(情報技術)ベンダーもこうした方針を後押しする。

全面刷新を避ける潮流に対して、1つの疑問が浮かぶ。アプリケーション部分に手をつけず、システム基盤の更改に限定するのは、問題の先送りではないかという点だ。勘定系システムを塩漬けにし、中身を知る人材がいなくなれば、新サービスの開発に時間を要し、システム障害の影響も拡大しかねない。

一方、勘定系システムの全面刷新は莫大なコストや大規模障害のリスクを抱える割に、メリットが見えづらいという側面もある。

コストやリスクを抑えながら、いかに時代の変化に対応しやすい仕組みを手に入れるか。現実解はシステム基盤の更改と並行し、商品・サービスや事務プロセスの整理を進めることだろう。こうした地道な取り組みが将来の選択肢を広げることになる。

(日経クロステック/日経コンピュータ 山端宏実)

[日経クロステック2021年7月15日付の記事を再構成]』

地銀、深刻なIT統治不全 ベンダー頼みのツケ重く

地銀、深刻なIT統治不全 ベンダー頼みのツケ重く
金融PLUS 金融グループ次長 亀井勝司
https://www.nikkei.com/article/DGXZQOUB212F90R20C21A6000000/

 ※ どうも、最大の問題点は、「銀行側に、ITに精通した人材が無く」「ベンダー側に、経営・業務に精通した人材が無い」というところのような気がする…。

 ※ その両方の領域を、つなぐ人材が、決定的に欠いているという気がする…。

 ※ これを、「プライオリティの判断」という観点から見れば、従来・旧来の「銀行経営におけるプライオリティの判断」と、「IT導入におけるプライオリティの判断」が、決定的に乖離しているという気がする…。

 ※ 例えば、あるITシステムを導入しようとしているとする…。
 当然、そこにおいては、「導入することによるメリット」と、「導入したことによるデメリット」があり、そこを「抽出」「利益衡量」することが必要となる…。
 
 ※ さらには、「パッケージソフト」を導入して、安上がりに上げようと考えたとする…。

 ※ その場合、その「お仕着せ」による従来の業務執行形態を「変える必要があるのか、否か」「そのメリット・デメリット」の利益衡量をどう図るのか、などという問題も出てくる…。

 ※ 「お仕着せ」からハミ出した、「特殊業務」を残すのか否か、そこを組み入れて、一から「システム発注」するのか否か、その場合の後々の保守・管理業務のコスト計算をも含めた「プライオリティの判断」が必要となる…。

 ※ こういうものは、従来・旧来の「銀行の経営判断」とは、全然違う…。

 ※ そういう「判断」や、その判断に必要な「要素の抽出」が、できる体制になっているのか…。人材、手順の構築は、なされているのか…。

 ※ そういう辺りが、決定的に重要なんだろう…。

 ※ さらには、「新技術」への対応・拡張性…、という問題もある…。

 ※ オンプレミス全盛時に、クラウド環境への「備え」を考えておくということは、不可能事かもしれない…。「神対応」かもしれない…。

 ※ しかし、そこの「備え」が無いと、「後れを取って」、競争における敗者となる…。

 ※ こうして検討してみると、いわゆる「日本企業」が、決定的に「苦手」としている「分野」「事例」のようだな…。

『みずほ銀行で起きたシステム障害は、システムが銀行経営に死活的に重要なことを端的に示した。ただその重要性と裏腹に、銀行、とくに地方銀行自身が主体的に関与できているかといえば疑問符がつく。』

『「監視を厳しくしないといけない。システム対応できないか」(地銀幹部)

「半年後になりますね」(システム会社)

NTTドコモの電子決済サービス「ドコモ口座」に絡む不正送金があった2020年9月。ある有力地方銀行とシステム会社で交わされた会話だ。新しいサービスの開発からマネーロンダリング(資金洗浄)につながる不正送金の対策まで、システムは銀行経営の要だが、開発や運用はシステム会社に頼っている実態が浮かぶ。』

『システム会社はベンダーと呼ばれ、みずほ銀行が4500億円を投じて導入した新システム「MINORI」は日本IBM、富士通、日立製作所、NTTデータの4社が中心となって開発した。もちろん、数千万口座を抱えるメガバンクと地方銀行のシステムには差があるものの、地銀も平均して年間50億円弱のシステム関連経費がかかっている。

金融のデジタル化が進み、システム部門の戦略的な位置づけは高まっているが、上位地銀でさえシステムの実務部隊はベンダーにほぼアウトソースしているところも多い。効率化の一環で自行のシステム人材をベンダー側に移管し、開発・運用を委ねている。ドコモ口座で問題になったインターネットバンキングから「○○ペイ」にチャージする場合も、自行からの出金にもかかわらず、その取引情報を保有しているのは銀行自身ではなくベンダーだという。』

『特定のベンダーの製品やサービスに強く依存することで、他社の同じような製品への切り替えが難しくなることをベンダーロックインと呼ぶ。言い換えれば囲い込みで、公正取引委員会もかねて問題視してきた。機動的に機能を追加したいと思っても時間と多額のコストがかかる。それでもベンダーに依存しているため「言い値」を受け入れざるをえない構図が浮かぶ。』

『銀行業務の基幹である勘定系システムを日本ユニシスからマイクロソフト社のクラウドサービスに移行した北国銀行のように、ベンダー丸投げと決別する地銀はまれだ。北国銀はクラウド上に集積した顧客データを活用し、取引やサービスの利用実態を人工知能(AI)などで分析。営業やコンサルティングにつなげる計画で、システムのフル活用を経営の中核にすえる。

システムに関していえばベンダーが銀行に対して優越的地位に立っているように見えるが、ある金融庁関係者は「だからといって地銀が『被害者』かといえば、それは一つの断面だ」と指摘する。ベンダーロックインが機動性を奪い、高コストになっている面は否めないが、ベンダー側からみれば「非効率で硬直的な事務を温存しているため、それをつなぐのに複雑な仕組みが必要になり、結果的にコストが高くなる」という声も漏れる。』

『実際、システムを共同化している信金と地銀のコストの差は、システムにあわせて事務も共通化しているかどうかの違いが大きい。システムと一言でいっても、債務者の情報を管理するシステムや取引内容を記録するシステム、担保物権を管理するシステムなど多岐にわたる。そのうえ、ほぼ取り扱いがない商品もスクラップすることなく新たな機能を付け加えようとすると、「結果的にアクロバティックなシステムになり、その分コストも上がる」(金融庁関係者)という。』

『自行に必要な機能を絞り込み、コストを減らして機動性を高めるために何が必要かを把握し、それにあわせて不要な事務を削る判断がIT統治(ガバナンス)だとすれば、ベンダーロックインはその欠如が招いた帰結にも見える。もっとも、マネロン対策など迅速に対策を打つ必要があるシステム改修で多額の費用を求め、より安価なサービスを提案する他社を阻むのは優越的地位の乱用だ。金融庁は銀行の委託先であるベンダーに立ち入り検査することもできる。

金融犯罪への対応は新たな手口が出てくるたびにシステム的な対応が必要になり、金融サービスのデジタル化もシステムの裏付けがあってこそだ。ベンダーロックイン問題は、「銀行はシステム産業」といいながらシステムを傍流に追いやってきた姿勢に変化を迫っている。』

『浅川直輝
日経BP 「日経コンピュータ」編集長
コメントメニュー

分析・考察企業内のITシステムを構築・運用する情報システム部門は本来、社内の業務とシステムの全体最適を考え、ときには経営陣や事業部門に「このやり方ではダメだ」と業務改革やサービス改革を迫ることもいとわない重要な部門です。

そんな情報システム部門の役割を外部のITベンダーに丸ごとアウトソースすれば、内発的な改革は起こりようがありません。ITベンダーも「良かれ」と考えて全てのIT関連業務を受託すれば、結果として顧客企業のデジタル変革(DX)の機会や意欲を奪う結果につながりかねません。

DXが企業競争力に直結する時代、企業とITベンダーの関係を今一度考え直すべきでしょう。』

IBMに逆転敗訴した野村HD

IBMに逆転敗訴した野村HD、強い事業部門抑えきれず
https://www.nikkei.com/article/DGXZQOUC1075J0Q1A610C2000000/

 ※ ヒデーもんだ…。

 ※ 木村岳史大先生の、「日本企業は、勝手にやっている現場の集合体。だから、DXは、絶望的にうまくいかない…。」との指摘そのままだ…。

 ※ こういう「勘違いヤロー」は、どこにもいるんだろう…。

 ※ おそらく、単に、個人としての立場だけではなく、「ある事業部門」全体・全員の「利益の代弁者」というような立場を、背負っているんだろう…。

 ※ しかし、プライオリティのつけ方が、根本的に間違っている…。

 ※ 一体、何のために、何の目的で「海外製パッケージソフト」を導入しようとしているのか…。

 ※ そこいら辺の、「大所・高所からの判断」及び「指揮監督」を行うのが、「経営判断」を担っている「上層部」「経営陣」ではないのか…。そいつらは、一体、何をやっているんだ…。

 ※ 上層部も、おそらく、「回っている現場」に手を突っ込んで、反発を買いたくないんだろう…。「触らぬ神に祟りなし」だからな…。

 ※ そうやって、「責任回避」しているうちに、傷口はドンドン広がり、事態はどうしようもなく悪化して行く…。

 ※ みずほのシステム障害の背後にも、こういう問題が横たわっているんだろう…。

 ※ しかも、みずほの場合は、それが「×3」だからな…。

『東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券の「X氏」の振る舞いだ。

当時、投資顧問事業部(判決文では「投資顧問部」)の次長だったX氏は、パッケージソフトに合わせて業務を最適化するという会社の方針に反して自身の現行業務を維持することに固執。プロジェクト途中で追加要件を多発し、日本IBMの担当者らに対して「辛辣な他罰的、攻撃的発言」(判決文)を繰り返した。

東京高裁は判決文でX氏について「自分の庭先(担当業務)をきれいにすることだけを考えている」と認定。断続的に変更要求を多発するX氏から、目標としていた13年1月の稼働開始に間に合うのかについて「質問がなかったのが不思議なくらいであった」(判決文)などと指摘した。』

『さらに判決文や裁判記録の資料を読み込むと、発注側という強い立場を利用したX氏の横暴な振る舞い、それをコントロールできなかった情報システム部門、この状況に振り回された日本IBMという構図が浮かび上がってくる。

東京高裁はX氏について「野村証券の投資SMAFWのフィー計算徴収の要件・ルール・計算手法等の知識を属人的に独占していた特定の1名の社員」(判決文)と説明している。』

『X氏は投資顧問事業部で複雑な業務を担い、新システムの要件を洗い出すうえで重要な立場にあったとされる。裁判記録によると、システム開発プロジェクトの体制はおおむね下記の通りだ。

同プロジェクトでは海外製パッケージソフトをカスタマイズ導入することになっていたが、概要設計フェーズの開始直後から要件定義書になかった追加要件が野村証券から多発した。

その後、設計・開発やテストフェーズに入っても変更要求は続出し、13年1月の稼働を諦めて総合テストの中止を判断するまで五月雨式に続いた。変更要求はX氏からだけではなかったが、多くがX氏の業務関連だった。』

『工数の膨れ上がりを看過できない状況にまで追い込まれた日本IBMは、業務の見直しやシステム化対象の絞り込みなどによる工数削減を野村側に提案。しかし、わずか14口座を対象とした処理の手作業化(システム化から除外)による工数削減でさえもX氏の猛反対を受け、実現できなかった。』

『X氏の横暴な振る舞いは判決文の随所で見られた。

例えば野村証券と日本IBMが11年7月上旬に開いた打ち合わせの場での出来事だ。工数のさらなる増加を懸念した野村証券の「IT戦略部(同社情報システム部門に相当)」部長から「今後大きな工数追加が判明する可能性はないと認識してよいか」と念を押す発言があった。同席していたX氏はここで沈黙を貫いた。

だが、X氏は後日開かれた日本IBMとの別の打ち合わせの場(野村証券側はX氏のみ)で新たな業務要件を追加。そのうえで「今後もIBMに伝えきれていない要件が見つかる可能性がある」などとした。X氏はその後も変更要求を多発し、日本IBMに対して「他罰的かつ攻撃的な苦情を述べることを繰り返した」と判決文に記されている。

X氏は社内で強い発言力を持ち、情報システム部門も意見を言いづらい雰囲気があったようだ。例えば日本IBMの担当者がカスタマイズ量を削減するため、発生頻度の低い業務要件の入力を手作業にしてはどうかと提案したときのことである。

X氏は手作業化によるリスクやオペレーション時間の短縮を理由にこの提案を拒否。「同席したIT戦略部長及び投信顧問部長はX氏の反対を黙認した」(判決文)』

『システム開発を巡る訴訟に詳しいアドバンスト・ビジネス創造協会(ABC協会)の細川泰秀副会長は、「強い発言力を持つユーザー部門の担当者がプロジェクトをかき回すケースは非常に多い」と話す。ITベンダーは「追加要件が出たら費用が発生する旨を伝え、身をていしてブロックする努力が求められる」(同)

野村側の断続的な変更要求に対し、日本IBMの担当者がどこまで止める努力をしていたのか詳細は明らかになっていない。ただ判決文によれば、日本IBMがプロジェクト途中で野村証券に仕様凍結を求め、それでも変更要求を続けた野村側の対応を東京高裁は問題視したようだ。

裁判では複数の証人が出廷したが、当のX氏は出廷せず、同氏の肉声が法廷で聞かれることはなかった。日経クロステックの取材によると、X氏はすでに野村証券に在籍していないことが分かっている。退職理由について野村HD広報に問い合わせたところ、「個人情報に関わることであり、回答はできない」とした。』

『野村HDは現在、最高裁に上告を申請中だ。期限までに上告の「理由書」を提出し、それを基に最高裁が上告を受理するか判断する。ただ一般にこの結論が出るまで数年かかり、「システム裁判で最高裁が上告を受理するケースはほぼない」(識者)とされる。』

『システム裁判はこれまで、ITベンダー側に厳しい判断が下されることが多いとされてきた。だが、ABC協会の細川副会長によると「ここ数年は裁判所がプロジェクトの実態を精査したうえで、ユーザー企業側の責任を厳しく問う判決を下すケースが増えている」と話す。

実際、病院情報管理システムの開発が失敗した責任を巡り旭川医科大学とNTT東日本が争った裁判では、17年の控訴審判決でユーザー企業側の旭川医科大学に責任があるとの判決が下った。いったん仕様を凍結した後も追加開発を要求したユーザー企業側の姿勢が問われた。

「システム開発にはユーザー企業側の協力が不可欠という理解が広がり、風向きが少しずつ変わってきている」(細川副会長)』

『ユーザー企業内における意思統一と協力関係も極めて重要である。今回、ユーザー部門による変更要求の多発を情報システム部門が抑えきれなかった構図は明らかであり、情報システム部門の責任は重い。

ただ、かつて多く見られた「ユーザー部門の立場が強く、情報システム部門が弱い」という関係性が上記のような事態を招いたのであれば、その責任は経営層にあると言わざるを得ない。

経営層が現場任せにすることなくリーダーシップを発揮し、社内の意思統一を図っていればこのような事態には至らなかった。ユーザー部門と情報システム部門のぎくしゃくした関係も生まれなかったはずだ。野村-IBM裁判は改めて教訓を示した。

(日経クロステック/日経コンピュータ 鈴木慶太)

[日経クロステック2021年6月10日付の記事を再構成]』