業務改革がデスマーチプロジェクトに変わるとき
ソフトウェア開発に携わってきた方なら、「デスマーチプロジェクト」という言葉を聞いただけで、フラッシュバックを起こすような、悪夢のようなプロジェクトの1つや２つは、すぐに思い起こすことだろう。
デスマーチプロジェクトとは
「デスマーチ（死の行進）プロジェクト」とは、ソフトウェア開発において、実現する見込みが薄いことが分かっていながら、過酷な労働状況の中、続けざるを得なくなってしまったプロジェクトである。この状況は多くの場合、要件定義、すなわち何を実現するのかを明確に決めないままプロジェクトをスタートさせてしまった結果、要件が膨張し、あるいは定まらずに変動し続け、結果として、常識的な作業量では達成できないほどの負荷がかかってしまうことによって発生する。
ひとたびデスマーチ・プロジェクトが発生すると、組織への損失は計り知れない。膨大な作業工数と投入資金、そして時間が無駄になる。未来ある何人ものSEが過労で倒れ、あるいは辞職し、組織はガタガタになる。発注者と受注者、さらに下請会社との間で責任の押し付け合いが起こり、業界内での評判は失墜する。その代償として得られるものは使いものにならないソフトウェアだけである。
業務改革でデスマーチ・プロジェクトは起こるのか
デスマーチ・プロジェクトは通常、ソフトウェア開発で発生する事象のことを指すが、実際には、それに類した状況は、製品開発、イベント開催、建築工事など、あらゆる分野のプロジェクトで起きている。では、ソフトウェア開発とセットで語られることの多い、業務改革ではどうか。結論からいえば、業務改革プロジェクトそれ自体がデスマーチ・プロジェクトになることは通常、ない。これは、業務改革そのものが、どのように業務を変えてゆくかを試行錯誤を通じて探求する取り組みである以上、成果物に関する約束が成り立ち難いからである。
ある程度、具体的な成果物を想定してスタートした場合でも、プロジェクトを通じてそれが実現不可能、あるいは効果が得られないことが分かれば、それ以上は続けようがなくなるし、そうした結果となった原因が特定されれば、それはそれで一つの成果となって組織の資産になる。
業務改革がデスマーチに変わるとき
ただし、これは業務改革単独のプロジェクトであった場合である。システムの構築と業務改革を一体的に進める場合が最も怖い。業務改革特有の成果の不確実性が、システム構築コストを大きく変動させるリスク要因になるからである。要件自体が固まらないのに、システム投資が発生する。まさにデスマーチプロジェクトに陥る典型的なパターンへと変貌する。こうした形でプロジェクトがなし崩し的にスタートし、頓挫するケースは少なくない。プロジェクト開始者による、業務改革とシステム構築への理解不足がもたらす罪である。
逆に、先に業務改革をしっかり行っていれば、システム投資のリスクは大幅に低減され、投資額そのものも抑制できる。一見非効率にも見えるが、業務改革とシステム投資は、別のプロジェクトとしてきっちり分けた方が、結果的には、プロジェクトの期間もコストも、手戻りがなくなる分、ほとんどの場合、有利になる。
業務改革プロジェクトには本来、大きなリスクはない。しかし、それをシステム投資と同時に行ってしまったとき、突如デスマーチプロジェクトへと変貌するリスクを背負うことになる。
決して、業務改革とシステム投資を同時に行ってはならない。
© 2015 by JKE
