真夜中の脳みそ

詩集「半熟卵」(Update:2001. 9.16.)

コラム「午前３時の天気予報」(Update:2004. 8.21.)

AIBO日記(Update:2003.11. 3.)

アルバム(Update:2003.1.31.)

「紺野」とは？(Update:2004. 8.21.)

Links(Update:2002.10.20.)

更新ログ(Update:2004. 8.21.)

Mail Me !

第22回　書評：「デスマーチ」

---

「デスマーチ」〜なぜソフトウェア・プロジェクトは混乱するのか〜(株式会社トッパン)
原著者：Edward Yourdon／訳者：松原　友夫、山浦　恒央　\2,200(+消費税)
ISBN 4-8101-8982-1

"DEATH MARCH"
The Complete Software Developer's Guide to
Surviving "Mission Impossible" Projects

　まずはじめに断っておくが、この本は昨年(1998年)初頭に発売されたものである。本書の書評が日経BP社の「日経コンピュータ」に掲載されたときにタイトルにひかれ、「読んでみよう」と思って書店に赴いたのだが、見つからず、ずっとそのままにしていた。つい最近、別な目的で書店をうろついているときに本書を見つけたので「やっぱり読んでおこう」と思い、レジへ向かった(読み終わった今となってみれば、この期待感があまりよくなかったのかもしれない)。

　タイトル：デスマーチ、すなわち「死の行進」はアメリカ人にとってとても屈辱的な響きをもって、多くの犠牲と損失、または高い確率で失敗が予測される過酷なプロジェクトに転用された言葉、と訳者あとがきにある。

　分類的にはソフトウェア産業に位置する自分の会社の仕事の様子を見てみると、まさにこの「デスマーチ」がぴったりくる。いや、むしろこの「デスマーチ」以外の仕事をしてこなかった、というところまで言い切ってしまっても過言ではないだろう。さらに、訳者あとがきにある「ある組織では、発売日程が決まっている窓口装置のソフトウェアの開発にオブジェクト指向技術を採用した。不幸なことに、その組織はかねてからそのソフトウェア開発のほとんどを協力会社に依存していた。そのため、今まで稼動してきた窓口装置には、どこにも書かれていない裏仕様がたくさんあることに気付かず、開発責任者は生産性が飛躍的に向上するといううたい文句につられてオブジェクト指向に飛びついた。その結果、大量の機能デグレードが顧客から指摘され、プロジェクトは途中でほとんどとん挫し、大幅な遅れでソフトウェアが完成するまで、機器の出荷は完全にストップしてしまった。」(段落全文引用)という段落があるが、訳者の勤務先は私の勤務先の協力会社そのものであり(著者、訳者紹介文より)、私は実際にその様子を目の当たりにしていたため、このことはどう考えても私の勤務している会社で起こったことだ。つまり、本に書かれるほど、私のまわりには「デスマーチ」が横行している、とうことであろう。

　私としては、自分が常日頃接しているこの「デスマーチ」から抜け出す方法があるのか、手がかりがあるのか、それを求めたくて本書を購入したはずなのだが、日本でも、(ソフトウェア開発先進国と言われる)アメリカでもたいして状況は変わらず、ありとあらゆるところに「デスマーチ」が蔓延している、ということがわかっただけで、何らかの明示的な解決の指針が示されているわけではない。読み終わって、「だから何？」と著者に言い返したくもある。

　確かに「デスマーチ」の定義、発生原因、分類、巻き込まれた際の対処の仕方等々細かく書いてある(ときどき差別的なアメリカン・ジョークが混じっていて気分が悪くなることはあったが)ので、それなりの知識は身についた。大きな「デスマーチ」を乗り越えるのではなく、小さな「デスマーチ」を何回か乗り越え、その間に学べ、評価しろ、休息しろ、ということもわかった。システムの要求項目を"triage"スタイルで「やらねばならぬ:must-do」、「やったほうがいい:should-do」、「やれればやる:could-do」に分類して力を注ぎ込めばよい(重点主義)、というのもわかった。それがプロジェクト・チームのためのツールと技術にも適用できるということもわかった。「デスマーチ」が特殊な場合ではなく、「常態」である、ということもわかった。その上で、「だから何？」なのである。日ごろの愚痴をただだらだらと吐き出しただけではないだろうか、といううがった考え方が読み進んでいくうちに私の頭の中に浮かんできた。

　プロジェクト・マネージャや経営者をあからさまに「敵」と表記し、プロジェクトは政治ゲームだと断言し、本当に「デスマーチ」から抜け出したいと思ったら「仕事を辞めろ」という。これではただの飲み屋での酔っ払いの愚痴と変わらないのではないか？

　もったいぶって論文っぽく分類してみたり定義してみたり、角度を変えてみたりはしているが、結局は日ごろの愚痴をこぼしているだけに過ぎないで終わってしまっている。それに付き合わされた私は読み終わった後で不快感が残った。飲み屋での愚痴のこぼしあいでは互いに愚痴をこぼすことによって「吐き出した」というある意味爽快感にも似た感覚が双方にあるが、ただ一方的に愚痴を聞かされるのは迷惑この上ない。それに、副題である「なぜソフトウェア・プロジェクトは混乱するのか」があまり意味をなしていない。なぜ→プロジェクトが「デスマーチ」になるのは常態だから、で終わってしまっている。「なぜ」ときたら「だから」で終わらずに「ではどうすれば」というのがあって然るべきと私は思うのだが、それは期待し過ぎなのであろうか、それとも私が文意を読み取れなかっただけなのか？

　とにかく、本書は私の期待とは裏腹に消化できない不快感が残っただけの本になってしまった。これに費やしたお金と時間がもったいない、と思わずつぶやきたくなる。

(1999. 1.16.)

Prev　　　Next