採算のとれないライブラリに客が金を払うのか？
おいしい商売だ！
開発費の見積もりにXXXX万円を弊社のミドルウェアのライセンス費用に充てます、と堂々と書けばいい。
SIerがソフトウェアの再利用ができない理由 - プログラマーの脳みそ
すばらしい！
そもそもSIer的な仕事はプロジェクト単位で採算を考えるわけで、プロジェクト単体で採算が取れないライブラリを作ることは通常出来ない。
ソフト開発の効率化は会計処理改革から（修正版） - プログラマーの脳みそ
プロジェクト単体で「採算がとれない」＝「かけたコストに見合ったメリットは得られない」と説明した上でクライアントに請求する。
コレができるなら無敵の商売だ。
ライセンス料と聞くとまるですでにライブラリ（ミドルウェア？）が存在しているかのように聞こえるが、その実は
となりのプロジェクトでも必要とされている機能があったとき、その部分だけ括りだして双方のプロジェクトから予算をひっぱってきて潤沢な資金で高機能に仕上げる
ソフト開発の効率化は会計処理改革から（修正版） - プログラマーの脳みそ
と、書かれているようにプロジェクトが始まってから作り始めるものだ。 （少なくとも最初の一回は）
そんな見積もりにＯＫを出す客がいたとすれば、それこそ
客先のその決定をした人が背任に問われる可能性がある
SIerがソフトウェアの再利用ができない理由 - プログラマーの脳みそ
いやいや。 筆者もそういうことが言いたかったんじゃないだろう。
さすがに提供価値以上のコストを払えと言われて納得する客はいない。
「ソフトウェアの再利用を他の生産設備の再利用と同様に考えたうえで、日々のプロジェクトの中で計画的にライブラリの整備を行うべき」と言いたいんだろう。
計画的に、という話には同意できる。
その方法の一つとして、明示的に予算を割り当てて管理すべきだと。 それは同意しかねる。
方法としてはイマイチだ。
文中では「ライブラリの作成や改修に予算をよこせ」と言っているが、本当にほしいのはお金ではなく労力と時間だろう。
であるならば経営層の同意など得る必要は無い。 プロジェクト単位で採算を見ている会社であれば、人員配分についてはプロジェクトマネージャに一任されているはずだ。
つまり２プロジェクトで共通利用するプログラム部品を作りたければ、両プロジェクトのマネージャが合意すればそれで事足りる。
経営層からすれば「そんなこといちいち俺らに言わなくていいよ」という程度だ。
いやいや、会社の資産としてちゃんと管理していこう！ と言いたいのだろうか？
本当？ 本当にいいの？
まず、
有償のライブラリの利用が説明できないのに有償のRDBMSだとか有償のフレームワークだとかのミドルウェアの利用を説明できる道理はない。
SIerがソフトウェアの再利用ができない理由 - プログラマーの脳みそ
と書いているように、自社開発ライブラリをミドルウェアと同等とするなら、「プロジェクト単体では採算が取れない」という言葉で本当に言いたかったことは「ライブラリの開発コストとライセンス料の差が大きい」ということではないのだろうか？
Oracleのライセンス料でOracleを作れるはずがない。
客に「ミドルウェアのライセンス料として１００万円いただきます」と言う場合、そのミドルウェアの開発にかかるコストはその１０倍以上だろう。
そのコストをプロジェクト予算から捻出しようとするから「採算が取れない」のだろう。*1
もしそうなら話は通じる。
経営層としては社内ライブラリの商品価値について勘案した上で、プロジェクトを口実にライブラリ整備の追加予算を要求すれば良い。
予算が組める組めないは筆者の言うように
管理会計の仕組みを整備する労力
SIerがソフトウェアの再利用ができない理由 - プログラマーの脳みそ
の問題（もしくは経営者の能力の問題）だろう。
再利用によるメリットが高いか低いかは「プログラミング能力」に左右されるだろう。
話をもどして。 そうやって作ったライブラリを資産として管理しちゃっていいの？
ライブラリを作成し、ライセンス料を１００万円に設定したとしよう。
次のプロジェクトからは見積もりを１００万円プラスするの？ 最高だ。 そのライブラリにはOracleのStandardEdition以上の機能と品質があるということか。
そうじゃない？ 受注金額のうち１００万円をライブラリのライセンス料とする？
なるほど、つまりその分だけプログラマーは少なくて良いわけだ。
きつい？値段を下げる？ じゃあいくら？ 開発にかかったコストがペイできるまで何回プロジェクトをこなせばいいの？ ライブラリの維持費も勘案してね。
経営者からすると「資産として管理し活用する」とはそういうことだ。
プログラマーにとって何かおいしいことでもあるのだろうか？*2
結局
実際、SIをしながら共通利用できる部品ができあがっていき、最終的にそれが単体で製品となることはある。
しかしそれを計画的に行おうとすると、結局はパッケージソフト開発と同じようなリスクを背負うことになる。 しかもマーケットは「自社開発プロジェクト」にしかないとなると、そう簡単にＧＯが出せるものではない。
プログラマーにとっては当然、経営者にとってもハイリスクローリターンだ。
だから「プロジェクト間で使い回す」程度のライブラリ開発なら、わざわざ「管理会計！」なんて面倒くさいもの持ってこないでエンジニア個人レベル（もしくはチームレベル）で研鑽すればよく、むしろ経営者に見つからないようにこっそりいいものを作ったほうがよっぽどハッピーになれるじゃないか。*3
