デスマーチの誤用や誤認について

某所でデスマーチについて議論しました。その時点ではいくつか私の誤認もあったので、改めてデスマーチについて考えてみます。
個人的な意見としては、みんな「デスマーチ(ﾟ∀ﾟ)」と言いすぎると思っています。
なお、このエントリのBGMはマイ・ケミカル・ロマンスの「ザ・ブラック・パレード」で・・・

■個人的なデスマーチの定義（注：これはマチガイです）
デスマーチとは、ソフトウェア開発における悲惨なプロジェクトのメタファーです。メンバーに極度な負担を強い、かつ成功する確率が低い状況を、「死の行進（デスマーチ）」と呼びます。

後で調べて間違いだと気づいたのですが、個人的にはデスマーチの定義を次のように考えていました。

• これはデスマーチである
• 仕様が発散し、プロジェクトが収束する可能性が無い。仕様変更が多発し、つくれどもつくれども楽にならり。
• 品質が発散し、やはりプロジェクトが収束する可能性が無い。バグがバグを呼び、治せども治せども楽にならざり。
• これはデスマーチではない
• 単に、見積り・計画・メンバー・設計などに大きな間違いがあるため、期間内・コスト内に目標としたシステムを完成する可能性が低い為、ハードな労働を強いられている状態。
• プロジェクトの後期に大幅なメンバーの追加などを行った結果、コミュニケーションパス数が爆発し、混乱が発生し、結果として非常にハードな労働を強いられる状態。

要は、完全に何かのパラメータが発散する(際限なく増えていく)状況はデスマといえますが、単なる突貫プロジェクトや失敗を含むプロジェクトをデスマーチと呼ぶのは、不適切な不幸自慢なのではないかと思っていたわけです。

■真デスマーチの定義
改めて調べると、デスマーチの定義はこんな感じです(Wikipediaより)

• 公正かつ客観的にプロジェクトのリスク分析 (技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む) をした場合、失敗する確率が50%を超えるもの
• 与えられた期間が、常識的な期間の半分以下である
• エンジニアが通常必要な人数の半分以下である
• 予算やその他のリソースが必要分に対して半分である
• 機能や性能などの要求が倍以上である

これを見ると私の定義も別に誤っているわけではないと思うのですが、再考してみました。

• これはデスマーチである
  
• 公正かつ客観的にプロジェクトのリスク分析 (技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む) をした場合、失敗する確率が50%を超えるもの
• かつ、上記の状況に対して適切な対策を実施する前の状態
• これはデスマーチではない
• プロジェクトを成功させるために、不適切な労働を強いる状況 ( それは組織としてはダメですが、デスマというわけではない )
• よくわからないが、うまくいっていないプロジェクト

■要は何をいいたいかというと
みんな「デスマ」「デスマ」と言いすぎだと思っています。
「お前らに本当のデスマーチを思い知らせてやる！」
これはうそです。私もこんなデスマーチには参加したことはありません。キツイプロジェクトはありますけどね。

Blogged with Flock