ソフト開発の効率化は会計処理改革から（修正版）
ソフト開発の効率化は会計処理改革から - プログラマーの脳みそは途中で半端に書き直したら主張が意味不明になったので書きなおす。
内製ソフトウェアの扱い
まず、ソフトウェアの会計上の扱い。これはソフトウエア会計基準に依る。
基準の内容は、ソフトウエアの開発目的によって異なる。自社で利用するソフトウエアの場合、(1)外部に業務処理などのサービスを提供するためのソフトウエアと、(2)利用により将来、収益の獲得やコスト削減が見込まれるソフトウエアの開発費は「資産」となり、それ以外は「費用」となる。この基準は自社開発したり、ベンダーに委託して開発したソフトウエアだけでなく、ベンダーから購入したパッケージ・ソフトにも適用される。
既存のソフトウエアの改修やパッケージ・ソフトのカスタマイズにかかるコストも、(2)の条件を満たせば「資産」として計上できる。ただし、旧システムのデータを新システムに移行するのにかかったコストや利用者教育にかかったコストはソフトウエアの価値とは無関係なので、「資産」ではなく「費用」となる。
外販目的のソフトウエアは、これとは別の基準で開発費を処理する。ソフトウエア会社の場合、最初の製品マスターの完成までにかかったコストは研究開発にかかったものとみなして「費用」、その後の機能強化にかかったコストは「資産」となる。ここでいう製品マスターとは、「仕様が固まり、機能評価版（ベータ版）でのデバッグが終了した状態のソフトウエア」や、「製品番号が付くなどして製品ラインアップに加わったソフトウエア」、「製品カタログに掲載されたソフトウエア」などを指す。
ソフトウエア会計基準 | 日経 xTECH（クロステック）
社内で独自に作ったものは
の3パターンの会計処理に分かれる。そして、これらの改修や機能拡張に費やした資金は「資産」になる。
SIer的資産管理
通常、プロジェクト単位で資産の管理対象とされる。システムを細分化して資産管理することはされない。そのため、過去のプロジェクトから一部を流用して、ということは会計的な数字としては見えない。これは、ソフトウェアの場合は複製がコスト０でできることに依る。
通常は、ある既存の設備から機械をひっこぬいて新しい設備に流用したとすれば、資産価値を持つ機械の移動したということになる。工場Ａに設置されている機械を工場Ｂに移動して工場Ａがもぬけの殻になったら工場Ａの固定資産の価額は減る。ここで減らないようなら機械を移動させることで機械の固定資産価額分だけ錬金術のように資産を増やせることになる。
ところが、ソフトウェアに関してはそれができる。
これら流用の利くプログラムは共通ライブラリとして複製するほどに価値を生む。なので、プロジェクトの単位とは別に管理して再利用によってそのライブラリがどれだけの価値を生んだか管理するべきだと私は主張する。
管理されていないものには予算を割けない
そもそもSIer的な仕事はプロジェクト単位で採算を考えるわけで、プロジェクト単体で採算が取れないライブラリを作ることは通常出来ない。
となりのプロジェクトでも必要とされている機能があったとき、その部分だけ括りだして双方のプロジェクトから予算をひっぱってきて潤沢な資金で高機能に仕上げるということができない。複製のコストは０なのだから、ソフトウェアは量産効果が劇的に効く。
これは、現場のプログラマには再利用の効果が知れ渡っているが、カネの流れを握っている経理や、経営側の無理解からくる問題だと言える。プロジェクト単位で予算を割き経費を計上するという経理システムしか存在しない会社に、再利用されるライブラリの作成や回収に予算をよこせといっても、扱いにほとほと困るわけである。
冒頭述べたように、内製ソフトウェアは作成段階にかけたカネは「資産」か「費用」になる。以後のメンテナンスは「資産」になる。そうした経理上の管理対象物となるようにしなくては始まらない。管理対象物として識別してその利用実態が明らかになって初めて予算をさくことができるだろう。
利用頻度の高いライブラリは量産効果が顕著にあらわれるから相応の予算をかけることができる。つまり高品質になるわけだ。プロジェクト個別に車輪の再発明をするよりも遥かに効率が良い。
