[ガートナー特別寄稿]
みずほ銀行のトラブルから学ぶシステム統合の勘所
ガートナージャパン
ジャパン リサーチ センター リサーチディレクター
栗原 潔
2002/6/7
リレーコンピュータの採用そのものは悪ではない
みずほ銀行のトラブルは、実際には多くの要因が関連した複合障害であった。リレーコンピュータの障害が主な原因となったATM障害については、「完全統合せずにリレーコンピュータなどで間に合わせようとするからこのような問題が発生するのだ」というような意見も聞かれた。しかし、大企業の、特に金融業界における合併では、リレーコンピュータによる疎結合型のシステム統合は当たり前の手法なのである。疎結合での統合を行い、当面の問題を解決できた後に、時間をかけてシステムの完全統合を目指すこともできるし、新しいシステムを一から構築することもできる。また、場合によっては、疎結合型のシステムを使い続けることもできるだろう。合併やM＆Aが継続的に頻発する環境では、後者の考え方が有利だ。システムの完全統合という理想を追求しすぎると、IT部門は常にシステム統合に忙殺されてしまう。それよりも、新たな戦略的IT案件に投資をした方が適切であるという考え方だ。実際、米国の金融機関ではこのような考え方が支配的である。
一般に、システム統合、特に、大規模なものでは、データベースの統合による密結合型の統合よりも、トランザクション中継による疎結合型のシステム統合の方が有利な場合が多い。ガートナーでは、このようなトランザクション中継のハブとなるサブシステムをインテグレーション・ブローカと呼び、その採用を積極的に検討することを推奨している。みずほ銀行の問題は、リレーコンピュータの採用という考え方そのものにあったのではなく、その実装にあったといえるだろう。
フラットファイルによるデータ交換の弱点
もう1つの重大なトラブルであった、振替処理の原因について分析してみたい。一般的には、振替処理は取引先企業から送られたテープを読み込み、元帳（データベース）を更新し、結果をテープに書き出すという典型的バッチプログラムである。システム的にはごく単純な処理だ。このように単純な処理でトラブルが発生してしまったのは、想定された以上の多くのエラー･レコードが発生してしまったことにあるらしい。
この原因として挙げられているのがコード体系の問題である。振替処理のレコードの重要なキー項目として、銀行コード、支店コードなどがある。みずほ銀行の銀行コードは「0001」であるが、これは旧第一勧銀の銀行コードと同じである。また、合併に伴い3行間で重複することになった一部の支店コードが変更されている――。少しでも現場のシステム設計を担当したことがある方なら、このコード体系の選択はリスキーだと感じられるだろう。取引先企業が誤って旧フォーマットでデータを送った時に、処理プログラムではそれを知る手立てがないからである。実際、コード体系の決定の遅れ、現場の連絡不足、テスト不足により旧フォーマットでデータを送る企業、また、銀行コードのみを変更し、支店コードを変更しなかった企業が存在し、多量のエラーが発生してしまった、これが、振替処理のトラブルの主原因であったようだ。
これは、あくまでもさまざまなメディアやその他の情報源からの間接的な情報であるため、細かい点では現実と相違があるかもしれない（もし、もっと細かい話をご存知の方がいれば、匿名でもよいのでぜひ教えてください）。しかし、現在の振替処理、さらには、多くの企業間取引で使用されている固定長のフラットファイルによるデータ交換の脆弱性が、このトラブルの種であったといってよいのではないだろうか。
固定長のフラットファイルによるデータ交換では、データをやりとりする双方がデータの内容の解釈について完全に一致していることが大前提となる。今回のように、何らかの連絡不行き届きがあれば、エラー･データを送ることになってしまう（さらに、悪いケースでは、エラー･データを受け取っても、エラーと判断せずに処理を継続してしまうことになる）。また、多くの企業がデータを交換している場合には、ひとつの企業だけのためにデータの形式を変更することは困難である。その変更がほかのすべての企業の処理に影響を与えてしまうからである。
XMLの優位性：自己記述性
このような問題の最良の解決策は「自己記述的」であり、かつ、「コンテンツと物理的形式が独立」したデータフォーマットを使用することだ。このような条件を満足するソリューションが、いうまでもなくXMLである。
XMLを使用することで、データの内容はデータ交換を行う相手との取り決めではなく、データそのものの中に記述されるようになる。例えば、データフォーマットの変更があった場合には、新フォーマットのデータなのか旧フォーマットのデータなのかをデータの内容を見るだけで判別することができ、プログラムはしかるべき対応を取ることができるようになる（つまり、旧フォーマットのデータを誤って新フォーマットとして処理してしまうことを防げる）。これが、XMLの最大の優位性である「自己記述性」だ。また、特定の企業向けに新たなデータ項目を追加する場合も、他企業には影響を与えずに追加を行うことができる（他企業は、自分の処理とは関係がないデータ項目を読み飛ばせば済む話である）。
もちろん、みずほ銀行が振替処理にXMLを使えば問題は発生しなかったというつもりはない（そもそも振替処理のデータ形式は全銀フォーマットとして標準化されているため、1行だけの都合で変更することは非現実的だ）。しかし、今後のシステム統合案件においては、企業間でのデータ交換、さらには、社内でのデータ交換を行う場合でも、ぜひXMLを採用すべきだ。こうすることで、システムの変更にまつわるリスクを大幅に軽減できるだろう。つまり、XMLにより変化に強いシステムを作り出すことができるのである。
注：ガートナーは世界最大のIT戦略アドバイス企業で、本記事は同社日本支社 ガートナージャパン リサーチディレクター 栗原氏からの寄稿である。
[関連記事]
みずほのシステム障害が示すもの（NewsInsight）
マーキュリー、ライバルはテストをしないという古い慣習
（＠ITNews）
XMLの基礎理解〜これだけ知っていれば大丈夫〜（XML
eXpert eXchange）
システム連携の理想と現実（Business
Computing）
情報をお寄せください：
最新記事
 |
|
|
|
|
