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

著者 : エドワード・ヨードン 松原友夫 山浦恒央

• 日経BP (2006年5月3日発売)

作品紹介・あらすじ

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

感想・レビュー・書評

[きくらげさんの感想 · 2023年9月6日]

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

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

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

[dattsuさんの感想 · 2022年4月9日]

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

[kfznhmstさんの感想 · 2020年3月9日]

上司に読ませたい

[koyama1026さんの感想 · 2019年5月31日]

トナメール　10.4.28

E.ヨードンもその著書デスマーチで「デスマーチ回避に、要求工学
やPMBOKやテクノロジーや諸々の手法やツールは一部は役に立って
いるが限定的であり、最終的には政治力や交渉力やコミュニケーション
力が鍵となる」と言っています。

[hiroshirakawaさんの感想 · 2019年4月19日]

6年ぶりに前線に復帰したので、初心に戻ってITプロジェクトマネジメントの再学習。デスマーチとはプロジェクトが火を噴いている状態であり、技術やマネジメントの方法論ではデスマーチプロジェクトは解決できないことが多いのです。最新の開発ツール・方法論のようなハードなエンジニアリングアプローチではなく、優れた人材や効率の良いチームのようなソフトな要素が大事なのです。アメリカのITプロジェクトをベースにしている＆初版が古いのですが、参考になる要素は多いのです。
続きはこちら↓
https://flying-bookjunkie.blogspot.com/2019/04/blog-post_19.html
Amazon↓
https://amzn.to/2VhlNYU

[eraさんの感想 · 2016年4月30日]

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

[しんきちさんの感想 · 2015年9月25日]

-

[ayoshiさんの感想 · 2014年11月4日]

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

[momocusさんの感想 · 2014年7月15日]

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

[まき子さんの感想 · 2013年3月6日]

「デスマーチは常態」。うん。
お客さんから、いやむしろ経営者から、大げさに言うと半分の予算で！半分の人数で！半分の納期で！に「期待している」という言葉を添えて任される。
新しい技術、手法を取り入れてみる。誰もやったことない。つまりみんな新人と同じ。遅延する理由がたくさん。
だから圧倒的に時間が足りない。
勉強になったのは、Mustdo、shoulddo、coulddo＋20:80の法則からの気づき。あるシステムを構築するときに本当に必要で核となる機能は全体の20%。だから、アジャイルとかで徐々にお客にリリースしていけば、うまくいけば残りの80％を省略できるかもしれない。ま、ウォーターフォールでは無理ですな。
こういう手法で納期を守りつつ、お客さんの顔色（懐）を見ながら徐々に機能を縮小するのが、生き残るために必要なのかなって思いますた。