みずほ銀行は今週、3月に発生した大規模システム障害に対する事後対応で、一つの区切りを迎えた。 5月20日、弁護士ら第三者で構成するシステム障害特別調査委員会の調査報告書が公開された。調査報告書には、障害の発生原因やその後に起こした複数の対応ミスにより障害が長期化した経緯の全貌が記されていた。 これを受け5月23日には、みずほフィナンシャルグループが再発防止策を発表。さらに、みずほ銀行の頭取とIT・システムグループ担当常務執行役員が責任を取り6月20日付で退任することを明らかにした。 経営トップの引責辞任によってみずほ銀行は「けじめ」を付けたが、システム障害の事後対応はこれで終わりではない。みずほフィナンシャルグループは再発防止策の一つとして、みずほ銀行、みずほコーポレート銀行、みずほ信託銀行の基幹システムを統合する考えだ。 2002年4月にみずほ銀行が誕生して以来、2度の大規模システム障害
「なぜ」を何度も繰り返し、問題の再発防止策を導き出す「なぜなぜ分析」は、簡単なように見えて、実は非常に奥が深い。実際にやってみると、案外難しいことが分かる。 トヨタ自動車で語り継がれてきた「なぜなぜ5回」という言葉が今では世間に広く知られたこともあってか、なぜなぜ分析とは「なぜ」を5回繰り返す分析手法であり、5回繰り返すと問題の解決策にたどり着けると考えている人は少なからずいるように思われる。 だが日経情報ストラテジーの誌面で「なぜなぜ分析のここが落とし穴＜実践編＞」を連載しているマネジメント・ダイナミクス社長の小倉仁志氏は、「なぜの回数は扱う事象ごとに変わってくるので、回数そのものに意味は無い。私は様々な業界でなぜなぜ分析を実施してきたが、業種によってもなぜの回数は随分違ってくることを体験的に理解している」と話す。 そこで分析に入る前にまず、「なぜは5回繰り返すものだ」という強い先入観を
システム開発の現場には、システム開発標準やプロジェクトマネジメント標準など、様々な標準があるだろう。プロジェクトでは、それらの標準に沿った運営が求められる。しかし、実際のところ、それらの標準は本当に「現場のため」になっているのか。疑問に思うことが多々ある。 後藤 年成 マネジメントソリューションズ 取締役 PMP システム開発において、「標準化」と聞いて皆さんはどのようなイメージを思い浮かべるだろうか。「システム開発をを効率よく進めるために大変有効なもの」と答える人もいれば、「実利のない、面倒くさい手続きばかりで生産性を下げるもの」「品質を確保するために必要なのは理解できるが、ここまでやるべきか、ふに落ちない」など様々な意見があると思います。一般に、システム開発における標準化のメリット／デメリットを挙げると、以下のような点が挙げられます。 【システム開発における標準化のメリット】 （1）関
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
