 |
|
「デスマーチ」 株式会社 日立製作所 福原 雅之：5月号
1．デスマーチとは 「デスマーチ」(死の行進)という言葉をお聞きになったことはありますか? IT業界ではシステム開発現場の過酷な労働環境、過酷な開発プロジェクトを比喩する言葉として使われています。Edward Yourdonによるとデスマーチ・プロジェクトとは「開発期間、開発者数、予算などのプロジェクトに必要な資源のいずれかが、本来必要な水準の半分以下しか割り当てられておられず、多大な犠牲と損失、もしくは高い確率での失敗が予測されるプロジェクト」と定義されています。(注1参照) これは人員不足、短すぎる開発期間、予算不足、ユーザーとの調整不足などの悪条件が重なった時に起こります。このようなプロジェクトでは、自分たちが破綻に向かってどんどん進んでいるのがわかっていながら、往々にして前に進むことしか許されないという状況になります。 2．デスマーチの原因 デスマーチは必要な資源が半分以下しか割り当てられない、つまり計画通り開発できない無理なプロジェクトです。もともと破綻することが運命付けられたプロジェクトです。 この資源の割り当ての失敗は当初のプロジェクトの計画段階から十分な資源が割り当てられなかったり、当初は割り当てられていてもプロジェクト進行に伴う”異常” (設計不良の発覚、仕様変更多発、開発チームの力量不足による遅延等)により、資源が足らなくなるということから発生します。 割り当ての失敗の理由としては、まず考えられるのは“見積り誤り”で、システム仕様を十分理解していないことや自分たちの保有する資源を適正に評価できず(過大評価しているケースが多い)、目的とする成果に必要な資源を確保できないことが挙げられます。 3．デスマーチを防ぐために 有限な資源の割り当ては、プロジェクトの計画や再計画での問題です。 プロジェクトの上流工程で、ユーザーの要求を整理し、現実はなかなか難しいのですが、曖昧な仕様部分のリスクを適正に評価し対策することが必要です。それと同時に、特にソフト開発のプロジェクトは開発チームの生産性を考慮することが重要です。ソフト開発は、個人の能力によってその生産性には大きな差が出ます。ソフト開発の工数見積は、「誰が」やったらと考えないと、その見積の精度は狂います。日頃から開発チームの“顔の見える見積”に心掛けたいと考えます。 そして、プロジェクトマネージャーは、プロジェクトの進行と共に発生する“異常”に対する感度が重要だと考えます。異常の兆しが見えたときに、そのリスクに対し必要な資源を見積り、投入を判断する力量が必要です。さらに、必要な資源が確保できない時には、計画の縮小や、中止を上長やユーザーと調整するだけの力量が・・なかなか道は遠いですね。 いずれにしても、日頃から己の力量を十分知ることが重要なようです。自戒を込めて・・・ (注1)Edward Yourdon：「Death March: The Complete Software Developer’s Guide to Surviving "Mission Impossible" Projects」(邦題：「デスマーチ - なぜソフトウエア・プロジェクトは混乱するのか」) IT-SIG，内容にご意見ある方、参加申し込みされたい方は  こちらまでメールください。歓迎します。ITベンチマーキングSIGホームページは
こちら |
 |