日経コンピュータ「みずほ銀行　システム統合、苦闘の19年史」

アーキテクチャから見た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、（そして最近はどうなっているのかよく知らないが）、と変遷したがメンテナンス不備の問題は未だに多くのシステム運用の現場が抱えている問題だろう。
ハードウェアの進歩のスピードに比べて、ソフトウェア開発の現場の進歩はカメのようにのろいと痛感する。（ソフトウェア開発の現場でも革新的イノベーションが待たれる・・・）