ここの評判が今ひとつだったので購入をためらっていたが、実際に読み始めると抜群に面白い。
<br />易しい文章だし、1ページあたりの量も多くないので本来であればドンドン読み進められるはずだが、なかなか先に進まない。というのも、あまりにも、思い当たることが多すぎて笑い転げているだらだ。テレビの下手なお笑い番組に時間を費やすより、爆笑できますよ、この本は。
<br />だから、この本はDEATH MARCHを解決する特効薬を授けるというより、日々ストレスにさらされているプロジェクトのメンバーに笑いを授けることで崖っぷちから救おうとしているのかもしれない。えてしてプロジェクトのメンバーはまじめな堅物すぎて、Edward Yourdonのシャレにお怒りになるかもしれないが、彼のジョークをお腹を抱えて笑えるようになったら、DEATH MARCHをうまくいなしているのではないだろうか?だって彼自身、実はDEATH MARCHを否定しているわけではなく、楽しんでいる節がプンプンうかがえるから。
本書で言う「デスマーチ」とは、主にソフトウェア開発を対象として「開発者に過度の負担を掛けながら破綻への道を突き進む」プロジェクトを指す。私はソフトウェア開発25年の経験を持つが、私の入社時には「遅れたプロジェクトに新たに人員を投入すると、そのプロジェクトは更に遅れる」という名言で有名なブルックスの「人月の神話」がプロジェクト管理の本として著名であった。
<br />
<br />本書では、「プロジェクトのパラメータが正常値の50%以上のもの」をデスマーチと明快に定義している。例えば、納期、人員、予算等が見積もりに対して半分以下なら即デスマーチだ。逆に要求仕様が2倍だったらやはりデスマーチだ。著者はデスマーチが起きる原因を、経営、営業、楽観主義、不測の事故等に分類し、解説する。こうした分析嗜好はアメリカ人の性癖によるものだろう。簡潔に言うとアメリカでは職能(マネージャ、担当者etc.)主義が徹底しているのでそれに沿って、ある意味マニュアル化した方法で対処するのが良いと言う。
<br />
<br />翻って日本はどうだろう。顧客との折衝でビジネスライクに事を進め、常に必要な予算を確保できるのであろうか ? 私はむしろマーフィーの次のような法則の方が現実に近いように思われる。「失敗する可能性のあるプロジェクトは必ず失敗する」。そして、失敗する可能性の無いプロジェクトなど存在しないのである。
デスマーチの定義、デスマーチへ陥る原因のくだりは、共感する部分が多いのですが、
<br />そうなってしまった場合の対策はあまり具体的に述べられてなく、別の本を探したほうが良いのかなと感じました。
<br />
<br />また、純日本的な企業で働いていると、アメリカとの企業文化の違いもあり、
<br />ちょっと自分の環境とは現実離れしている部分も気になりました。
<br />
<br />- 本の中で出てくるアメリカのマネージャ・プログラマはハイリスク・ハイリターンで働いていて、
<br /> 失敗すれば首(ただし転職容易)、成功すれば多額のボーナス、長期休暇。
<br /> マネージャがプロジェクトを請け負うか断るかの選択肢まであり。
<br /> マネージャとプログラマで給料がかなり違う。
<br />- 一方の日本的な企業ではローリスク・ローリターンで、
<br /> 失敗しても首の心配はなし。
<br /> ただ、成功してもボーナスはほとんど変わらないし、休暇も桁違いに少ない。
<br /> デスマーチを断る権利はほとんどなく、デスマーチに巻き込まれてる人はほとんどが仕方なく巻き込まれてる
<br /> 管理者になると残業手当がなくなり、場合によっては残業代つく部下の方が給料多い。
<br />
<br />どちらの社会・会社がいいかは人によって違うと思いますが、こんなデスマーチを避けるにはどうすればよいか?というのは、もっと勉強と経験を積んで修得しないといけないのかなと思いました。