デスマーチ

"デスマーチ"、"死の行進"。日本流に言えば、大火事になったプロジェクトのことだ。
デスマーチプロジェクトの特徴や予防、対処方法などが書かれているといえば書かれているが、内容的に目新しいところはないように思う。デスマーチプロジェクトに対する新しいヒントや特効薬を求めて本書を購入すると期待はずれになるかもしれない。（自分もそんな気持ちで購入した一人ではあるが。）
個人的には本文よりも巻末に掲載されていた生々しい現場の人たちのメールがとても面白かった。約10年前くらいに書かれた本ではあるが、ソフトウェア開発業界の体質は今の時代とはほとんど変わっていないようである。むしろ悪くなっているのかもしれない。僕の周りでも今現在も普通にデスマーチ進行中のプロジェクトはいくつもあるんだから。
★★★☆☆。

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

どうしてソフトウェア開発業界はこうなんだろうか？

• 見積りが難しい。正確に開発スケジュール、コストを前もって算出することはほぼ不可能。見えているものだけでなく、リスクをどれくらい予想できるか。それが見積りで重要なところであるが、経験を積まないといけない。
• 機械が作るのではなく、人間が作るから。人間の能力に大きく左右されるし、交換がきかない。とくに日本の業界では簡単に人を解雇したり、入れ替えたりすることはできない。能力の低い人間も高い人間も同じ1人月とカウントされる。
• 開発する前に出荷日、お客様が決まっていることがある。こうなったら、どうしてもそれまでに開発しなければいけない。まずは形にすること、次に品質という順番になってしまう。開発の最初の工程では品質は数字では見えにくい。まずは開発量という数字をどんどん増やして、なんとかプロジェクトは進んでいるように見せなければならない。その後に、品質が悪いことで問題が大きくなって、作り直しなど悪いスパイラルに陥ってしまう。

つまり、業界として反省していないということ。この業界にいる人間でデスマーチに関わったことがないというものはいないのではないだろうか。それなのに、再びデスマーチを繰り返す。10年以上前から変わらないし、これからも変わる事はないと思う。ソフトウェア業界って最先端っぽいイメージがあるけど、中身は完全に人間に頼っていて工場制手工業と本質的には未だに変わらない時代遅れな業界って訳だ。

でも、本書にも書かれているがデスマーチには一度は参加しておくと良い経験にはなると思う。その経験や反省から、次からはそうならないように気をつけるようになるし、個人としてリーダとしての仕事のやり方が変わってくるはずだ。

僕も3年くらい前にデスマーチプロジェクトに関わった。品質が悪くて製品として出荷できるレベルにはほど遠い状態のプロジェクトがあった。すでに出荷予定日を大幅に過ぎていたときに、そのプロジェクトの火消し役を任されたのだ。僕と同時にそのときの僕のチームのメンバ全員とさらに他のメンバなど10数名が追加されて、なんとしても早急に出荷にこぎつけるようにとのお達しを受けた。品質を上げるためのコードレビューと並行してテストチームを編成して大規模なテストを実施。僕はそのどちらもマネージメントすることとなり、毎日毎日深夜・朝方まで働き続けた。当然のことながら土曜日も日曜日もなかった。そんなムチャな働き方を数ヶ月間続けて、なんとかかんとか出荷することができたが、そのときにはチームのメンバはバラバラになっていた。体や心を壊すものが続出したわけだ。会社にとってはあまりにも大きな被害があったはずだ。（正直、僕もそのときから睡眠薬を飲まないと眠ることができないようになっている。今も飲み続けている。）
本当にもう味わいたくない経験ではあるが、それまでは他人事のようだったデスマーチを自分で実際に経験することによって非常に大きなものを得ることができたと思っている。大火事になってしまってから消火活動を行っても大変作業であるが、火事が発生しないように火がつきそうなところを日々点検し予防するのは簡単なんだということとか。

まだまだ僕の近くのチームもデスマーチ中だけど。組織として根本的になんとかしていかないと。

次はこの本で頻繁に引用されたドム・デマルコの『ピープルウェア』を久しぶりに読み直してみようかと思う。