LL(Lightweight Language)の良いところと悪いところ、とフレームワークの価値

一つ前のエントリーの補足。あたかもフレームワークが無価値であるような書き方をしてしまったので。

フレームワーク論の前に、LLについて。
ネット企業では、若い企業ほどLLを積極的に使う傾向にあると思います。他方、大きい企業では若い企業ほどLLを使わない。これは何故か、という話です。

もちろん、大きい企業は、新しいことにチャレンジするよりも安定稼働させる方が大事だから（＝収益の期待値が大きいから）というのもあるんですが、それだけじゃないと思います。ポイントは「開発人数」。開発人員が増えてくると、大人数で一つのものを開発したり、あるシステムの担当者がころころ変わったりするということが頻繁に出てきます。その場合にもっとも重要なのは、「誰が書いても同じコードになること」です。誰が書いても同じコードにしておけば、担当が変わっても、大人数で作っても手戻りが小さくなるからです。

LLは学習コストが小さくて、簡単に書けますが、実は書き方には相当ばらつきが出る場合が多いと思います。若い企業の場合、人数も多くないし、担当者とサービスが一蓮托生の場合がほとんどだと思うので、とにかくスピード重視でコードにムラがあっても速いほうが良い。ところが、人数が増えると、ソースの品質を一定にしなきゃならないから、自由度の高いソースの書き方は許容しにくくなるというのが僕の仮説です。

さてここでフレームワーク論。フレームワークはどういった目的で導入されるべきか。よく「開発が楽になるから、早くなるから」という声を聞きますが、これは僕は違うと思います。フレームワークを使うことの最大のメリットは、「誰が書いても同じソースになること」なのではないかと。このように、ソースコード規約の延長にフレームワークを位置づけるとすっきりします。こうした用途であれば、フレームワークは価値がありますし、フレームワークを学習させるコストを払ってでも、ソースコードが均質になることのメリットの方が大きい場合は、こうすべきだと思います。

もちろん、mixiやモバゲーやはてなのように、最初からLLでフレームワークを作って、後のスケールに備えるというやり方もありますが、これができるのはかなり例外だと思います。この場合、競争優位性だけを考えればLLである必然性は、1)採用等のコストが小さい、2)独自フレームワーク化による技術要素の流出が少ない、という点だけだと思います。この場合、オープンソースで公開されているような優れたフレームワークを社内で開発できるくらいの圧倒的に長けた技術者がいる必要がありますし、その技術者が退職しないような形でコミットされている必要がある（例えば、取締役になっているなど）があると思います。