読者です 読者をやめる 読者になる 読者になる

takumi296's diary

技術士・匠習作の考へるヒント

ガバナンスと倫理

第一勧業、富士、日本興業の3銀行が再編して誕生した「みずほ銀行」は、2002年(平成14年)4月1日に現金自動預入払出機(ATM)の障害が発生、さらに公共料金の自動引き落としなどの口座振替に遅延が生じるトラブルが起き被害は拡大した。

口座振替の遅延は、4月1日だけで105,000件に達し、翌日以降の積み残しとなり、連鎖的に大量の未処理が発生、4月5日には遅延数は250万件にまで膨張していった。それに付随したかたちで、約3万件の二重引き落とし発覚し最大級の大規模システム障害に陥った。復旧を図るも、このトラブルでの顧客の混乱は1ヶ月以上も続いた。 

原因

1. システム統合方針決定の遅れ ( 企画・立案段階に原因あり )

企業統治(ガバナンス)の欠如により経営統合した旧3行が自社のシステムの存続にこだわって主導権争いを演じ、システム統合の方針が二転三転し、意思決定が大幅に遅れた。

システム統合に対して、本来、客観的に機能要件を調べたうえで、どこのシステムが望ましいかについて合理的な方針を導き出すはずであったが、旧3行の自社システムの存続にこだわって主導権争い等で、大変なシステム統合である割りには、単に三つのシステムを繋げばよいという、タテ割り体制の弊害が見えるような、合理性を欠いたものとなった。リレーコンピュータ方式は決しておかしな方式ではないが、問題はリレーコンピュータの開発作業に遅れが生じたことにある。根本的なところで設計思想がなかった。

銀行のシステム統合する際には、なるべく処理量の少ない時期を選ぶのがベスト、みずほは年間で最多の処理量を迎える4月 1日に固執したことも一因。

2. システム統合の開発スケジュールの遅れ

「統合プロジェクトの管理体制に問題があった」

管理体制については、システム開発が遅れていたのに、担当部署から経営陣に適切な報告がされていなかった。旧3行間でシステム開発を分担する「開発責任行体制」をとったため、相互チェックが働かなかった上、各行をたばねる持ち株会社の管理体制も機能しなかった。

システム統合のスケジュールの遅れは、昨年からCEOに数回にわたり報告されていた。これに対しCEOは「遅れを取り戻すように」などと指示するだけで、システム開発責任者の甘い見通しをうのみにし、突っ込んだ確認をしなかった 

3. システム間を接続するコンピューターの性能を考慮したテストが不十分、事前に有効な負荷テスト、異常テストが行われなかった。

4. 経営陣が障害発生の可能性を把握しながら、経営統合の直前に起きた処理の遅れなどを軽視し、見切り発車で統合に踏み切った。 

 

//// ここまでは、失敗知識データベースから省略・加筆して転載した。

 

組織的なミス、あるいは企業統治の問題と言われた事故である。エンジニアから報告されてくる、作業の遅れにたいして「遅れを取り戻すように」というだけでは管理者ではない。ただし、失敗したプロジェクトの殆どは、「遅れを取り戻すように」とだけ言う人がプロジェクトリーダになっている場合が多い。私の身近で見るプロジェクトもそうである。なぜ、遅れているのか、その原因は何か、プロジェクトの進行を妨げる問題点はどのように解決すればよいのか、これを考えるのはプロジェクトリーダの業務である。また、経営の根幹に関係するところに問題があるのであれば、CEOに対して提言するのもプロジェクトリーダの責務である。

銀行のIT関係部門に総監技術士がいるのかどうかは知らないが、総監技術士の知識と見識は、このような場面で役立てると良いと思う。