社内フレームワークが不要だと思う理由 #名前を挙げずに社内フレームワークの欠点を晒せ

#名前を挙げずに社内フレームワークの欠点を晒せ をまとめた - Togetter #名前を挙げずに社内フレームワークの欠点を晒せ をまとめた - Togetterの内容が思ったよりも好評なので。

Strutsを拡張したりして社内フレームワークとして使用している会社は多いです。
タイトルのとおり、私は社内フレームワークに関しては不要だと考えています。
その理由に関して以下に四つほど延べます。

使用者が少なすぎる

社内フレームワークの最大の欠点は使用者が少なすぎる事です。
そのため、OSSのソフトウェアに比べると熟れるまでに時間がかかります。
作成されてから2年でも、その間に100人に使われるか、1000人に使われるかではその後の使いやすさについては天と地の差が生まれるでしょう。

保守コストがかかる

ソフトウェアの作成にはお金がかかります。
一人が一ヶ月働くだけで一〇〇万円程度は諸費用としてかかるでしょう。
フレームワークを一度作ってしまえばそれ以降は費用がかからないと考えている方もいらっしゃるようですが、ソフトウェアですからバグは出ます。
また、使いにくいこともあるでしょう。
それらの修正費用は自分たちで賄わなければいけません。

社内政治の生贄になる

仮にあなたの上司がそのソフトウェアを作った場合に使いにくいと言えるでしょうか。
多くの人は文句を言えず、使いにくいまま使われることになるでしょう。

肥大化する

運よく、保守費用が賄われたとすれば、それは幸いなことと共に不幸なことです。
支払われた費用に対してフレームワークの製造部隊は結果を出さなければいけません。
そうすればいつの間にかそれほど使われない機能が増えるかもしれません。
しかし作ってしまえば保守をし続ける必要が出てきてしまい余計なコストが発生することになるでしょう。*1

どうすればいいか

さて、ここまで書いて、このままだと単純にdisるだけになるので仮に社内で標準的に作るべきものがあるならということを1つだけ記載します。

サービス提供側でプログラマブルな機能を提供する

言葉にすると当然のように聞こえますが、新規システムを作る場合に、既存のシステムとの連携について新規システムの責任で構築するということはないでしょうか。
もしくは、新規システムを作るたびに既存システムを毎回カスタマイズしていくとか。
本来それは非常によくないことだと思っていて、既存システム側はある程度の利用のされ方を想定して、利用する側が勝手にカスタマイズすることが出来るようにシステムを構築するべきだと思っています。

いわゆるSOAの考え方です。

Twitterなんていい例ですね。

ほとんどの機能に関してRESTfulにアクセスすることが出来、自由に組み立てることができる。
もちろん、Twitter程度の柔軟さをもったインターフェースを作成するのはコスト的に無駄だと思うので、実際には機能を絞る必要があると思いますが、とりあえず、社員のデータベースはすべてのシステムで必要だと思うので、社員の情報を簡単に取り出せるようなシステムとかは必要じゃないでしょうか。
これを社内フレームワークというのか?と言われれば広義では社内フレームワークだとは思いますが、このように"誰でも使えるように"構築されたシステムを閉じた世界では自分は見たことがありません。

*1:YAGNIの原則に反します。