━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■第19回 工事進行基準
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
前回の編集後記でも触れたとおり、2009年の4月から「工事進行基準」とい
う会計基準が義務付けされます。
（2009年3月に決算期を迎える企業から適用されます）
開発者の中には、あまり関係ないと考えている方も多いと思いますが、実際
の作業にも少なからず影響が出てくると思います。
ちょうど去年の今頃は「日本版ＳＯＸ法」が注目されていました。
「ＳＯＸ法」は、アメリカの上場企業で会計不祥事が相次いだことから、内
部統制の強化を図るために成立しました。
日本でもこの流れを受けた形です。
ライブドアの事件などを見ても、不正会計は大きな混乱を引き起こします。
株主の被害もそうですが、市場、もっと極端に言えば国の信用まで低下しま
す。
●ソフトウェア業界の習慣
そこまで意図した不正会計でないとしても、ソフトウェア業界では習慣とし
てグレーな会計が行われてきました。
例えば、受注することを前提として事前作業を強要したり、作業範囲が不明
確になりがちな一式契約といったものです。
ソフトウェア業界は業界としての歴史が浅いため、建設業界を参考にしてき
たところがある訳ですが、大きく違うのは、建築物は目に見えるが、ソフト
ウェアは完成間近にならないと見えてこない点です。
最近、私の住むマンションの前に新たなマンションが完成したのですが、工
事の着工から完成まで、素人の目で見ても進捗状況がだいたい分かります。
しかし、ソフトウェアでは進捗状況の把握は困難です。
建築物は最初に作成された設計図のまま、ほとんど変更なく進捗していきま
すが、ソフトウェアではなかなかそうはいきません。
要件定義でシステムの全容が見えてくることは少なく、ほとんどのプロジェ
クトでは、開発中でも仕様がコロコロ変わってきます。
完成系が決まってないのに進捗率が決まる訳は無いですよね。
では、この仕様変更で失われた作業量はどこに行ったのかというと、どこか
に消えてしまうのです。
確かに作業はあったのですが、無かったことになります。
無かったことにされた作業の請求は？原価は？
きちんと反映していればいいのですが、これらが曖昧なら株主はどう思うで
しょうか。正確な投資判断はできないでしょう。
こういった背景から、工事進行基準の適用が求められてきており、建設業で
は既に適用も始まっています。
●工事完成基準から工事進行基準へ
ソフトウェア業界では、工事完成基準という会計基準が一般的に使われてい
ます。
間違えやすいのですが、工事進行基準は新たに考えられた会計基準ではあり
ません。
どちらでも好きな方を選択できるため、工事完成基準が業界のスタンダード
として使われてきたというだけです。
どうやら、建設業界を参考にしたようです。
工事完成基準は、工事完成の引渡し日に一括して工事収益を当期損益計算書
に計上する方法です。
簡単に言ってしまえば、完成時に「これまでいくら掛かって」「いくらで売
れたのか」を明確にする方法です。
会計はとても単純なんですが、あきらかにどんぶり勘定のにおいがします。
工事進行基準は、決算期末に進捗度を見積もり、原価や収益を計算します。
これにより、「最後に帳尻を合わせればいい」というやり方ができなくなり
ます。
正確に進捗度を見積もれないと、翌年度に原価が膨れ上がり、大赤字になる
ことだってありえます。
従って、元請けの会社は下請けの会社に正確な原価管理を求めてくることが
予想されます。
これまでどんぶり勘定な下請けをやってきた会社は、大きな方向転換を求め
られ、対応できるかどうかが問われるでしょう。
元請け側も、高い精度の見積もりが求められ、一式契約は消えていくのでは
ないかと思います。
と、いろいろ書きましたが、よくよく考えてみると、本来ならやっていて当
たり前の事でもあるのです。
この機会に、仕事のやり方をイチから見直してみるのもいいのではないでし
ょうか。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━