中田敦のレビュー一覧
-
Posted by ブクログ
この本の出版は2020年で、その後結局2021年にシステム障害が発生したということまで含めて物語としての完成度の高さに感動する。
・日本で類をみない超大規模なシステムの構築に成功！
・「サービス指向アーキテクチャ」という耐障害性の高いモダンなアーキテクチャを採用することで、これまでの「みずほはシステム障害が多い」という汚名を返上！
ということが書かれています。この本でシステム障害の根本的な原因が経営層のシステムに対する無関心さにあると書いていますが、結局この部分は変わらなかったことが2021年のシステム障害についてまとめた続編「ポストモーテム」で明らかになります。 -
-
-
Posted by ブクログ
ネタバレ2004年の3銀行経営統合時と、2011年の東日本大震災義援金振込時に起きた計2度の大規模システム障害について、技術的な側面からみずほの人物的な側面まで幅広く原因が述べられている良本だった。
特に印象的だった部分について述べる。
・4章
▶︎ MINORIへのシステム移行に伴い、実際にシステムを使う営業店で働く人々へ教育する機会を設ける必要があった。そこで、特定職(一般職？)の女性170名が講師となり、1人4店舗ほど受け持って講師として活動した点
▶︎日頃自分の指定したエリアを出ることがない一般職の人達に協力をお願いして、エリア外の地域の支店をも受け持ってもらっていたという事実から、みずほのMINORIへの本気度をヒシヒシと感じ、感動した
・p206付近
▶︎3銀行経営統合時、勘定系をどの銀行のものを軸として統合すべきか話し合いが行われていた際、合理的に見れば富士銀行(IBM製)の勘定系に統合するのが良いことが分かっていたが、富士通のメインバンクであった第一勧業銀行が富士通製の勘定系を使っていたことから簡単に富士通を切ることができず、システムの追求とは別軸で不毛な争いが発生してしまっていた点
▶︎今まで3行のシステムをすんなりと1本化しなかっったなんてバカバカしいと思っていたが、特に取引先と密に関わっている銀行業のシステムを考えた時そうは言っていられないんだろうなと、銀行業故の人と人、企業と企業の繋がりの難しさに感服した。
-
Posted by ブクログ
良著。読んでて胸が苦しくなるし、色々な案件がフラッシュバックする。
システム部門がなんとかするのだ、専門家の責務だ。と言って上は歩み寄らず理解しようとしないが、システムの重要さは肥大化する一方。肥大化すれば、作っている最中から腐り始める。進歩の早いITシステムではなおさらだ。
銀行以外の巨大システムでは、さまざまな手法が提案され採用され、そして棄てられていく。そのように新陳代謝させられる仕組みを模索し続けれられるシステムと、組織風土は銀行に限らず、システムを中心に据えているどんな企業も必要だろう。これは銀行に限らず、基幹システムを軽視している企業に対する警鐘を鳴らす本である。 -
Posted by ブクログ
金融は情報システム産業といっても過言ではない。
自分自身金融機関に勤めているが、初めの頃は「システムは常に正確に、滞りなく動くもの」と誤認していた。
先日まで新会社立上げ・新規事業立上げを行い、システムの開発・運用を横目に見ながら思ったのは、システムには人の手がかかり、緻密かということ。そして、いくつものシステムが複雑に連動して稼働しているかということ。
みずほFGはシステムに苦心し続けてきた。その末にシステムを全面更改して「MINORI」を開発した。しかし2021年、再び度重なる障害を起こした。
この度重なる障害は、システムの全面更改が失敗したということではない。全面更改したからこそ、これまでとは違った苦難に直面している。
システムは要件定義から運用に至るまで繊細な管理が必要ということ、そしてMETIが提言する「2025年の崖」に対するヒントを、本書は圧巻の取材力で、丁寧に教えてくれる。
-
購入済み
日本の大企業組織の姿
面白かった。やはり終身雇用で人事制度が硬直化した組織は、個々が優秀でも正常な意思決定が出来なくなる。
多分誰でもすべき事やるべき事はわかっているが、組織としては動けない、もしくは必要以上に動きが遅くなる、みたいな事は内向きな終身雇用の組織で起きており、これが日本が世界からもアジアの国々からも凋落しつつある背景なのでは。
もっと人や組織が流動化して、組織が外部性を保ち続けないと、どんな組織も心地よく周囲の皆と同じくゆっくり死んでいくのだろう。 -
Posted by ブクログ
ネタバレこの本は素晴らしい！再読必須。
まさかあのGEがシリコンバレーの会社を習って「アジャイル」「リーンスタートアップ」「デザイン思考」「オープンソース利用」等やってるとは。
下記メモ（ネタバレごめんなさい）
・自社の責任と権限で「アプリ」開発
通常は顧客企業が要件定義し、インテグレーターがそれに従って実装する。
GEは自分たちで要件定義し、実装し、顧客企業に対してサービスとして提供する。
・デザイン思考では「ユーザーの観察」がすべての起点。顧客の考えを深く観察して本当の問題を発見する。人々の行動の背景にある感情にも着目する。顧客の立場に共感しながら解き明かしていく。
例えば電話を使った事のない人に「電話を使ってみたいですか？」と質問しても無駄。普段はどうやって隣村の人々と連絡していますか？等質問を工夫する必要性有。
・デザイン思考を使って顧客と対話。解決策をストーリーボード（＝ユーザーが製品やサービスを利用する一連の体験を絵物語風に記述するもの）にまとめる。ストーリー（絵物語）に仕立てあげることで問題点が本当に正しいのか、解決策が実現可能なのかグループで検証できるようになる。
ストーリーボードはある種のプロトタイプだ。
物語によって顧客に解決策を疑似体験してもらっているからだ。時にはドラマ仕立てのビデオを作ってみてもらうが、そのビデオもprototypeの１つ。
・デザイン思考をgoogleが進化させたものが「デザインスプリント」
・リーンスタートアップは自社の取り組みが「間違う」「失敗する」ことを前提としている。最初に出すものは絶対に間違っているからそれを大急ぎで改善し続ける。成功するためにはより早く失敗するしかない -
-
-
-
-
-
Posted by ブクログ
ネタバレ取材力がすごい。ただ、用語用語は分かってもななめ読みしようとすると、さすがに体制が複雑でわかりづらかった。経営陣が全くITわかってないことが分かった。ただ、PJ終盤や震災以降の部分はかなりしっかりとしたマネジメント体制を引いていると感じた。あとはローコード開発やテストの進捗確認ツールなどについても。
業務に活かせる話としては、十分な間を取って「質問ありますか」のタイムを
設けるなど、意外と基本のところからの意識が大事だと分かった。
また、SOAをかなり早い段階から考案していたことに感心した。（障害は起きているが）
ポストモーテム編もぜひ読みたい。 -
-
-
Posted by ブクログ
・みずほ銀行のシステム刷新までの過程と2度のシステム障害の背景について詳細に解説している一冊
・エンジニアとして一応読んでおくかと思い手に取った
・みずほ銀行の新システムがいつまでも完成せずにサクラダファミリアと呼ばれてることは知ってたけど大きいシステム障害を2回起こしてることをまず知らなかった
・金融というお金が密接に関係する業界で大きなシステムを統合するのはさぞ大変だろうと関係者を労いたい
・みずほFGは2度の失敗から学び、システム刷新という大仕事を乗り越えて組織として強くなったんだなと思う
・1度目のシステム障害については3行統合後の内部での争いが結果としてシステム障害に繋がっていてヤレヤレという印象
・2度目のシステム障害については、たしかにシステム周りの知識不足な経営層が大きな原因の1つではあるけど、同じように知識不足な経営層がいる企業はたくさんありそうなのでこれを糧に我がふり直す企業が出てくればいいなと思う
・そしてエンジニアの仕事が増えて欲しい笑
・MINORIを活用したみずほ銀行のこれからのIT戦略に期待 -
Posted by ブクログ
ネタバレ前半はみずほこんなことやって頑張ったぜ！ドヤ！みたいな内容。生のコードを書けなくして属人化を防ぐ超高速開発ツールなど、なかなかおもろい仕組みを使っていたのが興味深かった。しかし、ツール名が「超高速開発ツール」というのがダサい。
コロナが流行る前からWeb会議を使っていたのは先進的だと思う。（とはいえ、私もIT企業に勤めていて、コロナ前からWeb会議使ってたから、IT企業的には普通なのかしら）
後半がめちゃくちゃ面白かった。2011年と2002年のシステム障害の発生の原因について細かく描写している。仕様書やデータフローがなかったり、合併時のシステム統合の際に役員の中に有識者がいないなどとにかくやばい。システムくらい勉強しろよ。
エンジニアが本当に気の毒。
社内政治とか読み物としては面白かったけど、当事者にはなりたくないと思った。
みずほのシステムの関係者の皆様お疲れ様です… -
-
