2008年09月02日

フレームワークには2通りある(後半)

(続き)

現在、開発に使用するフレームワークの選択肢は多種多様ですね。オープンソースとして開発・公開されているものや、SIer達がこれらのオープンソースのフレームワークをラッピングしたりして独自のフレームワークを開発したりもしています。

こういった背景の中、SIerから2次、3次請けする会社のSE・PGが、同じフレームワークを使うプロジェクトに携わり続けるなんてことはほとんど無いでしょう。

例えば、前回はStruts+Spring+iBatis(期間6ヶ月)、今回はフレームワーク無し(期間3ヶ月)、次回はSIer独自FW+EJB3(期間8ヶ月)とかで、さらにOSやWebサーバやAPサーバの違いの合わせ技なんてのも、ありがちだと思います。

この状況下、多くの学習コスト(初期投資)を必要とするフレームワークでは、その回収がままならないというのが現実です。また、しばらく使用しないうちに個人の中の情報が劣化してしまったり、そのフレームワーク自体が陳腐化してしまったりすると、もはや回収不可能ということにもなります。

つまり、多くの学習コスト(初期投資)を必要とするフレームワークを習得することは非常にリスキーであると言えます。
※また、SIer独自のフレームワークは、機能の多い少ないよりかは、書籍が無いことやネット上の2次情報が期待できないこと、さらに下手すると1次情報(マニュアル)が貧相であることもあるので、学習コストは高く「学習コスト的に重量級」であると言えます。

よって、現状では回収フェーズにすぐに入れる「軽量級フレームワーク」が求められるもの、もしくはベターな選択であると言えます。

と、いいつつ実際の現場では重量級のフレームワーク(昔でいえばEJB2, 今だとHibernateとか)を採用している案件が結構多いような気がします。
#私も昔、EJB2の案件に携わったことが多かったです(当時はなんでこんなものが流行っているんだ?と疑問だったものです。。

わざわざ非効率的な方法を選択するのですから、酔狂なことです。

ところで、なんでこんなことになっているのでしょうか?
無知?、それともある組織の陰謀でしょうか?。

多分ですが、
通常、システム開発案件の見積もり項目に「フレームワークの学習コスト」なんて記載しませんし、記載しても認められないでしょう。現実には存在するコストなのですが、書面上には出てこないのですよね。そして、スケジュール上は多少考慮される場合もあるでしょうが、多くの管理者は個人の自助努力に学習コストを押し付けているのではないでしょうか?

こういった背景の中、「学習コスト」は管理されるべきコストからは除外されてしまいます。よって、フレームワークの選択による「学習コスト」の増減についても深く考慮されないのでしょう。
posted by 台北猫々 at 18:40| Comment(0) | TrackBack(0) | コラムみたいな
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/18724909

この記事へのトラックバック