デスマーチ 第2版 の商品レビュー

エドワードヨードン【著】,松原友夫,山浦恒央【訳】

2012/03/31

もはやシステム開発の世界では、日常語となっているデスマーチ。
プロジェクトがデスマーチに陥る理由は、かなり簡単に説明できるかと思います。つまり、プロジェクトの価格が開発費用によって決められ、開発費用は大半が人件費であり、人件費は（人月単価）×（人数）×（期間）ですから、人数と期間を削減することでプロジェクトの価格を抑える構造になっているから、となります。
人月単価も抑えられ、いくら働いても収入が増えず、生産性（収入を勤務時間で割ったものです）が上がらないという構造にもなっています。

デスマーチを避ける最善の策は、会社を退職してでもそのプロジェクトから離れること、とのことでした。ところが別のところでは、どんなプロジェクトもデスマーチになる、としており、これだとシステム開発に携わる限りはデスマーチから抜け出せない、となってしまいそうです。
そしてデスマーチがあるのはシステム開発だけではなく、アニメーション制作などのコンテンツビジネスも同様の構造を抱えているという話ですし、医療や介護の世界も職務に見合った報酬が与えられていないと聞きます。

システム開発に絞って書きますが、プロジェクトがデスマーチになるのは、プロジェクトマネージャが無能だからでも、営業や上層部が分からず屋だからでもなく（もちろんそういう点があることは否定しませんが）、それ以外の部分に原因があることも多いと思います。
まず、開発者側の工数見積もりに対する姿勢が、あまり適切とはいえないでしょう。与えられたタスクが技術的に困難を伴う場合、うまくいけば一瞬、ダメなら1か月でもできないということもあるわけですが、それにしても見積もりを極端に安全側に振ったり、そもそも正確な見積もりを最初から諦めて、意味のある見積もりを出してこなかったツケが回ってきている部分もあるかと思います。
また、システム開発の適正価格が定められておらず、開発者側から見れば自分の成果が給料に見合っているのかどうかが見えない、という事情もあるでしょう。これは開発者のモチベーションにつながりますが、あまり考慮されていないように思います。本来ならシステムの価格は（機能単価）×（機能数）×（難易度の補正）といった形で決まるべきかと思いますが、顧客や競合他社との提示額を見ながら、契約が取れるような価格で決められてしまうのが痛いところです。

本書で特徴的なのが、「トリアージ」という概念。工数が限られてしまっているため、要件を見直して必要性の低い機能を捨てる、という考え方です。
米国は契約社会で、日本は根がまじめだから、両国の開発者とも与えられた要件はすべて実装すべきと考えてしまうのでしょう。ですが本来は、開発者がプロジェクトにもっと口を出して、これはできる、これは間に合わない、といったことをきちんと主張するべきなのだと考えます。
米国の事情をもとにしているので、日本の開発環境とは異なる部分もありますが、システム開発がデスマーチに陥りやすいのはどこでも同じです。開発者が自分の仕事に自信と誇りを持ち、自分の能力と与えられたタスクを客観的に判断して、予定の工数では何がどこまでできるのかを率直に主張することが、求められているのでしょう。

2012/02/27

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

2012/01/21

一時間ほど時間があったので図書館にて。あまり面白くなかったので、途中まで。タイトルだけ追って見た。まぁ、関わりたくは無いわな。

2011/08/21

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

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

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

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

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

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

2011/07/20

たぶんプロジェクト経験後に読むべき本だったのでしょう。
とりあえず、IT系プロジェクトは覚悟して取り組もうと思った。
ただ、この本は海外(アメリカ？)でのことであり、日本でもこのまま当てはまるのかは疑問だった。デスマーチから逃れるために、仕事を簡単にやめても良いというスタンスは日本でも実行出来るのか…？

2011/03/30

和訳特有のヘンな日本語の言い回しに、終始ギクシャクしたかんじ。 ナニが趣旨だったか、ナニを感じ取ればいいのか漠然としていて、つかれました…。 この本がデスマーチな雰囲気でしたよ。 読まなくてイイです。

2010/09/29

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

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

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

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

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

2010/02/17

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

2009/10/25

トリアージを覚える。やる事・タスクについて、Must Do、Should Do、Could Doの3種類に分類する。
20:80の法則で20％の完成部分で要求仕様の80%を満たせる。。しかしこれは言いすぎかなと。。
あとポストモーテム(事後分析)が大事と。プロジェクトを主要メンバーと振り返って品質、財務、プロセス改善、教育などが上手くいき、予算の範囲内で利益をきちんと生み出したかを確認する。

2011/05/15

まずはITベンチャーのリスクを知っておくためにデスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのかを学習させました。この本はIT系の人間からすると耳が痛いことが山ほど書かれており、それを意識して組織を作るか耳をふさぐかで大きな違いが出ると思ってます。