【概要】
著者（監督）：日経コンピュータ、山端 宏実、岡部 一詩、中田 敦、大和田 尚孝、谷島 宣之 著
「IT業界のサグラダファミリア」と揶揄されたみずほ銀行勘定系システムMINORIの刷新プロジェクトを追う。銀行×ITということで正直あまりよくわからんかったのだが、プロジェクトマネジメントの教訓になるかも。プロジェクト管理体制がまた複雑なのよ。
学びになったのは、ITプロジェクトでは、要件定義をユーザー側にきっちり行わせるのが特に重要ってことかなあ（"As is"禁止、業務フローの洗い出し、あるべき姿の具現化…）。あとはITシステムがわかった人間を経営層に入れるとか、トラブったときは現場に頑張らせずに経営的判断を経営層が果断に下すとか（システム障害は初動が命）。合併時から残る3行の勢力争いには、全体最適となる超党派判断を阻害する人間組織の悲哀が感じられ興味深い。
他にも、設計思想の可視化・理解（ブラックボックス化させない）を絶えず行うとか、システムに拡張性を持たせてカスタマイズの余地を残すとか、SOA（サービス思考アーキテクチャ）でコンポーネント化された構造にするとか、データフロー図を作るとか、リスク評価を定量的に行うとか、進捗管理を専用ソフトを使ってきっちり行うとか、トラブル通報体制や顧客対応などの社員教育を実施するとか…。いろいろやっていたみたい。
化学プラントではおなじみであるが、多少の事故は許容しても経営を揺るがすような重大事故は極小化するようなリスクアセスメントが一層重要になるのかも。
https://www.jashcon.or.jp/oshirase/2018anzen1.pdf
【詳細】
＜目次＞
- はじめに
- 第一部 IT業界のサグラダファミリア、ついに完成す
第1章 三十五万人月、四千億円台半ば、巨大プロジェクトはこうして始まった
第2章 さらば八〇年代、新システム「MINORI」の全貌
第3章 参加ベンダー千社、驚愕のプロジェクト管理
第4章 緊張と重圧、一年がかりのシステム移行
第5章 次の課題はデジタル変革
第6章 「進退を賭けて指揮した」
みずほフィナンシャルグループ 坂井辰史社長 インタビュー - 第二部 震災直後、「またか」の大規模障害
第7章 検証、混迷の十日間
第8章 重なった三十の不手際
第9章 一年をかけた再発防止策 - 第三部 合併直後、「まさか」の大規模障害
第10章 現場任せが諸悪の根源
第11章 無理なシステム統合計画を立案
第12章 大混乱の二〇〇二年四月
おわりに
＜メモ＞
これ以降、大規模なシステム障害は発生していない…。
のお！ はずでしたがあ！
またかーい！
上記記事①によると、「第1に、MINORIのアーキテクチャの複雑性、第2に、保守運用フェーズでのリソース削減が急であったこと、第3に、経営とIT現場とのコミュニケーションが不十分だったこと、第4に、システム関連の銀行組織、開発会社、運用会社が連携しにくい体制であること、第5に、機器の所有を各ベンダーとしたことが挙げられる」とのこと。組織風土の刷新やスタッフの育成は一朝一夕にいかない模様だ。
