実際のところどうよ

エドワード・ヨードンの「デスマーチ」といえば、その筋では知らぬものなどない、いわゆるところの「名著」のひとつである。ということになっている。もちろんわたくしも読んだ。たぶん10年ぐらい前のことだ。その時は、ふーん、何だかよくわからんな、という感想だったと思う。今は改訂版が出ているようだ。どういうふうに改訂されたのかは知らんが、今回あらためてオリジナル版を再読した。

デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか

「あらゆるテクストは想像的にそれが書かれたリアルタイムに身を置いて読まねばならない」と内田樹先生はおっしゃっている。ふむ、そうだ。そうだよな。この本が書かれたのは1995年ごろ、だったかな。その時代に想像的に身を置きながら、そして1999年だか2000年ごろに「ん？」と思いつつこの本を読んだこの俺様自身に思いを馳せながら、といういささかアクロバチックな仕方でもって、読んでみた。
いやまあ、例によってほとんど何も憶えてないものだな。当時の俺様がなーんにも知らんかった、というのも大きいとは思うが。まず「デスマーチ」っていうのは単純に「よくないもの」だと思っていたのだ。だからこの本のテーマは「ソフトウェアプロジェクトがデスマーチになるのを避けるにはどうするべきか？」だと思い込んで読んでいた。そうすると、読んでいて混乱するはずだ。なぜなら前提が間違っているからだ。
筆者は必ずしもデスマーチを否定していない。まずデスマーチとは何ぞや？筆者の定義によれば、「『プロジェクトのパラメータ』が正常値を50%以上超過しているもの」だ。たとえば、開発規模に対して人員が必要な人数の半分ほどしか割り当てられていない。あるいは、普通は1年ぐらいかかりそうなものを半年で納品しないといけない、とか。その上で、デスマーチには、「良いデスマーチ」と「悪いデスマーチ」がある。いや、ヨードンは「良い」「悪い」という単純な分け方はしていない。「成功の可能性」と「メンバの満足度」の2軸で考え、「自滅型」、「モーレツ型」、「カミカゼ型」、そして「ミッション・インポッシブル型」と４つのスタイルに分類できる、としている。どれが良いとか悪いとかではないが、好みはある。著者は「ミッション・インポッシブル型」を好み、「モーレツ型」を嫌悪する。
「自滅型」や「カミカゼ型」は成功の可能性は極めて低い。逆に言えば、デスマーチ・プロジェクトであっても、「モーレツ型」や「ミッション・インポッシブル型」の場合は成功、とは言わないまでも完成までこぎ着けられる（たとえ大幅に予算を超過し、日程が遅れたとしても）可能性がないわけではない、ということになる。それは例えばマイクロソフトのWindows NTプロジェクト（「闘うプログラマー」！再版されたようですな）であったり、アップルのMacintoshプロジェクトであったり、ということだろう。そして、デスマーチを体験したエンジニアは強くなり、成長する。また、ともにデスマーチ・プロジェクトで働いたものどうしは、強い仲間意識を持つようになる。
2回めにしてやっと気が付いた。この本のテーマは、「デスマーチは避けられない。ではいかにしてデスマーチ・プロジェクトを最小限の被害で完了させるか？」ということだ。
特定の開発方法論にこだわりすぎてはいけない。リスク管理、要求管理をしっかりやる。「毎日の構築」（今で言うところの「デイリービルド」とか「継続的インテグレーション」のことだろう）をやる。・・・当たり前じゃないの？と言うなかれ。この本が書かれたのは1995年だ。「アジャイルソフトウェア開発宣言」が発表されたのは2001年のことだ。このテクストが書かれたリアルタイムに、想像的に身を置いて読まないといけない。
ソフトウェア開発方法論も、進化しているのだ。当時は完全なデスマーチであったプロジェクトも、現在は「ちょっとチャレンジングなプロジェクト」という感じになるのだろうか。