「それでもRailsを選択する3つの理由」を読んã

• http://ppworks.hatenablog.jp/entry/2015/02/19/223552

ほぼほぼ同意なのですが、フームと思って（ppworksさんプロダクトだから、ということでもないが）ポエムをしたためた。

でもなんかこれをあえてポエムにとどめないで書いたらどういう反応があるかな〜と思ったのでブログにも転載してみよう。

規約縛りの哲学

これは文句なくその通りだと思っていて、Rails以外のフレームワークではこれらの実現が非常に中途半端であると言う印象を持っている。

サービス作りにおいて技術選定やら何やらからの議論をしていてはリリースは当然遅くなるし、あまりしたくないということである。議論するならもっとユーザに近い、正体のよく分からない不安点（このアプリほんとにユーザに受けるの？ とか）に関してすべき。

議論は一般的に良いことのように思われているが凄い体力を使うし、本当に必要な議論以外はしない方がスピードが出る。不景気なんで少しでも無駄を省いてスピードを出したい訳だ。インセプションデッキとか、開発を良くする勉強をしてきた方はご存知だと思うけど、あれもぼくは議論を減らすための仕組みだと思っている。

「どこまでを議論しないか」に関してRailsが勝手に線を引いてくれるんならそれってめちゃくちゃ楽じゃないですか、と思っている。

これはリバタリアンっぽすぎるかもしれないが...。

webの進化への追従の速さ

Railsが今でも基本的にはガンガンバリバリバージョンアップすること、それにより開発者も常に認識を変えざるをえないことというフレームワークを含めてメリットだとぼくも思う。

しかし、それはそれで「サーバアプリケーション側の」追従の速さに関してのメリットしか享受できない状況かなあと思っている。フロントはAssets Pipelineの無理くりさをまだ保持しているし、今やネーティブアプリ時代でRPCの設計、ソシャゲ開発用語の「繋ぎ込み」が大変重要になってくるけど、例えばJSON Scemaみたいな仕組みへの対応には興味が薄い印象がある（まあRESTfulということはそれだけでもありがたいんだけど）。この辺の分野はむしろ敷かれたRailが邪魔をするように感じる場面もあるかもしれない。

ただインフラ、という点では12factorとRailsは非常に相性が良いんで、これはこれかなと思う。サーバをいちプロセスのように扱う昨今の風潮には逆らわない（HerokuもRailsの文化から出てきたし）。

大事なのはここも哲学的で、「Railsっぽい姿勢でガンガン変わって行く」ことを善とする、今の常識や前提はひとまず疑ってみるというのがどの分野でも大事なので、それをサーバサイドアプリケーションの分野でやって一定の成功をしているのがRuby on Rails。開発者としてはフロントやアプリのアーキテクチャ、大局観を考える段階で、真似をすることはできるだろう。

いやまあ、簡単じゃないんですけどね。わかります...。

Railsっぽい変化の仕方って、ただ思いつきで変わりまくってる訳でもなくて、そこ大事なんだけどでも実は未だにこれ、「DHHはすごいんですよ」以外の言葉でうまく説明できない...。

周辺gemのエコシステム

これは最近は、単純に過信できないなあと思っていて、たしかにほぼすべてGitHubに上がっていて「議論に透明性がある」わけだけど、gemが放置される（燃え尽きる）問題とか、透明な議論をしていてもgem・プラグインが肥大化してステークホルダーが多くなって結果あらぬ方向にバージョンアップして行くみたいな問題は、透明にすることだけでは根本的に解決しないように思っている。無論、コードや経緯が透明だからこそ、切り捨てる、forkする、調査するその他の判断は容易になる訳だけれど。

なので最近はサードパーティな機能についてはある程度自分で書くのもやむなしという考えになってきている。forkしてずっとそのまま、は避けたいところだけれど...。

forkや切り捨ての判断が容易なところも含めてのエコシステム、ということであればRailsのエコシステムはまだまだそれなりにワークすると思う。

で？という話

ここからはポエムに書かなかった。

> 議論をしない、規約縛りの哲学
> 今の常識や前提はひとまず疑ってみる

この2点は一件矛盾しているように思うかもしれない。だが、矛盾せず両立できる。

「今の仮定をとりあえず受け入れて進む」ことと、「仮定は仮定として常に疑って検証する」ことは矛盾しないからだ。 Railに乗るということは、Ruby on Railsが規定する様々な仮定を是として受け入れること に他ならないと考えている。仮定なので、おかしなことが起こればすぐに立ち戻って変更しなければならない。だから変更に強くなければならない。

逆に言えば常に仮に進んでいる気持ちを失わない（そのために自動化をするし、ソフトウェアテストも充実させる）でいれば、本当に仮説が間違っていたときも致命傷を負うことなく立ち戻ることができる。こういう一種のPDCA回転を提供してくれるのが真の Rails の強みなんじゃないぐらいに思っている。

---

ぼくも、今でもRailsは十分強いと思っている。

Javaが得意とかPHP愛してる！ とかそういうバイアスあるとフレームワーク自体は変わるかもしれないが、上述したような姿勢は随所で採用できそうに思う。

でもしかし、ぼくはいい加減アプリケーションエンジニアを名乗ると違和感がある感じになってきたので、まあやっぱりポエム、というかフラッシュアイデアなのです...。