デスマーチの要因

すこし、時間がとれるようになったので、ブログを書きまくっている(それほどでもないか)。

この手の開発をしていると必ずと行っていいほど碌なことがない。
今回は、デスマーチになる要因とどうすれば良いかについて考えてみた。

経験上、大体デスマーチになるのは、開発の途中に事が起こるのではなく、全くの最初の段階で嫌な雰囲気が漂って来ている事を分かりつつスタートしている場合に起こっている。
これらは、大体お客さんと、作業をする人(設計及びプログラムする人)、そして間を取りまとめようとする人のギャップにより発生する。

その結果、以下の項目が挙がってくる

- 開発期間が短い
- 開発金額が少ない
- 開発内容がハッキリしていない
- お客さん側の担当者が決まっていない
- 技術力が足りない

この項目の発生は次の様なストーリーだろう。

---

お客は少ない金額で早く物が欲しいと思っている。頭ではシステムが浮かぶが詳細が見えていない場合が多い。
(最悪、簡単にできると思い勝手に納期を決めてしまっている場合がある。例えば 3 ヶ月後には新しいシステムに切り替えたいとか)

なので、打ち合わせの際に詳細が漏れまいと複数人で挑んでくる。
この時、お客側でも取りまとめがいれば良いのだが、複数人となると大概誰かがやってくれると思っている。
よって、個々人が思い思いの発言をして仕様が曖昧になる(開発内容がハッキリしない)。

それを取りまとめの人が聞くと、仕様が混乱してくる。
要るか要らないか分からない仕様が出てくるが、お客との話を聞くと単純な機能を言っているので大したことないと思う。
なので、期間や金額を適当にかつ最小限でお客に伝えてしまう。
また、やったこと無い内容についても、引いたら負けと思い堂々と出来ますと発言して返ってくる。

仕様があやふやなまま開発側は、怪しいと思いつつも見積もりを出す。
この時なぜか、期間や金額については補正が入り不利な状況になる。

そして、開発がスタートされる。
開発が進むにつれ、細かな詳細が不明となり、内容を聞くと仕様の追加が重なり、挙句片方を活かすと片方が機能しないなどと行った状態になったりする。
追加見積もりは、受け入れられないのに納期だけが迫ってくるようになる。

---

経験則と、フィクションが入っての内容だけど、多分こんな感じが多数だと思う。

結局これらの解決策は、関係者がどれだけ細かく段取りと見積もりが出来るかによると思う。

お客側の心得としては、開発内容をしっかりとまとめた上で取りまとめ担当と話をすること。
取りまとめ担当の心得としては、開発内容を理解しようとすること、無駄な部分を省こうとすること。
開発側の心得としては、開発内容を理解しようとすること、自分たちの開発力を考えて話をすること。

とにかく曖昧な部分を一つでも作ってしまうと、それが歪となり後々に影響が出ることになる。
状況を明確にして、出来ないこと、わからないことをしっかりと各担当に浸透させ話し合える事が重要だと思う。
無理な場合は最悪開発自体を断念するといったことも一つのカードとして持っておけば悲劇を産まなくて良くなるかもしれない。
(こういったことを言える関係性があれば、きっとデスマーチにはならないと思うが。)

今回の要因のなかで該当するものがあれば、対処するようにすればデスマーチは防げるかも!?