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

エドワードヨードン / 松原友夫 / 山浦恒央

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

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 全般
• 出版社: 日経BP
• ページ数: 320ページ
• 電子版発売日: 2012年05月25日
• コンテンツ形式: XMDF
• サイズ(目安): 2MB

[ブクログ · ★★★★★]

現在、デスマーチ案件に関わっているので、なにかしらのヒントを求めて買ってみた。

この本を読んでわかったことは、デスマーチはたまたま発生するのではなく、ほぼ恒常的に発生するということ。そ
今までは、管理者の管理能力不足だけがデスマーチ発生の原因と思っていたけど、プロジェクトの内部や外部を問わず、政治的な要因が大きく関わっているのがわかった。

本書では、デスマーチ発生に至るまでの過程を分析し原因を解き明かしている。そして、デスマーチに対して、どう接していけばいいかを説明している。

デスマーチ解決法という内容ではないが、共感できる部分が多い。
この本で、おおよその原因を知っておけば、デスマーチを未然に回避したり、失敗を軽減したりすることが可能かもしれない。

邦訳がよく、読みやすい内容だと思うので、IT業界にかかわる人は新人ベテラン問わず、ぜひ読んでほしいと思う。

[ブクログ · ★★★★☆]

　デスマーチプロジェクトをどう回すか、ということについて色々書かれている。デスマーチプロジェクトが増え続ける昨今、プロジェクト・マネージャを務める人にはぜひ読んでいただきたい1冊。

[ブクログ · ★★★★☆]

ソフトウェア開発の現場がどうしてこんなに混乱するのか、がよく分かる気がする本です。身につまされます。

[ブクログ · ★★★☆☆]

PMP資格更新に向けて読みました。
個人メモ用にですが、ざっくり要約すると下記の感じかと思いました。
・デスマーチプロジェクトは多種多様あるが、結局無理な納期やスケジュールのプロジェクト
・デスマーチプロジェクトに対する最も効果的な対処はトリアージする事
・もちろん状況によるが、新しいツールや手法を導入するより使い慣れたツールや手法をうまく活用する方が効果的
・デスマーチプロジェクトはどれだけ時代が進んでも無くならない

少しクセがある文章のため、所々流し読みした箇所もあります。読書の時間がとれず細切れに読んでいたため理解しきれていないと感じる箇所もままありました。できるのであればしっかりと時間を確保した上でまとめて読む方が向いている本かなと思います。

また時間がしっかり取れるタイミングでじっくりと理解しながら読みたいと思いました。

[ブクログ · ★★★☆☆]

トリアージしよう。もっとも大切な要求、課題から手を付ける

【感想】
　「デスマーチ」をキーワードにして、プロジェクトマネジメントのよもやま話をしていく本。主張は基本的なプロジェクトマネジメント原則と大差が無いかも。ソフトウェア開発プロジェクトの難しさを理解するために読むとよさそう。書き方はエッセイ的で、メッセージが掴みづらい。既にPMの知見が無いと、難しい。単純にシステム開発プロジェクトについて理解するなら、「システムを作らせる技術」の方が分かりやすい。各章ごとの「まとめ」を読んでから、本文を読んだ方が理解しやすい。勉強のために読むなら、読んだうえで自分で抽象化を試みた方が良さそう。

【本書を読みながら考えたこと、気になったこと】
　問いを立てて読んだ方が良さそうな本。

■なぜ、デスマーチが起こってしまうのか
・正確に作業量を見積もることが難しい。見積もりより作業量が増えても、納期は後ろに伸びない
・時間的、資金的、人的な余裕がない。ソフトウェア開発プロジェクトはビジネスであり、より安く、早いサービスが求められる。市場競争の結果、コンペを勝ち取る際には、他社より少ない予算（人員）、より早いスケジュールでの計画実現を提示できたベンダーが、ソフトウェア開発プロジェクトを受託できる。結果的に、いつもギリギリの状態でプロジェクトはスタートする
・失敗が隠される。過去にソフトウェア開発プロジェクトでの失敗があっても、企業は体裁を守るために、できる限りその事実を隠そうとする


■デスマーチに巻き込まれたら、どうすればよいか
・トリアージする。優先順位をつけて、対応する。全ての問題に対応しなければ、何もかもうまくいかない、ということはない


●１章　はじめに
・デスマーチプロジェクトとは、プロジェクトのパラメータが50％以上超過している物
　・通常であれ二人月かかるところを一人月でやろうとしている等
・デスマーチは、教育効果が大きい
・プロジェクトの作業量、難易度を正確に見積もるのが難しい。予想より多くの課題、作業が発生し、デスマーチとなる

●２章　政治
・ソフトウェア開発プロジェクトは、様々な立場の人の思惑に左右される
　・顧客、プロジェクトマネージャー、出資者、顧客上層部等

●３章　交渉
・納期、人的リソースについて交渉しよう
・時には、PMとして、会社上層部に反旗し、プロジェクトメンバーを守ろう
・「見積もりが難しいのは、見積もりを現状と将来をベースにした最善の予測を」と解釈するため。これが、上層部においては、『厳守すべき値』に変わってしまう」
　→見積もりは常に最悪を想定して行いたいな

●４章　デスマーチプロジェクトの人々
・残業時間が多すぎると、途中から生産性は低下し始める
・プロジェクトの成功には、優秀な人、チームとして機能すること、働きやすい職場環境が必要だ

●５章　デスマーチ・プロセス
・この本で一番大事な言葉「トリアージ」
　・「80/20の法則」に従う。いくつかの項目は、永遠に実装されない。それを目指す。全てに手をつけていては、デスマーチプロジェクトは終えられない
・システムの要求項目は「must」「should 」「could」に分けよう。そそて、mustから手をつけよう
・要求管理をしよう
・そこそこ使えるソフトウェアができれば、それでいい

●６章　プロセスのダイナミックス
・もっとも生産性の高い人から辞めていく。好条件の求人など、いくらでも来る
・プロジェクト上で大切にする人や仕事の取り扱い方の考え方を、チームに共有しよう

●７章　クリティカルチェーンと制約条件の理論
・プロジェクトのボトルネック、クリティカルパスは確認して仕事を進めよう

●８章　時間の管理
・無駄なミーティングはするな
・利害関係者の意見が対立する　→　承認が遅れることによって、スケジュールが遅れることを文書化して提示せよ
・緊急で重要度の高い仕事、緊急でないが重要な仕事をしよう。緊急だが重要でない仕事（電話応対）などに対応する機会を減らそう

●９章　進捗の管理と制御
・リスク、問題を整理し、管理し、評価し、対応方法を決めよう
　・問題が多いデスマーチプロジェクトではなおさらだ。
・社内のプロジェクト後に、評価をしよう。同じ過ちは繰り返さないようにしよう

●１０章　デスマーチのためのツールと技術
・便利なツールは利用しよう。作業を標準化し、効率化しよう

●１１章　シュミレーションと「戦争ゲーム」
？メッセージが理解できなかった

[ブクログ · ★★★☆☆]

デスマーチプロジェクトとは「プロジェクトのパラメータ」が正常値を50%以上超過したもの。工期が半分、要員が半分、予算が半分、機能・性能が倍。高い確率で失敗が予測される過酷なプロジェクト。後半は面白くなってきてあるあるを感じる。トリアージという概念。注釈のある本は苦手、交互に読もうとしてリズムがつかめなくなる。

[ブクログ · ★★★☆☆]

発注先の本気度、システムへの理解がある、ないかによって左右される部分が多い気もする。官公庁のような体制や曖昧な人が多くなるとデスマーチはやってくる。

[ブクログ · ★★★☆☆]

デスマーチとは、プロジェクト特にソフトウェア開発プロジェクトが陥る悲惨な状況のこと。デスマーチは避けられないということか。

[ブクログ · ★★★☆☆]

これを読んだからといってデスマーチが解決することはないけど、注意深く意識することは出来ると思う。翻訳の仕方によってもっと読みやすくなりそう。

[ブクログ · ★★★☆☆]

火を噴いたプロジェクトに入った時に，「これって俺たちのことじゃないか？」と先輩に教えてもらった本．お酒飲みながら，ゲラゲラ笑って読んだのも，今では良い思い出です．