システム開発をしている会社には社内標準のフレームワークがあることでしょう。
大体新規案件なんかはそれを元に作成することが想定されます。
まぁ、大体EJBやSpring、Seaserなんかを元に作られるんでしょうけど。
お客さんはフレームワークで作られたシステムが欲しいんです。
作られたシステムで業務効率を上げたり、他社との差別化を図りたいんです。
もっと言えば、品質が良くて機能拡張が容易ならどんな言語使っても
実現さえできれば良いんです。
ただ、コストやスケジュールの問題で
作るあなたが実現するのに効果的なツールを使えば良いじゃない、って話なんです。
何で作られているか、最先端の技術を使っているかなんて二の次なんです。
それなのに、作るシステムの内容を十分に聞かずに、
今回はSpringで行きましょう！とかウチのフレームワークで行きましょう！
とか言ってる訳ですよ。
で、実際の案件に投入してみたら、
あんなことができなくて、こんなところではまって。
で、あのフレームワーク使えねぇ、って評価を頂戴するんです。
プロジェクトメンバーの習熟度もあるでしょうけど
「これしか知らない」選択肢で決められたフレームワークよりも
「要件を鑑みてあれこれ調査してみた」結果決められたフレームワークの方が
よっぽどプロジェクトの為になる気がします。
事前にレールを決めておいて、その上を走るだけなら実作業としては楽ですが、
想定外のケースはつき物です。
お客さんの要望をフレームワークの都合でできない、もしくはコストを余計にかけて
いいんでしょうか？
システムの出来は要件ありきだと思うんです。
どんなフレームワークを使っているかは別。
お客さんとの認識をアーキを決める前に合わせなきゃいけない。
ただ、新しいシステムを構築するたびに違うフレームワークを採用していると
保守が大変なのでその辺は注意が必要。
プロジェクトマネージメントも数千万程度の案件だったら、
お客さんを巻き込んで、動くものをできたそばから見せていくことで
失敗率はかなり下がると思うんですけどね。
（もっと大きいのは意思決定が遅くてフットワークがよくないでしょうね）
フレームワークの出来を比べるのもいいですが、
要件を引き出す腕も養いましょうね、ということです。
