デス・マーチ
なぜソフトウェア・プロジェクトは混乱するのか
書誌
| text | 唯野 |
| author | エドワード・ヨードン |
| editor | 松原知夫、山浦常央(訳) |
| publisher | シーブック24ドットコム |
| year | 2001 |
| price | 2,200 |
| isbn | 901280-37-6 |
履歴
| 2001.spring | 読了 |
| 2001.7.17 | 公開 |
| 2002.8.2 | 修正 |
感想
元はトッパンの本だが、周知のように復刻本。ソフトウェア工学の基本書のひとつなので、この復刻は歓迎すべきことである。もともとトッパンはオブジェクト指向の基本書などではよい本をたくさん出しており、そういう出版社がなくなるというのは「本当に IT 化が進んでいるのか ?」という疑問にもつながるのだが、これはこれで良書は生き残るということのひとつの証だろう。以前から読みたいとは思っていた本なので、これを機に同じく古典である 『人月の神話』 とを合わせて読んでみた。
そして、読了した上でいえることは、直接的にマネージャなどをやっていない人であっても、読んでみるだけの価値があるという点である。何より自分のやっている仕事というものを、一回り大きな視点から眺められるだけでも意義がある。ちなみに、デスマーチとは巻末でも触れられているように元々は第二次大戦中の「バターン死の行進」に由来する言葉である。同じ場所で指摘されていることだが、デスマーチに効果的なものとして見たオープン性は確かにその通りだなと思った。「オープンソース」から見た「デスマーチ」としての定義・比較をしてみるのも、おもしろいのではないかと思う。
# 後は 『ピープルウェア』 辺りが必読だろう
抄録
x/xi
今日のソフトウェア産業においてデスマーチ・プロジェクトは常態であって例外ではない。それゆえ問題はデスマーチ・プロジェクトといかに付き合うかという点になる。
2-6
デスマーチ・プロジェクトとは「プロジェクトのパラメータが正常値の 50% 以上超過しているもの」を指す。具体的には以下の場合。或いはリスク分析の結果、失敗の確率が 50% を超えるもの。
- プロジェクトのスケジュールが常識的見積りの半分以下
- エンジニアの必要人数が通常の半分以下
- 予算やその他の必要経費が半分以下
- 開発するものの機能、性能、技術的要求が通常の倍以上
これをプロジェクトの大きさから見ると次のようになる。最も多く最も成功もしやすいのは小規模のプロジェクトで、これが中規模プロジェクトだと成功率がかなり低くなり、大規模プロジェクトだとほとんどゼロになる。また、ユーザ数の多寡も判断材料になる。(ユーザ数の増大は複雑度の増大となるから。)デスマーチ・プロジェクトの多くは最初の時点で失敗しており、実現不可能なプロジェクトは理解不足のシステムと複雑度の高いシステムに大別される。
- 小規模 : 10 人以下のプログラマが 3-6 か月で行わねばならないプロジェクト
- 中規模 : 20-30 人のプログラマが 1-2 年で行わねばならないプロジェクト
- 大規模 : 100-200 人のプログラマが 3-5 年規模で作業するプロジェクト
- 超巨大 : 1,000-2,000 人という 7-10 年の長期プロジェクト (コンサルタントや下請けを含む)
7-17
デスマーチ・プロジェクトの発生要因として以下がある。
- 政治的な絡み 受注だけを優先して内容が厳しい、後回しにしているなど
- 企画部門・経営陣・PM の楽観的な将来展望 大抵は経験不足による
- 若者の幼稚な楽観主義 細かいことをシステムに含めない土日頼み
- ベンチャー立ち上げ時の楽観主義 ベンチャーそのものが楽観的な存在
- 海兵隊方式 市場での競争を煽った過酷な労働の正当化
- 市場の国際化による競争激化 上層部による斬新な製品の計画
- 新技術の登場による競争激化 最先端技術をビジネスの中枢に適用する場合
- 予期せぬ公的規制 規制緩和、民営化、公的機関への厳しい納入日程
- 予測不能の事件・事故 キー・エンジニアの退職、ベンダーの倒産など
# PM : プロダクト・マネージャ
# 「細かいこと」の具体例としてドキュメント、エラー処理、テストなど
18/20/44
デスマーチ・プロジェクトを辞めるタイミングとしては、スタート時が一番よい。参加を求められた時点で断るのが、最も間違いがない。あるプロジェクトが「デスマーチ・プロジェクトです」と書いてあることは稀なので、その会社がデスマーチ・プロジェクトを作りやすい体質なのかどうかを含めた判断が必要になる。デスマーチ・プロジェクトで必ず求められるのは「やるべきことを正しくできるだけの権限を持った優秀なプロジェクト・マネージャを見つけること」である。
21-35
一方、進んでデスマーチ・プロジェクトに参加する場合として以下の要因がある。デスマーチ・プロジェクトによる影響は若いエンジニアの場合には問題とならないことが多いため、それゆえ若いエンジニアによる参加パターンが多い。別の側面としてデスマーチ・プロジェクトは教育的効果が大きいという部分もあるため。cf.38/40
- リスクも大きいが見返りも大きい サクセス・ストーリーへの期待
- エベレスト登頂症候群 困難さが自分の存在意義や職業意識に直結する場合
- 若さゆえの純真さと楽観性 20 代プログラマによる自信
- ここ以外に仕事がない しかし大抵はより悪い状況しか生まない
- 将来の出世に有利 昇給・昇格を脅しネタに使う
- これ以外は倒産か類似の悲劇 仮に成功できても、またデスマーチが続く
- 官僚主義からの脱出 官僚的手続きにこだわらなくて済む開放感
- 復讐 会社への復讐そのものが動機となる場合
但し、エベレスト登頂症候群には実はさほど意義のないもの(そう見せかけた場合を含む)であったり、初めから失敗の分かりきっている場合がある。また官僚主義からの脱出は、デスマーチ・プロジェクトが大抵の場合、特権的で通常の手続きを踏まなくてよいという性質に依っている。
全文を読まれる場合はログインしてください
Up