- ベストアンサー
みずほ銀行のトラブルを専門家はどう見る？
トラブルの宝庫のみずほ銀行。 3行の主導権が絡み合い、システムの統合がうまくいかないとか・・・ そこで質問です。 みずほ銀行のトラブルをTVニュースなどで解説しているのは ほとんど経済ジャーナリストかエコノミストです。 コンピュータシステムのエンジニアの方やネットワークエンジニア の方はどのような感想をもっているのでしょう？ 起こるべくして起こった・・・・・ 事情はどうであれシステム自体お粗末である。 世界最大の顧客数ゆえにコンピュータの性能不足。 などなど・・・ 専門家の方の感想をお聞かせ下さい。
- akubimusume88
- お礼率92% (276/298)
- その他（インターネット・Webサービス）
- 回答数3
- ありがとう数5
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
経験者と書きましたが、実のところ金融系のシステムは未経験ですので、あくまで推測です。 報道等で聞いている限りでは、今回の統合は、元々の三行のシステムがバラバラだったが、 それを一つに統合することもできないので、元の各システムを維持したままリレー コンピュータで連携させるようにしたということです。互いに異なったシステムを連動 させるというのは、オープン系のシステムならば普通に行われていることで、それ自体が 間違っているとは思いません。 ここで、リレーコンピュータの役割は何だろうと考えてみると、とっさに思いつくだけで 次のような機能が考えられます。 （１）データの送り先を判断するルーティング機能 （２）データを一時的に保存するバッファリング機能 （３）データを通信方法の異なるシステムへ送るためのプロトコル変換機能 （４）データを構造の異なるシステムで扱えるようにするためのコンバージョン機能 他にもあるかもしれませんが、とりあえずこれだけの機能として考えます。 四つの機能のうち、最も複雑なのがコンバージョン機能です。金融システムで使われている メインフレームという種類のコンピュータでは、各メーカーが独自の仕様でシステムを 作ってしまい、メーカーが異なると全然動かないようになっていたのです。（そのように して、メーカーはお客が逃げないようにしたのです。パソコンなどは、逆にオープンにする ことで、新しいお客を獲得しやすくしました。）このため、一つのシステムのデータを別の システムへ送るために、データの形式を変えなくてはならなくなります。一口に言えば 簡単ですが、実際には大変です。例えていうと、一つのシステムでは「水」と「湯」という 別の形式で扱われているものが、別のシステムでは「Water」という一つの形式で扱われると いったようなことが頻繁に起こります。（あくまで例えです。） こうしたレベルの設計がきちんとできていないとシステムを連動させることはできません。 が、個人的には、今回起きたトラブルはこうしたレベルの問題ではなかっただろうと思います 。というのは、もしそうした問題が残っていたとすれば、二週間やそこらで復旧するとは 思えないからです。 次に複雑なのはプロトコル変換機能です。例えばインターネットならば、TCP/IPという 標準化されたプロトコル（通信の約束ごと）がありますから、Webページがどんな機械に 置かれていようと、またユーザがどんな機械で閲覧していようと、関係なしにデータを送る ことができます。ところが、上に書いたように、各行のシステムが異なりますから、 通信方法も異なります。ストレートに送受信できれば問題はありませんが（そんなレベルで 問題があればお話になりませんが）、もし送信が正常に行われなかったらどうするか、 システム全体で矛盾が生じないよう、細かく決めておく必要があります。このレベルで 問題が発生した可能性は小さくないと思います。 ルーティング機能は、プロトコル変換機能とも関係するものですが、このレベルで問題が 起きたとは思いません。 もう一つ問題が起きた可能性があると思っているのは、バッファリング機能です。処理量 が予想を上回ったとコメントされているからです。 ・・・と推測した上での私の評は「お粗末」です。データ収集不足とテスト不足以外の 何ものでもありません。バブル崩壊からこの方、ダウンサイジングやアウトソーシング といった様々な波がシステム部門を襲ったはずで、あるいは要員が不足していたのかも しれませんが、もっときちんとできたはずだと思います。
その他の回答 (2)
私がコンピューターから足を洗ってかなりの年月が経つのですが． 銀行のオンラインシステムは各社各様でまったく互換がありません。 ある会社なんて．本来ＳＱＬとかＦＯＴＲＡＮで構築すべきシステム管理をコポルで構築するなんて．無茶をやってのけた会社もあるのです。 このコポルでシステムを管理するのは凶器の沙汰に近い行動で． 事象発生．占有．事象の処理．解放 の一連の流れを待ち行列につないでおこなわなければなりません。 多分．２重引き落としがあって．引き落とし忘れがあったところをみると．待ち行列が極端に短かった（処理が多すぎてコンピューターが追いつかなかった）ような気がします。 これは．事象発生の後の占有に失敗すると待ち行列の実行が停止します。すると．もう一度待ち行列を最初から実行しますので．同じ処理を２会してしまう事になりますから。 多分．３社の相互通信コンヒューターの処理能力が極端に低いか．変な仕事を押し付けていたために．相互通信コンヒューターが本来の処理が出来なかったためでしょう。だから．処理が停止する土日で復旧できたのですし．前倒しで通常の業務が停止している夜中から処理したから１０日の集団引き落としが修了したのでしょう。 単に相互通信コンヒューターの処理能力が低すぎただけです。 現行のコンヒューターの３社間連絡通信網の容量不足でしょう。
お礼
返信いただいたみなさんありがとうございます。 週末、留守してましたのでお礼が遅れたことをお詫びします。 いろいろ勉強になりました。感謝いたします。 本日、質問を締め切りいたします。（4/14） ありがとうございました。
補足
返信ありがとうございました。 3行のコンピュータシステムはどれをとっても 大手なのにちょっとお粗末でしたね。 未だにトラブルは続いてますね。 いつまで続くのでしょうね。
ＩＴ業界に正社員として入り３年目を迎えるものです。 銀行システムはＣＯＢＯＬ言語で記述されているとずいぶん前に聞いたことがあります。 ですが、昨今Ｃ＋＋やJava等も活躍していますのでこれは一概には言えません。 いろいろな言語を習得していくと考える部分がありますね。 「Ｃ＋＋とＪａｖａを結合する…考えたくもない」と言うこと。 ですので統合三社の採用企業が異なるよりも使用言語、バージョンのほうが気になる所ですね。 同じバージョンの同じ言語全て記述されていたら統合は比較的スムーズだったと思いますよ。 逆に同じ企業でも使用言語が異なれば、資料がきちっとあるとはいえ難しいでしょうね。 (破棄してしまうほうが容易ではあります。そして末端の入出力はそれっぽく変更すればいい) ですので、言語レベルでの統合に無理があったが正しい解釈と考えます。
お礼
返信ありがとうございました。 トラブルが止まりませんね。 勉強になりました。ありがとうございました。
お礼
返信ありがとうございました。 今回のトラブルはなんとなく「Y2K」で指摘されていた ことがそのまま出ているような気がします。 「Y2K」の時はエンジニアの方々も初めての経験であり 「危機感」があったと思うのです。 それで、当初言われていたトラブルが発生しなかった と思っています。 やはり甘く考えていたのかもしれませんね。