デスマーチから生還して

やっとデスマーチから解放された。以前かかわっていたプロジェクトに火がつき、私が火消し要員として投入されたのが5月中旬。絶望的な状況をどうにか打開し、現在までに形だけは整えることができた。

守秘義務があるので具体的な経緯を書くわけにはいかない。しかしこの二ヶ月で一番驚いたのは、某中小ソフトハウス(私の会社とは別)から来ていたメンバーがある日突然いなくなったこと。そのうち一人は社長なので、会社ぐるみの蒸発事件だった。

遅れているプロジェクトに追加要員を投入すると、プロジェクトはさらに遅れる。これが「ブルックスの法則」だ。しかし、遅れているプロジェクトには必ず追加要員が投入されるのが業界の鉄則でもある。今回のプロジェクトも水膨れ式に人が増えた。しかし蒸発したメンバーの代わりは登場せず、結局は半分以上私が引き継ぐ羽目になった。

もう一つの業界の鉄則として、プロジェクトが崩壊しはじめると進捗管理がより厳しくなる、というのがある。週一回の進捗報告が毎日となり、遅れた理由をこまごまと報告しなければならなくなり、開発作業に割くべき貴重な時間が奪われる。「遅れているプロジェクトの進捗管理を厳しくすると、プロジェクトはさらに遅れる」という法則がありそうな気がする。「お前が管理しているプロジェクトは大丈夫なのか?」という天の声を無視できないからなのだろうが、迷惑なものだ。

私は追加要員として投入されたので、ブルックスの法則を実証してしまわないことを心がけた。既存のメンバーに対する質問は極力避け、自力でソースコードを理解するように努めた。以前かかわっていたプロジェクトなのである程度事情が分かっていたのも幸いした。一方、私の後に投入された追加要員に対しては、プロジェクトの状況や仕様の詳細を理解してもらうための努力はほとんどしなかった。極端に言えば「ただ座っていてくれればよい」という姿勢で対応した。冷たいが、それ以外のやり方は思いつかなかった。

しかし、ブルックスの法則にも例外がありそうな気はする。追加要員に独立した機能、たとえばユーティリティ関数群の作成をやってもらうことにするとか、メモリリークやNULLチェックの不備を見つけてもらうとか。プロジェクトの仕様や開発の経緯などを知らなくてもできる作業を担当してもらえばいいわけだ。

少し話が飛ぶが、いつも思うのは、システム構成やクラス構成を決める上流工程は決定的に大事だということ。設計に時間をかけず、適当な作りにしてしまうと、デバッグすればするほどコードが複雑化することになる。書いた本人でさえ理解できなくなるほどに。ましてや追加要員にとっては、ひどい設計のコードを理解してデバッグするのは苦痛以外の何物でもない。私は「最初から書き直す」という対応を取ることが多い。

ともあれ、今回私にとって救いだったのは、現場の人間関係が壊れていなかったこと。私は毎日が怒鳴りあいになったデスマーチも経験したことがある。精神的な理由で出てこれなくなった人が何人もいたほどで、私自身もそうなる寸前だった。今回はそうではなかったのでどうにか耐えることができた。

デスマーチに関してあちこち検索してみたら、iwatamさんの「デスマーチ」が引っかかった。そうなんだよなあ、と共感しながら読んだ。