山端宏実のレビュー一覧
-
-
-
Posted by ブクログ
ネタバレ2004年の3銀行経営統合時と、2011年の東日本大震災義援金振込時に起きた計2度の大規模システム障害について、技術的な側面からみずほの人物的な側面まで幅広く原因が述べられている良本だった。
特に印象的だった部分について述べる。
・4章
▶︎ MINORIへのシステム移行に伴い、実際にシステムを使う営業店で働く人々へ教育する機会を設ける必要があった。そこで、特定職(一般職？)の女性170名が講師となり、1人4店舗ほど受け持って講師として活動した点
▶︎日頃自分の指定したエリアを出ることがない一般職の人達に協力をお願いして、エリア外の地域の支店をも受け持ってもらっていたという事実から、みずほの -
-
無料版購入済み労働力や取引先を買い叩くことなくITを駆使してコストを減らし、安値を実現するベイシアグループやり方を、日本にはびこる旧体質の企業も見習うべきだと思いました。
-
Posted by ブクログ
良著。読んでて胸が苦しくなるし、色々な案件がフラッシュバックする。
システム部門がなんとかするのだ、専門家の責務だ。と言って上は歩み寄らず理解しようとしないが、システムの重要さは肥大化する一方。肥大化すれば、作っている最中から腐り始める。進歩の早いITシステムではなおさらだ。
銀行以外の巨大システムでは、さまざまな手法が提案され採用され、そして棄てられていく。そのように新陳代謝させられる仕組みを模索し続けれられるシステムと、組織風土は銀行に限らず、システムを中心に据えているどんな企業も必要だろう。これは銀行に限らず、基幹システムを軽視している企業に対する警鐘を鳴らす本である。 -
Posted by ブクログ
金融は情報システム産業といっても過言ではない。
自分自身金融機関に勤めているが、初めの頃は「システムは常に正確に、滞りなく動くもの」と誤認していた。
先日まで新会社立上げ・新規事業立上げを行い、システムの開発・運用を横目に見ながら思ったのは、システムには人の手がかかり、緻密かということ。そして、いくつものシステムが複雑に連動して稼働しているかということ。
みずほFGはシステムに苦心し続けてきた。その末にシステムを全面更改して「MINORI」を開発した。しかし2021年、再び度重なる障害を起こした。
この度重なる障害は、システムの全面更改が失敗したということではない。全面更改したからこそ -
購入済み
日本の大企業組織の姿
面白かった。やはり終身雇用で人事制度が硬直化した組織は、個々が優秀でも正常な意思決定が出来なくなる。
多分誰でもすべき事やるべき事はわかっているが、組織としては動けない、もしくは必要以上に動きが遅くなる、みたいな事は内向きな終身雇用の組織で起きており、これが日本が世界からもアジアの国々からも凋落しつつある背景なのでは。
もっと人や組織が流動化して、組織が外部性を保ち続けないと、どんな組織も心地よく周囲の皆と同じくゆっくり死んでいくのだろう。 -
-
-
-
-
Posted by ブクログ
・みずほ銀行のシステム刷新までの過程と2度のシステム障害の背景について詳細に解説している一冊
・エンジニアとして一応読んでおくかと思い手に取った
・みずほ銀行の新システムがいつまでも完成せずにサクラダファミリアと呼ばれてることは知ってたけど大きいシステム障害を2回起こしてることをまず知らなかった
・金融というお金が密接に関係する業界で大きなシステムを統合するのはさぞ大変だろうと関係者を労いたい
・みずほFGは2度の失敗から学び、システム刷新という大仕事を乗り越えて組織として強くなったんだなと思う
・1度目のシステム障害については3行統合後の内部での争いが結果としてシステム障害に繋がっていて -
Posted by ブクログ
ネタバレ前半はみずほこんなことやって頑張ったぜ！ドヤ！みたいな内容。生のコードを書けなくして属人化を防ぐ超高速開発ツールなど、なかなかおもろい仕組みを使っていたのが興味深かった。しかし、ツール名が「超高速開発ツール」というのがダサい。
コロナが流行る前からWeb会議を使っていたのは先進的だと思う。（とはいえ、私もIT企業に勤めていて、コロナ前からWeb会議使ってたから、IT企業的には普通なのかしら）
後半がめちゃくちゃ面白かった。2011年と2002年のシステム障害の発生の原因について細かく描写している。仕様書やデータフローがなかったり、合併時のシステム統合の際に役員の中に有識者がいないなどとにかく -
-
-
-
Posted by ブクログ
みずほフィナンシャルグループは、メガバンク史上初めてシステムを新たに再構築した。MINORIと呼ばれるシステムは、事務作業を大きく削減し、新しい機能を付加させるための開発費用を減らし、オープンイノベーションを促進する事が期待され、システムが寿命を迎える2025年の崖から転落しないよう各企業が見習うべき良いケースである。と思われていた。しかし結果は今の通りである笑
不具合続きの今から振り返ると、第1部の成功ケースよりも第2部・第3部の失敗学の方が遥かに有益であるように感じる。そもそも、失敗の原因として「システムのブラックボックス化」「風通しが悪く、責任者への報告が遅れ、対応が後手に回る」「経営 -
-
