Webフレームワークとノーフリーランチ定理
ちょっとでもフレームワークの流儀や対象範囲から外れたことをやろうとすると、
http://d.hatena.ne.jp/cnaos/20090210/1234277183
とてつもなく手間がかかるか、全く出来ないかのどちらかで、
適切でないフレームワークを使うくらいなら、個別にスクラッチで書いた方がよっぽどマシという状況が起こりうる。
まったくその通りで、Web用フレームワークではその傾向が強くなる。
たとえばCodeIgniterでちょいと有名な・
新しいアプリをCodeIgniter（略してCI）で作ろうとしている。
構成が分かりやすく拡張もしやすかったのですばらしい第一印象を受けて、これならスラスラ作れそうだと思っていたが、しばらく作業をしてみると徐々に気に入らない部分が見えてきた。
http://www.oddwit.com/blog/2007/coming-to-hate-code-igniter
という記事にあるように、CodeIgniterのように高速化された実装の場合、仕様がマッチしているときはいいが、そこから外れてくると開発しにくくなる。それは当然なので、そういうケースではCodeIgniterを使わなければいいという話なのだが、選択を難しくしてしまうのは、満たそうと思えば機能要件は満たせてしまうというあたり。機能要件の調査時は「できる？できない？」は注視するが、それ以上のことには気を使われないケースが多い。実際のところ、オープンソースである限り、カスタマイズによって満たせない機能要件というのはほとんど存在しない。
そこにあるのは、まさにノーフリーランチであって、何かにプライオリティを置けば、他のものが犠牲になってしまう。
そのプライオリティが目の前の企画にあっているかどうか、そこを見極める目が必要で、仕切る人はそこに"自信"を持っている。
現実には
Webの企画では、非エンジニアな人(会社）が仕切っている場合があり、選択権のある人がフレームワークの選定を行う目を持っているとは限らない。（顧客と直接絡むのは、広告代理店であったり、デザイン会社であったりするので）巷にあふれるフレームワークをすべてテストするというのは現実的ではない。要件すら固まらない段階であるフレームワークがそのニーズに本当にマッチするかどうかを検討するのは実際、難しい。
そこで、結局のところ比較されるのは、「標準の機能・パフォーマンス・アーキテクチャ」程度だったりする。
フレームワークの制約に合わせて要件を変化させることもあるから、問題は複雑化する。そこで、この辺の事情をSIがうまく説明しながら、フレームワークの選択と要件の間のカップリングを考慮して、ビジネスロジック部分に言及して仕様策定を行う必要がある。
顧客側がそれほど忍耐強くない場合やSI側の社内事情もあって、柔軟にFWを選択するよりも、大型のFWを使って開発していく必要がある場合もある。
時にはCMSをカスタマイズして・・なんて話すら出てきてしまう。
