システム障害はなぜ二度起きたか――みずほ、12年の教訓

(3.0点)
過去2回のみずほの大規模システム障害を、経営側のIT軽視の姿勢、「わからない・苦手」だからとシステム担当者・業者に丸投げして理解しようとせず責任を放棄していることが、真の原因と述べている点は納得・共感した。こういったことが遠からずユーザー企業システム担当者の丸投げ、責任放棄、消極的な関与に繋がり、間接的にSI業界の多重階層・工程分業による閉塞感、エンジニアの成長阻害、失敗の連鎖などの弊害を招いていると感じている。

経営とITはもはや切っても切れない経営課題と捉えて、ITをどう活用して他社との差別化を図っていくかが、今後のユーザー企業の生命線となるはず。
そのことを追求していくことは、引いてはSI業界を変えることにも繋がると思う。

そういった意味で、ユーザー企業の経営層、システム部門の担当者、SI企業の経営層、マネージャ・リーダー層は一度目を通しておくべき。

ただ、最後の第4部の提言は、概ね同意できる内容だが、細部で現場の技術者からすると違和感がある内容も含まれていると感じた。(記者からの視点なので仕方が無いのかもしれないが)
例を挙げると…
 ・プロトタイピングやアジャイル開発を採用するとしても、どこかで要件は凍結すべき → 常にビジネス環境は変化する、それに素早く追随できるようにするのがアジャイルの本質なので、凍結するのではなく優先順位と取捨選択を頻繁に回す、ということが誤解して伝わる気がする。
 ・昔に比べてシステムの安定性は退化している → そうだとすると Google や Facebook など先端Web企業の安定性は説明がつかない。システムの複雑さ・進化の速度に、日本のSI業界の設計・運用する側の人間のスキルが追いついていないだけでは?ことSI業界に限っては、昔の技術者よりも現在の技術者のスキルのほうが退化している、というのは納得できる。(設計と実装の分離が進み、上流の人間の実装スキル・仕組みを理解した運用スキル、下流の人間の設計スキルが退化しているのが実態。)
 ・計画偏重、プロジェクトマネジメント偏重 → 大規模なシステムの構築に計画が欠かせないのは事実だが、計画に時間をかけ過ぎたり、承認の多重階層化により実効性が皆無になっている現場は山ほどある。大規模なプロジェクトにおいて完璧なウォーターフォールを行うのは不可能とまでは言わないが、相当な難易度だと思う。むしろ問題をより小さく分割していき、解決しやすくしながらそれを何度も見なおしていくことを積み重ねることが、現場の肌感として成功に近いと感じる。もちろんそれを成功させるためにユーザー側の深い関与とコミットが不可欠。

参考になった人:2人   参考になった
(4.0点)

参考になった人:0人   参考になった
(3.0点)
2011/10/2
主にみずほ銀行のシステム障害について、技術云々ではなく、経営の観点から批評されている。企業経営者のリーダーシップが重要だとあらためて感じさせられる。東京電力も同様、トップがダメだとトラブル対応がまったくできない。現場任せではなく、トップが責任を持って決断をしなければ下の人たちもかわいそうだね。

参考になった人:0人   参考になった
(5.0点)
運用関係者だけではなく、利用ユーザを含めたITに関わる人全てに読んでいただきたい一冊です。

参考になった人:0人   参考になった
(5.0点)

参考になった人:0人   参考になった
ウィッシュリストへ追加
非公開
タグ

メモ


ライブラリへ追加
非公開
評価
 
読書ステータス
つぶやく
タグ

メモ


タグを入れることで、書籍管理ページで、タグ毎に書籍を表示することが出来るようになります。
また、スペース区切りで入力することで1つの書籍に複数のタグをつけることもできます。

※注意: このタグはあなたの管理用だけでなく、書籍自体のタグとしても登録されます。あなた以外の人に見られても問題ないタグをつけてください。
ウィッシュリストからライブラリへ移動
評価
 
読書ステータス
つぶやく