みずほ社長とみずほ銀行頭取が辞任へ システム障害の責任を取り [スペル魔★]
■ このスレッドは過去ログ倉庫に格納されています
みずほ銀行の藤原弘治頭取が、相次いだシステム障害の責任を取って辞任する見通しとなったことが19日、分かった。辞任が不可避となっていた親会社みずほフィナンシャルグループの坂井辰史社長の辞任も固まった。
https://news.yahoo.co.jp/articles/008e960e6d8c995e110a7df6c5a61903f54df430 みずほの下と仕事で関連持っても思うことはマニュアル人間しかおらん上にマニュアルにない事は絶対やらないやらせたいならマニュアル作れって話が必ずある点社風なんだろうな これで一連の騒動は幕引きと見てるのか市場は軟調とはいえ比較的落ち着いてるな
もしかしたら買い場かもしれない どうせまた障害起こすんだろうし後任やりたがらんだろ 旧朝鮮銀行 外為法違反 マネロン
答え出てなくね? いまさら銀行のシステムなんて手垢の付いた外国産でいいんじゃねえの
朝鮮向けの特別なシステムでも組んでるなら別だが >>174
それでいて、トラブった時にはマニュアルにない対応を「求めてくる」みずほ総研。
自分でやらずに奴隷にやらせるあたりがミソね♪ 逃げたな
トラブル続きな上に社内に財務省が常駐して監視
さらには障害対策に東京大阪にシステム分轄するとかいう次のトラブルの仕込みも完璧 >>173
やすすぎw
経営陣でも100万以下ってありえないとわかってもらえないとねw
技術的なことはわからんでも工数とかの資料はたくさん見てるはずだし みずほがいちばん行けないところは3社統合の際にどこも自分たちの仕様を譲ろうとしなかった上に別々のベンダー用意してきたところ
ただでさえ複数社が使用する大型基幹プログラムとか障害起きやすいのに内部分裂してるとか起きるべくして起きたってかんじだな >>165
そりゃ優秀なのが寄り付かないわけだww 次の社長と頭取は三振アウト制。2回までは仕方ないだろう。 せっかく前田が形を作って辞めたのに
全部ぶっ壊しやがった、さすがダメポ いよいよみずほも大蔵にひれ伏すことになりそう
社長は内部昇格、頭取は大蔵OB(財務、金融)になるんだな
むかし、地方銀行をつぶしたくない大蔵が、銀行局長OBを持って行ったが、けっきょくつぶれてしまった。
大蔵の人も、みずほ(富士、DKB,興銀)なんかにはいきたくないかも。 >>182
金融庁ね。
ゴミシステムの面倒を金融庁に丸投げの記事あったよね。税金投入と同じ意味なんだが恥ずかしくないのかね? >>180
自分たちはマニュアルで動かないから仕方ない
ここに限らず大企業はどこもそうだと思う
ちなみにマニュアル以外のことを下請けにやらせた上で
その特殊対応もマニュアル化させて報告させるまでがおしごと 何で動いてるか分からないシステムが止まる度に責任取ってたらきりがないぞ。 次のみずほ銀行頭取は
頭取就任が保留になってたあの人か こんな事になるなら、合併の時に
ジャンケンさせて勝った方のシステムをそのまま使った方か良かったなw 日本の大都市銀行くんは国際的な信用を落としてますねぇ(笑) 内部の足の引っ張り合いだろうな
興銀出身だし
この銀行の宿命 >>15
闇金になるからなw
公金入ってるから ヤー公と同じになる UFJが使えないみたいだけどスレ立たんなぁ
今日給料日なのに 4500億円で完成したシステムに謎の障害とかすごいな
新国立競技場が3棟建てられる金額に匹敵するのか 文系IT音痴が今できることは辞めることぐらいだからなあ >>184
それを反省して一回統合システム作り直して
この始末なんだよ。
現場では派閥割れしてるんだろうけど。 >>202
一つの皿の上のスパゲッティをイメージしてるだろ?
三つの皿の上にまたがってつながったスパゲッティだぞ
しかも味が皿ごとに違う (-_-;)y-~
丸投げ派遣システムの底辺が、遂にトップの首を獲れる時代が来たか。 >>193
納品終わってるってことは仕様通りに作ったんだろ 合併した3銀行は権力争いなんかばかりしてないで真面目に働け ナンバーズが三ヶ月くらい異常だったのはこいつらの秘密の退職金かな 最善の策
三菱か住友に吸収
楽天銀行かPAYPAY銀行に吸収 >>213
その統合してまた失敗したシステムを今度は東京と大阪で二系化して運用するとかいう高度なギャグを始めた >>202
そりゃつらいな。下手の書いたプログラムを読むのは超絶苦行
メインからの呼び出しが10階層を超える超絶プログラムを見たことはあるが
プロジェクト自体がほぼ爆発していた >>97 >>200
それ、ロックフェラーがやらせてたことだよ。
フェラって名前を子供時代に馬鹿にされたロックフェラーシニア(経済学部卒)。
FUKUOKA出身を起用しただったのだ。福岡って、英語だと、ファック岡って聞こえるから。
なので、マドンナの最初の日本ライブの場所も、FUKUOKAだったね。何でも福岡。
けど、ロックフェラー失脚したから、もう終わったけども。。。 ジャップにITは無理。
デキる人間がいたとしても「おい、そこのパソコンオタク」扱い。
銀行システムは最強のIT企業LINEに任せよう。
LINEバンク♪ >>226
アレは元々東京&千葉で二重化してたのを
東京&大阪に変えただけじゃないの? 社長が変わったところで指摘されてる社風とかの問題点を解消できるもんかね? それより外資銀行が逃げ始めた韓国からどう撤退するんだよみずほ銀行 >>1
システム障害中に海外送金してたらしいけど
多分北か南だろ
やっぱりみずほの障害と半島は繋がってたんだな
国に睨まれたから今後出来なくなるね みずほ銀行って時々韓国政府に融資してるんだけど、大丈夫なのか? NHKもさ、表に出ないだけで
ずっと利権を掌握し続けてる一族とか実在しそう。 >>77
上位者の尻を見つめ仕事のフリをしていることを上手く説明する自称コミュニケーションに長けた人材だ! >>233
祖国から逃げて来た情けない負け犬は
黙っとれ。
祖国からは裏切り者扱いのくせに。 こんなアホウな事が起きない様に金融庁は
先ず、行内の隠語を統一するくらいしろよw >>142
確かに会話は面倒だが、要点を絞ってコミュニケーションとらないとな。
仕事はチームワークだから、一人の天才がいるだけでは回らないんだぜ。 三菱UFJ信託銀行もシステム障害やらかしてるみたいだな。
頭取辞任待った無しだ! 奴等は何でも福岡の”せい”にしてくるから大変わかりやすい >>239
日本IBMから副CIOを迎えたらしいね >>234
それならまだ安心かな
まさか実績あるネットワーク構成を変えたりはしないだろうし >>230
データベースで、サブクエリ4段くらいになってる超絶長いクエリを見たことがあるぜ/(^o^)\ 東電みたいに海外に逃げる必要もないだろうし、後は国内で悠々自適の生活送るだけだろ >>245
お前らの祖国と関係のある
みずほとUFJ銀行じゃないかよ。 あんとき俺が統合プロジェクトのPMになってたらなあ
あそこののひとはPMOのことさえよくわからん人ばっかだったから
情報システムはシステムを作るよりまず業務プロセスを固定化することや
統一されたデータを創ることの重要性を訴えたが、
あまり理解されていなかったよ (-_-;)y-~
バブル崩壊がいまだに続いてる感じがしてならんわw そもそも自社開発しないといけないものなのか?
銀行のシステムなんて似たり寄ったりだろう。
システムを購入すればよい。
FX業者だって取引システムを内製しているわけではない。
珍しく内製していた業界大手の外為どっとコムは「100均セール」「半額セール」などと
呼ばれるシステム不具合を起こして営業停止処分を食らった。
日本人にシステム開発は無理だから海外から買えばいいだけ。
「ご安全に」と挨拶してKYやってからシステム開発する日本人は
世界から淘汰される。 とりあえずしばらくは再トラベル発生は起きない目処が立ったからこのタイミングで責任取ったんかな?
一時期の障害頻発してた時期はあまりに連続すぎて
再発防止に努めます とすら言えなくなっちゃってたのに >>244
心配するな
大丈夫じゃない時は公的資金を投入するからみずほは大丈夫だよ https://news.goo.ne.jp/article/jbpress/business/jbpress-66788.html?page=2
勘定系システムの統合には、大きく2つのパターンがある。
一つは全く新しい情報システムを構築して、各行が既存システムから移行する。
もう一つは、どこか一行の既存のシステムに他社が移行する。後者は片寄せ統合という。
合併期においては、優劣の開いたシステム間で統合が図られることが多かったために、原則的に先進的なシステムか、規模の大きいシステムに片寄せされる片寄せ統合が多く行われた。
三菱UFJ銀行の場合は、旧三菱銀行のベンダーであった日本IBMのシステムに片寄せされた。
三井住友銀行の場合は、旧三井銀行のベンダーであったNECのシステムに片寄せされた。
さて、みずほFGであるが、旧みずほ銀行の勘定系システムのベンダーは富士通であった。
ところが、全く新しい勘定系システム「MINORI(みのり)」のシステム構築は、旧みずほ銀行の2002年および2011年にも大規模なシステム障害を受けて開始したこともあり、富士通、日立製作所、日本IBM、NTTデータ(プロジェクト・マネジメント・オフィスの支援を担当)の4つのベンダーが新システム構築に参加した。
以上まとめると、みずほFGは、富士通、日立製作所、日本IBM、NTTデータのマルチベンダー体制(注)でシステム開発を推進した。
他方、三菱UFJ銀行および三井住友銀行は、それぞれ、日本IBMおよびNECのシングルベンダー体制でシステム開発を推進した。
各銀行のシステムベンダーである富士通、日立製作所、日本IBMおよびNECは、いずれも日本を代表するシステムインテグレーターであり開発能力に遜色はない。
よって、筆者は、みずほ銀行の採用したマルチベンダー体制が、システム障害発生に何らかの影響を及ぼしているのではないかと考えた。
一般に、システム構築の手法には、マルチベンダー体制とシングルベンダー体制の2通りがあるが、各々にメリットとデメリットがある(メリットとデメリットについては後述する)。
しかし、大規模コンピューターシステムの開発にはベンダーの数が増えれば、それだけ調整事項が増え、設計にミスが出やすくなる。
また、参加する人が増えれば増えるほど、信頼できない人がまぎれ込む可能性が大きくなり、業務の忙しさにかまけて必要なチェックを手抜きするかもしれない。
マルチベンダー体制の最大の問題点は責任の所在が曖昧になることである。これはシステム開発時にもシステム運用後のシステム障害対処時にも当てはまることである。
銀行のシステムに詳しい京都情報大学院大学の甲斐良隆教授は、「開発に複数企業が関わるとバックアップ機能のテストが難しくなる。一般論だが、責任の所在も曖昧になってトラブルが起きやすい」と指摘する(出典:読売2020.8.25)。
上記のようにマルチベンダー体制には問題があるが、やりようによっては、すなわち、十分な時間と資金と人材を大量に投入し、経営トップの卓越したリーダーシップがあれば、マルチベンダー体制でも完璧なシステムを構築することができることを付言しておく。
本稿は、みずほFGのシステム障害に関する報道においてあまり注目されていないマルチベンダー体制の問題点に焦点を当てている。
以下、初めに大規模なシステム障害の経緯について述べ、次に、シングルベンダー体制とマルチベンダー体制のメリットとデメリットについて述べる。
(注)ベンダーは、元々販売業者、販売供給元を意味する言葉である。ただし、IT業界では、システムの企画、設計、開発、運用、保守までの業務を受託する企業は、ITベンダー、システムベンダー、またはシステムインテグレーターと呼ばれる。
「マルチベンダー体制」とは、複数のITベンダーが協同一致して開発プロジェクトを推進することをいう。他方「シングルベンダー体制」とは、単一のITベンダーが開発プロジェクトを推進することをいう。 >>258
肩書きばかり立派なCIO(78)とかじゃなきゃいいけど…
そもそも最上流のあいだで偉い人を回転寿司しても必要なスキルに到達できないのでは ■ このスレッドは過去ログ倉庫に格納されています