工事進行基準（その６） システム開発の大きな危険性

受託システム開発の原価計算に「個別原価計算」を用いる、と書いた。

個別原価計算では、元来、作番管理上、しっかりした要件定義、
しっかりした原価見積もりが必要だ。

重ねて言うが、要件定義をはっきりさせ、
しっかりした見積もりをすることと
作業進行基準とは本来関係ないのだ。

さて、工事の進行具合によって売り上げを計上する「工事進行基準」が
受託システム開発において「大きな危険性をはらんでいる」とは
どういうことか。

一般の公共工事や土木工事では、もともと赤字で受けたものなら別だが、
黒字のつもりで受けた作業が、作業の内容も条件も全く変更がないのに、
突然赤字に陥ると言うことはまずないだろう。

それは、できないような工事条件で発注されることは無いからだ。

もし当初指示された作業条件ではできないとすれば、
それは作業指示が間違っていたと言うことであり、
作業内容や条件を変更して当然のようにそれに基づいて
手戻りや仕損なども勘案した上で、
契約金額の変更（多くは追加だろうが）が行われるはずだ。

しかし、受託システム開発の場合はそうではない。
土木工事や建設工事と違って、作り方までは指示されないというか、
要件定義の中には入らない。

土木工事や建設工事であれば、どういう部材をどういう風に使い、
どういう工法でやるかを事細かに決めることができる。

しかし、システム開発の場合、
要件定義はシステムの機能や性能であり、
工法やツールの指定もされることはあるが、
だれが作っても同じもの（ソースコード）になるとは限らないのだ。

ソフトウェアは、機械を使って作るものの、
すべて手作りと言っていい。

コーディング、つまりプログラムソースは、
同じ機能を実現しようとしても、
設計し作成するシステムエンジニア、
プログラマによって異なるものになる、
と言うか同じものにはならない。

当然ながら作る人によって性能にも差が出るし、
バグと呼ぶ不具合の程度も違ってくる。

また、要求性能が当初思っていたほど簡単には実現できず、
手を入れるのに膨大な労力がかかったり、
作り直しになってしまうことも少なくない。

黒字のはずの作業が大赤字になることはしょっちゅうだ。
そしてその赤字の額は大型作番、
つまり受注額の大きいものほど大きくなる傾向がある。

ここに工事進行基準の落とし穴があるのだ。
それについて、詳しくは次回、、、。

＊＊＊

「プレＳＥ奔走す」　ISBN4-434-07543-8　1200円
セブンアンドワイ
楽天ブックス

その他オンライン書店で。

紀伊国屋（新宿）、ジュンク堂（池袋）には店頭在庫もあります