進行基準会計
日経ソリューションビジネス９月３０日号が会社に届いていた。特集は「２００９年会計ショック 進行基準という怪物が襲う」だ。
日本で働いていた会社はすでに進行基準を導入していたので、自分としては特に驚くことはない。企業会計の透明化、という観点では完成基準より進行基準の方が明らかに合理的だからだ。
とはいうものの、ウォーターフォール開発に進行基準を無理矢理適用するのはいただけない。
- プロジェクトのごく初期段階で正確な見積をすることはほぼ不可能
- 設計文書類の完成度とシステムの完成度の間には何の関係もない
本当にシステムの完成度で評価するのであれば、ウォーターフォールでは図（上）のような感じで完成していくはずだ。プロジェクト後半の結合〜総合テストの段階でようやく完成度を語れることになる。にも関わらず、基本設計完了[*1]の段階で進捗率○○％みたいに無理矢理評価してしまう。
会計の透明化を目指したつもりの進行基準であっても、ウォーターフォールの場合はプロジェクトマネージャの恣意的な判断に左右されてしまう。記事では富士通の人が「赤字化の早期発見」などという利点を強調しているが、これは進行基準移行前がいかにボロボロだったかを語っているだけであろう。進行基準化により、プロジェクトの要所要所でのチェックが厳しくなるので問題の早期発見確率も高くなるであろうが、プロジェクトのオーバーヘッドは当然膨らむ。そして、そのコストは結局は顧客に転嫁される。
Agileなら図（下）のように、「当初設定したフィーチャの○○％が完成」という形で客観的に完成度を評価できる。途中発生したフィーチャがあったら、その分工期は伸びる（進捗率は下がる）だけ。
進行基準会計をまじめにやるのなら、Agileでいくべきでしょ。
*1:これも不思議な話で、基本設計が終わったかどうかはシステムが完成するまでは断言できないんだよね
