日経コンピュータのレビュー一覧
-
Posted by ブクログ
システム・ダウンの事例と原因が数多く紹介されている。
ありとあらゆる部分にダウンの危険が潜んでいて、読んでいるとだんだん落ち込んでくる。
今まで何の問題もなく動いていたとしても、1時間後も正常に動いているとは限らないというなんとも憂鬱な事実が繰り返し語られる。
二次災害とか…やってられるか！と言いたくなるレベルの話だ。
手をかければかけるほど良くなっていくわけではないと分かった時の失望を思い出した。
何か問題を指摘されても「いやぁ、そんなはずないんですけど…」と、弱気に返すしかないという事態。
「テストしなかったの？」というお決まりのセリフに怯える日々。
そしてこの本を読んで知る、さらに最悪な状況…。
もっと気を引き締めて仕事しないとなと改めて思った。
勉強になりました。 -
-
Posted by ブクログ
日経コンピュータの連載をまとめた本。
技術書ではなく、ＳＥとしての喜びや、情報化投資についての洞察、仕事への心構えがまとめられている。
何より、筆者はＳＥの仕事に誇りを持っているのが伝わってきた。
また、努力している自社のＳＥは我が子のように慈しんで育てている。
こういう社長の元で働きたいものだ。
【ココメモポイント】
・二十一世紀のＳＥには「問題解決型」のアプローチは適用しにくい。未知のビジネスモデルを作る作業が求められる
・情報化投資にはビジネスモデルの変革を推進する力がある
・商品やサービス、ビジネスプロセスの「ToBeモデル(あるべき姿)」を考える作業について、物事の構造を整理できるSEの参画は必須
・サービス設計図が描けて、その内容をオープンにできたとしたら、そのサービス会社の繁栄は間違いないだろう
・プロジェクトが実現しようとしている「効果」や「価値」についてもレビューする
・システム開発プロセスの成熟度を表すモデルに「ＣＭＭＩ」がある
・リスクばかりが前面に出ると、「チャレンジしない経営」になりかねない。それこそが最大のリスク
・人間の能力開発には、オンもオフもない。オフの時間帯に右脳を活性化すれば、それが会社の仕事に生きてくる -
Posted by ブクログ
過去2回のみずほの大規模システム障害を、経営側のIT軽視の姿勢、「わからない・苦手」だからとシステム担当者・業者に丸投げして理解しようとせず責任を放棄していることが、真の原因と述べている点は納得・共感した。こういったことが遠からずユーザー企業システム担当者の丸投げ、責任放棄、消極的な関与に繋がり、間接的にSI業界の多重階層・工程分業による閉塞感、エンジニアの成長阻害、失敗の連鎖などの弊害を招いていると感じている。
経営とITはもはや切っても切れない経営課題と捉えて、ITをどう活用して他社との差別化を図っていくかが、今後のユーザー企業の生命線となるはず。
そのことを追求していくことは、引いてはSI業界を変えることにも繋がると思う。
そういった意味で、ユーザー企業の経営層、システム部門の担当者、SI企業の経営層、マネージャ・リーダー層は一度目を通しておくべき。
ただ、最後の第4部の提言は、概ね同意できる内容だが、細部で現場の技術者からすると違和感がある内容も含まれていると感じた。（記者からの視点なので仕方が無いのかもしれないが）
例を挙げると…
・プロトタイピングやアジャイル開発を採用するとしても、どこかで要件は凍結すべき → 常にビジネス環境は変化する、それに素早く追随できるようにするのがアジャイルの本質なので、凍結するのではなく優先順位と取捨選択を頻繁に回す、ということが誤解して伝わる気がする。
・昔に比べてシステムの安定性は退化している → そうだとすると Google や Facebook など先端Web企業の安定性は説明がつかない。システムの複雑さ・進化の速度に、日本のSI業界の設計・運用する側の人間のスキルが追いついていないだけでは？ことSI業界に限っては、昔の技術者よりも現在の技術者のスキルのほうが退化している、というのは納得できる。（設計と実装の分離が進み、上流の人間の実装スキル・仕組みを理解した運用スキル、下流の人間の設計スキルが退化しているのが実態。）
・計画偏重、プロジェクトマネジメント偏重 → 大規模なシステムの構築に計画が欠かせないのは事実だが、計画に時間をかけ過ぎたり、承認の多重階層化により実効性が皆無になっている現場は山ほどある。大規模なプロジェクトにおいて完璧なウォーターフォールを行うのは不可能とまでは言わないが、相当な難易度だと思う。むしろ問題をより小さく分割していき、解決しやすくしながらそれを何度も見なおしていくことを積み重ねることが、現場の肌感として成功に近いと感じる。もちろんそれを成功させるためにユーザー側の深い関与とコミットが不可欠。 -
Posted by ブクログ
2011年3月のみずほのシステム障害の詳細をまとめた一冊。加えて、2002年のシステム障害も取り上げています。経営者など、システムに詳しくない人をターゲットというので、IT業界に片足をつっこんでいた私としてはまどろっこしい気もしましたが、途中からは逆にこれでは経営者は分からないでしょ…という記述が増えてやや中途半端。経営トップが情報システムに積極的に関わるべきという主張は分かるものの、最後の章はややくどい印象。
ともあれ、2011年のシステム障害で何があったのかを知りたかったので、それがまとまっていただけでとりあえずは目的達成。それにしても、あのときの現場は悪夢だっただろうなぁと。そして、そんな現場ので状況が、どこか別なところで起きていても全くおかしくないくらい心当たりがあるようなことばかりで怖くなったのでした。 -
-
-
-
-
-
-
-
Posted by ブクログ
p58：みずほ銀行の二度のシステム障害は、どちらも経営陣のIT軽視、IT理解不足に原因がある。
→会社にとってITをどう活用するのか、経営陣がどうITを活用するのかが不明確なのだろう。
p178：情報システムの開発や運用のカギを握るのは、技術ではなく、人だからである。
→結局、開発は人である。
p204：プロジェクトを始める前に「プロジェクトを定義」することである。・・・そもそも何の目的でプロジェクトを推進するのか、その目的を達成するために必要な人材や資金を用意できているのかどうか、そのプロジェクトのリスクは何か、といった点を事前に考え抜いて、プロジェクトの計画を作ることである。
→研修でもたびたび習っているが、すべては計画が大事。
計画段階で詰まっている案件は上手くいく。
うちの会社はここをしっかり検討すべき。
p220：集めた要望を整理し、矛盾を排除したものが、情報システムの要件となる。
→要望と要件は異なる。要望を見極めるのもSEの仕事の一つ。 -
Posted by ブクログ
システム障害の経緯が緊迫感があって興味深い。このトラブル対応を生き延びたエンジニアはどこでもやっていけるんじゃないか。
システムはそれを使ってビジネスする企業のものであり、システムの品質にも、トラブルにも責任を持つ必要がある。品質の高いシステムを作ることも、システムを安定的に運用することも難しい。システム屋任せで、速く、安く、確実に出来るシステムなんか存在しない。その事実に気付いているユーザーもまた少ない。だからこそ、その前提にたって、システム屋として品質を向上させる必要があるんだと思う。
以下、本のまとめ
2011年3月14日からのシステム障害詳細
銀行合併に伴うシステム障害詳細
他行等、みずほ銀行以外でのシステム障害について
動かないコンピューター撲滅のための十カ条について -
-
-
-
-
-