T

生産性

孫引きなのだが、Rubyのまつもと氏の発言とされる以下の記事:

【XDev】「とりあえず作って,後から作り直せ」,Rubyのまつもと氏が語るエンタープライズ開発:ITpro:
「エンタープライズRubyに関しては,実績もあるし,生産性が高いことも認められ始めてきた。楽天が社内向けシステムをRubyで開発したところ,JavaやPHPと比べて,生産性が1.6倍から3倍に上がった」

これ、どうやって生産性を計測しているのだろうか。

もっともありがちなのは、JavaやPHPでだいたい同規模のソフトウェア開発をやってみた時の実際の工数と比較すると、Rubyで作った場合の方がこれくらい早く仕上がった、という計測の仕方だろう。いや、実際にそうやったんだろう、と下司の勘ぐりをしているわけではない。よくあるパターンだとこうだよね、という話。

でも、プログラミングの世界では、生産性の個人差が大きいので、1.6倍や3倍といった程度の違いなら、個人のスキルで十分に吸収されてしまう誤差でしかなかったりする。

また、もっとベタな状況を想像してみよう。10人の開発者を抱えるごく普通のソフトウェア会社があるとする。主にPHPを使ってウェブアプリケーションを作っている。普段は数人のチームに分かれて開発をしている。よく出来る人にそうでもない人を混ぜているので、どのチームも生産性はいつもだいたい同じくらいだ。そこへ、新任のプロジェクト管理者が登場し、プログラミング言語による生産性の違いを計測するために、それぞれのチームにPHP、Java、Rubyをそれぞれ使わせて、同じ内容の社内向けアプリケーションを開発させてみた。

あまりの贅沢さにトム・デマルコの本に出てくるトムキンスが聞いたら呆然とするかもしれない。まあ、仮定の話なので細かいところはいいとしよう。

だが、この実験プロジェクトを遂行するにあたっては、様々な問題が噴出した。最初の問題は、では誰がJavaやRubyのプロジェクトを担当するか、だ。普段の業務で使っている言語なら、どのメンバも短くても半年、職歴の長いメンバなら5年以上の実務経験がある。そこへ、急に別の言語の仕事がまわされるかもしれなくなったのだ。どちらかを選べといわれれば、平均的な開発者であれば、普段使っている言語の方を選びたがるだろう。コーディングを担当する者にとって、目標とする期日までに業務を完了させることは、決してないがしろにできないミッションでもある。キャリアの浅い言語のプロジェクトは敬遠するはずだ。誰だって、期日前に受けるプレッシャーは避けたいものだ。それが直接人事考課に響くなら、当然のことだろう。

そんな状況でJavaやRubyでの開発を受けるような人間は、以前Javaの現場にいたか、あるいはRubyを独学していて、それなりの勘所を押さえているに違いない。

もうお分かりかと思うが、独学で実務では使っていない言語を習得しようとするような意欲的なプログラマに、生産性の低い人間はほとんどいない。だから、必然的に普段から他人の何倍もの生産性を発揮しているかもしれない。

JavaとPHP、Rubyのチーム編成を考えると、RubyなんかさっぱりわからないメンバをRubyチームに入れたり、JavaとJavaScriptの違いもよくわかっていないようなメンバをJavaチームに組み入れたりするのは、いくらなんでも問題だろう。データとして使い物にならない上に、下手をすると普段の業務で発揮していた力を出せないことを苦にメンバに退職されてしまうかもしれない。誰だって自尊心は必要なのだ。というわけで、だいたいのケースでは、意欲的なプログラマがRubyチームに入ったりする。

そうなると、まつもと氏が語っているような、Rubyで生産性向上があったというのは実際にはちょっと違っていて、言語など関係なく、元々生産性の高い人を集めたチームが、他の言語で開発していたチーム(つまり、優秀な人を除いた、まあ平均的技能のチーム)より高い生産性を発揮したという、ごく当たり前の結果がなんだか視点によって違うもののように見えてしまっているだけだということも十分にあり得る。少なくとも、自分の会社でこんなベンチマークをやろうとしたら、きっとこんな風な事態になると思う。

もちろん、個人的にはRubyはとにかくガシガシ書けるし、テスト可能性の高いコードを書こうと思ったらあれこれと便利なところがたくさんあって、個人的にはとてもいい言語だと思う。しかし、生産性の計測という点では、もうちょっと詳しく書いてほしかったな。

追記:

まず、記事の総論にはぜんぜん反対じゃない、というのははっきりしておきたい。もちろん、誰も正解がわからないソフトウェア開発で「速く作って、後から直す」という主張が出てくる背景も理解できる。ただし、これはRuby on Rails絡みのよくある話にもいえることだが、ソフトウェアを直すというのはとんでもないコストがかかることなので、いくら素早く開発してリリースすることが出来たとしても、この「後から直す」を軽視するととんでもない事態になる、というのは強調しないといけない。このやり方では初期開発費用は抑えられるけれども、ソフトウェアが軌道に乗るまでの費用が全て減るわけでは決してない。開発費と保守運用費のトレードオフになることを、開発者だけじゃなくて経営側、営業側も理解しないと、リリース後の下らないゴタゴタでひどい苦労をすることになる。つまり、単純にいえば、今までのやり方では直すことを前提としていないために見積もられなかった改修費用を、最初から折り込んでおきましょう、という話なのだ。変化に対応出来る体制というのは、こういうお金の絡むところの体制と、関連スタッフの意識の体制でもある。

Posted by on 9月 9, 2007 in Ruby

コメントを残す