« [読書メモ]G. ポリア『いかにして問題をとくか』 | トップページ | [勉強会]2012/03/31 セミナーズチャンプル »

2012年3月31日 (土)

[読書メモ]エドワード・ヨードン『デスマーチ』

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

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

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

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

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

|

« [読書メモ]G. ポリア『いかにして問題をとくか』 | トップページ | [勉強会]2012/03/31 セミナーズチャンプル »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/75808/45719080

この記事へのトラックバック一覧です: [読書メモ]エドワード・ヨードン『デスマーチ』:

« [読書メモ]G. ポリア『いかにして問題をとくか』 | トップページ | [勉強会]2012/03/31 セミナーズチャンプル »