プロジェクト管理あれこれ

本書は、サブタイトルに『史上最大のITプロジェクト「3度目の正直」』とあるように、みずほ銀行における勘定系システムの刷新と統合プロジェクトの経緯を追ったものである。みずほ銀行
本書の構成は、
第一部:勘定系刷新プロジェクト「MINORI」の全貌とプロジェクトの経緯、みずほFGのデジタル経営戦略
第二部:2011年3月に発生した大規模システム障害の振り返り
第三部:2002年4月の経営統合直後に発生した大規模システム障害の振り返り
の三部からなる。
みずほ銀行における勘定系システムの刷新と統合は、2000年にみずほホールディングス(現、みずほFG)が発足して以来の19年越しの悲願であった。
勘定系刷新プロジェクト「MINORI」は、2011年6月にスタートしている。プロジェクトがスタートするまでに、みずほ銀行は大規模なシステム障害を2回起こしている。それが本書に記載されている、第三部と第二部の障害である。
2011年3月に発生した2回目の大規模障害が、みずほ経営陣をして、「勘定系システムの刷新と統合」への投資を決断させた。
MINORIは、旧第一勧銀の勘定系「STEPS」と、旧興銀の勘定系「C-base」、みずほ信託銀行の勘定系「BEST」を統合するものである。
アプリ開発費は4,200億円、開発工数35万人月、ピーク時8,000人のエンジニアが参画(いずれも本書の推定)と言われており、文字通り日本で最大規模のシステム構築プロジェクトであろう。(本書では、東京スカイツリーの建設費と比較して、東京スカイツリー7本分に相当するとしている)
プロジェクト「MINORI」は、これだけの大規模プロジェクトであるから、決して順調に推移したわけではない。
2014年4月と2016年11月の二度にわたってプロジェクトを延期し、最終的に2019年7月に本稼働している。実に8年の歳月をかけた大規模プロジェクトである。このうち、システム移行は1年がかり(移行のためにATMを停止した回数は9回)で行われた。 

アーキテクチャから見たMINORIの特徴は、SOA(サービス指向アーキテクチャ)を採用していることと、バッチ処理(振込処理をはじめとするバッチ処理)をオンライン処理にしたことだという。
本書で描かれている問題点(旧システムにおける問題点や、MINORIプロジェクトを推進していくなかで発生した問題点など)は、いわゆる「あるある」に近いものがほとんどである。
システム開発やシステム運用を担当したことがあるSE(システムエンジニア)であれば、経験したことがある問題だろう。(その意味では、システム開発、特にソフトウェア開発は、この数十年間ほとんど進歩していないように感じる)
本書に書かれている問題点をいくつか取り上げてみる。

旧第一勧銀の勘定系「STEPS」は、夜間バッチとオンライン処理を平行稼働できない。日中にオンライン処理を実施して、夜間にバッチ処理を行うという運用形態である。さらにバッチ処理には、いわゆる「リスタート機能」がなかったようである。
従って、夜間バッチ(バッチJOB)が途中で異常終了した場合は、該当のJOBネットを最初からやり直さなければならなかったようだ。
これらは、古い基幹系システムではよくあることだと思う。(それでも、バッチJOBのリスタート機能というのは、障害対策として実装しているシステムがあったと思う)
DBMSは階層型のDBを採用していた。これも古い基幹系システムではよく見られる形態だろう。STEPSが稼働した1988年当時は、まだRDBは商品が出始めたばかりだったろう。さらに、RDBの多くはUNIX系の商品がほとんどであり、性能面では階層型DBのほうが有利であったと記憶する。(基幹系システムのようにDBへのアクセス経路が固定的な場合は階層型の方が有利であり、RDBは情報系システムに向いていると考えられていた。基幹系システムにもRDBが実装されるようになったのは、もっと後のことである)

バッチJOBにリスタート機能がないことが、2011年3月の大規模障害の原因の一つになった。異常が発生した場合のJOBネットを現場で組み立てて、手動でJOBを実行していたようだ。これでは当然人的ミスが発生する。障害への対処が新たな障害を誘発するという事態に陥る。

旧システムであるSTEPSは、稼働後も新サービスの投入や法制度対応などで修正を繰り返していたため、ブラックボックス化していた。俗にいうソースコードのスパゲッティ化と、設計ドキュメントのメンテナンス不備の問題だろう。
特にドキュメントは、データフロー図などは最初から無かったようだから、システム運用の現場は随分と苦労しただろう。
ドキュメントのメンテナンス不備の問題もいわゆる「あるある」だ。システム運用のなかでドキュメントのメンテナンスが不十分なために、ドキュメントの記載内容が間違っている、記載が漏れている、最悪のケースではある種のドキュメントそのものが無い、等の問題は多くのシステム運用担当者が直面してきた問題だろう。

MINORIの要件定義では「As Is」を全面禁止して、業務フローを全面的に見直した(いわゆるBPRした)そうだ。これなども古くからある、「現行踏襲には注意しろ」という警句そのものである。
また、実装面では各サービスを疎結合で結合し、各業務アプリケーションを構成する「商品サービス」の粒度にも留意したという。
「疎結合」や「粒度」というのも昔からある課題であろう。オブジェクト指向が流行った頃も、オブジェクトの粒度や結合度が設計上の課題に挙がっていたと記憶する。(さらに古くは、構造化設計が唱えられていた頃にも、この種の課題は存在していた)

本書では明示されていないが「標準化」も昔からある古くて新しい課題である。システム開発プロジェクトでは、稼働後のメンテナンスを考えて、ドキュメントやプログラム構造などを標準化して、俗人性を極力排除することが重要になる。
MINORIではXupperや超高速開発ツールを採用することで俗人性を極力排除したようだ。一般のシステム開発プロジェクトでは、俗人性を排除するために、ドキュメントの体系を定義したうえで、設計ガイドラインやコーディング規約の類を整備することが多い。
統合開発ツールの導入なども、設計・開発の効率化だけでなく、俗人性を排除して標準化を図ることがその目的のひとつだろう。

このように見てくると、MINORIで発生した課題や問題点は昔からある「あるある」であるが、規模が超巨大であるだけに、このプロジェクトが無事に収束してカットオーバーを迎えたことには素直に感動を覚える。現場のSEをはじめ、プロジェクトマネジメント層、経営層の活躍は称賛に値する。
一方で、(先にも少し触れたが)ソフトウェア開発はこの数十年でほとんど進歩していないようにも感じる。
アーキテクチャは、オブジェクト指向からサービス指向、マイクロサービスへと変わってきたが、機能の「粒度」や「結合度」などの課題は、本質的に変わっていないように映る。
要件定義段階における現行踏襲の問題やBPR(ビジネスプロセス・リエンジニアリング)の発想も変わっていない。設計ドキュメントも、DFDやERDの世界から、UML、(そして最近はどうなっているのかよく知らないが)、と変遷したがメンテナンス不備の問題は未だに多くのシステム運用の現場が抱えている問題だろう。
ハードウェアの進歩のスピードに比べて、ソフトウェア開発の現場の進歩はカメのようにのろいと痛感する。(ソフトウェア開発の現場でも革新的イノベーションが待たれる・・・)

 

INDEX

Update

2021年8月
« 5月    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Archive

Navigation