いろいろやってみるにっき

てきとーに生きている奴の日記

https化に伴い、表示できなくなっているリンクについて修復中。
2018年から遡って修正し、2015年分まで修正完了。


ソフトウェア開発現場で厳密な原価計算が難しい理由

興味深いツイートが流れてきた。

 

原価計算についてはかつて原価厨を引き合いに書いた。

shigeo-t.hatenablog.com

 

ソフトウェア開発現場で厳密な原価計算がなぜ難しいかを勝手に補足してみたい。図を再掲しておく。

https://cdn-ak.f.st-hatena.com/images/fotolife/s/shigeo-t/20140508/20140508152536.png

 

ソフトウェア開発において大きなウエイトを占めるのは労務費である。そしてウエイトが低いのは材料費である。

 

一方、ツイートにも出ているが製造業はまず材料費のウエイトが大きい。機械化度が高ければ労務費は下がるが、ラインに人が並ぶような製造業の場合は労務費は大きい。また、製造をしていくために掛かる経費も無視できない。

 

製造業の場合、材料費は直接材料費も間接材料費もきっちり原価計算を積上げていく。原価におけるウエイトが大きいので、価格を簡単に変えられない製品の場合、利益の増減に直結するからである。場合によっては赤字もある。大量生産する製品、多品種少量生産するが合わせると大量になる製品の場合、ちょっとしたブレが大きく増幅される。しっかり原価計算するのは当然である。また、材料の場合は物によるが基本的に品質が大きくブレることはない。品質が大きく劣る材料を調達した場合、その調達担当はかなり責められることになる。

 

労務費は自動車製造などのようにラインに人が並ぶタイプの製造業と、鉄鋼業などのようにほぼ機械が製造して人は制御・監視がメインで少人数の場合では原価に占めるウエイトが異なるが、基本的には製造工程に対して労務者の寄与率は高い。基本的に製造工程のラインに並ぶ労務者や、制御・監視、検査に従事する労務者は他の作業はあまり行わない。企画や設計、製造側で管理するオフィスワーカーの労務費については一製品で見ればウエイトは大きくないことが多い。

経費も材料費と同じように直接経費も間接経費もきっちり原価計算を積み上げる。原価におけるウエイトが大きいので、価格を簡単に変えられない製品の場合利益の増減に直結するからである。

 

さてソフトウェア開発の場合はどうだろう。多くの場合材料費はほぼ考えなくて良い。材料費が大きいウエイトを占めるのであれば、ハードウェア等の開発に伴うソフトウェア開発であって、純粋なソフトウェア開発とは言えないだろう。

経費もあらかじめ稼働人員数やオフィスの費用などである程度ブレが無い。頭数で配賦すればいい。失敗プロジェクトなどで人を急に大人数集めたりすると面倒だが。

 

難しいのは労務費である。労働集約型産業なので労務費のウエイトは大きいが、難しいのは製造工程に対する寄与率である。オフィスワーカーの場合は難しい。プロジェクトやプロダクト全体で見た場合は各担当者はプロジェクトやプロダクトに対してある程度の寄与率に収束するはずであるが、製造業のようにアクティビティレベルに落として寄与率を考えるととても面倒である。まず担当内容によって寄与率が変わる。担当者は寄与率が高く、管理業務の多寡でソフトウェア開発作業そのものに対する寄与率が下がる。直接労務費と間接労務費の割合が人毎に変わるので、それをそれぞれアクティビティ単位に算出して積算していくのが大変である。

活動原価会計の研究―ABC・ABMアプローチ

活動原価会計の研究―ABC・ABMアプローチ

  • 作者:吉田 康久
  • 中央経済グループパブリッシング
Amazon

 

結局、ソフトウェア開発の場合労務費の原価計算を厳密にやっても、積算してみるとプロジェクトやプロダクト全体でざっくり計算したものと大差ない。逆にアクティビティレベルに落とした原価計算にコストを掛けることになるので、その算出のためのコスト分の作業増加損が発生する。

 

というわけで「ソフトウェア開発現場で厳密な原価計算が難しい」というか、単に徒労なので毎回やるべきではないという話になる。と言っても、何が問題かわかんないけどコスト掛かってるよと言う場合は一度アクティビティレベルまで細分化してみるべきではあるが。毎度やることではない。問題が抽出できたらそこを排除してあとは謎の問題が出ない限りグロスでいい。