発売前から各所で騒がれており、発売した際にはAmazonのビジネス書ランキングで1位を獲得、10日足らずで重版となった超話題作です。私もSEなので、職場でも話題になっていました。
流行に乗って、 3月上旬くらいに Kindleで購入して読んだので、本の構成や感想・どんな人におすすめかなどを書いていきます。
『みずほ銀行システム統合、苦闘の19年史』をオススメする人
この本がどういう人におすすめかということと、勝手なおすすめ度を記載していきます。
注意点：現場の詳しいことを知りたい人には期待外れ
下記の構成の説明や感想のところで詳しく書いていますが、まず結論だけ言います。
この本は、「散々炎上していたみずほのシステム開発案件の現場がどんなものだったのか、内部視点から知りたい」という人には完全に期待外れです。
私もSEなので、開発の現場がどうなっていたのか、マネジメントがどのようになっていたのかなど、開発していたSEや情報システム部門の人たちの視点から書かれた苦労話が読みたくて買いました…。残念ながら、そのようなことはほとんど書かれていません。
組織的な問題の話(経営陣のITへの無理解や意思決定の遅さなど)に焦点を当てています。
みずほという会社やプロジェクト自体を外から見つめて書いていますね。
SEが読んでもそこまで深く現場のことが書かれていないので、技術などに関して新しいことを知る余地はあまりなく読み物にしかならないです。
ということで、SIerや情報システム部門に就職しようと考えている就活生が読むといいんじゃないかなと思います。日本大企業の組織的な問題点を知り、現実を見つめるという意味でです。
独断と偏見で選ぶおすすめ度
難易度：★★☆☆☆【星2つ】
オススメ度：★★★☆☆ 【星3つ】
技術やプロジェクトについてそこまで詳しく書かれていないので、難易度は高くないと思います。
おすすめ度に関しては、読んだ分には普通に面白かったし、世間の話題性からもう少し評価しても良いと思いましたが、上記の通り期待しているものとは違ったので★3つにします。
タイトルやキャッチコピーから現場の苦労が書かれていそうだと思いませんか？私は思いました。
あと、2019年に終了したシステム刷新の話ですらないパートが半分くらいあります (下に書いています) し、正直期待値を下回りました。
Amazonのレビューを見ると、実際に私と同じような感想を持った人も多そうでした。
難易度の基準
以下のイメージで主観で選んでいます。
- ★1：ITのことが分かっていない初学者も読める本
- ★2：一通りの基礎知識が付いた人が読める本
- (プログラミングであればProgate、IT分野であれば基本情報技術者試験の範囲に一通り目を通したことがあるくらいの想定)
- ★3：専門分野の話を覗いてみたい人が読む本
- ★4：専門分野の話がより詳しく書かれている本
- ★5：それ以上
オススメ度の基準
世間での評価と読んでみた自分の評価を合わせて、個人的なオススメ度合いを相対評価で付けています。
★5だと上位20％、★4だと上位21～40％、★3だと41～60％、★2だと61～80％、★1だと81～100％となることを想定していますが、最終的にこのように分布するかは分かりません。
『みずほ銀行システム統合、苦闘の19年史』の内容と構成
この本は、3部構成になっています。
第二部と第三部は、みずほ銀行のシステム刷新の話ではなく過去の話なので注意です。
第一部は、タイトルにもなっているみずほ銀行のシステム刷新プロジェクトについて、主に経緯や概要がまとめられています。35万人月、アプリケーション開発費が4200億円程度というとんでもない規模のプロジェクトです。SOAを採用した新システムのアーキテクチャも本当にざっくりとですが解説されています。
第二部は震災直後に起こったシステム障害の話です。
テレビ局がみずほの口座へ義援金の振り込みを呼び掛けたことをきっかけに障害が起こりました。
システムが古すぎて仕様を把握できている者がいない、上層部の判断の遅れなどの様々な問題が積み重なって障害規模が拡大してしまった、というお話です。
第三部はさらに前の話です。
第一勧業銀行、富士銀行、日本興業銀行の三行が合併するときの意思決定に焦点が当てられています。一度決まったことが白紙になる経営陣の合意形成、IT投資への先送りの判断、ITベンダーのつばぜり合いなど、様々な思惑があったことが分かる話ですね。
『みずほ銀行システム統合、苦闘の19年史』の目次
第一部 IT業界のサグラダファミリア、ついに完成す
第1章 三十五万人月、四千億円台半ば、巨大プロジェクトはこうして始まった
第2章 さらば八〇年代、新システム「MINORI」の全貌
第3章 参加ベンダー千社、驚愕のプロジェクト管理
第4章 緊張と重圧、一年がかりのシステム移行
第5章 次の課題はデジタル変革
第6章 「進退を賭けて指揮した」
みずほフィナンシャルグループ 坂井辰史社長 インタビュー
第二部 震災直後、「またか」の大規模障害
第7章 検証、混迷の十日間
第8章 重なった三十の不手際
第9章 一年をかけた再発防止策
第三部 合併直後、「まさか」の大規模障害
第10章 現場任せが諸悪の根源
第11章 無理なシステム統合計画を立案
第12章 大混乱の二〇〇二年四月
おわりに
『みずほ銀行システム統合、苦闘の19年史』を読了した感想
内容について強く印象に残ったのは、以下の2点でしょうか。
- 結局SEが技術的なことを頑張っても、根本的な原因をたどると組織的な問題に行き着く
- SIerという仕組みは(正確に言うと「ウォーターウォール開発は」、といった方が近いかもしれません)属人性を取り除くことが正義
それぞれに対して解説します。
結局、根本原因は組織的な問題にたどり着く
この著者は経営陣の意思決定や組織間のコミュニケーションにかなり焦点を当てていました。
組織のメンバーや体制の問題だけで、ざっとこれくらいの問題点があるでしょう。
- 経営陣のITへの理解のなさ
- 経営陣がITへの投資を決定できない
システム刷新はいつかはしなければならないが、巨額の投資となるため何か起こってからじゃないと投資の決定ができない。「わざわざ自分のときにやらなくても、次の人にやらせればいいや」となる - 謎の縦割り体制(合併の名残で情シス部門などが縦割り)
- 合併に伴う忖度・お気持ちの調整(システムのあるべき姿としてベストな状態ではないけれども、力関係を平等にするために不自然なシステムの統合が行われる、など)
これにコミュニケーションの方法(障害が起こった時に現場がきちんと報告をし、経営陣が安全に倒した意思決定を行うルールをつくるなど)や役割分担、管理ルール(パラメーターの管理などをどう行うかなど)が加わります。安定して稼働するシステムの開発と運用の仕組み作りのためには、考えなければならないルールが無数に存在します。
そして、SIerのSEや情シスが頑張っているシステムの開発や運用というのは、これらのルールが適切に定められてはじめてうまくいくものなのだと感じました。大げさに言えば、システムの生殺与奪を握っているのは経営陣というか…。
このような状況があるからこそ、ITをデザインするときに経営にもスコープを当てて一緒に考えようという思想を持つ「ITコンサル」が生まれたのではないかとの仮説を最近立てていますが、どうなんでしょうかね。
SIer(ウォーターフォール開発)は属人性の徹底排除が正義
みずほ銀行の刷新プロジェクトには「超高速開発ツール」というものが使われ、生のコードが人の手によって書かれることはなかったようです。それだけではなく、テストケースの自動生成なども行われました。
超大型のシステム開発であったため、コード記述の統制が取れていないと保守性が低下してしまうことから、「超高速開発ツール」が導入されたようです。
大規模なシステム開発であるので合理的な判断だと思いますが、これによってSEの仕事はベンダーや顧客との調整と仕様書を書き続けることの2つになります(まあ、プライムベンダーはすでにそうなっており、調整ごとを行うことがほぼ全てですし、将来的には大小問わない全てのシステム開発案件でそうなりそうですが)。
しかも属人性を排除した仕組みの中で歯車として働いていくことになります。就活生の皆様は自分が果たしてそこに身を投じたいかはよく考えるべきでしょう。
「システム開発」という言葉から連想される仕事内容とは異なる世界が広がっています(経験談)。
まとめ
予想とは違った内容の本でしたが、読んだら読んだでそれなりに考えさせられるところはあって楽しかったです。
ドロドロしたSEの話が読みたいなぁ…と思ったけど、会社の人に聞けば大体解決しそうだとも思いました。もし大炎上のデスマーチの様子が客観的なデータで記述されている恐ろしい書籍や漫画がありましたらお知らせいただけますと幸いです。
コメント