SIerがソフトウェアの再利用ができない理由

　ソフト開発の効率化は会計処理改革から（修正版） - プログラマーの脳みそではソフトウェアの再利用をしようよ、その価値をちゃんと管理しようよというごくごく単純な主張を行った。

　そしてこれを現在のSIerができていないことにたいする言い訳はおおむね経営者が自社ライブラリの開発に予算を割きたくない理由 - 売り切れましたで述べられている通りである。

固定資産税

　１億のプロジェクトが２本あって、それぞれの予算から2000万、つまり合計4000万わりあてて「今後も使い回せるライブラリ」を作るとすると、当然、資産計上しなければならなくなる。

　予算はすべて人件費とし（つまり全額が資産として計上され）たうえで、当期内にライブラリが完成した場合、法人税率を小さめに３０％程度とみてもライブラリに対する課税額は1200万となってしまう。

経営者が自社ライブラリの開発に予算を割きたくない理由 - 売り切れました

固定資産税は1.4%ではなくて？4000万円に対する1.4%で56万円が税額なのでは。

ソースコードの所有権

　ソースコードの所有権を客先に渡すとしている場合、再利用ができないというのは指摘の通り。このあたりは契約の仕方次第なのだが、内正のミドルウェアの部分のソースコードの所有権は渡さない、そしてミドルウェアを使うことでのメリットを納得してもらうということになろう。

　というかソースの所有権「全て」を渡すことのデメリットを説明せず、高い金額で低品質なシステムを納品していた場合に、それを客先に説明できるだろうか？受注金額を釣り上げるために「ソースの所有権を全て渡す」という条項を敢えて飲んだんだろう、と言われた時に釈明できるだろうか？

採算云々よりもお客さんに堂々と言える？「今回の開発費用のうち？？？？万円は自社ライブラリ作成に充てさせていただきます」って。

経営者が自社ライブラリの開発に予算を割きたくない理由 - 売り切れました

　開発費の見積もりにXXXX万円を弊社のミドルウェアのライセンス費用に充てます、と堂々と書けばいい。

　そして「それはだめだ」という顧客には「ではミドルウェアより機能的に劣り、品質も劣るものをXXXX万円で独自開発します。そしてそのために工期はこれだけ延びます」と説明すればいい。それでもそっちを選ぶという客がいるならそうするより仕方がない。客先のその決定をした人が背任に問われる可能性があるが、それはこちらの知るところではない。

プロジェクトの経理上の扱い

プロジェクト単位で予算を割き経費を計上するという経理システムしか存在しない会社に、再利用されるライブラリの作成や回収に予算をよこせといっても、扱いにほとほと困るわけである。

おそらく暗黙に「プロジェクト＝受注」としているのだろうが、それ以外の経費計上ができない経理システムなどあり得ない。

　ここでは「システム」をプログラム的な意味での「システム」と誤解させてしまった。私の「プロジェクト単位で予算を割き経費を計上するという経理システムしか存在しない会社」の文脈でいった「システム」はプログラム的な狭義の「システム」ではなく「仕組み」といった意味合いの広義の「システム」だった。「会社としてそのような経理処理しかしていない」というところに、新たにこういう経理処理をしてください、と言って内規やらなんやら整備するのが大変なわけで、そうした（もちろん広義の）「システム」を作り上げるには労力も時間もかかる。

　もちろん経営層の理解を得て許可をもらう必要もあるだろうし、経理の人にも説明した上でそのプロジェクトの扱いを考えなくてはならない。

　だが、その労力をかけて時間をかけて

じゃぁ「ライブラリ開発プロジェクト」を立ち上げれば良いだけ。

　が出来たのならば、その時点で「ソフト開発の効率化は会計処理改革から」というタイトルにある「会計処理改革」がある程度できていると言える。

そして管理会計でこっそり予算割りしてしまえば良い。

という下りで言う管理会計の仕組みを整備する労力が、このような管理ができない理由だと私は考えている。そもそもこういった改革は平社員が言い出したところで実現は難しい。トップかそれに近い立場の人が旗を振らないと実現は難しいだろう。

ソフトウェアの再利用性

それでもなお予算が割かれない理由は「プログラマーですらクライアントにメリットを説明できない」ところにある。

　この意見には私は懐疑的だ。ミドルウェアの利用のメリットが説明できないような事象だろうか？有償のライブラリの利用が説明できないのに有償のRDBMSだとか有償のフレームワークだとかのミドルウェアの利用を説明できる道理はない。

このような考え方から脱却したうえで

　の下りは、当然ながらその手前の引用部分を否定しているのだろう。私はソフトウェアの再利用性については簡単に説明するために機械を例に、できないはずの複製ができると方便を用いて述べた。もちろん、そのままもってきてコピーで使えるわけではないが、かといって再利用は不可能だと考えているのだとしたら、その人のプログラミング能力を疑う。*1

　構造化プログラミングからオブジェクト指向といったように、この20年でこうしたソフトウェア工学の成果が実用化されてきた。もちろん、オブジェクト指向が万能なわけではなく、補うようにジェネリクス指向やアスペクト指向が浸透してきている。

　これらに対応した言語を採用すれば直ちにソフトウェアが再利用できるわけではない。結局のところ、ソフトウェアの再利用性を高めるには、再利用性が高くなるように設計できる技術者が必要だ。そして、その人材不足がライブラリ化という目新しくもなんともない高品質・低価格化手法を実現できないでいる理由だと言えよう。

まとめ

• 管理会計の仕組みを整備する労力が実施の際の障壁
• 再利用性を高めたソフトウェア設計ができる技術者がいないことにはどうにも実施できない

*1:この下り、私のプログラミング能力を疑うがゆえに「そんなに簡単じゃないよ」と言っていると言うのなら、結局のところ私と同意見だと言うことになる。