デスマーチは「人災」だった

近頃デスマーチについて考えることが多くなった。
現在、僕が思う「デスマーチ」の原因について書いてみる。
ただ、僕一個人の意見であって、それが正しいかどうかは保障しない。
気楽に読んでもらえたら光栄である。

---

デスマーチは、次の計算式で簡単に求められる。

デスマーチ　＝　（１ヶ月の生産性（残業含む） × 開発期間）　＜　案件数


この図式を打開すべく、個人の生産性（＝１ヶ月の生産性）を向上させようと色々足掻いて来た。プロとして、生産性を向上させようと成長することは当然だと考えていたからだ。

そのために、上流工程での「設計」を重視し、下流工程でバグを出さない様「テスト」を十分実施する。「設計」と「テスト」を満たすべく、足りないリソース（人員）を補充し、プロジェクトを進める。これが定石だろう。

---

しかし。
しかしである。
危険な媚薬も存在する。

「開発期間を短縮するために、設計／テスト／確認をはしょって素早くリリースする」という考え方。

確かに早くリリースは早くなる。しかし、即座にバグが見つかって修正／再リリースすることになる。また、開発者もテスト／確認の時間が奪われ、どこにバグが潜んでいるか把握できなくなる。こうなると、開発部隊とテスト部隊で頻繁にバグレポートが行き来して、いつまでたっても収束しなくなる。

開発　＞　リリース　＞　バグ検出　＞　改修　＞　リリース　＞　バグ検出・・・・

こんな時、マネージャーは決まって「リリース日は迫っている。残件を早急に片付ける様に」としか言わない。現場は終電／徹夜をいとわずがんばっているのに、「もっと早く！」と言われ、テスト／確認時間は更に短くなり、バグが止まらなくなる。開発者も毎日残業で疲弊し、冴えない頭で仕事するのでミスや確認モレが発生し、加速度的に障害件数が増えて行く・・・。

悪循環極まりない。

---

更にやっかいな問題がある。
コミュニケーションを嫌う開発者が、「仕様」を軽視する場合である。

自分が「正しい」と思った事を誰にも言わず、こっそり（本人はこっそりではないのだろうが）仕様を変更し、「仕様書と異なる」と言われ、障害として指摘される。本人は「これが正しい！」と主張し、「俺様はプログラマーだから仕様書を書く暇なんてない」と言い放って別の担当者が仕方なく仕様書を修正する。

昨日まで動いていた機能が、次の日まったく動作しなくなった。
「インターフェースが気に入らなかったので、変えました」
とか平気で言う。デスマーチで終電／徹夜を繰り返している状況で、この一言は殺意を抱くのに必要十分である。

本来であれば、そんなプログラマはとっととお払い箱にするべきだが、仕様を一人で抱え込んでいる場合は仕方なく仕事を続行させるしか手は無い。

こちらも、悪循環にしかならない。

---

以上、デスマーチは「人災」であることがお分かり頂けたと思う。
纏めると、下記２点がポイントとなる。

• 期間短縮のため「設計」「テスト」「確認」を軽視するという考えを持った人々
• 自分勝手に開発を進めるキーマン

デスマーチは「人災」です。
デスマーチが発生しそうな人材がプロジェクトに居る場合は、傷の浅い内に適切な処置（プログラムを書かせない、重要なポジションから外す、プロジェクトから追い出すなど）を実施することをお勧めします。