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

概要

時間、人員、予算などのリソースが、本来必要な水準の半分以下しか割り当てられていないプロジェクトを「デスマーチ・プロジェクト」と呼ぶ。本書では、そのようなデスマーチがなぜ起こるのか、どうすればそうした状況を乗り切ることが出来るのかを解説する。経営陣との交渉、プロジェクト内政治の対処法、効率的な開発手法、クリティカルチェーンによる計画の立案など、具体的かつ実践的なノウハウを紹介する。ベストセラーの第2版。ITプロジェクトのプロジェクトマネージャ、管理者、品質責任者に薦める。

本書の使い方

ITプロジェクトのプロジェクトマネージャ、品質保証責任者向け。
第1章～第4章は、デスマーチの構造と概要、基本的な対処法を知る上で、是非通読を薦める。
第5章～第10章は、前半を踏まえた上での、応用的なノウハウを示す。読者の興味に応じて読むことが出来るが、できれば一度通読の上、再度、興味を持った章を読み直すと、多くのヒントが得られるだろう。

何を学べるか

第1章 はじめに
「デスマーチプロジェクト」とは、著者によれば、開発期間、開発者数、予算などのいずれかが、本来必要な水準の半分以下しか割り当てられていないプロジェクトを指す。なぜ、デスマーチプロジェクトが発生するのか、その原因を解説する。また、なぜ人々はそのようなプロジェクトに参加するのか、に関しても考察する。

第2章 政治
本章では、プロジェクトには政治が存在すること、プロジェクト内の政治は時としてプロジェクトを中断においこむこと、そしてこうした政治への対処法を説明する。プロジェクト内政治の登場人物、プロジェクトの性質の4分類、メンバーの貢献度、などを解説したうえで、プロジェクトが政治的不和に至るポイントを説明する。

第3章 交渉
プロジェクトマネージャは、上層部との交渉においては必ず負ける、と著者は述べる。本章では、新任のプロジェクトマネージャが、デスマーチプロジェクトの最初で、どうすれば許容範囲内の条件で交渉を勝ち取れるか、を解説する。トレードオフを引き出すための質問、起こりうる交渉ゲームの様々なパターンの紹介、不利な政治ゲームに巻き込まれないための戦略、交渉に失敗した場合の身の処し方、などを具体的に説明する。

第4章 デスマーチ・プロジェクトの人々
プロジェクトが成功するか、デスマーチに陥るかは、人に関わる部分の比重が大きい。本章ではプロジェクトマネージャの立場からチームメンバーに着目し、人選の方法、メンバーにどう報いるか、コミュニケーションの取り方、チームメンバーを一体にさせる方法、作業環境の改善の方法、などを解説する。

第5章 デスマーチ・プロセス
デスマーチプロジェクトにおいて、最も重要な考え方は「トリアージ（優先順位）」である、と著者は説く。開発プロセスには様々なアプローチがあるが、現実のプロジェクトにおいては「役に立たない」ことも少なくない。CMM、ISO9000シリーズといった公式的なプロセスのメリットとデメリットを示し、大切なのは、「要求を優先順で管理すること」であると著者は説く。「そこそこ使えるソフトウェアを目指す」など、きれいごとではない、現実のプロジェクトを乗り切るための考え方を解説する。

第6章 プロセスのダイナミックス
ソフトウェア開発プロセスを、どのように把握し、分析するか。「生き物」ともいえるプロセスをとらえるための認識の枠組みである、「システム・ダイナミクス」の考え方について解説する。本章ではシステムを記述・認識するための様々なシステム・ダイナミクスのモデルを紹介する。

第7章 クリティカルチェーンと制約条件の理論
機能不全を起こしている組織は、人的、時間的資源を効率的に使えていないことが多い。本章では、プロジェクト・マネジメントにおける有効な戦略として、制約理論（ＴＯＣ）を紹介する。スケジュールからクリティカルチェーンを見出し、適切なバッファを持った計画を立案する方法などを解説する。

第8章 時間の管理
時間の効率的な使い方について考察する。企業組織では、形式的な会議や、非効率的な慣習によって、時間を無駄にしている場合が多く、その対策について考える。また、時間を重要性と緊急性の2次元の座標軸で4つに分類する方法を紹介し、一見生産性が低く見えて後回しにしがちな、「じっくりと時間をかけて計画を立てる」ことが、生産性を上げる上で重要であることを説く。

第9章 進捗の管理と制御
プロジェクトにおいて正確に進捗を管理し、制御するための方法を解説する。「毎日の構築」は、文字通り、毎日その日に作成したコード全体をビルドしてテストを実施する開発手法である。それにより、管理者は毎日、現在の状況をリアルに把握することが出来る。また、リスク・マネジメントの方法を紹介し、リスクに対する事前対処のノウハウを説明する。また形式的なレビューなどを減らし、実質的な生産時間を増やすために、定期的な「ポストモーテム（事後分析）」が有効であることを説明する。

第10章 デスマーチのためのツールと技術
デスマーチプロジェクトを乗り切るためにはどのようなツールが必要なのか。この問いに対して著者は、様々なツールを挙げた上で、重要なことは、ツールをどのような「プロセス」で使うのか、であることを説く。とりわけデスマーチにおいては、「銀の弾丸」を求めてやみくもに新しいツールに飛びつくことに対して警鐘を鳴らす。

第11章 シミュレーションと「戦争ゲーム」
デスマーチプロジェクトを避けるために、シミュレーションの重要性を紹介する。とりわけ、戦争シミュレーションの有効性を例に引きながら、ＩＴ分野のプロジェクトマネジメントにおいても、同様にシミュレーションが大切であることを解説する。