デスマ寸前のプロジェクトは無事納品出来た。まだいろいろ問題はあるのだけど、「区切りをつける」ことは大事だ。

件のプロジェクトをやっていると、この客は「デスマ体質」を持っていることがわかったので、そうならないように細心の注意… ってあたりは別エントリにて。

件のエントリのコメントに、頭の悪い反応があったので、あらためて反論… じゃなくて注意しておこう。

どんなエントリだったかあまり正確な内容は覚えてないんだが、要するに「デスマであるかどうかわかったところで、末端のプログラマには大した問題じゃない」的な話。まぁデスマであろうとなかろうと、厳しいプロジェクトになってしまえば、末端がキツいことは確かに大差ないから、「末端のプログラマ」の感想としては妥当なところかも知れない。

しかし、これが「末端のプログラマ」ではなくて、SEやPMの感想であるなら、

とっとと業界から足を洗え！

と言いたい。そんな奴がデスマを作って行くからだ。

「デスマ」と「単に厳しいだけのプロジェクト」とを区別する必要があるのは、プロジェクトのマネージメントが全く違うからだ。ここを間違えると、デスマでないものをデスマにしてしまったり、デスマがますます悲惨なものとなりかねない。

「厳しいだけのプロジェクト」なら、その対処をすればいい。マンパワーが足りないならマンパワーを追加すりゃいいし、スケジュールがタイト過ぎるのであれば、その辺の調整をすればいい。「いいツール」を使うのもいいだろう。やり方はいろいろあれど、方針は同じだ。スケジュールや要求、あるいはマンパワーのバランスを調整してやればいい。もちろんそこで間違えればとんでもない結果になるし、容易でない事情があったりするのではあるが、基本は変わらない。足が遅ければ急ぐ、時間がなければ時間を稼ぐ。パワーがなければパワーを補う。基本は単純だ。

ところが、「デスマ」の場合はそうではない。前にも書いたように、デスマとは、

工程が破綻した結果、
着地点がわからなくなったもの

だ。つまり、「ゴール」が見えなくなった状態なのだ。

「ゴール」が見えないんだから、マンパワーを追加しようが、時間稼ぎをしようが、「いいツール」を使おうが無駄だ。場合によってはもっと事態を悪化させる。下手をすれば、

ゴールと反対方向に
全速力でつっぱしる

ことになりかねない。「ゴール」が見えないんだから、いくら急いでも無駄なのだ。

だから、「デスマ」になってしまったら、まずやらなきゃいけないことは

「ゴール」の発見

なのだ。それをしないでマンパワーを追加してもあまりプラスにはならない。まぁ「方向としてはだいたい合ってる」場合で「ゴールは多分遠い」時には、「だいたいの方向」を目指して行くために走りまくるという手はあるのだが、そもそもゴールがどうこう言っている時点でそうなっていれば、デスマでなくてもヤバい。

だから、「兵卒」であれば「デスマであろうがなかろうが、とにかく進め」なのだけど、PMでそう思っていてはマズい。PMなら、あの手この手を使って「ゴールの設定」をまずするべきであるし、それをしないでマンパワーの投入をするのは間違い。だから、「デスマ」と「単に厳しいだけ」は区別されるべきなのである。

だから、プロジェクトの状態がどうであるかを把握することは、意味がある。同じ「納期に間に合わない」ものであっても、デスマになっているものとそうでないものでは、対処はまるっきり違う。