※一部記事はこちらからメールでニュースレターをお申込みください。
2009年4月から、受託ソフト開発に工事進行基準の適用が始まることになった。簡単にいえば、これまでの「開発物が完成し、納品・検収を受けて売上として認識、計上される=完成基準」から、「事前に定義した工程などが予定通りに進んでいれば、売上、原価として計上できる」というもの。当然、開始前に仕様や工期を明確にする必要も出てくるし、「システム一式」といったある意味であいまいな契約ができにくくなる。
はるか昔の毎月清算する受託契約に似ているような気もするが、出来高による契約ではないので、工期ごとに、あらかじめ見積で合意した内容と金額がキチンとした出来上がりや進行のチェックのもと、計上され、支払われるということになるということだ。これまでも、分析、概要設計、機能設計など、工程別の納品物の検収を行う契約の仕組みはあったのだが、実際にはそう単純に工程や成果物が区切れるわけでもなく、結果的には、作業内容の一部は、仕掛かりとしてBSに計上され、不採算案件の隠れ蓑に使われたりしてしまう。また、長期案件は中小企業にとっては、最終的な売上は大きくても、完成までのキャッシュフローを悪化させる要因になり、技術があっても財務的にリスクを負えない企業は、下請に甘んじざるを得ないことになっていた。
なんで、これがADRのカテゴリのエントリかというと、この仕組みにより、SIerと発注元との間の紛争が減るあるいは、泣き寝入りがなくなってくるのではないかと考えるからである。
SIerにいて元請けおよび発注元になった経験からだが、発注元の場合は、業務は定義できていても、それをシステムに(そのパートナーを最大限活用して)効果的に落とし込む方法を定義するのは結構面倒くさい。あるいは、それもできないかもしれないし、心の中では、ベンダーの持つ(であろう)ノウハウで、自社業務をBPR的に効率化してもらっちゃおう!と密かに思っている可能性もある。一方、受託する元請けは、受注しなければ始まらないので、多少の不明確な要素が見えていても「なんとかしますよ!」というふところの深さをアピールして、請け負ってしまう。どちらの思惑もよくわかる。しかし、その通りに事が運べばいいのだが、実際には、発注元は要求の定義の段階で、社内抵抗との調整や統制がうまくいかなかったり、見えていなかった事情などがわかってくるし、受託側では「なんとかしますよ」の範囲でこなす事自体が、存在価値の一つだったりするので、途中の段階で当初見積より費用がオーバーしつつあっても、「最後には一気に挽回!」という根拠のない英断で、
?折り合いのつかないコストをかけ、しかも、
?機能を果たさない(あるいは中途半端に果たす)システムが、
?納期を遅れてでてきてしまう
という三重苦の結果、経営レベルでは、かかった分は支払ってくれという受注者と、完成しないのだから払えないという発注者が、紛争に突入している場合も少なくないと聞く。
ADRという視点から見ると、進行基準の導入は、経営レベル(会計)で把握しにくかった仕掛かりの期間を適切に把握し、不採算状態や工期の遅れ、当初仕様との食い違いを、経営レベル(会計)の目で、早期に発見し、対処してしまおうということなのだ。
紛争のタネを蓄積、熟成してしまい、爆発的な紛争にしてしまう前に・・・・
2009年4月から、受託ソフト開発に工事進行基準の適用が始まることになった。簡単にいえば、これまでの「開発物が完成し、納品・検収を受けて売上として認識、計上される=完成基準」から、「事前に定義した工程などが予定通りに進んでいれば、売上、原価として計上できる」というもの。当然、開始前に仕様や工期を明確にする必要も出てくるし、「システム一式」といったある意味であいまいな契約ができにくくなる。
はるか昔の毎月清算する受託契約に似ているような気もするが、出来高による契約ではないので、工期ごとに、あらかじめ見積で合意した内容と金額がキチンとした出来上がりや進行のチェックのもと、計上され、支払われるということになるということだ。これまでも、分析、概要設計、機能設計など、工程別の納品物の検収を行う契約の仕組みはあったのだが、実際にはそう単純に工程や成果物が区切れるわけでもなく、結果的には、作業内容の一部は、仕掛かりとしてBSに計上され、不採算案件の隠れ蓑に使われたりしてしまう。また、長期案件は中小企業にとっては、最終的な売上は大きくても、完成までのキャッシュフローを悪化させる要因になり、技術があっても財務的にリスクを負えない企業は、下請に甘んじざるを得ないことになっていた。
なんで、これがADRのカテゴリのエントリかというと、この仕組みにより、SIerと発注元との間の紛争が減るあるいは、泣き寝入りがなくなってくるのではないかと考えるからである。
SIerにいて元請けおよび発注元になった経験からだが、発注元の場合は、業務は定義できていても、それをシステムに(そのパートナーを最大限活用して)効果的に落とし込む方法を定義するのは結構面倒くさい。あるいは、それもできないかもしれないし、心の中では、ベンダーの持つ(であろう)ノウハウで、自社業務をBPR的に効率化してもらっちゃおう!と密かに思っている可能性もある。一方、受託する元請けは、受注しなければ始まらないので、多少の不明確な要素が見えていても「なんとかしますよ!」というふところの深さをアピールして、請け負ってしまう。どちらの思惑もよくわかる。しかし、その通りに事が運べばいいのだが、実際には、発注元は要求の定義の段階で、社内抵抗との調整や統制がうまくいかなかったり、見えていなかった事情などがわかってくるし、受託側では「なんとかしますよ」の範囲でこなす事自体が、存在価値の一つだったりするので、途中の段階で当初見積より費用がオーバーしつつあっても、「最後には一気に挽回!」という根拠のない英断で、
?折り合いのつかないコストをかけ、しかも、
?機能を果たさない(あるいは中途半端に果たす)システムが、
?納期を遅れてでてきてしまう
という三重苦の結果、経営レベルでは、かかった分は支払ってくれという受注者と、完成しないのだから払えないという発注者が、紛争に突入している場合も少なくないと聞く。
ADRという視点から見ると、進行基準の導入は、経営レベル(会計)で把握しにくかった仕掛かりの期間を適切に把握し、不採算状態や工期の遅れ、当初仕様との食い違いを、経営レベル(会計)の目で、早期に発見し、対処してしまおうということなのだ。
紛争のタネを蓄積、熟成してしまい、爆発的な紛争にしてしまう前に・・・・