投稿元:
レビューを見る
C0055 分かりきった提言や過去話しは削って、タイトルのシステム障害を深堀りして欲しかったです。これだと新聞と大差ないです。冒頭だと、システム要員として運用担当も一括りにしているのに、最後の方はきっちりと運用担当として区別しているのは、執筆担当者の違いでしょうか。
投稿元:
レビューを見る
大規模システム障害の構造を把握するために購入。マスコミ等で話題となった事件の事実詳細を確認することができた。やはりシステム障害や開発遅延の理由には上位への情報伝達遅延があり、その背景には組織におけるシステムへの関心度合いがあるのであろう。
投稿元:
レビューを見る
書いてることは当たり前のことばかり。でも歴史は繰り返されていることを考えると、なかなか守ることの難しさを感じてしまう。
投稿元:
レビューを見る
多分、社内でも問題意識を持った人はいたはず。その意見が取り上げられない組織が問題なんだよな。どこの会社でも起きてる事。こればかりはボトムアップでの改善が難しい。。。どうしたものか。悩ましいな。
投稿元:
レビューを見る
みずほ銀行のCIOは、過去もそして今も、取締役ではないという指摘あり。三菱UFJ銀行は、次期頭取候補には必ずCIOを経験させている由。システム経験は、銀行経営の必修科目?、このあたりの指摘は、実に興味深い。
投稿元:
レビューを見る
2011年3月、震災後に起きたみずほ銀行のシステムトラブルをきっかけに書かれた「システム障害はなぜ起きたか」の続編。重複する部分もかなりあります。経営陣のシステムに対する意識の薄さに警鐘を鳴らす立場は変わってません。
投稿元:
レビューを見る
システム屋としては読みたいなと思っていた一冊。経営陳がシステム部門の重要性を分かっていなければならないと主張されており、我が社の経営陳陳のも読んでほしいと思う。
投稿元:
レビューを見る
2002年に続き2011年3月の震災後、2度目となったみずほ銀行システム障害事件のドキュメント。
みずほFGの経営幹部へ注目すると、原発事故の東電と重なる企業体質の様な気がする。問題意識を持った行員やベンダー等関係者はいたはずだが、その意見が取り上げられない組織が問題。
金融は当然のことながら装置産業の側面を持っている。
大手金融機関ともなれば、勘定系システムで処理されるトランザクションは、平均で毎秒500件なんて規模になる。その1トランザクションの処理に必要なステップ数は数万になったりするので、勘定系に求められる能力というのはとてつもなく高い。
ところが第三次オンライン(1988年頃)からメインの勘定系は変わっていなかったらしいというのは、怖いことだ。
現代の銀行システムは、その三オン時代に構築されたシステムが土台となっていて、現行システムはこの改良または発展した姿である。しかし、その発展の形というのは、それぞれの金融機関によって異なっているわけで標準化はされていない。しかもブラックボックスのまま。システム屋側から見たら「中身のわからんプログラム・システムは触れない」という別の恐怖となる訳だ。
『臭い物に蓋をする』この企業体質文化が、東電やみずほを生んだといっても過言ではない気がする。
投稿元:
レビューを見る
システム障害は、現場のシステム担当やシステム開発会社だけの責任では無く、経営トップの責任である。
なるほど、確かに現場がどんなに頑張ってもトップが決めなくては先に進まない事項は良くある事に思える。
これからの時代は、システムは現場に任せれば良いという時代では無いとつくづく感じた一冊でした。
投稿元:
レビューを見る
大規模システムの問題点を経営的視点から解説。
古いシステムを使い続けてしまっている問題があるが、メガバングの新システムへの入れ替えには2000億から3000億円かかる。経営陣トップは、積極的な入れ替えよりも、現システムの維持という先延ばしする選択を選んでしまう。
CIO、情報責任者を執行役員ではなく、将来のトップとすべく取締役に入れる必要がある。現場まかせで、トップがシステムの重要性を理解していないことが根本的な問題と捉える。
動かないコンピュータ撲滅の10箇条(メモ)
・経営トップが先頭に立ち、社員を巻き込む
・複数のシステム会社を比較し、強みを持つ会社を選ぶ
・システム会社を下請け扱いしない。むやみに値切らない
・自社の力を見極め、無理のない計画を立てる
・社内の責任体制を明確に決める
・上流工程に時間をかけ、要件確定後はむやみに変更しない
・進捗を把握し、テストに時間をかける
・あきらめない
・システム開発会社と保守契約を結ぶ
・うっかりミスを軽視せず、抜本的な対策をとる
投稿元:
レビューを見る
2011年3月のみずほのシステム障害の詳細をまとめた一冊。加えて、2002年のシステム障害も取り上げています。経営者など、システムに詳しくない人をターゲットというので、IT業界に片足をつっこんでいた私としてはまどろっこしい気もしましたが、途中からは逆にこれでは経営者は分からないでしょ…という記述が増えてやや中途半端。経営トップが情報システムに積極的に関わるべきという主張は分かるものの、最後の章はややくどい印象。
ともあれ、2011年のシステム障害で何があったのかを知りたかったので、それがまとまっていただけでとりあえずは目的達成。それにしても、あのときの現場は悪夢だっただろうなぁと。そして、そんな現場ので状況が、どこか別なところで起きていても全くおかしくないくらい心当たりがあるようなことばかりで怖くなったのでした。
投稿元:
レビューを見る
吉祥院図書館から。
日経コンピュータの連載からの抜粋。
「動かないコンピュータ」撲滅のための10ヶ条は参考になるかもしれない。
投稿元:
レビューを見る
想定読者は技術者ではなく経営層です。
期待してたものとは違いましたが、運用エンジニアの仕事が社会インフラに与えるインパクトを再確認出来たと言う意味では意味のあった読み物ではあったかな。
後半は日経コンピュータのコラム「動かないコンピュータ」を何本か載せて嵩まししてます;
投稿元:
レビューを見る
会社後輩に勧められ読む。結構裏話知ってると思っていたけど知らなかったこともあり。ふむふむと。組織論というか日経コンピュータ論というか。まあバッチはこえーと。
投稿元:
レビューを見る
過去2回のみずほの大規模システム障害を、経営側のIT軽視の姿勢、「わからない・苦手」だからとシステム担当者・業者に丸投げして理解しようとせず責任を放棄していることが、真の原因と述べている点は納得・共感した。こういったことが遠からずユーザー企業システム担当者の丸投げ、責任放棄、消極的な関与に繋がり、間接的にSI業界の多重階層・工程分業による閉塞感、エンジニアの成長阻害、失敗の連鎖などの弊害を招いていると感じている。
経営とITはもはや切っても切れない経営課題と捉えて、ITをどう活用して他社との差別化を図っていくかが、今後のユーザー企業の生命線となるはず。
そのことを追求していくことは、引いてはSI業界を変えることにも繋がると思う。
そういった意味で、ユーザー企業の経営層、システム部門の担当者、SI企業の経営層、マネージャ・リーダー層は一度目を通しておくべき。
ただ、最後の第4部の提言は、概ね同意できる内容だが、細部で現場の技術者からすると違和感がある内容も含まれていると感じた。(記者からの視点なので仕方が無いのかもしれないが)
例を挙げると…
・プロトタイピングやアジャイル開発を採用するとしても、どこかで要件は凍結すべき → 常にビジネス環境は変化する、それに素早く追随できるようにするのがアジャイルの本質なので、凍結するのではなく優先順位と取捨選択を頻繁に回す、ということが誤解して伝わる気がする。
・昔に比べてシステムの安定性は退化している → そうだとすると Google や Facebook など先端Web企業の安定性は説明がつかない。システムの複雑さ・進化の速度に、日本のSI業界の設計・運用する側の人間のスキルが追いついていないだけでは?ことSI業界に限っては、昔の技術者よりも現在の技術者のスキルのほうが退化している、というのは納得できる。(設計と実装の分離が進み、上流の人間の実装スキル・仕組みを理解した運用スキル、下流の人間の設計スキルが退化しているのが実態。)
・計画偏重、プロジェクトマネジメント偏重 → 大規模なシステムの構築に計画が欠かせないのは事実だが、計画に時間をかけ過ぎたり、承認の多重階層化により実効性が皆無になっている現場は山ほどある。大規模なプロジェクトにおいて完璧なウォーターフォールを行うのは不可能とまでは言わないが、相当な難易度だと思う。むしろ問題をより小さく分割していき、解決しやすくしながらそれを何度も見なおしていくことを積み重ねることが、現場の肌感として成功に近いと感じる。もちろんそれを成功させるためにユーザー側の深い関与とコミットが不可欠。