「10倍プログラマ」の神話、Ruby on Railsの生みの親が語った高い生産性のカギとは!?

ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。

Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。

2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り、「10xプログラマ」(テン・エックスと読む。平均的エンジニアの10倍の生産性を持つスーパーエンジニアのこと)は一種の神話のようなものであり、ある種のマーケティングだったことを大っぴらに認めている。その一方で、プログラマの生産性について多くの示唆に富む発言をしている。

この記事では、2014年に米マーケティング企業のJerryvisionがデイビッドと同僚のジェイソン・フリード氏を招待して行った50分ほどのトークセッションから、ソフトウェアを作る、ソフトウェアでビジネスをすることについて両氏が披露した興味深い洞察と意見をまとめてみよう。

session

オープンソースも、成功のためにはマーケティングが必要

まず、オープンソースプロジェクトで成功するためにはマーケティングが必要だ、というのがデイビッドの主張だ。多くの人は、その必要性を過小評価しているという。

「オープンソースのプロジェクトにはマーケティングは不要という人もいるけど、ほかのプロダクトと何も変わりませんよ。もし良いアイデアがあって、それが自分の頭の中にとどまっていたら、誰のためにもならないですよね。大きなインパクトを与えることの大部分は――、これはオープンソースをやっていて一番楽しいとこだと思うんですが――、ほかの人がそれを使って何か素晴らしいことができるようにシェアすることにあります」

「2、3人しか使わなかった、それまでのこと。でももし数万人が使えば、これはもっと素晴らしい。そうするためには売り込みが必要なんですよ。売り込まないとダメです。それは課金するってことじゃなくて、良いマーケティングをするってことです。作れば使ってもらえるというのは良くある勘違い」

「マーケティングといっても広告を打つんじゃなくて、ストーリーを語ってコミュニケーションをするってことです。2004年に最初にやったのは動画を作ること。Railsを使って15分でブログを作るというデモ。当時は誰も動画を使ってオープンソースを売り込んだりなんかしてなかったですよ。お金や人員を集中投下するというような意味では何もやってなかったけど、ぼくはほかのどんなWebフレームワークよりも上手にマーケティングしたかった」

「特に初期にはゲリラ・マーケティングのテクニックとして仮想敵を選ぶとかね。初期にはJavaです。こんなクソなやり方なんてあるか、と。意識的にね。当時としては、それはとても煽った言い方でした」

「だけど、ああ、あれもいいよね、これも同じぐらいいいよね。どれでも好きなものを使うといいよ。どれもみんないいよねー、うん、とか言ってたら、誰もおまえの言うことなんて気にしねぇよって話じゃないですか。誰も話を聞かないし、考えを変えようとすらしないわけですよ。だから、もうちょい炎上するぐらいじゃなきゃダメなんですよ。だから意図的にそうやったんです」

「実際、ほかの言語やフレームワークは、ウンザリするほどダメダメでした。単にダメっていうんじゃなくて、人間にとってダメだったんですよ。プログラマをみじめな気持ちにしてるんだから。当時はプログラマの喜びなんて話をしている人は、あんまりいなかった。ソフトな、感情面の話です。コンピューターサイエンスとか背後にある数学とか、事実とか、どの話もソフトな面じゃなかった」

「Webフレームワークにとって最も大切なもの。それはどのぐらい速いかでもなければメモリ使用量でもない。それを使うプログラマの気分がいいってことだ、と。当時、これは議論を呼んだもんです。今はそんなでもないと思いますけどね」

「10倍の生産性」はマーケティング上の詭弁だったのか?

では、「10倍の生産性」というのは単なるマーケティングのためのレトリックだったのか?

「10倍の生産性というのは神話なんかじゃないと思います。神話だなって思うのは、特定の誰かが、ほかの人たちよりも10倍のコードを書いて、それが良くテストもされていて、素晴らしいコードであるっていうような話」

「10倍の生産性っていうのは、何をプログラムするかを決めるときに出てくる話です。何を、どうやってプログラムするのか。どうやってある機能を実現するのか」

「生産性っていうのは、何を実装するかを決める部分にかかってます。ある特定の機能で考えてみると、それを200ドルで実装できるバージョンもあるでしょうし、100ドルでできるやり方もある、あるいは7時間で実装できるものもあるでしょう。生産性の高い人、あるいは価値を生み出すことの意味が分かっている人というのは、200ドルの実装よりも7時間を選ぶ人です。7時間のほうを選んで価値を生み出すことを知ってる人。同じ仕事を速くやるっていうんじゃなくて、違う仕事するってことです。その違う仕事に、より価値があるってことです」

dhh

手早く実装できる機能だけでは、あまり価値がないようにも思える。これに対してデイビッドは、ソフトウェアを作ることに関して野心的になることはバカげていると一蹴する。

「ちょっとヘンだと思うかもしれませんが、ぼくはあんまり野心的なプログラマじゃないですね。ソフトウェアやプロダクトに限っていえば、基準がすごく低い。世の中、出来の悪いものはあまりに多いし、改善すべき点というのはたくさんあるので、ほんの少し良くするだけでいいんですよ。ロケットを月に送り出すなんてことは必要ないんですよ」

「以前はサイエンス・プロジェクトって呼んでたんですが、3カ月以上かかるようなプロジェクトですね、そういうものにぼくは関わったことはないですね。3カ月以上かかるものはやりませんっていうんだから、できることの上限は知れています。重要な仕事には何年も何年もかかるものがあるでしょうし、そういう意味で、うん、やっぱりぼくは野心的なプログラマじゃないですね。今後もそういうものに関わろうとは思いません。だって、それが生産的であるってことの一部なんだから」

無駄に使っている時間を減らす

ここでインタビュワーに、現在取り組んでいるソフトウェアプロダクトのBasecampに費やす時間は週に40時間だけなのかと問われて、限定された労働時間と高い生産性の相関について以下のように続ける。

「40時間というのは1つの目標。それより少ない週も多い週もある。ただ、もし週に40時間とか、それ以下なのだとしたら、全部の時間を意味があるものにしたいですよね。もし何かやるのに週に40時間以上かかるのだとしたら、たぶん多くのことをやろうとしすぎてるってことですね。そんな生活はしたくないし、そんなの価値ないですよ。ほとんどの人は、ほとんどの時間を無駄に使ってるだけだと思いますね」

「だからぼくがやろうとしていることは、自分の時間を浪費する時間を減らそうっていうこと。どうでもいいことに時間を費やすのを減らす。やたらと野心的であるために永遠に日の目を見ないプロジェクトに時間を無駄をすることもしない。最終的にリリースされる、ほどよく野心的か、あるいは全く野心的じゃないプロジェクトに時間を使います。そうすれば、じゃーん。ほらっ、簡単なことですよ」

やらないこと:会議、新規プロジェクト、人材採用

デイビッドはRailsの生みの親としても知られているが、Basecamp(旧社名:37signals)の顔としても知られている。Basecamp創業者のジェイソン・フリード氏と2人で、ソフトウェア・ビジネスを回していくことについても多くの示唆に富む意見を披露した。特に「やらないこと」の話が興味深い。

1つは会議。「ミーティングというのは、誰かが誰かに何かを言うためだけにやってるわけでしょ。メールなら5分で済むものを、最もコストのかかる形でやっている、贅沢で生産的でない時間の使い方」とデイビッドは会議自体に批判的。最近のツイートでも、「ああ、部長さま、それは凄くいいアイデアですね。今やってることを全部やめて、それを追求するべきですね。うわー、みんなで協力するって楽しいですね(棒読み)」という皮肉を言っている。

時に議論やミーティングが有意義であることを認めつつも、ザックリ計算して、デイビッドは、こんなことを言う。

1時間の会議を週に6つもやるとなれば、その前後30分やら何だかんだで3時間、合計18時間が費やされることになる。「40時間のうち18時間? こんなんじゃ何もできなし、誰の時間の有効活用でもないよね。仕事してるように感じてるだけ。同僚の顔をみて、なんかしゃべってたねって。でも、ときどき振り返ってみて思うわけ。これのアウトプットって何だっけ? (人件費の)20万円分の価値あったっけ? ってね」。

多数のプロダクトに取り組まない、無駄にバージョンを増やさないということも、意図的だという。そもそもBasecampでは創業以来増えてきたプロダクトを整理し、メインのプロダクトだったはずの4つを最近1つに絞ったという経緯がある。この決断を行ったとき、Basecampでは書籍の出版も含めて、12ものプロダクトに取り組んでいて、さらにデイビッドとジェイソンが「良いアイデア」を思いついたことから、取り組むべきものの数が増えようとしていたという。ジェイソンは、こういう。

「新しいプロダクトに取りかかりはじめたんですが、プロダクトを作ることは(ソフトウェアビジネスの)一部でしかありません。リリースして、メンテして、サポートして、マーケティングもしてって、それ、誰がやるの? っていう話です。ぼくら43人しかいないのに、どうやってやるんだっていう。4つのプロダクトだけでも本当に良い仕事ができてなかったのに」

「どうするかってなったときに、もっと人を採用しようかという議論もしました。デイビッドと2人で議論を戦わせて気付いたのは、これ以上は人を採りたくないねっていうことでした」

「ふつうの会社は、それをやります。もっと人を採用する。より大きな目標を掲げて、より多くのことをやる。だから、もっと人を採用する。それはそれで全くいいんですよ。だけど、ぼくたちBasecampの目指すものではなかった。たくさん採用して、より多くのことをする代わりに、より少ない人数でできるように、少ないことをやろうと決めた。自分たちが一番良く知ってて良い仕事ができるものに戻るのに、今は良い頃合いだと。短期的には一定のユーザーをがっかりさせることになるとは思うけど、長い目で見れば、これでいいんです」

jason

変化なんて求めていない人も多い

1つのプロダクトでもバージョンの数が増えてしまいがちなのがソフトウェア・ビジネス。いったんリリースしたものは保守やサポートも必要になるが、簡単にバージョン数を減らすのは難しい。Basecampではどう考えているのか?

「レガシー」という言葉はソフトウェアビジネスの世界では否定的なニュアンスを帯びている。安定性と言えば中立なので、変化やバージョンアップは見方次第で、良い意味にも悪い意味にもなる。単なるツールとして使っている人からしたら、互換性を失い、再学習を要求する時点でバージョンアップや変化というのは全く歓迎されるようなのじゃない、とデイビッドは言う。自分が作っているソフトウェアだから新機能が重要なことと思うかもしれないけど、単にツールとして使っている人から見れば変化なんて迷惑。「これから学校に子どもを迎えに行かなきゃいけないんだけど……、何いっちゃってんの? ってこと」。

Basecampというプロダクトでも同様に、新しくすることを歓迎しない人たちがいることを理解した上で、「クラシック版」という変化しないバージョンを提供、保守し続けているという。10年で4つのメジャーバージョンアップのうち、2つを残しているということだ。

「変化というものに陶酔してしまうのは良くあること。確かにBasecampも10年前のものとは違うものになっている。だけど、半分のユーザーはクラシック版を使っている。変化なんて求めてないんですよ。クラシック版を保守、サポートするのに半分の人員も必要ない。それでお金を払ってくれるんだから、これは、すごく価値ある投資ですよ」

競合との機能実装合戦にも与しないとジェイソン。

「競合がやっていて、ぼくらがやってない機能があったとき、焦ることも時々あります。でも競合製品じゃなくて、ぼくらのグループウェアの最大の競合はメールとか電話です。そもそもソフトウェアを使わない人たちに使ってもらう、そこが大事。だからユーザーに話を聞くときにもストーリーを聞くようにしています。特定の機能のことなんて聞きません。どういう課題を解決したいのか、なぜソフトウェアを使わないか? それを解決するほうが、競合よりいくつどの機能があるかよりはるかに意味がある」

「(潜在顧客は)みんな自分の問題のことを考えてるんであって、プロダクト比較なんてしてないですよ。そんなものに誰も注意なんか払っていない。友だちからBasecampっていいよということを聞いたりしてソフトウェアを使うようになるんです」

ソフトウェアを無駄に変えすぎないことを強調する2人だが、デイビッドはここでAmazon創業者のジェフ・ベゾスの有名な「変化しないものにこそ注力しろ」というポリシーに言及して以下のように言う。

ECサイトで購入アイテムが届くのが遅ければいいのにと思う人はいない。速ければ速いほどいい。これは10年経っても変わらない。だからAmazonのベゾスは徹底してロジスティクスを最適化して翌日配送を実現した。「いまやAmazon以外のサイトに行って、配送に5〜7日かかりますって言われたら、何いってんの、Amazon Primeは翌日だよ? なんとかならないの? って1人の消費者として、そう思うわけです。これはスゴいアドバンテージですよ」。

「じゃあ、ぼくらに何ができるのか。ユーザーサポートって、みんなの期待は低いじゃないですか。サポート担当者に繋がるまで時間がかかる。誰か出てきても、返信はテンプレのクソ。たとえクソじゃないとしても、何も解決しない」

「でも、もしそうじゃなかったら?」

「クレイジーなほどソッコーで返信する。例えば1分以内で返信がくるとしたら? コストに関わらず、あるべき正しい対応をする権限がサポート担当者にあるとしたら? 日曜日の夜にサポートにコンタクトして即座に返信がもらえるとしたら?」

「ぼくらはこれらを全部やった。今から10年経って、サポートの返信が1分じゃないほうが良かったよねと人々が言うかって? ノーだよ。1分で返信する。即座に返金する。エンジニアを呼び出して、すぐに問題を修正させる。12、13人のサポートが必要で、全部とてもコストがかかること」

Railsで「ソフト面」を強調したデイビッドに呼応するかのように、ジェイソンはソフトウェア・ビジネスにおける「ソフト面」を強調する。

「ユーザーをちゃんと丁寧に扱うこと。これはソフトウェアの1つの機能ですよ。多くのソフトウェアは、この機能を実装していない。なんか特定の機能がないとか、ある機能が期待したように動かないとか、そういう話じゃないです。ぼくはユーザーを見放したりしない。人間というのは、ちゃんと自分に向き合ってくれる人の元を去らないもの。ソフトウェアも同じで、機能、機能、機能、技術、技術、技術……、そんな話じゃない。ソフトウェアも人の話なんです。使いやすさとか、きちんとユーザーに向かうことの大切さが過小評価されてると思います」