オルタナティブ・ブログ > データイズム >

記録するジャーナリズムから、測って確かめるデータイズムへ

IFRSでSI案件の工事進行基準は廃止?ソフト開発と建築の違いと類似点

»

「坂本君、システム開発もあの高層ビルの工事のように鉄骨をもう組んで、だいぶできているとか見えたらいいのにねぇ。」そういうつぶやきが、今も耳に残ります。もう、15年以上昔のプロジェクトマネージャーの言葉です。当時、私は、メインフレーム・COBOL・CICSというガリガリの伝統的な枠組みでクレジットカードシステムの開発プロジェクトに参加していました。協力会社と一緒にシステムを作るのですが、私自身も仕様書だけでなくプログラムコードを書いていました。

巨大な情報システムはベースとなるシステムを元に要件を定義して追加開発の仕様を決めて、そこから作りこみに入るというウォーターフォール型の開発を取っていたのですが、カンカン叩いて作る工程に入っても、「柱の数を変えよう」「窓がもう一つ欲しい」とかいうくらいに相当するような仕様の変更というか、要件定義の不足というか、そういうことが起きていました。ソフトウェアとか情報システムだと、ちょいちょいと直せるように見えてしまうけど実はそうもいかないと、建築工事のように見えたらいいのにという心からの言葉でした。
工事進行基準とは「長期請負工事契約に関する会計上の収益認識基準の1つ。」であり、工事完成基準と対になる言葉です。建築とかでは工事進行基準が原則で、半年かかる工事の進捗にあわせて検収と支払いを徐々に行います。請負会社は費用が発生した都度早めに資金を回収できるので、完成基準よりは資金繰り的に望ましい支払い形態となります。

建築は、積算で見積もりが細かくでて、どこまで進んだからとか、説明がしやすいという特性があります。もちろん手抜き工事とかありえるわけですが、最後まで仕上がらないとその「仕事の良し悪し」が判断つかないなどということはあまりなく、工程のチェックやら検査やらで判断がつきます。タコマの吊り橋が完成後直ぐに壊れたとかいうような事件は稀です。

一方、ソフトウェアの受注制作では、できたものが本当に使えるか?とかあいまいな部分を多く残します。工事が終わってから本当に使えるか、ストレステストとかをやって確認してから使うとかいうのは、建築の世界ではあまり考えられないことでしょう。、そういう懸念を感じていたら、東葛人的視点で「【Watcher】IFRSで工事進行基準は廃止? ITベンダーを悩ます話の深層」というニュースを知りました。物理的に結果が積みあがる建築とソフトウェア開発は違うので、恣意的な操作をしやすくてよくない というしごくまっとうな結論になりそうだと思います。

とはいえ、IFRS(国際会計基準)に振り回されて、それで実際に適用できないとかなるとその徒労はすごいだろうと思い巡らします。ただ、そういうとり組にプラスの面があるというのは救いです。

仮に工事進行基準を止めるような事態になった場合、ITベンダーの適用のための努力は何だったのか。私はそれでも大きな意味があったと思う。なんせ危ない会計処理なものだから、正しい売上や利益を計上するために、事前にSI案件の収益総額を確定し、原価総額を正確に見積もったうえで、精緻なプロジェクト管理が要求された。

より精度の高いリソースプランニングがされ、デスマーチプロジェクトが減ることに役立ったとしたら、とてもいいことなんじゃないでしょうか。

巨大システムの開発は「地図に残る」ようなものではありません。しかし、確実に一人一人の身近で役立つ、建築と同じように大事なものです。見えないかもしれないけど大事なこととして、誇りと自信を持たれて、「手戻り」という辛いことが減ることを祈念して止みません。

>>>>>> ポツポツとTwitter 始めました。お気軽にフォローください。
http://twitter.com/sakamotoh

お断り:
本ブログでの坂本英樹による投稿やコメントは、あくまで個人の主観に基づくものです。現在および過去の勤務先の意見や見解を表すものではありません。

Comment(0)

コメント

コメントを投稿する