持たないのではなくて持てないのかも知れません。
ソフトウェア技術者をたくさん抱えているのなら、自社の独自のライブラリを持つべきです。
Cランタイムのfopen()とか、CreateFile()を直接呼び出すようなコードを書いてはいけません。
どんなプラットフォームでも同じようにかけるラッパーライブラリかラッパークラスライブラリを自社で開発しなければなりません。
いろんなプロジェクトから社員をかき集めて新規プロジェクトを作る際に、同じライブラリの使用経験がなければ、それは同じ会社の社員である価値が全然ないからです。
もちろんプラットフォームごとの差異は必ずあるので、カンペキなラッパーはかけません。そりゃそうです。
ですが、fopen()で書いてあるものをひたすらCreateFile()に書き換えたりするのが、利益率の高い仕事でしょうか。
SQLの良いところは、DBMSが変っても、大部分のSQL文の書き方は流用可能な点です。DBMSごとの差異はストアドプロシジャや、管理スキームに集約されます。
その他のプログラミング言語でも同様であるべきです。
ファイルIOとデータベースアクセス部分のラッパを一式持つだけで、社員のスキルの交換性はすこぶる上昇するでしょう。引継ぎコストもとてつもなく引き下げ可能です。
社内ライブラリのメンテのためだけの専用要因を抱えても充分元が取れます。
その部署は、そのままコンサル業務で即戦力となります。既存プロジェクトを社内ライブラリでリライトするだけでバグ低減、性能向上、クロスプラットフォーム化が可能だからです。
まともな会社はそのようなライブラリを必ず持っています。もっていない会社は、いつもやっつけ仕事です。半年か一年単位で仕事を回していたら、やっつけ仕事になるのは当たり前のことです。
社内ライブラリへに取り込まれる機能をたくさん作ったプロジェクトには報奨金が出ます。流用性が高まるからです。
ある会社向けのプログラムをそのまま競合他社のプログラムに流用したら、コンプライアンス的にＮＧですが、利用可能なライブラリを水平展開しても誰も文句は言いません。
お分かりでしょうか。
コメント