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

書いていることは事実をある視点で記述しているのだと思います。
解決策は、それぞれの現場で違うので、自分達で考えるしかありません。

現場の感触としては、能力のある人間にやる気を与えて仕事をした結果を、
どうお金に変えるかの手腕が経営者や営業にあるかだと思っています。

そういう手腕のある人でも、手腕があるが故に、仕事量が１０倍、１００倍になったときに、対応方法を誤ることがあるように思います。

万能の解決策はないということではないでしょうか。

少なくとも、
１　有能な技術者を組織する（やる気にさせる）
２　お金を支払う顧客を捜してくる
の２つができれば、大丈夫なのではないでしょうか。

割とありがちな問題と、割とありがちな解決策が体系的に書かれているので、時間があるときにのんびりと読むとよい。くれぐれも、デスマーチプロジェクトの時には読まない方がよいと思った。こまっているときには、原因を解決する方法か、対策が大事で、ありがちな解決策では解決しない。それは、公式プロセスの導入という、デスマーチプロジェクトに適用してはいけないと本書で書いていることと同じではないだろうか？

著者ははじめににおいて，「デスマーチプロジェクト（常態よりも５０％以上逸脱している
プロジェクト，死ぬほど大変なプロジェクト）は、常態であって、例外ではない」と述べている．
このような大変なITプロジェクトが避けられないならば，そこから生還するにはどうすれば
良いのかを書いている本．

中身は，アメリカのコンサルタントが書いてある本にありがちな，最初の章で定義を行い
その後の章が色々書いてあるという形態そのもののように思える．ちなみに２章以降は
政治，交渉，デスマーチ・プロジェクトの人々，デスマーチ・プロセス，プロセスのダイナミックス
クリティカルチェーンと制約条件の理論，時間の管理，進捗の管理と制御，デスマーチのためのツールと技術
シミュレーションと「戦争ゲーム」と１１章からなる．

特に難しい理論が展開されているわけでもなく，最後の２章は自分のツールのCMなので
気楽にまずは読むことができるのではないかと思う．そのなかから，トリアージ，時間の管理
チームの構成など，気になるものを探し出す方法が良いのではないかと思う．

→著者が　たった一つだけ覚えてほしいことは
　「トリアージ」・・・作業に優先順位をつけて実施すること

→これ以外にも
　お笑い芸人　小梅太夫が乗り移ったかのように
　「はっ　はっ」と驚き、気づくこと請け合い

→新しいツールを使うことの危険性、
　デスマーチＰＪの「シミュレーション」を作ることの費用対効果
　などなどなど

→現在、火が吹いているプロジェクトを実施しているプロマネやメンバには、
　読ませない方がいいでしょう
　きっと　みんな本当のことに気付いて　会社をやめてしまうと思います
　(悪魔のささやき）

→できるなら　プロジェクトが始まる前に読んで！
　上司に隠れて読んで！

素晴らしい。システム開発に携わる人に必読の書である。以前から読みたいと思っていたが、絶版であったのか手に入らなかったものが、今回、第2版の翻訳で書店に並ぶことになった。

システム開発の鋭い分析とともに、問題点をずばりと突く明快な文章と、鋭い批判精神を持った語り口が絶妙である。第一版を読んだことがないが、少なくともこの第二版については翻訳は悪くない。もちろんアメリカ人のジョークを理解できる読解力はいる。

第一章「はじめに」を読むだけで、並みの書籍一冊分の内容がある。読み出すとやめられなくなり、仕事が手につかなくなる。したがって、この本によって目前の仕事がデスマーチになるかもしれないことを覚悟しなければならない。

ここの評判が今ひとつだったので購入をためらっていたが、実際に読み始めると抜群に面白い。
易しい文章だし、1ページあたりの量も多くないので本来であればドンドン読み進められるはずだが、なかなか先に進まない。というのも、あまりにも、思い当たることが多すぎて笑い転げているだらだ。テレビの下手なお笑い番組に時間を費やすより、爆笑できますよ、この本は。
だから、この本はDEATH MARCHを解決する特効薬を授けるというより、日々ストレスにさらされているプロジェクトのメンバーに笑いを授けることで崖っぷちから救おうとしているのかもしれない。えてしてプロジェクトのメンバーはまじめな堅物すぎて、Edward　Yourdonのシャレにお怒りになるかもしれないが、彼のジョークをお腹を抱えて笑えるようになったら、DEATH MARCHをうまくいなしているのではないだろうか？だって彼自身、実はDEATH MARCHを否定しているわけではなく、楽しんでいる節がプンプンうかがえるから。