プロジェクト破棄、火消し活動 - 工事進行基準導入で早まるのか？ -

このままでは、ソフトウェア開発プロジェクトを継続しても採算がとれない。あるいは、この時期に商品を出しても開発に見合う売り上げや利益を得られない。そのような判断のもと、プロジェクト活動を当初の目的を達成する前に停止することをプロジェクト破棄（中止）と呼ぶ。プロジェクトが期待通りに完了することに越したことはないが、プロジェクト破棄自体は必ずしも悪いことではない。うまくいく目処がつかない場合に、当初の計画を一から見直すことは全体最適にもつながるし、「あ～。うまくいってない。」ということが常に頭にある場合と比較すると、関係者の心理面にもよい効果があるだろう。

欧米ではソフトウェア開発やシステム開発プロジェクト全体の破棄がそれなりの割合で発生するようだ。国内でも組織の風土に依存しているようで、すぐに全体破棄をするところもあれば、なかなか踏み切れないというところもあるようだ。踏み切れないところはうまくいっていないプロジェクトを放置しているかというとそうではなく「火消し」という名目でプロジェクトを仕切りなおしていることが多い。火消しはベテランが対応することが多く、開発スコープの縮小、リリース延期、品質の優先順位づけで実施される。火消しはほとんどの場合で計画の再定義があるが、メンバの入れ替えはケースバイケースだ。メンバの多くが入れ替わる場合には、実質的にはプロジェクト破棄と再立ち上げを短期間でやっていると考えることもできる。

プロジェクト破棄や火消しを実施するためには、当然、このままだと立ち行かないという判断基準が必要になる。「火消し」というからには火が目に見える形になっている必要がある。顧客を巻き込む場合には、プロジェクト破棄の判断基準に関してプロジェクト発足前～立ち上げ段階で合意をとっておくのが本当は望ましい。始まる前から失敗を考えるなんて、、失敗は許されない、という感じではあるが、リスクとして検討しておくこと自体は悪いことではないと思う。

来期から請負ソフトウェア/システム開発の会計に工事進行基準を取り入れる企業が増える。あくまで会計制度なので、これだけでプロジェクトの成否を判断するのは難しいが、判断基準の1つになり得るだろう。これまで判断が難しかったプロジェクト破棄という選択肢を選ぶ後ろ盾となったり、これまでよりも早い段階で破棄や火消しに踏み切ることができるかもしれない。ここでも書いたが、ソフトウェアタグもこのような判断基準の1つと考えている。