大規模アプリケーションシステムにおける品質劣化の要因

東京情報大学総合情報学部　　関口　益照

（２） 第２期：1980年代後半

国際化（グローバリゼーション）と証券化（セキュリタイゼーション）の荒波に翻弄された時代である。大手銀行の第３次オンラインシステムは軒並み暗礁に乗り上げ、大幅な計画変更と開発目標の後退を余儀無くされた。この時代のシステム開発思想は以下のようなものであった。

　?『横並び型総花開発』　　：業務の多元的拡大（国際業務、証券業務他）によりマンモス化

　?『属人的システム分割』　：勘定系、情報系、国際系、証券系、対外系　⇒設計思想の欠落

　?　『総合オンライン主義』　：SISの挫折とシステムインフラ論への後退　⇒投資基準の欠落

（３）第3期：1990年代〜現在

銀行が護送船団行政下の制度機関的存在から自由競争企業への転換を迫られ適応不全に陥った時代である。同時にシステム部門のガバナンスが問われている時代でもある。総合オンラインシステムは刻一刻と肥大化が進み、９０年代半ばには3０００万行、さらに現在は１億行に達しているともいわれている。この時代のシステム開発思想は以下のようなものである。

　?　インクリメンタル開発の継続　：第3次オンラインシステムの後遺症

　?　システムの再分割　　　　　　：商品別システムへの分割（旧住友銀行、１９９５年）

　?　プログラム構造の転換　　　　：４GLの採用（旧住友銀行、１９９５年）

　　　　　　　　　　　　　　　　　　　　　　　　　 generic module への分解と合成（新生銀行、２００1年）

大規模統合システムのもっとも深刻な問題は、本来事業目的遂行の手段であるべき情報システムが、事業戦略から遊離してしまう、さらには事業の足枷になってしまうということである。銀行の場合は以下の２つの問題が存在する。

　?　法人部門と個人部門等のビジネスモデル間の衝突に対処しきれない。下図でいえばHard Systems Thinkingの枠内で Complex Systemへの道を走ってしまうことを意味する。

Progress in systems thinking

		Increasing divergence of values/beliefs/interests
		Unitar	Plurarist	Conflictual/Coercive
Increasing complexity	Simple	Hard Systems Thinking	Soft Systems Thinking
	Complex	Design of Complex Adaptive Systems

Mike C. jackson “Systems Thinking and Information Systems development”
Journal of the Japan Society for Management Information, Vol.6 No.3, 1997, pp.7

　?　各事業部門のトップに情報システムが自らの事業基盤であるとの認識がないため、彼らのコミットメントを得られない。その結果、システム部門はコストセンターとして全事業を支える共通設備を一手に引き受けることとなる。このような状況に置かれたシステム部門は自らの所管である省力効果を極大化するため標準化と統合を追及せざるをえず、個別事業への柔軟な対応が困難となる。


（２）技術的誘因

システム肥大化への誘引は、システムの効率化及びシステム開発の効率化という技術者にとって当然の行動の中に潜んでいる。

　?　効率的なシステムの追求　⇒統合原理主義

仕様が確定しているかあるいは確定しうる場合、事前に共通化できる要素は最大限共通化すべきであるという命題にはいかなる技術者も抗しがたい。特に、戦後４０年間、法律と当局の通達、そして業界団体における協定（公認された談合）によって規制されてきた銀行業の場合、業務＝制度、商品＝科目（制度化されたキャッシュフロー）であり、事前に確定できない要素はほとんど存在しなかった。したがって、銀行SEにとっては、１次から３次にいたる２０年余にわたるシステム開発は基本的には断続して継続した１つのプロジェクトだったと言ってよい。
１０年前やり残したことは今回やればよいという按配である。こうして既存の業務（＝制度）に極限まで適応したマンモスシステムが完成したわけである。このようなマンモスシステムが環境の変化に直面したとき何が起こるかは説明を要しまい。

　?　開発効率の追求　⇒インクリメンタル開発の罠

統合システムは、現行業務の一切を内包する１つのユニバースである。したがって、既存の商品やサービスに類似する新商品や新サービスを追加する場合、まったく新規にプログラムを起こすより既存のシステムに変更部分をアドオンする方がはるかに効率的である。少なくとも数分の一、場合によっては数百分の一ですむかもしれない。銀行の場合、下図のように科目単位で構成されるアプリケーションプログラムにさまざまなアドオンを施して各種の新商品に対応してきた。しかし、このような方法が効率的であるためには、担当者が既存のシステムに精通していること、つまり、既存システムの開発者自身であることが必要である。したがって、このような変更や追加が長年の間に積もり積もって膨大なものとなり、しかも、かつての開発担当者がいなくなったときに何が起こるか、これも説明を要しまい。




（３）管理的誘因

最近銀行界で起きた一連のシステム障害を通じていえることは、当事者たちの業務及び技術に関する知識の底の浅さである。その原因の一つは８０年代以降に進展した分業の細分化とそれに伴う技術者の役割の固定化にあると考えられる。

　?　分業による役割の凍結　⇒知識の陳腐化

１９８０年代以降ユーザー、メーカー、ソフトウエア会社（及びインテグレータ）間の多段階分業関係が定着し、相互の責任分担が細かく規定されるようになってきた。その結果、慣習化された仕様やインターフェイスが金科玉条となり、それに縛られることによって陳腐化したソフトウエア構造の見直しも行われなくなってしまったように思われる。下図に示したみずほ銀行のケースでも自動振替における企業側とのインターフェースやATMにおけるメーカー側とのインターフェースは、いずれも２０年前と同じである。いずれも改良の余地はいくらでもある。まして今回のみずほの一斉移行は、世界的にもほとんど前例のない方法である。新しいニーズに対しては新しい発明があって当然なのにそれがなかったとすれば、これはきわめて深刻な問題である。

上述のように銀行のオンラインシステムは、その歴史的条件の中で巨大な統合システムへの道を歩み、その巨大さゆえに業務、技術、及び管理の３つの側面においてさまざまな品質劣化の誘引を内包するにいたった。以下は、これら劣化誘因に対する改善提案である。


（１）業務面から見た方向

　?　ビジネスモデル（事業構造）に基づくシステム開発

　?　ビジネスユニット単位の投資計画（原資の配分、コストの賦課）

　?　トップマネージメントによる事業投資としての統括





（２）技術面から見た方向

　?　商品ラインに対応したソフトウエア構造

　?　generic function に対応したモジュール化

　?　４GLによる商品定義とプログラム生成




（３）管理面から見た方向

　?　絶えざる技術アセスメント　⇒システムアーキテクト、ソフトウエアアーキテクトの育成
　　（東京三菱銀行：システムアーキテクト制度　２００２年度〜）

　?　業務システムとしての開発と運用　⇒ビジネスエンジニアの育成