2016年10月16日

小話題: システム障害はなぜ二度起きたか みずほ、12年の教訓の TOSHI!!さんのレビュー

Amazon.co.jp: システム障害はなぜ二度起きたか みずほ、12年の教訓の TOSHI!!さんのレビュー
http://amzn.to/2dFPGsO

花粉症だろうか。

春に続き秋もだと本当に効率がわるい。
効率がわるければ休めばいいという正論も通じぬまじめな会社。

ところでタイトルの内容。

真の原因は、統合するシステムそのものの設計書・仕様書レベルで、負け組(=新システム開発に乗れな
かったカイシャ)が、意図的なイヤガラセで、「現状」の仕様や設計を開示しなかったことにあります。
システムというのは、使えば必ず手直し(所謂、バグだけでなく、法律改正に対応する修正もあります)が
多々発生します。都度、「その場しのぎのパッチ当て」から「キチンと予算を組んだ修正対応」まで。

設計書や仕様書は非常に大事です。

ソースコードを読まないと検討できないと非常に時間がかかります。

私も最近コードを読む必要があるが時間が不足で非常に辛い感じなのです。

設計もソースコードもよく理解した人でないとまず理解からはじまって正しく修正するのは非常に工数がかかる。そんなことを感じている非常に辛い日々です。

もちろんそういった理想的な状況ばかりでないというのは理解できます。よく知らないソースコードを修正するのは非常に時間がかかるという事実は忘れがちですがよく認識しておくべきです。

短時間で検討不足でも動くコードを作ることはできるでしょう。でもそのデータはどうやって使われますか?みたいなところを理解するのはきっと時間がかかるはずでひとまず動くコードを作るというのとはレベルが異なります。

ソフトウェア工学の言葉でいえば影響範囲分析とかソフトウェア理解、ソースコード理解という名前の課題でしょうがこれは見積もりの問題とあいまって以前重大な課題であることに変わりはないように思います。

愚痴も混じっててスマソ。

続きを読む
posted by ソフトウェア工学なんて忘れて at 20:53| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする