ITも、使う人が問題なんだよ。

総点検ねぇ…

前フェーズで検出すべきバグが一件でも出ると、前フェーズのテストの信頼性に疑義を持たれ「全部再点検しろ！」とか言われて、追加の作業が積み上がる。

その非人間的な苦痛な（続く

再発防止策が気合いでカバーする系で笑ってしまった

> これから取り組む再発防止では「組織の隅々まで、行員の一人ひとりに浸透させて自発的な取り組みにつながるよう徹底していく」と強調した。

正式報告書に基づく日経のこの記事、しかしやはりツッコミどころは「3年間で約7割減る」というシステム担当者への塩対応。つまり人を、技術者を大切しなかった報いです／

「傘下のみずほリサーチ&テクノロジーズでみのりに関わっていた人数が18年3月末から3年間で約7割減るなど「人員の減少などが、システム開発および運用に不可欠な技術力を弱めた可能性を否定できない」と指摘していた」

地獄の障害コンボ＞
"故障したディスク装置を予備の装置に切り替えようとしたが失敗。店頭取引のシステムが全面停止する可能性を認識したのは、21時半ごろだ。その後バックアップのサーバーに切り替えようとしたが、それも失敗"

設計通りになっているか、テストしてなかったのかな。

みずほフィナンシャルグループ，みずほグループは無くても日本に影響を与えないから廃業しちゃえよ🔥

「当初想定した設計となっているか点検を検討する」っていったところで、次は「当初想定した設計になっていたが、設計自体が間違っていた」となる予感。流石IT界のサグラダ・ファミリア。

「バグをよく見つける部署＝バグがよく出る部署」として、優秀なデバッグ能力のある人をリストラして行ったんじゃないか？と疑ってみる…。
＞：

35万人月の人員を抱え込んでおくことができないのは当たり前だから、人が減ったのはしゃあないけど、改善策が、「組織の隅々まで、行員の一人ひとりに浸透させて自発的な取り組みにつながるよう徹底していく」という精神論なので、たぶんまた再発すると思う。

これを言われるとなかなか途方にくれる感じがする。
ただ、状況的にここまで一回やらないと行けない…ってところまできているってことなんだと思います。
規模はもっと小さいですが、同じ様なことになりそうなのがすぐ隣で起きてて、でも手も足も出せないのが歯がゆい。

原因は誰にもわからないが解決策だけは極めて明瞭なこの会社のシステム、どこか（できればパワハラワンマンが経営している）銀行に会社ごと買って貰ってシステム全部を除却すればきっと解決する→ 報告書の全容判明、システム「設計通りか点検」

みずほの中の人も途方に暮れてるんじゃないかと思う内容ですが、結局これなのでは＞新システムに関わる人数が3年間で約7割減。「人員の減少などがシステム開発と運用に不可欠な技術力を弱めた可能性を否定できない」／

「当初想定した設計」であるとちゃんと判断できるんやろか？

運用系と予備系とバックアップ系の
トリプルハード故障とのこと。
うん？！ありえるのか？！
あるいは元々、壊れる仕様だった？🤔
なんか開発時から致命的なバグあった気がする。

ITに携わる人間として、この地獄は一生経験したくない

『発端になった富士通の機器の故障を最初に検知したのは19日の午後8時前だった。故障したディスク装置を予備の装置に切り替えようとしたが失敗。〜〜その後バックアップのサーバーに切り替えようとしたが、それも失敗』

←あれ？？この前NASの時に言ってた対策と同じじゃない？一瞬、今の時間が分からなくなったわ。。

納品時に確認してないんですかね…

◆

知らんのに適当こくけど、こういう現場って十中八九、吊し上げ文化で人の仲悪くて腫れ物に触れないので、情報の風通しが悪いのよね😅

設計通りとはどういった状態を言うのか。。。(禅問答

すぐ分かるぐらいなら年6回も、失敗しないよね。

この総点検は絶対に参加したくないわｗ

直ちに総点検しろとか言われたら、意味のない数万項目のチェックシート出してやりました感だすのはIT界あるあるだからな。各セクションごとに仕様を深く理解してる人物を地道に作っていって穴を塞いでいくしかない。

仏の顔も三度まで、だよ。

結局ハードが切り替わらなかった原因が不明って事か？
ハード切り替わらないでよく復旧したわ、、、、

総点検って言葉は良く聞くけど、絶対的に全設計を確認するとか不可能だろ。。。。

ディスク障害なんかどう考えてもテスト項目に含まれてるだろうに、そっちはどうなってるんだ

「きさま────いったい何千人のエンジニアの時間をその紙のために吸い取った!?」
「おまえは今まで書いた設計書の枚数をおぼえているのか?」

これぞウォーターフォール。

設計通りか点検する、の前に、何が設計として正しいのか仕様から点検する、でしょ。たぶん。
---

「エラーで失敗」「復旧が成功しない」「再起動に失敗」――。なぜこうもうまくいかないのか。大きな問題はシステムではなく人の運用にあるのかもしれない。

基幹システムで設計書など無意味って言っちゃう人、銀行の基幹システムで書類が残ってなくて「なぜ上手く行ってるか不明」「仕様が不明」なので、新システムで再現できないという問題を再度引き起こす気？

＞みずほは報告書で「ディスクが壊れた理由も偶然か、他の要因が内在しているのか現時点では不明で、さらなる調査・確認を進めていく必要がある」とした。

装置Aが故障したが予備装置に切り替わらなかったという時点で障害時にバックアップが作動しない場合の復旧手順って。どんなのだろうね？

世の中には設計バグ更に仕様バグというものがございまして、というのもあるけど、当初の想定から所与が変わってる可能性が大きいと思う。

半沢直樹みたいな超殺伐とした空気の中みんなで必死になって獲得した利益を使ってゴミシステム作っちゃうの本当に草すぎる

観点は「設計通りか」じゃなくてそれ以前に「設計自体がやべぇんじゃないか？？」くらいまで戻った方がいいと思うけど。。。

ピラミッドはできたが、本当に設計図通りになっているか、確認するってことかい⁉️

そっかーそこからかー(白目

まぁエッチデーデーひとつでここまで派手にイクのは何をどう考えてもおかしいしなー。余程根が深くてキッチリ隙間に落ちた系か、超絶しょーもない系か…

わりと地獄っぽそうだね。中の人、大変だと思うけど、頑張ってね

"新システムが「当初想定した設計となっているか点検を検討する」"

設計通りか点検←ｲﾏｺｺ
↓
設計通りでした
↓
設計を見直します

この展開までは読めた

原因はなお特定できておらず、巨費を投じて開発した新システムが「当初想定した設計となっているか点検を検討する」としている。

作ったばかりでスパゲッティになってるのか…

設計がミスってコトもある。
滑稽で漫画な事故続きで
ATM還付詐欺に関してはATMの現場検証を拒否して居るよ。

二審ではみずほ銀行の弁護士が公判で証拠になるのでしょうか？と叫んで居たよ。世も末だね！

どれだけの期間かけてどれくらいずつ減らしたかにもよるね。
日経(↓) だと3年で7割減らしたって話なので。

【Y!】みずほ、新システム導入後に要員６割減らす…トラブル遠因になった可能性

待機系のディスクが同時に飛ぶまではロット近かったからあるとしてディスク障害で災害用の遠隔サイト立ち上げる羽目になってるのすげーな。それ都内大地震とかのときに使う想定のやつちゃうん

あれだけのインシデントで報告書が50ページってだいぶコンパクトな印象だけども

これ、 テストとか運用テストってやつでは？？

設計通りだったらどうするんだ？

(｡･ω･｡)ﾉ みずほ報告書の全容判明、システム「設計通りか点検」

設計を証明する技術なんてあるんすかね...

九龍城砦のようなシステムを点検できる人材がいるのでしょうか？：

瑕疵担保で訴訟展開か？

未だに原因不明って…

①設計通りかどうか
②設計そのものは正しかったのか
③仕様に問題はなかったか
と辿ることになるでしょう。
相当大変そうです。
作り直したほうが早いかもしれないね。

そもそも設計が間違っている（考慮が漏れている）ってやつですよね…わかります…

設計から間違ってる定期

原因が特定できないって相当ヤバいよね。
しかも、こういう時に落とし所としてよくやる「設計通りか点検」。
これってあまり意味のない、時間のかかるだけの作業である事が多い。。。
報告の為の作業でしかない。

設計自体が間違ってたら永遠に見つからないし😅

もうみずほから逃げ出した方がいいだろうね。他のメガバンクだって巨大で複雑怪奇なシステム運用しているわけだけど、どれだけ障害起こしてたっけ？／

なんかすごいこと言い出しはじめたｗｗｗ

や、これって設計が間違ってるんじゃないかな。「要求通りか点検」なら話はわかる。

プロジェクト終盤に運用設計をケチったのかなあ。キツいプロジェクトあるあるだけど。ディスク障害要因の解明は難しいかもしれないね。。。それより、障害があることを前提に点検しないといけない。

“「エラーで失敗」「復旧が成功しない」「再起動に失敗」――。報告書からはさまざまな復旧手順を夜通し試しては復旧できない様子が浮かびあがった。結局、朝の開店までに間に合わないと認識したのは翌朝6時ごろだ。”

「報告書」の全容が判明しても。。実態と改善策とその実施戦略と予実、エンドユーザのリスク低減が図れたかが知りたいのであって、、、

「当初想定した設計となっているか点検」だと。
これの次は裁判か？

【運用前のテスト、レビューはどうなってた？
総点検が今からなのか？
これだけトラブル続きで。】
の全容判明、システム「設計通りか点検」

いや、そこじゃなかろ

> これから取り組む再発防止では「組織の隅々まで、行員の一人ひとりに浸透させて自発的な取り組みにつながるよう徹底していく」と強調した。

ーートラブルの連鎖。報告書から浮かび上がる現場の焦燥感。Think!欄にコメントを記しました。

言葉を聞いただけで大作業な気がするし、資料に全て残っているとも思えんし過去に参画した人を全員呼び戻すくらいのことをやらないと無理じゃないか。

運用を軽視するからこうなる。

ぐぇぇ…根本的な解決が出来ていないのが浮き彫りですな…この案件に関わるSEはしんどいね…

富士通のHDD故障を検知したのが19日の午後8時前。
故障したHDDを予備に切り替えようとしたが失敗。
店頭取引のシステムが全面停止する可能性を認識したのは、21時半頃。
その後、バックアップのサーバーへの切り替えも失敗。
開店に間に合わないと認識したのは翌朝6時頃。

はたして設計書が整備されているのか
ソースが仕様 の典型になるやろな

設計通りだった→設計したベンダーが詰められる
設計通りでなかった→実装したベンダーが詰められる
やつかな

●「設計」に運用に関わる設計を含んでいるか？（運用設計）
●「運用設計」には、障害時運用やBCP/DRの運用を含んでいるか？
● 同・IT部門以外のユーザ部門、経営まで含めた運用を対象...

/ みずほ先生……

“原因はなお特定できておらず、巨費を投じて開発した新システムが「当初想定した設計となっているか点検を検討する」としている”

あんたら評価しないでリリースしてるんかい？と言いたくなる。こんな基幹システム使っている会社にお金預けるの怖いわ〜

引用：原因はなお特定できておらず、巨費を投じて開発した新システムが「当初想定した設計となっているか点検を検討する」

「要求通りに正確に作る」
ことを求めることと
オープンソース化は相反する

どんなに注意しても論理矛盾や機器の制限とか設計通りにならないところは必ずあって、それが設計に還元されなかったり、周知されないのです。そういう箇所は、往々にして重要な要素であることが多いものです。

特段の進展はないということか。

つくづく、みずほにとってシステムは鬼門なのだと痛感するが、一方でこれだけ痛い目にあってもシステムを軽視し続けていることの表れなのでは。
システム部門の人員を6割削減したとの報道もある

全文は読めないけど、今年に入ってから6回も障害が起きているのか。銀行でこの障害は多い気がするけど、あまり叩くと思い切った刷新をどこもできなくなるよね。関係者のみなさんは気の毒としか言えない。

みずほ銀行駄目だこりゃ、
メインバンクソニー銀行にした方が良いな

相当やばそうだな…。

設計通りにできている筈がなく,その点検には意味がないだろう.現時点で脆弱な個所を探して潰していくのが現実的と思うんだけど,そうしないのは責任逃れのためかな？ 未だに犯人捜しなそういう体質の問題では.

設計通りにできている筈がなく,その点検には意味がないだろう.現時点で脆弱な個所を探して潰していくのが現実的と思うんだけど,そうしないのは責任逃れのためかな？ そういう体質の問題では.

うわぁ………

祝日が土曜日に重なった時に振替休日が発生しないのは、銀行が大反対したからだ。
…という噂を聞いたことがあるけど（真偽不明）、どんだけ時間や人を費やしてもシステム改修できないみずほの姿を見るに、本当なのかも。

青い銀行さん……
まず要求がきちんと明確に整理されているかを点検した方がいいパターンなのかなぁ。「止まらない」とかじゃなく、数字で示されていますか？とか……

続き。設計通りのシステムでも、その設計が間違っていたら、トラブルは今後も起きる。ただ、同銀行に設計を見直す余力があるかは別問題。"

「エラーで失敗」「復旧が成功しない」「再起動に失敗」

こういうの見ると、定期的にオペレーションが発生する状態の方が健全なのだろうなと思う。
これくらいの規模だとそれ自体がめちゃくちゃコスト高そうだけど、それを少しずつコスパ良くできるようにするためにも、継続的に運用改善できる必要はありそう。

銀行だけの問題かな？システムメーカ、NTT等も子会社経由して中共にソフト作成を依存してることが問題では？ドコモは迷惑メイルわんさか来る。アドレスをさらした覚え無いが片言の日本語だから海外だろう。

やるしかないんだろうけど。この手の点検では進めるうちに「これ設計正しいですか？」が出てきがち。では要件リバースは現実感あるのか。うーん、やるしかないんだろうけど。

おぅ，大事なとこだよなそこは(´・ω・`)

緊急時にバックアップが作動しない仕様というのもなかなか...

報告書の焦点は、一連の障害が起きた背景を、第三者委員会報告書と同様に運用に原因を求めるのか、システムに問題があったとするか、待機系への切換失敗の理由をどこまで言及できるのか、でしょうか。"

各ベンダー「検収終わった後なんで開発マターじゃないッスね。」

なんと、

$4 billion spent... on what?? Hmmm.. better check that now. Oh well, at least it has a cute name.