PR
カレンダー
たばきん
物欲の街、アキハバラで散財生活を送るエピソードのあれこれ
2002年04月06日
テーマ： 一流の意識・仕事術とは？(111)
カテゴリ： カテゴリ未分類
ナポレオンの言葉でしょうか？
（雌にばかり狩りをさせて何もしないダメ雄、というイメージは最近の野生研究の成果によるもので、この言葉の裏側には微塵もそんな影はないですねﾊﾞｷｯ!!☆／(x_x)）。
リーダーが戦略的な視野を持っていないと、例え優秀な部下を数多く持っていても、役に立たない...という比喩なんですけどね。
まぁ並な獅子は、部下の羊をパクパク食べてしまいそうで、それこそ無能をさらけ出してしまうかもしれませんが...
この間のM銀行の顛末は、これを地でいっていますね。
システム障害による口座振替の未処理件数は5日現在10.5万件
新たに誤送金の発生も判明
これの 記者会見用資料 もなかなか面白いです。
最後の方にシステムの概略を書いた資料が出てきます。
M銀行はF銀行、D銀行、I銀行が合併して出来た銀行ですので、3/31までそれぞれ別々のシステム（I社、H社、F社のシステム）を使っていました。それぞれのシステムは中継接続コンピュータで接続されています。
また147件の引き落とし未了の処理でも残高が引き落とされていることがわかりました。これ自体はなんとか147件の顧客に2日までに現金を返すなどの処置をしたようです。しかし、悪いことは続くもので、口座振替の遅延や二重引き落としが発生してしまいました。（当初10万5千件、その後250万件に上ることを発表）
この図を見ていると、全銀やBANCS等の対外インターフェースはD銀行のシステムを使っていて、F銀行のシステムからは既存のATMをつないでいるだけのようです。振替にしても、一旦D銀行のシステム（STEPS)で受け付けてから、各銀行の口座に入れる、という方法のようです。
ここにも中継接続コンピュータが関係しているようです。
一体、この中継接続コンピュータというのは何なのでしょうか？
メーカーの違うホストマシンの接続手順というのはあらかじめ決められたものしかありません。まして他のメーカーの接続なんて最初から考えないのが普通です。（頭を下げて接続に参る、というのが元々のホストマシンのお手前ですので）
そこで、異なるホストマシン同士の接続手順を「通訳」するマシンを用意すればいい、ということになります。
問題はこの「通訳」の中身と「通訳」に必要な時間です。
単純に通信制御手順だけの問題なら、業務電文の内容を保護するだけでよいのですが、ここに各種のコード変換処理を組み込みはじめると、際限なく泥沼に陥ります(^0^;)
たとえば他行のATMからF銀行のカードを使ってカネを下ろそうとした場合、
他行のATM→他行のホストマシン→BANCS→D銀行のホストマシン→「RC1」→F銀行のホストマシン
という経路で、まず残高照会が出来ます。そしてこの逆の道順で他行のATMに応答を返すのですが、おそらくBANCSにたどり着くまででタイムアウトしてしまったケースが少なからずあったのではないかと思われます。
通常、タイムアウトした時は、取引未成立で元帳の残高を元に戻さないといけないのですが、この指示が「RC1」の中でエラー電文なのか、取消電文なのか、錯誤に陥った可能性があります。元々インテリジェントな処理をさせるために流量を制限していたのに、1日の「想像を超える取引量」をこなすために、その制限を取り払ってしまった代償なのかもしれません。
わがままなホストマシンの狭間でしわ寄せを喰らった不幸は、やがてホストマシン全体を含むシステム全体に影響を及ぼしてしまった、というわけです。現場に全体を統轄する役割の人間がいない、というのが致命傷だったのではないでしょうか？（そういう役の人はいるかもしれないけど、例えば執行権限が与えられていなくて、即時の対応が取れない..などの弊害も考えられます→副頭取がヘッドに立つ対策委員会を持つようですが、時すでに遅しですね）
今回の経営側の見識の甘さ（ 「準備すべきことの認識が甘かった。慎重で手厚いシステム・人的対応を取るべきだった」 なんて発言が責任者から飛び出してくる...）は、まさに 「気の緩み」 としてきちんと経営責任を取らせないといけないのですが、持ち株会社化してしまっているこの会社の責任は誰が取るべきなのか？で、これまたグループ内で揉めそうですね。
ここでも利用者不在、預金者不在、株主不在の泥沼が用意されているようです。公的資金をいくら投入しても、貸し渋りはする、預金金利は際限なく落とす、では「盗人に追い銭」と言われても仕方ありません(^0^;)
せっかく獅子百匹飼っているんですから、先頭に立つのも獅子であってほしいものです。くれぐれも部下をスケープゴート（生け贄の羊）に出さないようにお願いしますよﾊﾞｷｯ!!☆／(x_x)
それにしても1800文字から5000文字に制限が拡張されたので、これだけ長い日記でもOKになりました。ここまでお読みくださり、ありがとうございました。
（雌にばかり狩りをさせて何もしないダメ雄、というイメージは最近の野生研究の成果によるもので、この言葉の裏側には微塵もそんな影はないですねﾊﾞｷｯ!!☆／(x_x)）。
リーダーが戦略的な視野を持っていないと、例え優秀な部下を数多く持っていても、役に立たない...という比喩なんですけどね。
まぁ並な獅子は、部下の羊をパクパク食べてしまいそうで、それこそ無能をさらけ出してしまうかもしれませんが...
この間のM銀行の顛末は、これを地でいっていますね。
システム障害による口座振替の未処理件数は5日現在10.5万件
新たに誤送金の発生も判明
これの 記者会見用資料 もなかなか面白いです。
最後の方にシステムの概略を書いた資料が出てきます。
M銀行はF銀行、D銀行、I銀行が合併して出来た銀行ですので、3/31までそれぞれ別々のシステム（I社、H社、F社のシステム）を使っていました。それぞれのシステムは中継接続コンピュータで接続されています。
また147件の引き落とし未了の処理でも残高が引き落とされていることがわかりました。これ自体はなんとか147件の顧客に2日までに現金を返すなどの処置をしたようです。しかし、悪いことは続くもので、口座振替の遅延や二重引き落としが発生してしまいました。（当初10万5千件、その後250万件に上ることを発表）
この図を見ていると、全銀やBANCS等の対外インターフェースはD銀行のシステムを使っていて、F銀行のシステムからは既存のATMをつないでいるだけのようです。振替にしても、一旦D銀行のシステム（STEPS)で受け付けてから、各銀行の口座に入れる、という方法のようです。
ここにも中継接続コンピュータが関係しているようです。
一体、この中継接続コンピュータというのは何なのでしょうか？
メーカーの違うホストマシンの接続手順というのはあらかじめ決められたものしかありません。まして他のメーカーの接続なんて最初から考えないのが普通です。（頭を下げて接続に参る、というのが元々のホストマシンのお手前ですので）
そこで、異なるホストマシン同士の接続手順を「通訳」するマシンを用意すればいい、ということになります。
問題はこの「通訳」の中身と「通訳」に必要な時間です。
単純に通信制御手順だけの問題なら、業務電文の内容を保護するだけでよいのですが、ここに各種のコード変換処理を組み込みはじめると、際限なく泥沼に陥ります(^0^;)
たとえば他行のATMからF銀行のカードを使ってカネを下ろそうとした場合、
他行のATM→他行のホストマシン→BANCS→D銀行のホストマシン→「RC1」→F銀行のホストマシン
という経路で、まず残高照会が出来ます。そしてこの逆の道順で他行のATMに応答を返すのですが、おそらくBANCSにたどり着くまででタイムアウトしてしまったケースが少なからずあったのではないかと思われます。
通常、タイムアウトした時は、取引未成立で元帳の残高を元に戻さないといけないのですが、この指示が「RC1」の中でエラー電文なのか、取消電文なのか、錯誤に陥った可能性があります。元々インテリジェントな処理をさせるために流量を制限していたのに、1日の「想像を超える取引量」をこなすために、その制限を取り払ってしまった代償なのかもしれません。
わがままなホストマシンの狭間でしわ寄せを喰らった不幸は、やがてホストマシン全体を含むシステム全体に影響を及ぼしてしまった、というわけです。現場に全体を統轄する役割の人間がいない、というのが致命傷だったのではないでしょうか？（そういう役の人はいるかもしれないけど、例えば執行権限が与えられていなくて、即時の対応が取れない..などの弊害も考えられます→副頭取がヘッドに立つ対策委員会を持つようですが、時すでに遅しですね）
今回の経営側の見識の甘さ（ 「準備すべきことの認識が甘かった。慎重で手厚いシステム・人的対応を取るべきだった」 なんて発言が責任者から飛び出してくる...）は、まさに 「気の緩み」 としてきちんと経営責任を取らせないといけないのですが、持ち株会社化してしまっているこの会社の責任は誰が取るべきなのか？で、これまたグループ内で揉めそうですね。
ここでも利用者不在、預金者不在、株主不在の泥沼が用意されているようです。公的資金をいくら投入しても、貸し渋りはする、預金金利は際限なく落とす、では「盗人に追い銭」と言われても仕方ありません(^0^;)
せっかく獅子百匹飼っているんですから、先頭に立つのも獅子であってほしいものです。くれぐれも部下をスケープゴート（生け贄の羊）に出さないようにお願いしますよﾊﾞｷｯ!!☆／(x_x)
それにしても1800文字から5000文字に制限が拡張されたので、これだけ長い日記でもOKになりました。ここまでお読みくださり、ありがとうございました。
お気に入りの記事を「いいね！」で応援しよう
Re:一匹の獅子に率いられた百頭の羊は、一
売り子☆姫
さん
唐､ちのかーちゃんがD銀行を使っていたので、<br>合併になったら、絶対ばたばたする～～<br>と言って、事前に預金の引き出し<br>記帳をやったそうだ。かあちゃんえらい。<br>2000年問題では、動かなかったのに。<br>でも、引き落とし先が、M銀行なんで、<br>「確認のため」といいつつ、やっぱり遊び歩いているようだ・・・・。
(2002年04月06日 11時26分26秒)
Re:一匹の獅子に率いられた百頭の羊は、一
pianika!!!
さん
唐ｽばきんさん、こんにちは！<br>わかりやすい説明で、今回のトラブルの件わたしでもわかりましたぁ。<br>いちおうM銀行と取り引きはないので傍観者的立場ですが、これから自分の銀行が合併するときは気をつけよう。<br>↓下記の売り子☆姫さんのおかあさまのように、合併前にいろいろ処理しておいたほうがいいなと学びました。<br>では、また(〃⌒ー⌒〃)ノ
(2002年04月06日 11時35分14秒)
Re:一匹の獅子に率いられた百頭の羊は、一頭の(4/6)
武蔵野唐変木
さん
ついに日記？になっちゃいましたか。(^^;<br><br>近視眼的な作業、枝葉を見て大樹を見ず、というか･･･。<br>システムの陥る罠に見事にはまっていますね。金融業界のシステムには関わった事はありませんが、現業で携わっていない私にも解っちゃうので困ります。<br><br>不労所得しかない私が毎月振り込む先なので、きちんと処理してくれないと困ります。＞目一杯、不安！
(2002年04月06日 13時17分11秒)
Re:一匹の獅子に率いられた百頭の羊は、一頭の(4/6)
うりこひめ
さん
あ、そうだったの？<br>５０００文字までＯＫになったんだー！<br><br>ところで、いつも思うのですが<br>たばきんさんは、難しい漢字をよく使っていますよね。<br>（それがフツーのお・と・な？）<br>＞逞しい娘ほどおいしい「締まった」おにぎりでした。<br> ↑これは、なんて読むんでしょう。<br>随分考えましたが、やっぱりわかんない！！！<br><br>私には、できるだけ ”ひらがな”で書いていただければありがたいのですが・・<br>おバカ！でごめんね＊<br><br>（＊＾－＾＊）<br><br>＊うり＊
(2002年04月06日 16時18分41秒)
Re:一匹の獅子に率いられた百頭の羊は、一頭の(4/6)
巨頭星人
さん
たばきんさま<br>なるほど。かなり説得力のある推理であると思います。<br>実はこんなことはプライベートの企業のシステムのなかでは数多く<br>見受けられます。同様に汎用機のメインシステムと多くのWindowsや<br>Unixなどのサブシステムで構成されるものです。たいていは融通の<br>利かない汎用機システムに原因を求められることが多いのですが。<br>プライベート企業内のことだけでしたらあまり表沙汰になることは<br>ないのですが、今回のような公共性の極めて高い大銀行での出来事<br>となると社会的影響は大きいですよね！<br>仰るようにシステム全体を本来の意味で管理できる技術者がいなか<br>ったのでしょう。<br>巨大になったがゆえにシステムの脆弱性とカオス傾向が強まってし<br>まったというのは警鐘になると思うのですが、このことがちゃんと<br>認識されるかどうかも疑問ですね。<br>巨頭星人<br>
(2002年04月06日 19時19分24秒)
，???Y
紫風
さん
Re:一匹の獅子に率いられた百頭の羊は、一刀uうーん、そういうことだったのね」と<br>興味深く読ませていただきました(*^_^*)<br>田舎に生息しておりますので、今回の件に関しては直接関係はないのですが、銀行などの合併はリスクのあるのもだったんですね・・・<br>大きくなりゃいいってもんじゃないんですね。<br>まっ、どのみち大銀行は、個人なんて相手にはしてくれませんからね。<br>うちみたいな、個人事業者は、信用金庫しか頼るところがありませんね(*^_^*)<br><br>
(2002年04月08日 11時33分42秒)
【毎日開催】
15記事にいいね！で1ポイント
キーワードサーチ
▼キーワード検索
コメント新着
© Rakuten Group, Inc.
