結局のところ名のあるフレームワーク、ツール、製品を使うのが一番なのかも

今のプロジェクトはいわゆる内製でクローズドなフレームワークを２つ使っています。いつごろ作られたかはわかりませんがどちらも製品化はされていません。内容はというと１つはExcelをもとにStrutsのActionやstruts-config.xmlを自動生成するEclipseプラグイン。つまり開発者は主にロジックをコーディングする。もう１つはExcelの仕様書をもとにボタンを押すとDBアクセス周りを自動生成するというもの。どちらもコンセプトはそんなに悪くないと思う。Strutsが出てきてORマッパーがまだそんなにメジャーじゃなかった2002年くらいだったらそれなりに効果的だったんじゃないかな。ただいまとなってはちょっと古びているのは否めない。使う前に経験者からヒアリングしたときもあまりいい印象は無かったように思う。使ってみて確かにいまいちな部分がある。ただフレームワークの開発者に訊いてみると「そんなことないよ。あれ、いいじゃん。」みたいな答えが返ってくる。これはやっぱりフレームワークを熟知している人とそうでない人のギャップが大きいということなのだろう。そう聞いて僕も少し腑に落ちた部分がある。僕は静的解析ツールを担当していて製品自体はそんなにわるくないと思ってた。でも、実際の現場では全く活用されていないし（というか僕自身も使って無かったｗ）、客先にプレゼンにいっても反応は薄い。まあこれは僕の能力不足か。。。またちょっと話は変わるが以前のプロジェクトで親会社のAPサーバ、DBサーバを使うことになった。まあ親会社向けの案件なのでしょうがいないかなとおもったけどこれが使いにくい。というかマニュアルがわからんｗ　warファイルのデプロイ方法がわからなかったｗ　これは製品なのだがWASやOracleといった有名どころと比べると知名度はかなり落ちるのでググれない。ググれない上にマニュアルが読みにくくしかも気軽に質問できる場所が社内に無い。まあ自社製品（親会社のでもいいけど）だからといってその会社にその製品を熟知している人がいるかというと別問題ですよね。売れているものならサポート体制も充実してると思いますけど。同じことは内製フレームワークにもいえる。ググれないっていうのは使う側からするとかなり致命的だと思う。ググれない上に実際に使う協力会社の人がアクセスできないイントラの場所にドキュメントが置いてあったりするとほんと申し訳ない気持ちになる。で、結局のところ名のあるフレームワーク、ツール、製品を使うのが一番なのかもって僕はまあ思ってるわけです。ただ実際には内製フレームワークを使っている人は少なからずいるわけです。で、どんなフレームワークを使うにせよログ、例外、認証といったプロジェクト特有の共通基盤は作る必要があります。ちなみにこのプロジェクトでは共通基盤はフレームワーク開発者が作ったそうです。まあフレームワーク開発者がかなりべったりとプロジェクトに張り付かないと回らない気はします。ただ最初はうまくいってもエンハンス時にはメンバーが替わってくるので開発が難しくなってくるんじゃないでしょうか。そんな現状がありますけど内製フレームワークも協力会社の人が気軽に質問できる状況があるならまだありなのかなと思います。どうせ作るならオープンソースでっていう気はしますけど、まあ難しいかな。