建物と違って、一見簡単に修正が利きそうなのがソフトウェアの問題点かな、と

　これを読んで、「SIerの仕事って『工事』だったのかあ」と思った人は私だけではないはず。

これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」を取るケースが多かった。一般的に日本のシステム開発は要件定義やユーザー企業との契約が明確でなく、開発中の手戻りや期間の超過が多い...【デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ − ＠ITより引用】

　さらに「工事進行基準」と「工事完成基準」の定義を読むとますますそう思える。

工事進行基準
　長期請負工事契約に関する会計上の収益認識基準の1つ。工事期間中、目的物が完成に近づくにつれて徐々に収益が発生するものと考え、工事の完成度合いに応じて工事に関する収益と原価を計上し、各会計期間に分配する方法である。“発生主義”に基づく収益認識法とされる。【工事進行基準 − ＠IT情報マネジメント用語事典より引用】

工事完成基準
　長期請負工事契約に関する会計上の収益認識基準の1つ。工事が完成し、引き渡しを完了した時点でその工事に係る工事収益を認識し、当該会計期に一括して計上する方法のこと。【工事完成基準 − ＠IT情報マネジメント用語事典より引用】

　ちなみに、私はちょうど家を建てているところだが、必ずしも私が図面から想定した通りに建つとは限らないのが難しい。まあ、私がちゃんと図面を読みこなせていないのも悪いのだが、「あ、ここ思ったのと違うんで少し変えてくれませんか」と頼むと、「できるけど、やり直しになるからお金かかるよ」と言われるので我慢をしたりしている。

　まあ、建物だから「やり直すと高くつく」というのは直感的に分かるのだが、ソフトウェアの場合は、（顧客から見て）一見簡単に修正が効きそうなのがこの「開発中の手戻りや期間の超過」に結びつくのかな、と。

Comments

[とおりスカリー]

建築物だと壊している最中は「壊しているな」という風景が見えるので判りやすいのだけど、ソフトの場合壊すのは一瞬で、何回作り直してもどこにも瓦礫の山は見えない。

実際、内装工事まで進んでる時に「基礎から掘り返してやり直しだね」と言ってもジョークにしか受け取ってもらえない。一方ソフトの場合・・ありえない話じゃないですよね。

[hirono]

ソフトウェアの進行度合いを建築中の建物として視覚的に表示するようなツールとかあれば便利かもしれませんね。
顧客の無謀な要求が出てきたたら、視覚的には完成間際の建物を鉄球でぶっつぶすような表示になるとか。

[ken]

同じような話で聞いたのが、ＣＭ制作みたいですね（もしくは商用映像系一般）。
これも別にトータルにはプラスにはならないクライアントの修正依頼を無料でやっているうちに制作側は儲からなくなる。。。らしい。みんなであーでもないこーでもないとやっているとトータルで良い物になるという妄想から、別に本質的にはどうでもいいお偉さんの「こだわり」で全てがぶちこわしになることも多々あるとか。。。

[titan]

出来高検収が、できるようになれば受注側も予算的に楽になります。検収時の成果物がこれからの課題になりそうですが、作り手側の品質の向上につながる様な物を作ってい行きたいですネ。中間成果物の為にバタバタする様な事は避けたいナー。

[humu]

ソフトウェアの場合「ここちょっと直して」と言われたときに
「ここをこういう感じに直すのでコストはどれくらい，期間はどれくらいです」
と，明確に分析できる人がいないんじゃないでしょうか？

実際にそこの部分を直そうとするエンジニア自身は自分の工数をどれくらいか？
単価いくらとした場合どれくらいか？ というのは出せるだろうが
プロジェクト全体でのマイナスコストとロスする工期，工数はどれくらいになるか？を
責任を持って提示できる仕組みが無いような気がする

[naa]

建築のIT化という事で、ビルディング・インフォメーション・モデリング(BIM)という手法があります。建築のほとんどの要素を3DCADを使ってモデリングするのですが、この方法だと図面を読むのが不得意な人にも、完成型がイメージしやすくなると思います。
もっと普及してほしいモノです。

[cielacanth]

これは本当にそうだと思います。

「建物全体を北に１ｍ動かしてよ。簡単でしょ？」
みたいな依頼が後を絶ちませんし。