590Picks
Pick に失敗しました

人気 Picker
別の合併メガバンクの人が言っていたのですが、以下の話が心に沁みました。
特に、合併時に、どの部分で降りる、引くを決めるかはトップの仕事というところ。

・システムはつなぎ合わせは、やばい。どれか一つのシステムを活かして、他を吸収するのが良い
・銀行の名前は、A社が取る。英語名はB社が頭をとる、システムはC社を採用する、などが、良い統合ではないか
・その際にはトップが「我が社はここは降ります」と言わなくてはならない。部下はトップを守ろうとする。トップしか、降りる、引くの決断はできない

経営者の覚悟、経営判断が、その後に長く負の遺産を残すことになりますね…他山の石にします。

話は変わりますが、デジタル庁が発足し、これから各自治体がDXを進めることになります。日本の基礎自治体(市区町村)は、1741あります。

それぞれがシステム化を進めた結果、どこかで、市町村合併とか、起こる可能性は十分あると思います。(今までも市町村合併は、良くありましたし、これからも、少子高齢社会で人口減少しますし)

その際には、システムの統合が必要になります。
その時に、このようなことを繰り返さないことを今からデジタル庁は意識しておかないといけないと思います。

市町村合併して、自治体システム止まりまくり、住民票でないとか、マイナンバー流出とかしたら、大変ですので…。
システム開発から離れて長いのですが、記事中にあった「バッチ処理は時代遅れ」ってホントですか。夜間バッチ対応の夜番経験者としては感慨深いんですけど。

しかし、システム障害多発ですが、経営統合の際のシステム統合方針について、教科書に乗りそうな事例ですね。おそらくこの事例引けば、「M&A後のシステムは新しく作り直しましょう!」と言いやすくなりそう。
以前、伝聞とことわってコメントした内容が記事化されています。

要するに、当初のシステムのプログラム言語を使える人材がいないので、根幹を治すことができないということですね。

長期間システムを止めて抜本的に再構築する訳にもいかないでしょうし…。

素人なりに考えると、今のシステムを動かしたまま新しいシステムを同時並行的につくり、どこかでチェンジするかバックアップとして使うしかないのでしょうか?

技術的に可能かどうかはわかりませんが…。
たまたま昨日、某銀行のシステム部門の現場で数十年に渡って働いて退職した人と雑談していてみずほ銀行さんの話になって「全面的に改定したはずなのになぜこうした問題が起きるの? システムが新しくてバグが残っているから?」と聞いたら「いや○○銀行のシステムにサヤ寄せして拡張しただけで言語はCOBOLなんですよ。流石にうちの銀行はとっくに使うのを止めていて、信じられない話です。これからも問題は起こりそう」と聞かされて驚いたばかりです。
『史上初めて、銀行が自社の勘定系システムを全面再構築した』という報道を私は信じていたわけですが、その人の話は『一から作り直した「新築」ではなく、既存の「塔」をさらに建て増しした「改築」だったと考えなければ、説明がつかない謎があるのだ。先に触れたCOBOLがいまだに使われているのである』という一文と符合します。
まさかとの思いで聴いていたけれど、職業生活の大部分を銀行のオンライン部門の現場で過ごした人だけに、真の事情に通じているのかもしれないな・・・ もしそうなら「これからも問題はおこりそう」という感想も当たっていそうで心配です (・・;
これはどれだけ真実かはわからないのですが、頻繁に起きる障害が解決もしないしちゃんと説明もできてないからユーザーとしては不安になりますよね…
COBOL問題は銀行だけではなく、大手の基幹系にかなりまだ残っています。金融は特に根深いと思いますが、これは大きな課題。COBOLが悪い訳ではなく、古い技術を残すとそれを扱うエンジニアがいなくなること。特に若いエンジニアがわざわざCOBOL覚えようというインセンティブ無いことが問題になります。持続可能な社会とよく言われますが、システムも同じで作って終わりではなく運用し続けられることが大切。みずほの例は日本企業の悪しき例として今後も語り続けられるだろうなと。可能であれば「みずほでも潰れた」くらいの激震が走ると、皆襟を正してくれるので良いのですが。まだその危機感が日本企業には無いと思われる。
キメラはITシステム以外にも、色々な社会の仕組みの中にいますね。
記事を読んで日本型雇用もその一例のように思いました。
銀行の勘定系だけでなく、企業の根幹を担うシステムは大規模でかつ毎日変更しています。要するに業務が複雑で変更が多いのです。そして、その業務の隅から隅まで分かっている人はいません。顧客向けのサービスはどんどんできるし、法律もどんどん変わります。その都度プログラムのどこまで影響するのかを理解し変更してテストするわけです。母体が複雑になればなるほど、影響範囲は広がり、漏れやミスも増えます。そしてテストデータですら異常データなどを網羅性高く作ることの難易度が凄く高いはずです。業務自体が分かっていて、どのようなトランザクションが発生し得るのかが洞察できなければならないわけですが、そのような人材が恐らくめちゃくちゃ乏しいのだと思います。

システム更改は人財育成から始めなければならないわけです。もちろんそれを長期的に実践している銀行もあります。

みずほの実態はこの記事通りかどうかは分かりません。しかし、絶対に乗り越えられるはずです。病根をあぶり出せれば、解決は時間の問題でしょう。しかし、それが難しいのでしょう。頑張ってほしいものです。
「いまや、システムの全容を知る者はみずほにも、ベンダーにもいない」
これが本当であれば、今後も含め、かなり不安な状況だと感じます。
バッチ処理は全然今でも使います。
オンラインバッチかオフラインバッチかによって全く異なりますし、どちらにしても要件次第では検討します。

記事に出てくるITジャーナリストの方が正しい認識をお持ちなのか、少し疑問です。まぁ週刊誌特有の切り抜きでしょうかね。


あと銀行同士のシステム統合は片寄せがベターな選択肢と思います。
実績あるシステムに乗せて安定させるのが先です。
統合に伴って新しいのを毎回作ってそこに載せる選択なんてしたら死にます。障害起きた時に業務や運用、事務でカバーしようにもそちら側も混乱してるはずなので。
国内3大メガバンクの一つを持つ銀行持株会社。銀行、信託、証券の一体戦略を推進。2016年に傘下の資産運用会社を統合してアセットマネジメントOneを設立。
時価総額
7.59 兆円

業績