masayangさんの日記で面白そうだったので工事進行基準会計について調べてみた。
本当に工事進行基準に移行するの？
ちなみに私の会社は「金もらって嘘つく商売」に該当ｗ足を洗いたいｗ
【要点】
・2009/4よりシステム開発に工事進行基準会計が導入される(原則的に導入が必要)。
→今までの工事完成基準会計ではシステム完成時に売上100%を建てていたのが、進捗に併せて売上を建てることができる。
・工事進行基準会計は元々建設業で使われていた会計基準。
→建設業的なウォーターフォールモデルを元に考えられている。
→但し、建設業のウォーターフォールは手戻りが(ほぼ)ないが、システム開発のウォーターフォールは手戻り(特にフェーズをまたぐ仕様変更)が必ず発生する。
→仕様変更のため、プロジェクト初期段階における正確な見積もりはほぼ不可能。
→ウォーターフォールで進捗度合いを測り、売上を適切に建てることは事実上不可能。実際にするとしたら相当主観的になる。
・agileは変更を積極的に受け入れながら機能単位で完成していくため、進捗率が測りやすく、ブレる可能性は低い。
→工事進行基準会計で評価するには適している。
→但し、システム収益総額や原価総額を初期段階で見積もるのはこちらも難しい。
→じゃあ見積りもアジャイルでしようよ
【感想】
・ERP導入とかの大規模PJTいくつか見てきたけど、基本的に予定日にカットオーバーできるわけねー
・日本は海外と比べると仕様変更大杉で、工事進行基準会計に向いてないと思う。軍服に体合わせる気概はどこへ行ったｗ
・そもそも多くのPMがまともにPJTマネジメントできてない(個人の努力に依存しがち)のに、どうやってやるんだ？
・例えば、要件定義フェーズが予定の6倍くらい(半年の予定が3年)かかってるときは(かかってるんだけどｗ)、どういう会計処理になるんだ？ｗ
・おらの村(会社)には、agileはねーだ。
【だから？】
・(少なくとも)これまで以上に要件の選別やPJTマネジメントをやらないと、会計面で破綻することになる。
・agileでやれないか、原則agileで開発できないか検討。
・ウォーターフォールでやらざるを得ない(?)大規模システム開発はどうすんだろうね・・・
（あなたがPJTmgrなら）
・ウォーターフォールで進捗率を正確に測るのは難しいので、極力余力を持たせた見積もりをしましょう。
→少なくとも基礎契約＋フェイズ毎の契約（金額の大部分はこっちで設定）にするなど、後工程で莫大な赤字が出るリスクをヘッジしましょう。
→進行基準で、要件や設計段階の進捗を低く評価するのもOK。要件定義完成はシステム完成の5%に過ぎないとするとかｗ 会計士が認めてくれるかどうかは不明ｗ
・ウォーターフォールでできる限り管理できるように仕様変更削ったり、PMBOKでPMの勉強したりする。
・昇進がかかっているときは、甘く評価して成績をドレッシングする。昇進したらさっさと転職汁！
・見積もりをagileにできないか懇願してみる
(あなたが経営者なら)
・まず自社株かストックオプションを大量に取得します。
→次にシステム開発PJTの進捗基準見直しを行い、甘く評価します。
→すると工事進行基準会計に基づいて、大きな売上(と利益)が計上されます。
→株を売ります/オプションの権利を行使します。
→会社から脱出します。脱出した後に、見えない形で元自社株の空売りをするのも良いでしょう。
参考；
1.工事進行基準とは?〜8.工事進行基準への対応 : 株式会社アクセンチュアの事例
進行基準会計
工事進行基準とアジャイル開発
工事進行基準とアジャイル開発 その２
工事進行基準とシステム開発への弊害
ITの工事進行基準を再考する
