プロジェクトマネジメント、プロジェクト管理におけるポータルサイト

HOME > プロマネに役立つオススメ本 > デスマーチ 第2版 ソフトウェア開発プロジェクトはなぜ混乱するのか

2006年5月26日

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

紹介者:
ザ・プロジェクトマネジャーズ編集部
出版社:
日経BP社
著者:
エドワード・ヨードン
価格:
2,200円 (税別)

IT業界におけるシステム開発現場の過酷な労働環境を表す言葉として、IT用語辞典にも載っている言葉である『デスマーチ』。この言葉は、著者であるエドワード・ヨードン氏が1997年に出版した『デスマーチ』の初版がきっかけとなっており、本書はその第2版です。

進歩した技術、つまり最新の開発ツールや開発方法論を使うことは大切である。しかしその技術を使っても、デスマーチ・プロジェクトがなぜ解決できないのかを具体的な例を挙げながら、その要因を分かりやすく解説しています。

『デスマーチ』第2版のキーワードは「トリアージ(triage)」。グループ分けをすることを意味する古いフランス語の“trier”から来ている言葉。

著者は、デスマーチ・プロジェクトに携わる場合はシステムの要求事項を次の3つに分け、「やらねばならぬ」ことにプロジェクト資源を集中させ、時間があれば「やったほうがいい」ことを行い、奇蹟が起これば「やれればやる」要求項目に手をつけると書いています。

  • やらねばならぬ(must-do)
  • やったほうがいい(should-do)
  • やれればやる(could-do)

ここでのポイントは、「優先度-6」に入れるべきか「優先度-7」に入れるべきかといったくだらない口論をしないよう、要求項目を3つだけに分割することが重要だと同氏は書いています。

一番興味深かったのは、デスマーチ・プロジェクトでは、とかく構造化分析やISO-9000のような公式プロセスのパイロット・プロジェクトに指定されることがあり、そのことがプロジェクトの状況をさらに悪化させてしまうという記載です。つまりデスマーチ・プロジェクトでは、はじめからデスマーチの状態でプロジェクトがスタートする。よって(そもそも学んでいる時間的ゆとりも金銭的ゆとりも無い)スタッフが新しい(または初めての)方法論を同時に学んだら、それはプロジェクトを死に追いやる機会を増やすだけだということです。

プロジェクトの失敗を望んでいる人はおりません。しかし何度プロジェクトを実施しても必ず失敗してしまう教訓を十分再認識できる、そんな本です。

コメント[0件] | トラックバック[0件]

コメントを書く

名前もしくはニックネーム(投稿者名として表示されます)※必須

メールアドレス(ページには表示しません)※必須

URL

コメント(スタイル用のHTMLタグが使えます)

 

トラックバック

このページのトラックバックURL:
http://www.promane.jp/blog_manager/mt-tb.cgi/406

↑ このページの先頭へ