デスマーチはいつからデスマーチだったのか

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

デスマーチとは

残念ながら「デスマーチが約束されたプロジェクト」というモノは実際にあります。(利益ではなく)売上に魅入られたITベンダーは、デスマーチとなることが確実でも前向きに商談に取り組むものです。

Wikipediaによりますと「デスマーチ」とは、

(略)具体的には以下のいずれかに該当するものと定めている。

  1. 与えられた期間が、常識的な期間の半分以下である
  2. エンジニアが通常必要な人数の半分以下である
  3. 予算やその他のリソースが必要分に対して半分である
  4. 機能や性能などの要求が倍以上である

とあります。なるほど。

ITベンダーの仕事とデスマーチ

「時間がなく、エンジニアの数も足らず、費用も限られており、かつユーザーの要求は膨れ上がる」というのはシステム構築プロジェクトの常とも言えます。

これが常態であるとするなら、ITベンダーの仕事は「デスマーチを避けることではなく、デスマーチから利益を搾り出すこと」ということになってしまいます。

こうなると、「10のプロジェクトで7つがデスマーチ化し赤字プロジェクトになっても、残り3つが十分な利益を出してトータルで黒字になればいい」という考えるITベンダーもでてくるかもしれません。

しかし、極端かもしれませんが、デスマーチはエンジニアの生命と精神を脅かします。いくら利益がでたとしても、これでは健全とはいえません。

目指すべきは「デスマーチから利益を出す」ことではなく、「デスマーチをもたず、つくらず、もちこまず」を遵守しつつ利益を出すことです。

デスマーチはどこで作り出されるのか

私の経験上、デスマーチが作り出されるのはシステムの開発フェーズではなく、無謀な計画、曖昧な要求を許容してしまったシステム企画フェーズや商談フェーズです。

企業や案件の規模にもよるでしょうが、このフェーズでデスマーチを作り出した人は、デスマーチには参加しないケースが結構あります。無責任にやっているのではないかもしれませんが、デスマーチを作り込んでいるかもしれないという自覚を持つべきです。

上流工程で作り込むのは品質であって、デスマーチではなかったはずです。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

カテゴリーIT