「デスマーチ」を読んだ

---

この本を読んだ理由

デスマーチの最中なので、どうすればよいのか知りたかった。

---

デスマーチとは

初めから失敗することがわかっているプロジェクト

公正かつ客観的にプロジェクトのリスク分析をした場合、失敗する確率が50%を超えるプロジェクト

---

なぜデスマーチは発生するのか

• 社内の政治

• 無謀なスケジュール（通常12ヶ月掛かると見込まれるものが、6ヶ月に短縮される）

• 予算（人員不足、人数は足りていても経験の無い人ばかり）

• 過度の要求（提供する機能が多すぎる、要求される性能が高い）

• その他いろいろ

---

デスマーチを乗り切るにはどうすればよいのか

• トリアージ（要求の優先順位付け）

• クリティカルチェーンと制約条件（よくわからず使いこなせないのにデスマーチプロジェクトでやろうとすると失敗の要因になる）

• スカンクワーク（会社の偉い人たちや部外者に邪魔されないように会社から隔離された場所で作業を行う）

• そこそこ使えるソフトウェア（完璧ではないがそこそこ安く、速く、機能が充実していて、安定して使えるソフトウェア）

• 80:20の法則（ソフトウェア全体の内、使われる機能は20%であり、残りの80%はなくても困らない）

---

デスマーチプロジェクト（に限らず）の主な問題は、技術的な要因であることは少なく、人に起因するものであることが多い（ピープルウェア問題）。

ITプロジェクトを円滑に進めるためには、ピープルウェア指向アプローチで取り組む必要がある（プロジェクトの問題を解決してくれる銀の弾丸はない）。

交渉術の例が面白かった。

例)　プロジェクトが9月1日ではなく、9月5日に完成するとしたら、9月2日に倒産を宣言するのですか？

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか