中間管理職から見た Ruby On Rails

最近コンビニで

店員「温めますか？」
私「いえ、いいです」
店員「ありがとうございまーす（レンジ直行）」

というやりとりが連続して発生してるんですけど、なんでですかね？この思い届いてないんですかね？業務用レンジってアッツアツじゃないですか。プラスチックひしゃげてるじゃないですか。苦手なんですよ。気遣いなの？それは嬉しい、ありがとう、でもね、プラスチックひしゃげてるじゃないですか。

というわけで

Ruby On Rails プロジェクトをPMとして見てきて２年くらいになります。
（一部で）耳にする「開発生産性は本当に高いのか？」について、独断と偏見でちょっと。
そもそも基準とする「生産性」って何よ？というところは、仮に「早く出来る」ないし「敷居が低い」とします。

早く出来るの？

コーディングは、「こんなんあったら良いのに」が全部あるんちゃうかというレベルで関数やGemが充実しており、ウッキウキで書けます。これもうウッキウキです。これはRubyの恩恵もデカイですね。

コーディングレベルで実現手段があらかじめ用意されているということは、エンジニアが小さなロジックを考える時間を省略できると言えるため、効率化＝コーデイングする早さに大きく寄与していると思います。

その他、migrateでのDDLの変更適用、CapistranoでのデプロイもRubyという同じ言語文法で記述でき、且つコマンド一発なので総合的にローンチまで早くできます。「簡単に手早くWebアプリができる！」ようなことどっかで見たような気がしますが、こうしたアプリケーション周辺のものを含んだ自動化のおかげですね。

簡単なの？

Railsはシンプルなくせに複雑というか、合理化の塊というか、それ自体は敷居は高いです。

基本的にはデザインからリリースまで全工程一環してエンジニアないし同等の知識を保有することが前提となっていること、みんな大好きAsset Pipeline問題や、Gemの導入による意図しないメンテ性の低下、scssやcoffeeにした場合の分業の面倒くささなど、忘れてはならないトラップも多く存在していることから、必然的に扱うエンジニアに対して求めるスキルセットは高くなります。同じく周辺技術も含めて一定以上の知識をPMも保有した方がベターです。運用、およびトラブル発生時の判断や顧客説明の元ネタのためです。

そしてCoC（Convention over Configuration）の「開発者が指定しなければならないのはアプリケーションの慣例に従わない点だけだ（wikiより）」を徹底していることで、うっかりしたコーディングをしてしまう場合も外せません。そのActiveRecordの使い方は意図したSQL吐かれてますか？「Railsっぽく」に執着して余計なloop発生してませんか？など。
ちなみにこれ「設定より規約」って訳されてるけど、ちょっと違うからね。

先述の「こんなんあったら良いのにが存在している」「コマンド叩くだけ」というのものもの、そしてCoCの徹底と並べて、Railsの言う生産性とはおそらく無駄を省く「合理化」であって、誰でもできるというものではないです。
どちらかといえば「お膳立てしてやってんだから、どう使うかはお前次第だ」と言われている気分になります。

じゃ、生産性は？

実現手段の存在、自動化、同一言語文法での管理運用などなど、効率的なRails君はとっても優秀であり、生産性の高いフレームワークと言えます。感覚的にでも「ええやん！」と実感しているエンジニアが少なくないのも、そういうことだと思います。

要は、便利であればあるほど、あとは「どう使うか」にかかっているという単純な話です。
「このフレームワーク使ったら戦争がなくなった」なんて神みたいなもん存在しませんわ。
便利なもの、というものは、総じて同じだろうけど。

ところで、RoR流行りってもう何年も前じゃないですか。確か。そう思うと、もっと市場にいても良いんじゃいですかね。確かに覚えること、気をつけることは多々ありますが、やってみるとエンジニアに人気！というのも納得だし、やってみたいなーと思っている人は是非、トライして欲しいものです。