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

デスマーチ ソフトウエア開発プロジェクトはなぜ混乱するのか 第2版
無理な納期や予算を前提にした過酷なシステム開発プロジェクトに対し、プロジェクト・マネジャや開発メンバーはどう対処すべきなのか―。経営陣との交渉術からツールの選択方法まで具体的な防衛策を示す。

デスマーチ・プロジェクトとは、開発期間、開発者数、予算などのいずれかが、本来必要な水準の半分以下しか割り当てられていないプロジェクトを指す。本書は、この問題を取り上げて1998年に話題を集めた初版に、大幅に加筆、改訂を加えたものだ。

筆者は、昨今のオフショア開発やアウトソーシングの進行に伴って競争が激化し、その結果IT部門の限界をはるかに超えたデスマーチ・プロジェクトが生まれていると警告する。

米国の統計では、ごく平均的なプロジェクトでも計画と比べ6~12カ月遅延し、予算を50~100%超過しているという。これらの数字をそのまま日本の状況と比較することはできないが、デスマーチ・プロジェクトが常態化している点に変わりはない。現場でシステム開発に携わる人だけでなく、運用・保守要員やマネジメント層も、自らを守るために読むべき一冊と言える。

(日経コンピュータ 2006/06/12 Copyright©2001 日経BP企画..All rights reserved.)

1週間6日、1日14時間働いても終わらない。スケジュール、人員、予算は半分。どう分析しても50％以上失敗することがわかっている。明らかに無謀それが、「デスマーチ・プロジェクト」。巨匠エドワード・ヨードンが、1996年に発表し業界に衝撃を与えた名著『デスマーチ』の第2版。「失敗プロジェクト」の代名詞となり、現在も減ることのないデスマーチ・プロジェクトについて、発生のメカニズム、いかにすればそこから“生還”できるかを鋭く説いていきます。既存の章を全面的に見直し、エクストリーム・プログラミング、システム・ダイナミックス、クリティカルチェーンなどの話を織り交ぜながらプロジェクト・マネジメントについて独自の視点を展開します。

「失敗プロジェクト」の代名詞となった「デスマーチ」の改訂版。

デスマーチ・プロジェクトとは、多くの犠牲と損失、または高い確率で失敗が予測されるプロジェクトを言う。その実態と対処方法を、ソフトウエア開発に焦点を絞って述べる。

ヨードン,エドワード
ニューヨークを拠点にするコンピュータ関連コンサルティング会社NODRUOY Inc.のCEO。1970年代、構造化分析/設計方法論、1990年代初期コード/ヨードンオブジェクト指向方法論を提唱したことで知られる。ソフトウエア・ジャーナル『Cutter IT Journal』を主宰。ソフトウエアに最も大きな影響を与えた人物として、チャールズ・バベッジ、セイモア・クレイ、グレイス・ホッパー、ビル・ゲイツと並んで「コンピュータ殿堂」(米カリフォルニア州コンピュータ博物館)に入った

松原 友夫
1950年、早稲田大学専門部機械科を卒業。1956年、日立製作所に入社、1970年日立ソフトウェアエンジニアリングに転属。1991年末に同社を定年退職。その間、数多くの大規模プロジェクトを担当。分野は政府、銀行オンライン、プラント制御、科学計算、基本ソフトなど多岐にわたる。1992年からコンサルタントビジネスを始め、現在に至る。現在、Cutter IT Journalの編集委員会委員、IEEE Softwareの副編集長、編集委員、Soapboxコラムエディター、産業諮問委員会委員を歴任

山浦 恒央
1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授。大阪大学基礎工学研究科情報数理系後期博士課程単位取得退学。1984年から1986年、カリフォルニア大学バークレイ校客員研究員。2001年から2004年、IEEE Software産業諮問委員会委員。2001年から、法政大学情報科学部非常勤講師(オペレーティング・システム)。2006年から東京大学大学院情報理工学系研究科非常勤講師(ソフトウエア工学)。ソフトウエア工学に興味を持ち、ソフトウエア検証技法、ソフトウエア・メトリクス、設計パラダイム、要求仕様分析などを主な研究テーマとする(本データはこの書籍が刊行された当時に掲載されていたものです)