ホーム > 読んだ >

デス・マーチ
なぜソフトウェア・プロジェクトは混乱するのか

書誌

authorエドワード・ヨードン
editor松原知夫、山浦常央(訳)
publisherシーブック24ドットコム
year2001
price2,200
isbn901280-37-6

目次

1感想
2抄録

履歴

editor唯野
2001.spring読了
2001.7.17公開
2002.8.2修正
2013.5.26修正

元はトッパンの本だが、周知のように復刻本。ソフトウェア工学の基本書のひとつなので、この復刻は歓迎すべきことである。もともとトッパンはオブジェクト指向の基本書などではよい本をたくさん出しており、そういう出版社がなくなるというのは「本当に 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 の楽観的な将来展望 大抵は経験不足による
  • 全文を読まれる場合はログインしてください


    Up