日経BP社 (2006/05/03)
売り上げランキング: 23434
この本は読む立場によって違う印象を受けるだろう。
PM レベルなら「うちは違う」、担当者なら「うちもそうだ」。
ソフトウェアというと、IT 系、SE などの言葉が連想できて、
顧客からの要件を整理して...
というイメージがまずある。顧客から理不尽な要求仕様を言い渡されて
徹夜・休出覚悟のプロジェクト、が多数存在しそうだし。
＃仕様という名のものが落ちてくるならまだましだろう。
ソフトウェアは IT に限らず組み込みもハードに近い部分も
同じ悩みを抱えるのだ。しかしよりユーザに近いレイヤ、もしくは
ソフトウェアによって機能の味付けをするブロックはより
死の行進が早くやってくるのではないだろうか。
著者がいうようにデスマーチプロジェクトはいたるところに存在するのだろう。
けれどもその事実を知って日本でとれる手段として、
会社を辞めるということはなかなか難しい。
ソフトウェア一本で生きていくならまだしもマネジメントの仕事を
少しでも目指した人なら心残りが多いだろう。
デスマーチプロジェクトはそのプロジェクト自体が破綻してしまっていることが
怖いのではないと思う。
そういったプロジェクトを渡り歩いてしまうことが怖いのだ。
つまりデススパイラルこそエンジニア、プログラマにとっては生活に支障をきたす。
個人的にデスマーチプロジェクトから抜け出す方法は
「品質を追い求める」
ことであると直感的に信じている。工数が増えるからダメだ、
品質をあげても効率はあがらない、という問題は同時に起こるが
バグを恐れるエンジニアからすると満足できるレベルはあがり
精神的に満たされる割合が増す。これが今のもしくは次のプロジェクトに
フィードバックされ徐々にではあるが改善されていくと思うからである。
よくこうゆう言葉が世の中に広がると
「おれはデスマーチプロジェクトに参加したんだ」
と自慢の如く言う人間がいるがこれは一番虚しいですな...
