Web制作などで陥りやすい状態を示すデスマーチという言葉があります。簡単にいうと、制作担当者への過負荷状態が継続的に起こってしまうこと。原因として考えられるのが、要件定義や詳細見積作成時などでのスケジュールや作業量などの検討不足。これらはいずれも、初期段階で気を付けなくてはいけないこととしてよく挙げられる曖昧さを残したまま見切り発車してしまったことが顕在化した場合に起こると言われています。この対処は早いに越したことはなく、この状態に気づいたら、すぐに関係者協議のうえ、状態の冷静な見極めと致命的と判定されたときは早急な対処が求められます。この素早い対処が最悪の事態を免れる唯一の方法であるとともに、対処した後のフォローも重要です。
デスマーチは初期の検討不足が主原因
あるプロジェクトが本格稼働していくなかで見られる特定のプロセスや担当者に過負荷が継続的に起こっている状態を示すデスマーチ。この兆候をプロジェクトマネージャは見逃してはいけません。しかしその解決はマネジメントだけで図れるものではなく、もっと上流となる要件定義や詳細見積時点での検討不足などに起因していることが往々にして考えられます。さらに突き詰めていくと、疑問点に気づいていたにも関わらずその時点で調査したり、周囲に相談したりせず先送りしてしまったことが根本原因だったということもよく聞かれます。そこから見えてくる防止策として、プロジェクトの初期段階ほどあいまいさを先送りせず分かった時点で対処することが基本であり、さらに要件定義や詳細見積では必ず複数の目で検証を行うことの重要性を再認識し共有するということではないでしょうか。
ソフト開発の見積手法のかずかず
ソフト開発の見積には従来から各種手法が考えられてきました。基本的にボトムアップ方式と呼ばれるものが主流で、LOC（Line of Code：プログラムのステップ数）や機能を基本にしたFP（Function Point）法、開発規模をベースとしたCOCOMO（Constructive Cost Mode）などが知られています。さらに開発規模が大きくなると、作業分解図などと訳されるWBS（Work Breakdown Structure）をベースにしたり、係数モデルを使った手法も編み出されてきました。これらはいずれも算出の基本となるものがある程度明確になっていて、その積み上げたものを合計するというボトムアップ方式となるものです。
Web制作の見積ではトップダウンが多い
ソフト開発プロジェクトの見積のようにボトムアップ方式が多い中、Web制作のようなプログラムのステップ数だけで全体規模を掴み切れない、要件追加などで作業内容が変動しがち、というようなプロジェクトでは、むしろトップダウン方式が主流と言えるかもしれません。稼働から成果物完成までが短期間という事情などもあり、やむを得ないところもありますが、精度を高める必要性に変わりはなく、そのためには可能な範囲でボトムアップによる見積も作り比較したりと、各社で独自に作り上げた見積方式で行われる傾向にあります。いずれにしろ苦労して完了させたプロジェクトが最終的に赤字だったでは済まされない（戦略的配慮から承知されていたなら別ですが）ことに変わりはありません。