内作フレームワークが持つリスクを考慮すべきですよ＞某大手 SIer さん
大手（ばかりではないでしょうが）SIer さんがたまにやる、どこにも公開していない内作フレームワーク（今回は、Java の Web アプリケーション用のものを念頭におきます）でプロジェクトをすすめるのはこういうリスクがあるんですけど、考慮してますか？ っていう話です。
わざわざ書くってことは、考慮してない現場をまのあたりにしてるからなわけですが。
名の知れているフレームワークと言うとまずは Struts ですね。名が知れていないものでも、容易に情報が得られるフレームワークはたくさんあります。また、プロの編集者がちゃんと編集・校正して、しっかりと製本されたそれらの参考書も手にはいります。
いっぽう、内作のフレームワークについて、それを使わされる下請けさんなどの立場で見るとどうでしょうか。
- プロジェクトが始まるまで、下手すれば名前すら聞いたことがない。
- プロジェクトが始まっても、なぜか実行環境が提供されない（1ヶ月とか平気でかかっちゃう）。
- マニュアルは、Excel ファイルで、複数に分割されており、検索もままならない。
- たどたどしい日本語でかかれたマニュアル。
- 的を射ていない小見出し。
- なぜか横票。って、これ、マニュアルじゃなくて仕様書ですか？
- もちろん Google 先生は頼りにならない。
客観的に見て、これだけでも「ヤバい」感じがぷんぷんするのはお分かりでしょう。それなのにこれで GO を出させる顧客、JV の他の幹部。
学習コストを負担するリスク
もし、Struts を使うとすれば、人員を手配するときは Struts 習熟者を手配すればいいのです。下請けさんにお願いするにしても、下請けさんが「Struts なら大丈夫」と言えば、もし大丈夫でなかった場合は、下請けさんの責任で学習コストを負担してもらうことができます。
しかし、内作フレームワークを使った場合は、誰しもがゼロです。必ず学習コストが発生します。これの責任は下請けさんが負うものじゃありません。そして、プロジェクトで使い物になるレベルまで習熟にかかる時間がかかろうとかかるまいと、これも下請けさんは悪くないですよ。でなかったら、クソなフレームワークを使って下請けいじめできちゃいますから。
見積り精度が低くなるリスク
大して実績もないフレームワークを使って1画面をどれぐらいで完成させられるかなんてわかりませんよ。「うちは Struts の実績バリバリです！」なんて豪語した下請けさんが、大した仕様変更もないのに見積りを2倍も3倍も狂わせたらそれは下請けさんが悪いですが、プロジェクトが始まるまで見たことも聞いたこともないフレームワークで見積りするのなんて、はっきり言って無理です。不可能！ インポッシブル！ 当てずっぽうにしかなりません！
また、多くの人に使われ、もまれてきたオープンソースのプロダクトや、Microsoft の Visual Studio クラスの開発ツールに比べたら「仕様の正規化」の度合いが低いので、客観的に見ると統一性のない使い方が多い場合が少なくないので、「慣れたら開発効率が上がるか」と言われたら、No です。それほどあがりません。
メンテナンス性が低くなるリスク
これが一番の大誤算！ メンテナンス性を求めて内作フレームワークを使ったはずなのに、こんなリスクが！ これはどういうことかというと、結局一番問題を起こすのはフレームワーク側なんですよ。結局、業務ロジックなんて、どんなフレームワークを使っても書き方は同じです。変わってくるのは、ユーザインタフェースや通信、データの永続化まわりでしょう。しかし、このへんのノウハウを持っているのがごく一部の内作フレームワーク開発者に限られるわけです。当然 Google 先生なんて当てになりません。誰にも聞けないんです。
ということで、もちろん、Struts とかみんな知っているものを使えばまるく収まるかといえばそうではありません。これはこれで別のリスクを伴います。でも、逆に内作フレームワークならすべて丸く収まるという発想も捨てるべきでしょう。
営業トークにはいいことばかり挙げるわけですが、つられて開発側もなんのリスクもないと思い込んでしまうのはアホすぎます。
