全21件 (21件中 1-21件目)
1
東電の福島第1原発における停電原因について最終見解が報道されていた。前に一番疑わしいとされたネズミ侵入によるショートであると断定していた。十分予想されたことだと周囲の人たちも東電側も話している。その通りだと思う。じゃあ、予想されていたのになぜ予防策を講じていなかったのか?そこについての説明がまったくないのがまずいのではないかと思う。現場を見たわけではないので、あくまでも、推測だけど、現在、3000人の人があの場所で働いているということを考えるとさまざまな対応が並行して行われているはず。緊急度の高いものもあれば、1つの場所に多くの機材や人が入れないことからどうしても後回しにせざるをえないというものもあると思う。その中でこの事故予防はどのような位置を占めていたのかを説明しないことが一番の問題ではないかと思う。考えられるトラブル予防策がすべてすぐに実行できればよいけど、実際にはいろいろな制約があり、一斉に実行に移すことは不可能なことがほとんどだ。その時に優先度をつけて、実行せざるを得ない。そのようなことを東電は行っていたのかどうか?結果としてトラブルが発生し、「これは今月末に交換する予定でした」だけを発表したのでは言い訳に聞こえてしまうだろう。技術者観点から見ても、本当に危険度を把握した上で工事の優先度を付けていたとは思えない。作業や工事の優先度をどのようにランク付けしているのか?その中でこの予防策はどのランクにあったのか?東電のサイトをみても今回の事故に対して、そのような報告が1週間たっても出てこないことが問題だと思う。初動で状況把握をうまく行い、時間的な余裕があることを確認したうえで優先度を付けて、順番に電源回復を図っている対応と予防策についての話が出てこない状況はあまりに格差がある。報道関係への説明だけが情報提供ではなくなってきているし、それも分かってWebでも情報公開をすすめているのだと思うので、説明責任を果たしてほしいと思う。もし、優先度が整理できていなかったなら、この事故を契機に優先度を整理すべきだと思う。東電の事故はどれも世間の関心が高く、危険と隣り合わせなので、大変であり、僕が関わっているような簡単なコンピュータシステムとは違うのかもしれないが、予防策の実行に対する考え方の基本は同じだ。
2013.03.26
コメント(0)
東電福島の核燃料プールの冷却システム停止のニュースがおとといから流れていて、先ほどのニュースで29時間ぶりに回復したと言っていた。東電自体は十分な時間的な余裕があるので確認を行った上で復旧を行うという発表に対して、この様な自体を想定していたのかとの質問が報道陣がでていた。すべてを想定して、100%トラブルを起こさないことを求めるかのような質問に疑問を感じてしまう。今回の冷却システムについては停止してからの時間的な余裕があることは早くわかっていたし、急いで復旧するよりも2次災害を起こさないように十分な確認をした上で復旧にあたったのは技術者からみれば妥当な判断だったと思う。どれだけ色々想定してもすべてを想定できる訳ではないし、現在の福島第1原発に設置してある装置のほとんどが突貫工事的なものであろう。だからこそ、発生したときの状況把握とできるだけ適切な判断というのが一番求められると思う。トラブルが発生してもすぐに復旧するようにすべてを2重化して、トラブルフリーとすることが夢のように語られるが、すべてをそのようにしていくには時間もお金も足りないのが一般。また、2重化しても完全にトラブルフリーにはならないこともコンピュータシステムトラブルでも過去が証明している。コンピュータシステムでも何時間停止するとどのような影響・問題が発生するのかを事前に考えておけば、柔軟な対応ができるのに、早く復旧することばかりを考えて失敗しているのはいくつもある。記憶に残っているのは東日本大震災の後に発生したみずほのトラブルもそんな事例だと思う。それこそ、トラブルの要因を想定して防御策を考えるだけでなく、トラブルで停止すること必ずあるのだから、停止時間がどれだけ長引くとどのような影響・問題が発生するのかを想定しておくことが重要だろう。
2013.03.20
コメント(0)
昨日に続いて、今日はコンピュータシミュレーションについてちょっと考えさせられることがあった。コンピュータシミュレーションというのも非常に多種多様になってきていると思う。有限要素法に代表されるような数値解析もあれば、待ち行列問題や物流のようなOR分野もある。さらにシミュレーションではないのかもしれないが、フライトシミュレータも幅広い意味ではコンピュータシミュレーションと言われれば、シミュレーションの一分野なのかもしれない。厳密な定義が見当たらないので、コンピュータを使ってある状況をコンピュータ上で再現することがコンピュータシミュレーションと言っても良いのだろう。どれもある仮説=考え方にしたがって、コンピュータ上に数学的なモデルを作成し、その数学モデルから予測や過去の再現しているのだけど、その再現性をどうやって検証するのかが一番むずかしいところ。手間暇かけて、実際に起こったことを再現したとしても、過去に起こったバターンの検証はどうしても一部分に止まってしまう。実際のところ、有限の時間と有限のコンピュータパワーで再現するにはモデルのどこかを妥協せざるを得ない。したがって、完璧なシミュレーションというのはあり得ないのだけど、すごいコンピュータやすごいソフトというお題目だけでなんか完璧に思ってしまう人が多いような感じをうける。結局、理解できないところになるとまったく受け入れないのか、100%信じてしまうのかのどちらかに極端に偏ってしまう。現在の天気予報もシミュレーションの一種だけど、計算時間の制約などから100%あたる結果は出てこない。それでも以前よりは非常に良くなっている。コンピュータの能力アップだけでなく数学モデルの進化もあると思うが、どこまで言っても100%とはならない。100%にならないから使えないということでもなく、外れることが何%かの確率で発生する、あるいは、含まれていない条件があるということを理解した上で使えば使えるのだ。しかし、この様な説明をするとわかりにくくてつかえないという判定がくだされてしまうのが、ジレンマ。今日、シミュレーションの研究をしてる学生さんたちと話する機会があったのだけど、100%再現することを目指しているような発言があった。素人のひとならともかく、プロの入り口にいる人たちがシミュレーションの基本みたいなところをどこまでわかっているのかなとふと不安になった。この100%主義というは日本の特性なのかもしれない。1%でも不完全な部分があるとダメという烙印が押される。それがこのようなところにもでているように思えた。考えすぎだろうか?
2013.03.19
コメント(0)
今日、ちょっとある人と話をしていて、考えさせられた。その人が言うには自動化が進んでいるシステムが良いシステムだと。しかし、あまりに自動化してしまうと自由度が下がって、いろいろ調整して使いたいユーザーには思ったようにならずに使いにくいシステムになってしまうという話。最近のソフトはできるだけ操作を少なくすることを考えて設計されていることが多くなってきた。けど、その想定された使い方から外れるとどうやって調整したら良いのか分からないことが多い。その想定パターンがよく使うパターンであれば問題ないのですが、さまざま使い方が想定されるようなソフトについてはそれでは使いにくいということなる。操作を少なくしようとしていることが、逆に操作を複雑にしているというパターン。僕自身は使いやすいソフト=良いソフト、使いやすいシステム=分かりやすいシステム=良いシステムだと思っていて、自動化=良いシステムとは思っていない。ブラックボックスにしても良いのだけど、それから出てくる答えに納得性があれば良いが、納得いかないが自動化されているでは良いシステムとは言えないと思う。単純なエアコンのコントロールでも外気温との差や前日との差など人間は絶対値で感じ取っている分けではないので,絶対値で18℃にコントロールしても満足しないし、外気温だけとか一部だけでも満足しない。それくらいなら絶対値を簡単に指示できる既存のシステムが簡単であり、生き残ってきているのだと思う。自動化という誘惑の言葉にどうしてもシステム屋さんは引かれていくんだけど、その開発する手間とそれが本当に使う人が満足してもらえるものになるのかをよく考え見ることが大切だと思わされた日でした。
2013.03.18
コメント(0)
ちょっとこの写真のシールをみてください。JR北陸線の特急列車の座席に貼ってある出口の案内。これまで何気なしに見ていたんですが、今回はちょっとした疑問がわきあがってきました。このシールが直接的に示しているのは座席に平行な左右で、座席に直角な前後の出口を示している。さらにこの座席180度回転するので、出れない出口は前後で変化するのに、この一枚で表現できているのはなぜだろう?しばらく、考えてみたら、人間の思いこみをうまく利用したシールだと理解できた。まず、座席に座って、出口が前後にあることは列車に乗った人には理解できている。このため、このシールは左右で示しているが、前後を表現していることだと見た人が解釈する。では左右をどうやって前後に変換するのか?これがシートの右側に貼ることで人は右回転させて考えることを利用しているのだと理解。でもシートを180度回転させるとその考えはまちがっていることに気付いた。単に自分が入ってきた方向を理解しているので、その既知情報でこのシールをあてはめて考えるだけだと納得した。人の思いこみをうまく利用して、左右表現を前後指示に変換することを可能して、シートが回転してもこのシール一枚でお知らせすると言ううまいやり方です。単純だけど、直感的に分かると言ううまいやり方ですよね。システム設計でもこんな感覚でインターフェースを設計できたらと思った事例でした。
2013.03.17
コメント(0)
今日、みずほの株主総会があり、その中でやはりシステムトラブルが焦点になったとの記事。当然のことだと思う。しかし、どうもみずほ銀行から出ている資料を見ても、どうも信頼回復をどうしていくのかが分かっているのかなと疑問を感じてしまう。みずほ銀行のサイトの「株主みなさまへ」のP3をみると、次のような点に疑問を感じる。このページに今後の変革についてのまとめを行っているけど、次の点は矛盾しているのではないか?1、「お客様第1主義」と「ワンバンク」統合はどうして繋がるのか?拡大解釈すれば、「ワンバンク」でないことが内部のいざこざに終始していて、お客様を向いていないのと言うことなのかもしれない。しかし、そんなことはすでに他行では出来ていることであり、「お客様第1主義」を示していることではない。2、その統合の中に「業務インフラの一元化」があるが、これも目的が効率化である。今回のシステムトラブルでは効率化ではなく、品質を求められているはず。3、やはり収益力強化が1番?その実行プログラムとしても1番が収益力で2番が財務力になっている。今回の問題の起点となった現場力は3番目?信頼を回復するには人事の問題は根底にあるけど、業務品質をどうやって高めるのかが1番でその土台が業務システムであり、この基盤・土台の上で収益力強化ではないのかなと思う。「お客様第1主義」を抱えているけど、外からみるとまだ内側が気になって仕方ないと見えるのは僕だけですかね?
2011.06.21
コメント(0)
日経コンピュータからこの3月のみずほトラブルを解析している記事が配信されてきた。30のトラブルが重なったためという内容だけど、僕が着目しているのはなぜ早期に回復が出来なかったのか?と言う点。確かにシステムテストが掛けていたとか、リスク評価が不十分であったというのは正解だし、その部分に手を打っておけば、このような重大なトラブルに発展しなかっただろう。でも、どれだけ事前に考えても、その想定を越えることはある。問題はその想定を越えたかどうかが早く分かることとその想定を越えた場合にどれだけ早く対応方法を見つけるか、あるいは、問題の拡大を止めるために通常運用を止めるのかというような判断をどうしたら早く行えるのかである。今回のみずほのトラブルは想定外と思われることが、当初から発生していて、さらにはシステム担当者が経験していないトラブルであることはトラブルが発生した夜間バッチのトラブルが発生した段階では明らかであったと思われる。でもシステム部門あるいは担当者は復旧できると報告したのか?それとも上層部が復旧せよと命令したのか?なんとしてでも次の日の稼働を優先したところが一番、今回の問題を表しているように思える。その背景が旧組織のエゴだったのか?組織全体として悪いことを認められないのか?わからないことを素直に分からない、あるいは、トラブルが自分たちの力量を越えたところだとうことを素直に認められるというような当たり前のことが一番難しい。けど、テストにしても監査にしても、トラブルを起こさないため準備であると同時に、どこまでは対応ができるのかを確認したことにもなっているはずという認識ができていればできるはずと思っている。それよりもこの教訓として、日本の文化の中にある「完璧でないとだめ」という追求は「できない」という発言を止めてしまっている点を反省することからスタートと言いたいな。
2011.06.13
コメント(0)
システム屋として、ずっと注目しているみずほ銀行トラブルに対して、金融庁が業務改善命令を出した記事が今日ありました。ここ。内容的にはこれまで報道されてきているのと同じで、責任が不明確になるような企業風土とスピード感に掛ける企業風土を改善しない際という。2002年に指摘されたシステム統合に点いての問題も風土問題としてはっきり指摘している点は評価できるものと思うが、どうだろうか?6月末を期限として改善計画を提出することが求められているけど、どんな改善計画というのか、具体性をどこまで計画として盛り込めるのかがほんとうに信頼回復を行えることを示す最後のチャンスだと思う。僕も野次馬で言いたい放題かも知れないが、外部からの指摘がどれだけあっても、内部が自ら行動しなければ改善はできないということを経験しているので、みずほ銀行にもはやく気づいて行動となって改善がみえるようになってほしい。金融庁発表の行政処分みずほ銀行の今日の発表
2011.05.31
コメント(0)
ちょっと忙しくて、このニュースを見落としていました。全文をすみからすみまで読んではいないけど、原因と対策の部分を読む限りではこれまでの報道されていることからはそんなに新たなことはない。義援金振込口座で問題を起こしたのは1つだけでなく、2つあったことが問題を複雑化したことはこれまで報道されていなかったように思う。この報告書はちょっと期待はずれ。というのも問題の掘り下げが浅いように思う。組織体質などへの掘り下げがほとんどなく、単に投資が不十分であったことやリスク分析が不十分であったで終わっていて、なぜ、リスク分析が不十分であったのかへの追求がない。この点は第3者による報告書であるので、分析することが難しいのであろう。組織体質や企業文化のことはどうしても主観が入るので、第3者としては報告書に意見を述べることができないのだと思う。やはり、自ら分析して反省して、それで決意を述べる、そんな報告書が今必要じゃないのかな。そう考えてみると、第3者による分析の良さはある一方で、その報告を受けて、自己分析の上に自己反省と決意を表明しないとこの報告書で要求されている継続的な改善ができないと思う。その意味では報告書が継続的な改善を求めるだけでなく、自ら深く分析する事を求めることが欲しかった。
2011.05.27
コメント(0)
最近、また業務システム設計の仕事に戻ってきて、昔勉強したことを思い返すようになってきた。システム屋と言われる人たちはコンピュータを使えればOKみたいな風潮は20年前と変わらず、意外と「システムとは」という定義を知らない人もうちの社内には多い。システム屋と言われる人が「システムとは」と改めて聞かれて「どきっ」としている。昔読んだ本にはインプットとアウトプットが定義され、さらに定義された処理を有しており、その処理によりインプットを処理すると要求定義されたアウトプットが得られるものと書いてあったように記憶している。若干の表現の食い違いがあるかも知れないが、要求される出力を得るための処理を明確にし、さらにその処理を行うための入力を定義し、これを表現したものがシステムと呼ばれるものになる。コンピュータはまさにアウトプットもインプットもはっきりしており,処理についてもプログラムというもの表現されているので、システムそのものとなる。この30年ほど前の定義からオブジェクト指向の考え方などが現れていて、少し表現の仕方が変わってきている部分はあるが、この考え方は基本の基本と信じている。この基本的な考え方で仕事の流れをシステム的に分析してみることが非常に重要である。意外とインプットが不明確なまま業務設計がされていることが多く、業務フローやユースケース図がそれらしく書かれていることがある。それは分析というほどのことを行わなくても、「インプットはなにですか?」という質問だけで、答えることができず、その業務フローはおかしいと判明するか、処理の説明を求めると破綻してしまう。システム分析もシステム設計もきれいに仕上げることが優先されて、現行の業務設計に問題があるという指摘は嫌われがち。なぜなら、曲がりなりにも現行の業務は遂行されているから、問題がないと信じられている。遂行されているのは定義されていないインプット情報は担当者が無理やりに集めてきたり、経験値をインプットしたりで、担当者が変わった途端に破綻するシステムになっている。それを解明してシステムを作り上げるのがシステム屋と言う意見も多いけど、システム的な思考なんて、ここまで説明するとごくごく当たり前のことで誰でも仕事を設計する上では行わなければならないことじゃないかな?それが出来ていないことを指摘する事自体、その部門や会社の問題を明らかにしていて、改善点を見つけていることだから非常に大切なことだと信じている。
2011.05.26
コメント(0)
以前から注目している、この3月の震災後に発生してみずほ銀行のシステムトラブルのその後で、今日はみずほ銀行とみずほコーポレート銀行と合併の記事が出てきた。3行が合併してできた銀行でその昔の体制がみずほ銀行のシステム投資判断やトラブル対応判断にも影響したというのが報道関係の論調になっていて、この合併がその体制問題の解決の一つであるとの話になっている。たしかにトラブル時の対応判断に遅れや間違いがあったために今回のトラブルが大きくなったのは否定できず、その判断おくれは組織や企業文化から来ているので、まずは見える部分から変えていくのは改善に繋がると思う。ただ、問題は表面的なことだけでなく、システムの担当者が率直な情報を経営陣に流すことが出来なかったのではないかというような内部の企業文化に起因するような問題にまで踏み込んでいけるのかが今後の解決の鍵であることは報道からも読み取れる。しかし、そのような動きについては委員会や金融庁の調査が終わるまでは報告出来ないという。組織の変更もトラブル対策であり、まだ、正式では無いにしても情報として出てきているのに、それ以外の対策案については金融庁などの報告が揃わないと話ができないというのはどうも矛盾しているように思う。地震対策のような緊急性は無いのかも知れないが、見えてきている問題についても早く取り組みを行うべきと思う。
2011.05.18
コメント(0)
システム屋として注目しているこのトラブル。ようやく金融庁へ報告書を提出したようです。内容はみることができないけど、この記事では人為ミスがクローズアップしているし、別のこの記事では合併した旧3行の確執が影響しているという報道になっている。どれも正解なのだと思う。いろいろな要素が絡み合ったからこそ大きなトラブルになってしまった事例だと思う。だから解決策も3行の確執を解消していくようなことから最初の口座受付のマニュアル整備まで多岐に渡ると思うが、どう連環しているのかや実行するために掛かる時間ことを整理した上で根気強く実行していく必要があると思う。実際のところ、システム屋から体質的な問題を上層部や利用者側にあげることは非常に難しいのは僕自身も経験している。でも例えば、使う側が一方的に絶対にトラブルの発生しないシステムを求めるような場合、使う側にはシステムを一緒に作り上げようということが欠落していることが多い。普通のシステム屋ならトラブルが発生しないように作ることは当たり前。なのにあえて、このような要求を出してくるとしたら、信用関係が崩れていて、責任のなすりつけが発生していると思う。もちろんシステム屋側にも問題があるはずで、だから信用ができず、当たり前のことまで要求している状態になっているのであり、そのことにシステム製作側も気づかねばならない。もちろん、手法や技術面というのは重要であり、これらの基礎がないままに利用者側の信頼を得ようとしても無理がある。いいたいのは技術的な話だけでなく、システムを作っていくあるいは運用していく時の気持ち見たいな部分も大きなウェイトを占めていて、その部分を感知できるようなアンテナを立てている必要があるということ。構築と運用に関わる体制と信頼関係について感じていないなら、チェックしてみてはどうか。100%大丈夫何て言うのは無いのに、「大丈夫」と答えさせた状態という記事を読んで、過去の経験を蘇って来るとともに、言い方が悪いかもしれないが、トラブルでみんなが目覚めて一体感を作れれば良い状態に持っていける絶好のチャンスで変化したことも経験しているので本当に注目するとともに自分自身の反省材料にしたい。
2011.04.29
コメント(0)
東日本大震災後の3月14日に発生したみずほ銀行のシステムトラブルから1ヶ月が経過。やっぱり区切りの1ヶ月ということでいくつかの記事を見つけました。みずほ銀行の発表毎日新聞週刊実話システム統合がうまく行っていなかったことが問題でそれに処理能力を越えるサービス提供をしたことが原因になっているというのが大筋の見かたになってきているように思います。そのシステム統合がうまくできていなかった原因として経営トップの体制とエゴが話題になっている。ほんとうかどうかは分かりませんが,そんな話が噂としてでもでてくることは何らかの問題が潜在していたのではと思います。システムエンジニアとは関係のない話のようですが、作るべきあるいは必要となっているシステムがまわりのエゴで作れないというのはシステムエンジニアとしては大きな問題として訴えなければならないことだと思います。自分自身がその局面になったときにできるかどうかというのはありますが、原理原則に立ち返り、あるべき姿を考えることというあたりまえのことができていないとこのようなトラブルは減ってこないと思います。どちらにしてもみずほ銀行は信用を大きく落としたことは確かであり、内向きの思考=権力争いが外部に影響を与えたことを素直に認めることが改善のスタートでしょう。直接的な原因に対する対処では解決しない問題であることは確かだと思います。
2011.04.16
コメント(0)
個人的に注視しているみずほ銀行トラブルですが、25日の会見以降の情報がでてきていません。みずほ銀行のサイトも28日のお詫びのままになっていますが、日経系のこの記事を見つけました。一番気になるのが振込処理システムのトラブルは銀行システムを知っている人の中では処理トラブルに至りやすいことは周知の事実で、みずほ以外では対策がすすんでいたとの話。ITガバナンスと指摘されていますが、確かにいろいろなサービスへの注力が優先されたのだとすると問題の本質はかなり奥深いところにあるでしょう。前にも書いたように、窮地に企業文化と言うか体質が出てくると。今回のトラブルはそれが表面化したのだと考えて、システム設計や運用面だけの対策に終わることのないようにしてほしいと思います。
2011.03.31
コメント(0)
このニュース、もうコメントもありません。明日というか、24日から25日にかけての給与振込が無事終わることを祈るだけです。すでに依頼先を変えた企業なども出てきているようで、24日の7:00段階でこの「終息宣言』後のトラブルに対するコメントがホームページで見られないことは非常に悲しい。以下にみずほのホームページの24日7:00段階でのコメントを残しておきます。お客さまへこの度のシステム障害により、お客さまに対し多大なご迷惑をおかけしておりますことを心より深くお詫び申しあげます。当行はシステムおよび遅延した事務の早期正常化に向け全力で取り組んでまいりましたが、3月23日(火)よりほぼ全てのサービスがご利用可能となっております。また、3月24日(木)の店頭・ATM等の営業につきまして、別紙(PDF/60KB)PDFのとおり、ご案内させていただきます。今回のシステム障害に対し、お客さまから多数のご意見・ご要望を頂戴しておりますが、その対応に至らぬ点がありましたことを改めて深くお詫び申しあげます。現在、頂戴したご意見・ご要望を真摯に検討させていただいております。お客さまには引き続き多大なるご迷惑とご不便をおかけいたしますが、何卒ご理解賜りますようお願い申しあげます。なお、この度のシステム障害は計画停電に起因するものではありません。【お問い合わせ先】フリーダイヤル:0120-3242-86 音声が流れましたら「1」と「#」を押してください。【受付時間】午前9時~午後9時
2011.03.24
コメント(0)
読売新聞の記事。さらにはこの記事。この記事のコメントには3回に渡って給与振込が行われているというのもあり、かなり混乱している模様。復旧処理は早くもあるが、ミスの悪循環になることは一番避けなければならないのが鉄則。そのあたりがどうも欠落しているのかも。コストと納期を優先して、品質は後回しなんていう最悪の状態が続いている。単なる人為ミスという会見があったらしいが、その人為ミスがなぜ起きたのか?最初は小さな人為ミスがなぜこんなに大きな事故になったのか?やはり体質的な問題が横たわっていないかをチェックする必要があると思います。どれだけ良いシステムを作ってもそれを運用する部分がお粗末なら、問題が発生する。今回はシステム設計自体もすごい古い仕様だとコメントしている人がいたりで、設計自体も良くない、運用も悪いのダブル、トリプルで大きなトラブルに発展している。もう「早く」を捨てて、「確実に」に集中すべきと思います。
2011.03.23
コメント(0)
この記事。やっぱりという印象。昨日の段階で22日の処理はきびしいだろうと予測したけど、その通りとなってきた。結局22日の午前はやり残しの振込処理を行うためにATMからの処理は預け入れと引き出しだけになった。さらにコンビニからの処理も午前中はストップということで、正常な状態になるのは23日以降という。25日の給与振込の集中については引き受けると言っているが、何が問題でどう対策したのかの説明がないのでは、信用できないと言うのが個人的な感想。もし、僕がみずほに口座があったら、全面的に移動させてしまうかも?厳しい意見かも知れませんが、説明があまりにも稚拙です。原因と対策の説明もなく、信じてくださいでは納得できないと言うのが普通だと思うのですが、僕が短気なだけでしょうか?
2011.03.21
コメント(0)
先ほど日記を19:00ごろ公開したけど、その後19:50にこの記事が出てきた。やっぱり、相当苦戦しているようで22日朝の正常化が厳しい状況になっている。みずほ銀行のホームページには何も掲載されていないので、この記事を丹念に読み取ってみよう。18日の夜、ATMを閉鎖し、窓口業務も終了した時点の未処理数が残っていないが、先の東京新聞の記事からすると18日の夜には27万件の処理ができたとあるので、19日の夜の116万件の未処理からすると143万件があったと思われる。20日の夕方までに38万件の処理が完了して78万件にまで減少した。それが問題が発生した15日分の未処理らしい。16日分が6万件、17日分が6万件の合わせて12万件を20日夕方までに処理する予定であったのが、まだ、処理できていないということで18日分の66万件の処理について目処が立っていないということらしい。ここには書いていないが、日付が過ぎているので、日付を過去日付とするような処理を行った後に各種処理を行わないと一時的に金額不足になったのかを確認できないので、この種の作業はシステム規模が大きいだけにかなり大変な作業と予測します。件数だけをみると18日分が際立って多いがこれは給与振込みが主。15日分も給与振込みがあったと見るのが正しいと思うので、ATMなどの給与振込み以外は10万件以下と見るのが妥当じゃないか?22日の朝までにこれら78万件を完了するのはぎりぎりの状況だろうけど、それにこの2日間の10万8000人分の引き出しはすでに反映されているのか?たぶん、処理の順番からすると18日分の66万件を完了した後に実施しないとここも処理順番の不整合が発生するので、この分は22日分発生分として処理させるのかも?ここまでの推測がただしいなら、22日の処理量は10万8000人+21日の引き出し分となり、10万件を軽く超えていて、システムの処理能力を増強したというが、19日から20日の状況からするとまたトラブルが発生する可能性がある。これだけATMを止めているので、現金を必要としていないが、振込みなどの処理を待っている人も多いのでは?実際の窓口へ行ったわけではないので(幸いながら、みずほの口座は持っていませんでした。第一勧業時代に引き上げて、それ以来作っていません。)、そのあたりの処理を行うことを書いていないし、実際にはシステムは停止しているので、振込みを受け付けたとしても、22日にしか反映できないことは普通に考えられます。このように考えてみると21日の66万件の処理も大変ですが、22日の方が本当に処理できるのか?こちらの方が山場に思います。
2011.03.20
コメント(0)
今朝のニュースもやっぱりおかしい。さらにこの記事。金曜日の夕方段階で90万件余りの未処理があり、先の記事では金曜日の夜に38万件の処理ができたことで確かに22日朝までには90万件の解消はできるであろう。後者の記事ではまだ72万件もの未処理が残っている。これでは22日の朝までに解消しない。東京新聞は入送金のすべての処理件数を上げていて、朝日新聞は振込みだけなのかもしれない。それだとすると振込みの処理が極端に滞っていると言える。振込みするための何らかの確認でエラーが発生しているのではないか?この連休はこれまでの溜まっている処理を解消するだけでなく、次のピーク25日の給与振込みにどう対処するのかをPRしてもらわないと安心できる状態ではないので、振込みに処理エラーが出ているのであれば、その原因を解消したという情報がない限り安心できない状態と思う。みずほのサイトももうすこし情報を公開しても良いと思うのですが。
2011.03.20
コメント(0)
みずほ銀行トラブルの続報が出てきました。夜間バッチ処理に問題があったらしいが、はっきりとした原因はつかめていないのか?公表したくないのか?はっきりと言い切っていません。単なるATMの処理問題でなく、バッチ処理がある条件のもとで非常に時間が掛かりすぎて、夜間に完了しなかった。それで処理がどんどん滞っている状態が続いている。なんとなく2日連続発生段階でうすうす感じられた内容。一番の問題はこの25日。給与振込みが集中するため、もっとタイトな状況が予測されている。通常は数日前から準備を始めるということなので、この連休明けの22日には正常に戻らなければ、また発生する。夜間バッチ処理がうまくいかないことで昼のATM処理もうまくいかなくなるという悪循環に陥っているので、21日がタイムリミットになる。この4日間もいろいろな制限を加えているのに解消するところか、逆に処理が溜まっている。18日に給与振込みが発生して処理が集中したこともあるのだろうが、好転しているとはとても思えず、原因を掴んでいるとも思えない。とりあえずの対処方法として、この3連休も窓口をあけることにしたが、これもこの3連休の暫定であり、システムの正常化が見られないと来週は何らかの制限を行いながらの運用になるものと思う。21日にはこの連休での対応状況について記者会見を行うということなので、引き続きシステム屋さんとして注視したい。
2011.03.19
コメント(2)
巨大地震の報道と原発事故の報道にやや隠れるようなみずほ銀行のシステム障害事故だけど、普段であれば大変大きな事件だと思います。1日ならまだしも3日続けて発生して、解消するのは3連休だという。3連休明けに起きないということがまったく説明されていない。こちらは説明がまずいとかではなく、考えられる原因についても開示されていないに等しい。みずほ銀行のホームページにもこの3月17日19:30現在説明らしい、説明がされていない。なんとか新聞報道のページから類推するしかないが、日経新聞の報道では地震後の都内一部の店舗での振込が集中して、処理能力を越えたためということ。だが、これが正しいとするなら、その集中している店舗を切り離せばよいし、夜間の処理が完了しないというのであれば、開始時間を遅らせれば良いはず。ATMの数を制限するだけでも解消しそうな報告内容なのに3日連続で停止していて、完全な解消は3連休明け明けというのはどうも納得できない。ホームページを見るとわかるけど3連休明けにはインターネットバンキングのリニューアルが計画されていることや今回の地震で停止しているATMが多数あることなどシステムに影響を与える要素がいくつもあり、このようなことが複雑に絡み合っているように思う。システムエンジニアの端くれとしては注目したい。
2011.03.17
コメント(0)
全21件 (21件中 1-21件目)
1