Rails Hub情報局

　噂レベルですが、ちょっと気になる動きがあったので紹介したいと思います。

　2012年10月12日にPostgreSQL関連のメーリングリストに投稿されたエンジニア募集のメールが波紋を広げています。メールの差出人はSalesforce.comで採用担当責任者のMarcy Davis氏で、メールのタイトルには「今年5人のデータベース技術者を、来年には40～50人をSalesforce.comの大規模PostgreSQLプロジェクトのために募集中」とあったのです。求められる役割として「（同社の）コアとなるデータベースインフラの重要な部分を設計、実装できること」と書かれています。

　このメールがキッカケとなって、SalesforceはバックエンドのデータベースインフラとしてOracleDBを捨てて、オープンソースのPostgreSQLに移行する計画ではないかという予測が各方面から出てきています。

　あくまでも推測の範囲を出ないものばかりですが、あり得なくない話です。いきなり1年後に総取り換えをすることが可能とは思えませんし、顧客もそんな無茶は望まないでしょう。ただ、オプションとしてPostgreSQLの提供を開始して移行を促すというのはあり得るシナリオです。

●悪化する師弟関係が発端か

※以下、基調講演の話において、2011年のイベントと2012年のイベントを混同して書いてしまいました。ここ数年、2人の間で舌戦が繰り広げられているのは間違いありませんが、時系列的に無関係な話を連続して起こった出来事のように書いてしまいました。申し訳ありません。お詫びして訂正いたします。

　PostgreSQL技術者募集のメールが飛んだのは10月12日の金曜日ですが、実は、その前日にSalesforce.comとオラクルの間で前代未聞のハプニングが起こっていました。

　Oracle OpenWorld 2012で予定されていたSalesforce.com創業者でCEOのマーク・ベニオフ氏の基調講演が、前日になってオラクル側からドタキャンされたのです。健康問題などが理由で基調講演が1週間前になって急遽キャンセルになるというようなことはときどきありますが、前日に一方的にキャンセルというのは聞いたことがありません。当のベニオフ氏も驚いたようで、理由は分からないが残念だとTwitterでつぶやいています。

　Salesforce.comのベニオフCEOは13年間オラクルに勤めた後に独立してSalesforce.comを創業しています。ベニオフ氏とオラクルのラリー・エリソンCEOは長らく師弟関係にありましたが、近年その関係はビミョーに悪化しているように見えます。少なくとも2人の間の舌戦は過熱気味でした。例えば、昨年に「クラウドと称して箱を売りつける、偽のクラウドに気をつけろ！」とベニオフ氏がオラクルに噛み付いたのに対して、今年はエリソン氏が「独自言語で囲い込んで、仮想化の分離もしておらず、キャパシティに制限もある、そっちがの方が偽のクラウドだろ！」とやり合ったとPublickeyが報じています。

　The Registerが伝えるところによれば、オラクルのラリー・エリソン氏は、Salesfore.comは子会社のHerokuを通してPaaSではPostgreSQLを顧客に使わせておきながら、自分たちのSalesforce.comのクラウドの基盤にはOracleDBを使っている、これは「私には興味深いことに思える」と揶揄したといいます。客にPostgreSQLを使わせているのに自分たちは使ってないじゃないか、ということですね。後から買収した会社のことで揶揄するのもどうかと思いますが、「ドッグフーディングしていないじゃないか」というのは正論でもあります。

　こうしたやり合いがあったにせよ、競合であるSalesforce.comのベニオフCEOに対して、オラクルは今年も基調講演という晴れ舞台を用意していました。では、なぜ土壇場でキャンセルしたのでしょうか？ 実はラリー・エリソン氏が激怒したのではないかと思わせるレポートがあります。OpenWorldの展示ブースで、Salesforce.comは製品やソリューションの展示を一切せずに、チャリティ活動をしていたというのです。CRMSearch.comのデニス・ポンブリアント氏が伝えるところによると、その光景は異様で、まるでベニオフ氏がエリソン氏に対して「ほら、オレたちにはあんたが金儲けのためにやってるX-boxesなんて要らないんだよ。オレたちはもっと崇高な仕事をしてるんだ」と言わんばかりに思えたといいます（X-boxesと言ってるのはExadataのことでしょうね）。もしこれが本当なら、エリソンCEOが怒るのも無理はありません。つばぜり合いが一線を越えたのかもしれません。

　もともと競合する面が強くなりつつあったSalesfore.comとオラクルという2社の“顔”が、とうとう正面衝突したと見ることもできそうです。もちろん衝突そのものはわれわれからは見えませんが、「基調講演のドタキャン」「OracleDBからPostgreSQLへの移行を匂わせる動き」は、2人の関係に衝突があったことを想像させます。

●ライセンス料よりもビジネスモデルの説得力として重要

　ドタキャンされたことに逆切れ（？）したベニオフ氏が、「だったらオレたちはもうPostgreSQLで行こう」と考えて翌日さっそく行動に移したのかもしれません。直情径行型の思い付きは経営には良くないですが、もともとSalesforce.comがPostgreSQLを担ぐべき理由はあるように思えます。

　Salesforce.comがPostgreSQLに移行すべき理由があるとしたら何でしょうか？

　Salesforce.comほどの規模となれば、オラクルにとっても得意客でしょう。特別なライセンス料に基づく個別契約となっているでしょうが、それでもSalesfore.comはオラクルに相応のライセンス料を支払っているでしょう。OracleDBからPostgreSQLへ移行すれば、このライセンス料がなくなります。これは言うまでもなく利用料金の引き下げや、収益率向上、競争力の強化につながりますからSalesforce.comには好ましいことです。オープンソース界の2大RDBMSといえばMySQLとPostgreSQLですが、エンタープライズ方面では、PostgreSQLのほうが好まれる傾向にあります。そして、MySQLは今やオラクルに買収されていますから、Salesforce.comとしては選択肢はPostgreSQLしかありません。

　OracleDBからPostgreSQLへの移行というシナリオは、ライセンス料というよりも、ソフトウェアテクノロジーによる革新を進める企業にとってのレーゾン・デートルに関わる話なのではないかと思います。ソフトウェアスタックのコア部分がブラックボックスとなったまま他社に握られているというのは、トヨタがエンジンを他社製品に頼るような話だからです。この点ではオラクルのエリソン氏の言い分に説得力を感じる顧客が多いことでしょう。「結局、オラクルのDBが基盤に必要なのだ。だったら、上から下までウチに任せない」ということです。これではSalesforce.comがマーケティング上、劣勢に立たされる可能性もあります。

　上から下まで全てのソフトウェアを自社開発でまかなえる企業はマイクロソフトやグーグルぐらいしかないかもしれません。それでも近年のソフトウェア企業、とくにWeb系の企業の間では、OSやミドルウェアとしてオープンソース製品を採用して、基盤部分は協業しながら改善していくというモデルがうまく回り始めています。一連のNoSQL関連のプロダクトはその典型です。このオープンソースの流れが、やや遅れてエンタープライズで使えるRDBMSの世界にもやって来る、と見ることもできるのではないかと思います。

　プロプライエタリなソフトウェアは中身が見えないブラックボックスであると同時に、その利用者が自ら手を入れることができないという制限があります。開発の方向性や優先順位付けの意思決定に関われるという意味でのオーナーシップもありません。成長したSalesforce.comが、自らのビジネスのコアとなるソフトウェアでプロプライエタリなソフトウェアを取り除きたいと考える理由は十分にありそうです。

　Salesforce.comがPostgreSQLにガッツリと肩入れをして“エンタープライズグレード”となるのであれば、これはオープンソースコミュニティにとっては、非常に意義のあることだと思います。最近はNoSQLが注目を集めていてRDBMSはホットなトピックではないかもしれませんが、まだまだRDBMSを使うのが正解というプロジェクトのほうが圧倒的多数派でしょう。業務アプリならなおさらです。利便性の面でも、もともとPostgreSQLは扱えるデータ型が豊富で厳格ですし、最近のPostgreSQLはKVSの拡張やJSON型の採用など柔軟性も増していて、わざわざほかのミドルウェアを入れることはないのではないかと思えたりします（ちなみにこの辺は、QA@ITというサービスを担当していて感じたことです。QA@ITはHeroku上で稼働しているのですが、機能追加の実装方法を見るたびにPostgreSQLは素晴らしいなと思ったりしています。というような話は、PostgreSQLとMySQLはどちらかに明確な優位性がありますか、というの質問・回答にもまとまっています）。

　Salesforce.comはOracleDBからPostgreSQLに移行する可能性があるでしょうか？ 皆さんは、どう思われますか？

　RubyやPHPのPaaSを提供する米Engine Yardが日本進出を準備中です。すでに法人登記済みで、現在は数名のスタッフが活動を開始しているそうです。2012年6月25日に東京・麹町で行われた「Tokyo Rubyist Meetup」で、日本法人の代表を務めるTim Romero氏が同社のビジネスについて概要を紹介していたので、ここでシェアしたいと思います。

本格操業に向けて準備中

　Engine Yardといえば、先日までJRubyやRubiniusといったプロジェクトのコア開発者を雇用していたことでRuby界では有名です（JRubyの2人はRed Hatに、RubiniusのEvan PhoenixはLivingSocialにそれぞれ移籍しました）。しかし、Engine Yardのサービスのほうはといえば、EC2を使ってRuby/PHPのPaaS事業を行なっているということ以上には、あまり知られていないのではないでしょうか。競合ともいえるHerokuに比べると、サービス内容が多様で複雑。ちょっと試してみるような感じもありません。日本ではまだ本格的にオペレーションを開始していないこともあり、ほとんど存在感はありません。

　というように、私はEngine Yardについて、今ひとつよく分かっていなかったのですが、Romero氏の話を聞いて膝を叩きました。Engine YardとRuby on Railsの関係は、Red HatとLinuxの関係に似ているのではないか、と。端的にいうと、Ruby/Railsアプリを開発するのに必要な技術サポート、教育サポート、プラットフォームサポートなどを全面的に展開している、ということです。

互換性検証の専属チーム

　例えば、Engine YardにはGem（Rubyのライブラリ）のテストばかりやっている互換性検証の専任チームが存在しているそうです。顧客に対して、どのGemはバージョンアップしたほうがいいか、どれはバージョンアップを待ったほうがいいかをアドバイスしてくれるそうです。どのGemでどういう問題が発生するかも把握していて、Engine Yardのエンジニアがアップストリームに対してパッチを書いたりもするといいます。

　従来、こうした情報は開発会社単位やコミュニティで共有されることはあったでしょうし、それはRuby/Railsを使っていく上で必要なコストと見られてきたのではないでしょうか。誰かがGemfileを書き換えてGemのバージョンを上げると、どうもテストが落ちる。ソースコードで追う。結果、GitHubで対象のGemをフォークしてモンキーパッチを当てたものをアプリからBundleするようにする、といったことです。PostgreSQLやPostfix、Redisなどサーバやミドルウェア管理・運用するのがコアバリューを生む行為でないのと同様に、Gemの互換性やトラブル対応といった仕事を、Rails開発者はアウトソースするべきなのかもしれません。RubyやRails自体はシンプルで簡潔ですが、それを支えるソフトウェアスタックは結構複雑です。

　クラウドというものが企業やIX、時に大陸をまたいだ開発者同士の分業だったのだとしたら、Ruby/Railsスタックのエコシステムにグイグイと食い込んでサポート業務をやるEngine Yardのビジネスモデルには説得力があるように思えます。現に、Engine Yardは2006年創業ですが、すでに社員数は140人。58カ国に有償の2400顧客を抱えていて、年間売上は2800万ドルとなっているそうです。

サポートチケットの23％は顧客でなく、EYがオープン

　もう1つ、Engine Yardのサポート業務を象徴する言葉だなと思えたのは、Romero氏の次のような発言です。「日本ではサポートとは謝罪のことだ、というジョークもありますが、われわれのサポートは違います、プロアクティブ・サポートと呼んでいます」（Romero氏）。

　どういうことかというと、ホスティングしている顧客のアプリに関して投げられるサポートチケットのうち23％は、顧客側ではなく、なんとEngine Yard側がオープンしているのだそうです。“プロアクティブ”という用語はマーケターが好みそうな空疎なバズワードの代表ですが、問題が起こる前、あるいは顧客が気付くより先にチケットを作ってしまうというのですから、これは確かにプロアクティブです。Engine Yardは、技術的検証のために80個ほどの“ミニアプリ”を持っていて、常にこれらのアプリでテストをしているといいます。

　Engine Yardはコールセンターを持っていないそうです。サポートは、すべて開発者やエンジニアが直接行うからです。さらに、ペアプロやセキュリティ監査、アーキテクチャ評価、データベースクラスタリング、マルチリージョンDRなど、顧客が必要とする技術的サポートのほとんどを提供していると豪語します。

　オープンソースのスタックを使い、技術者集団がエキスパティーズを“サポート”というカタチで提供している点で、Engine YardはRed Hatに似ているなと思います。実際には極めてエンジニアリング・セントリックなのに、外から見るとエンタープライズの匂いが強いというところも似ています（Engine YardのWebサイトに行くとホワイトペーパーがあってダウンロードしようとすると会社情報を登録しろと来て驚きます）。何よりも、オープンソース界のスターエンジニアを抱えていて会社としてコミュニティに一目置かれている、というところは、Engine YardとRed Hatでそっくりだなと思うのです。

こんにちは、＠IT編集部の西村賢です。本日、2012年5月29日にITエンジニア向けの質問・回答コミュニティサイト、「QA＠IT」をローンチしました！ あるようでなかった、日本語による本格的な技術系のQ＆Aサイトです（プレスリリース）。

今さらQ＆Aなの？

今さらQ＆Aサイトなの？ と思う人もいるかもしれませんが、QA@ITは以下のような特徴があり、先行する多くのQ＆Aサイトとは異なります。

• ITに特化している
• Wikipediaのように他の利用者の質問や回答を編集できる
• 質問や回答に対してプラス、マイナスの両方の評価ができる
• より多くの利用者が評価した回答が上位に表示される
• コミュニティに認められたユーザーは、徐々に権限が増える
• 回答と、回答以外のやり取り（質問への質問など）が区別できる

以下、順に説明いたしますが、その前にヒトコト。

分かる人には一瞬で分かると思いますが、QA@ITはStackOverflow.comの日本語版とでも言うべきサービスとして開発をスタートさせました。QA@ITの開発チームはStackOverflowという偉大な先行者を研究しながら開発しています。

ITに特化している

さて、QA@ITの特徴についてです。

まず、＠ITなので当然なのですが、ITエンジニアの問題解決に特化しています。ソースコードのハイライト表示やMarkdown記法の採用などエンジニアにとっての使いやすさを重視しています。コード表示が見やすくなるように表示幅もだいぶ頑張って確保しています。ログインもGitHub、Twitter、Facebookのアカウントがあれば可能です。

Q＆Aサイトの多くはジャンルを絞らずに幅広く利用者を集めています。われわれはノンジャンルとして「何でも聞ける」ことよりも、プロの専門家が見て有意義なコンテンツが集まることのほうがはるかに重要で価値があることだと考えています。専門家が参加したいと思う理由は、さまざまでしょうが、参加したくないと思う理由はいくつかハッキリしています。全体のレベルが低いこと、ノイズが多いことには我慢ならない人が多いのではないでしょうか。ですから、QA@ITは利用者層としてITエンジニアやソフトウェア・エンジニアリングに熱意を持って取り組んでいる人を想定していて、そこに一定の基準を作りたいと考えています。例えば、QA@ITは「学校のプログラミングの課題が分からないので教えてください」という質問をする場所ではありません。プログラミングを学習する上での疑問を聞くのは良いことですが、そのためにまず自分で十分に自習なり調査なりしてください、ということです。

QA@ITの存在意義は2つあります。

1つは質問者の目の前の問題が解決することです。そしてもう1つは、後から検索でその質問・回答にたどり着いたエンジニアの問題や疑問の解決速度が上がることです。特に後者が重要だと考えています。この目的のために、さまざまな機能があると言っても良いぐらいです。質問ガイドラインを設けて具体例を掲載しているのも、同じ理由からです。

Wikipediaのように他の利用者の質問や回答を編集できる

QA@ITでは、自分の投稿した質問や回答は特に制限なく何度でも編集できます。それに加えて、十分に権限が上がれば、他の利用者の質問や回答も編集できるようになります。

各種権限はレピュテーションという数値に応じて自動で付与されます。レピュテーションとは、他の利用者にどれだけ評価されたかによって増減する数値で、この辺の関連性はFAQにまとめてあります。レピュテーションは同じ技術領域を専門とする人々のコミュニティに、どれだけ評価されているかを示す指標でもあります。

他の利用者が投稿した質問や回答が編集できることには、以下のメリットがあります。

• 質問が不明瞭だったり、情報に不足があっても補足して改善できる
• 間違った情報の定着を防げる
• 古くなった情報を書き換えられる
• 追加情報があれば後から追記できる

今のところ、編集差分は表示できていないのですが、編集履歴自体は保存しているので、なるべく早い段階で編集差分が表示できるようにしたいと考えています。誰が何を書き足したとか、削除したが分かるようになります。今はWikipedia同様に、権限さえあれば誰でも本文編集やタグの追加・削除ができますが、編集の承認ワークフローを実現できればと考えています。

質問や回答に対してプラス、マイナスの両方の評価ができる

良い質問や回答にはプラスの評価を与えるができます。回答はデフォルトでは評価順に並びますから、検索などでたどり着いた人は、どの回答が一番有効かが一目で分かります。QA@ITの存在意義の1つである、検索でたどり着いた人の問題解決の速度を上げたいというのが狙いです。掲示板形式だと、どれが正解、もしくは有効か、パッと見では分かりません。質問スレッドの2ページ目、3ページ目と議論を追ってみても、結局どこにも答えはなかった、ということもよくある話です。

質問者自身が考える最も役立つ回答は「accept」することができて、それは緑色のチェックマークで表示されます。ただ、質問者が考える良い回答よりも、より多くのエンジニアが考える良い回答のほうが表示の優先順位は高くあるべきだと考えて、そのようにしています。

今回のQA@ITでは「いいね」に相当する+1だけではなく、-1のボタンも付けています。これは何も「顔を洗って出なおしてこい（エラーメッセージぐらい貼れよ。フレームワークやSDKのバージョンぐらい書けよ）」と言い募るためにあるのではありません。もし質問が拙いものであったなら、何をどう書き直せば良いかを、相手を非難したりすることなく指摘し、オリジナルの投稿者がより適切な質問に書き直すよう促すための仕組みとして入れてあります。「良い質問スタイル」を促すような、そういうやり取りができる文化を定着させられればと願っています。そのため、-1を押すときにはキチンと相手に-1の理由と改善案をノートに残すことで伝えてくださいということをお願いしています。

このあたりは、機能と運用ルールの両輪で良いコミュニティが育てばと願っています。例えば、今は-1の取り消しができませんが、取り消せるべきではないのかということで、近々実装する予定です。こうした機能の1つ1つがコミュニティのあり方を規定するのだ、というのがStackOverflowの創始者であるJoel SpolskyやJeff Atwoodらの洞察で、私も非常に共感しています。

コミュニティに認められたユーザーは、徐々に権限が増える

良い質問や回答して、他の利用者が+1すると「レピュテーション」が増えます。-1の評価を受けるとレピュテーションは減ります。

レピュテーションが溜まれば、質問や回答の編集が可能になります。登録したばかりの状態ではレピュテーションはゼロで、質問や回答の評価もできません。今のところ、レピュテーションと権限の関係は以下のようになっています。

• 質問に+1する:15
• 回答に+1する:15
• 質問にノートを付ける:50
• 回答にノートを付ける:50
• 質問を編集する:300
• 回答を編集する:300
• 質問を-1する:125
• 回答を-1する:125

回答と、回答以外のやり取り（質問への質問など）が区別できる

些細なことのようですが、質問と回答以外に「ノート」という投稿スタイルがあります。ノートは質問や回答にぶら下がるものです。補足情報や質問（質問への質問など）、感謝の言葉などはノートで付けるというルールにしています。これは回答投稿は回答にのみ限定することで、そうではないコミュニケーション系のメッセージによるノイズを最小限に抑えるためです。

ベストな質問・回答のペアを残したい、そのことでITエンジニアの生産性を上げたい、というのがQA@ITの狙いです。ですから、質問・回答のセットと直接関係のない情報は目立たなくしたいのです。追記、修正がある場合でもノートのやり取りを通して行って投稿を編集していけば、後から検索してやってくる人々は、いちいちやり取りの経緯を追わなくても、編集済みの質問・回答だけを見ることができますよね。カノニカルなQ＆A集を作って、育てていける場所になればと願っています。

検索結果から安心してクリックしてもらえるサイトに

ベストな質問・回答のペアを蓄積していければ、それは非常に価値のあるオンラインリソースになると思います。今の時代、特にオープンソース系のスタックはそうですが、答えはネット上のどこかにあるものです。公式ドキュメンや技術系ブログ、メーリングリストのアーカイブ、あるいはソースコードの中に書いてあります。QA@ITは、そうしたリソースに対する分かりやすいポインタ群となれるのではないかというふうにも考えています。公式ドキュメントよりも、QAほうが粒度が小さくてズバリのカタチで書いてあって話が早いし、用例も書いてある、と。

例えば、「gitでclone後にリモートリポジトリを切り替えたい」というのは、答えがmanに書いてある話です。でも、どのmanを見るべきか分からないケースや、そもそもの概念や機能の存在を知らないケースもあるでしょう。何よりネットの検索で済むなら話が早いと思うのです。すでに、StackOverflow.comはそういうサイトになっています。検索結果にstackoverflowの文字を認めただけで、私などは「ああ、問題は解決した」とすら思うことがあります。英語圏には、そうした安心してクリックできるサイトがあります。日本語圏にもそういう技術系QAサイトがあればいいのに、というのを実現しようとしているのがQA@ITです。

QA@ITはオープンしたばかりで、まだこれから機能的にも進化させたいと考えています。使いづらい点や、追加すべき機能などがあれば、お知らせいただければと思います。よろしくお願いいたします！

　RubyやPython、Javaなどで書かれたWebアプリをGitのワークフローに合わせて簡単にデプロイできるPaaSプロバイダの「Heroku」（Salesforce.com傘下）が、気になる新機能を準備中です。2012年4月19日、来日中のプロダクトマネジメント担当シニアディレクターのMorten Bagaiさんに、東京・六本木で話を聞く機会を得ました。（記事初出時に肩書きに誤りがありました。修正してお詫びいたします）

　注目の新機能は3つです。

1. TCPルーティング
2. アドオン向け従来課金API
3. Team機能

　これまでHerokuは、HTTPレベルでのルーティングを行っていましたが、TCPルーティングも可能にするべく模索しているそうです。TCPルーティングには2つの意味があると思います。

　1つは、WebSocket対応です。これまでHerokuでは、Pusherなど外部サービスを使うことでしかWebSocketは使えませんでした。このため、例えば現在のスタックでNode.js＋Socket.IOでリアルタイムなWebアプリを作るとなると、WebSocketからロングポーリングに切り替える設定が必要です。

　もう1つ、TCPルーティングが可能になれば、例えば、Skypeのようなストリーミング系のアプリケーションやメッセージサービスのようなミドルウェアが扱いやすくなるでしょう。こうしたサービスを提供するアドオンベンダにとっては福音となるかもしれません。

　注目の新機能の2つめは、アドオン向け従来課金APIの開放です。

　従来、サードパーティベンダがアドオンを提供する場合、段階的な課金メニューとならざるを得ませんでした。例えば、Redis To Goなら、無償（5MB）/Mini（月額5ドル、20MB）/Small（月額25ドル、100MB）といった具合です。これはこれでシンプルで良いのですが、メール受信のアドオン「CloudMailIn」やスケーラブルなメッセージキューのアドオン「IronMQ」といったアドオンなら従量制のほうが良いかもしれません。今のところ、Herokuの課金インフラの実装と、どういった提供形態にすべきかということを模索している段階だそうです。

　PaaSとしてのHerokuのポリシーがよく分かるのは、Mortenさんの次のような発言です。

　「（従量制課金について）われわれが気を付けないといけないのは、もし複雑なものをユーザーに見せてしまったら、ユーザーは月末にコストがいくらになるのか分からないという事態になりかねません。だからわれわれは課金モデルとして、もともと定額メニューのものしか用意しなかったのです。今でもわれわれはこのシンプルさを気に入っています」（Morten Bagaiさん）

　これはIaaSとして人気のAWSと異なる点です。

　「Amazonはすべてのギア（注：調整のための機械のパーツという意味）を顧客に見せるのを原則としていて、それは非常にすばらしいことです。細かくコントロールできるのが重要なのです。IaaSとPaaSは違うもので、われわれPaaSベンダはより抽象度の高いプラットフォームを提供しているのです」（同）

　マルチ・リージョン（グローバル・ルーティング）対応も同じことですが、新機能の実装は技術が難しいというよりも、どういうモデルがPaaSとして正しいのかを考えることだといいます。

　ちょっと余談ですが、この従量課金インフラの一部はGo言語で書かれているそうです。Herokuでは、自分たちが開発したサービスやプロダクトを、まず自分自身で使うという“ドッグ・フーディング”を重視しているので、ポリグロット（1人の開発者や1つのプラットフォームが複数の開発言語を使う・対応すること）ということを唱道する以上、自ら多様な言語やフレームワークを使おうという開発者が多いのだそうです。Go言語を使ってインフラの一部の書いた、というのには、そういう意味合いもあるといいます。

　さて、3つ目の注目新機能は、チーム単位でアプリが管理できる機能です。名称未定だそうですが、Heroku内部でTeamと呼んでいるそうです。これまでHerokuを使ってチームでアプリ開発をするときには、個別にユーザーアカウント（メールアドレス≒公開鍵）をアプリ単位でコマンドラインから足していくしか方法がありませんでした。新しいTeam機能では、複数プロジェクトに対して複数開発者がいる場合に、権限管理などが可能になるようです。ステージング環境やプロダクション環境という区別についても、分かりやすくすることを考えているといいます。

　Mortenさんによれば、これらの機能は近いうちにリリースされるもので、一部はすでにリアルユーザーが使い始めているといいます。こうやって新機能が利用できるユーザーの幅を広げていく手順というのは、Herokuのプラットフォーム自体が持っている「Feature Flag」（機能フラグ）という機能で実現しているといいます。何か新機能を実装したら、プロダクション環境で実際に限定的に少数のユーザーやグループに公開して、フィードバックを得て、それから徐々にその機能の提供範囲を広げていく、というアプローチです。

　Herokuは従来の大手IT企業と違って、中長期的なロードマップを示したり、新機能について事前にアナウンスすることはありません。その代わり、リリースすることを前提として実装中の新機能については、特に隠すことなく、コミュニティの場で語ることがあります。上に挙げた3つの新機能も、これまでにもユーザーイベントで紹介されたことがあるものだといいます。

　「事前アナウンスというのはHerokuではやりません。われわれが新機能をブログなどでアナウンスするときは、その機能が実際に利用できるようになったときです。ただ、利用者からフィードバックを受けることに関心があるので、リリース前にお話しすることがあります」（Morten Bagaiさん）

　マルチ・リージョン（グローバル・ルーティング）対応についても、あちこちで語っているので、これらの新機能のリリースは、すべて時間の問題ということで、楽しみですね。

　Merbのコア開発者でRails3でMerbとRailsの統合で重要な役割を果たしたYehuda Katzさんが、Mac向けのRails.appを作るという新プロジェクト「Tokaido」（東海道新幹線からの命名）を発表して話題を呼んでいます。プロジェクトをスタートするにあたって、Yehudaさんはまず、Kickstarterを使って、プロジェクトの必要性と、自分がそれを遂行できる能力があることを示しつつ、募金を開始しました。開発に先立って2万5000ドル（約200万円）の募金を始めたことについて、オープンソースの開発手法として違和感を持つ人が少なからずいたようです。

Mac上でのRails開発環境構築は面倒？

　Tokaidoは、Mac向けのRails.appを作るというプロジェクトです。最近のMac上のRails環境はさまざまなツールが発達していて、インストールすべきツールや、その順序、やり方が自明ではありません。これが新参開発者を遠ざけているのではないかというのがYehudaさんの問題意識のようです。

　これはある程度経験を積んだRails開発者でも思い当たる節があるのではないでしょうか。rvmとrbenvはどちらがいいの？ Rubyのバージョンってどれを使えばいいの？ クリーンな環境でRubyをコンパイルするには、どのライブラリがあればいいんだっけ？ 動的にリンクするライブラリのバージョンの整合性の問題でgemが警告を出しているんだけど……。よく分かっている人であれば、コマンドラインで5つか6つほどコマンドを叩けば終わることでも、そもそもどういうツールがあるか分からない初心者には難しいですし、分かっている人でも、何か問題があったり、環境がクリーンでないようなケース（MacPortsで競合する何かがどこかにインストールされているなど）では、問題の特定にムダに時間がかかったりします。

　Windowsには、EngineYardがスポンサーとなって作られた「RailsInstaller.exe」という優れた環境設定ツールがあります。RailsInstallerをダウンロードして実行すれば、Ruby、Rails、Bundelerだけでなく、Git、SQlite3など、Rails開発に必要なものがひと通り揃うようになっています。Rails.appは、これに相当するものと言えるのかもしれません。

　Tokaidoで何を作るかということについてはまだ具体的に決まっていないようですが、Rails.appというアイコンを、Macの/Applicationsフォルダにドロップすれば、Ruby、Rubygems、Rails、それに必要となるgem（ライブラリ）の一式がコピーされて開発ができるようなものを目指しているそうです。ターミナルを開けば、Rails環境のコンソールに入っていくことができるようにするといいます。少なくとも、Rails開発にCコンパイラが必須である必要はないのではないか、ということです。

　初心者や、ほかの開発ツール、言語からの移行組のためのツールというだけでなく、Yehudaさん自身や、ほかのRails開発経験者も喜んで使うようなツールにしたいということですから期待できます。

OSSプロジェクトを立ち上げるのに募金はアリ？

　Tokaidoプロジェクトに対して、2つの疑問の声がすぐに上がりました。

　1つは、少しコマンドを叩くだけでインストールできるようなRails開発の環境構築に、そんな大げさなプロジェクトが必要なのかというものです。少しのコマンドを叩くだけなのだから、自動化するスクリプトでも十分ではないのかという意見です。

　これには2つの反論があります。1つは、スクリプトの自動化では本質的な問題が解決しないというものです。途中でスクリプトがコケたとき、たいてい環境は「よく分からない状態」になり、ここから正常な状態にするのは骨が折れることだからです。Tokaidoプロジェクトを擁護するEric Hodelさんは以下のように述べていて、Yehudaさんも、これに同意しています。

ちょうどRubyがautotoolsやbisonのインストールから解放してくれ、rvmがzlib、OpenSSL、cursesなどのインストールから解放してくれているように、Rails.appはコンパイラやrvmなどから解放してくれるものになるだろう。

　さて、もう1つの大きな疑問の声は、何か新しいOSSプロジェクトをスタートするのに、なんで募金なんかが必要なんだというものです（Hacker Newsの議論のスレッド）。Gitを作ったLinusが募金なんてしただろうか、という心情的な反発です。Yehudaさんは、RailsやRuby関連だけでなく、SproutCore（後にEmber.jsと改名）などでも広く知られた多産なOSS開発者なので、今回のTokaidoプロジェクトはOSSカルチャーに悪い影響を与えかねないという懸念の声もあります。

　ただ、すでに2万5000ドル（約200万円）の募金に対して、634人から4万4000ドル（360万円）の資金が集まっているところを見ると、こうした懸念の声よりも、むしろOSS開発のあり方として共感している人が多いようにも思われます（ただし、2日前にプロジェクト名とともに発表されたところによれば、Herokuと、BugHerdの2社が企業スポンサーとして支援することになったようなので、金額については企業スポンサーの比重が大きいのかもしれませんが）。

　これまでにもOSSプロジェクトは、企業に雇われたハッカーたちが取り組むものが多かったわけで、これらの開発者たちは間接的に報いられてきたわけですが、YehudaさんのTokaidoプロジェクトはもっと直接的です。もしRails.appが欲しいという人が十分な数いてオレの実績を信用してお金を出してくれる人が十分にいるならRails.appを作る、というわけですから、確かにこれまでのオープンソースのプロジェクトと、ちょっと違う感じがします。

新しいOSSの開発スタイルとなるか？

　これを書いている私自身は大変素晴らしい取り組みで、上手く行ってほしいと願っています。困っていないとはいえ、確かにRails環境の構築や維持は、必要以上に面倒だと思いますから、Rails.appはほしいです。

　それより関心があるのは、これが新しいOSSの開発スタイルとなるか？ という点です。

　何か問題を持つ人が一定数いて、それを解決するコードを書く人に対して対価を支払うというのは、とても健全なソフトウェアビジネスのあり方に思えます。これまでOSSそのもの、あるいはOSSを使ったソリューションを提供する企業が、受益者とOSS開発者をバルクで結びつける中間的なブローカーの役割を果たしていたのだと考えれば、インターネットによる直接的でミクロな契約が可能となった今、実は新しいOSSの開発スタイルとしてTokaidoモデルも、相対的な数は少なくても成立し得るのではないかと思えるからです。

　十数年前、フリーソフトウェア財団のリチャード・M・ストールマンにインタビューしたときに、まさにこうした開発モデルを説明されて、私は面食らった覚えがあります。例えば、テレビ録画機能を持つセットトップボックスに新しい機能がほしい人たちが数百人いたら、この人たちは開発者を雇えばいいというのです。このとき、セットトップボックスのソフトウェアも、追加ソフトウェアもGNUでいうところのフリーであって何の不都合もないだろう、と。理屈はそうかもしれないけれども、私にはそんな世界がやってくるようにはとても思えなかったことを思い出します。いま、YehudaがRails.appでやろうとしていることは、開発者向けツールというニッチなものですが、まさしくストールマンが言っていた開発モデルではないか、と私には思えるのです。

　Tokaidoはまだアナウンスされただけで、5月12日に受け付けを終了してプロジェクトが開始となるようです。どういう成果物が出てくるのか、またOSSコミュニティを含む周囲の反応がどういったものになるのか、しばらく目が離せません。

　先週、地域RubyコミュニティのAsakusa.rbの定例ミートアップにDave Thomasさん（ブログ）が遊びに来ました。Daveさんといえば、いくつかの定番Ruby/Rails関連書籍の執筆者として、また、2001年に公表されたアジャイルソフトウェア宣言の初期の17人の署名者の1人として、ソフトウェア開発者の間ではつとに有名です。1999年には「達人プログラマー―システム開発の職人から名匠への道」という本を共著で書いています。また、全米でユーザー数が数十人程度だった14年ほど前からずっとRubyユーザーでもあり、Rubyコミュニティでは「偉大な先人」という感じの人です。このブログをご覧の方であれば、「RailsによるアジャイルWebアプリケーション開発」の共著者の1人といえば分かるかもしれませんね。

Pragmatic Bookshelfの販売実績を聞いてみた

　Daveさんは、技術系電子書籍に特化したオンライン出版社「The Pragmatic Bookshelf」の共同創業者でもあります。本当はAsakusa.rbの場では、主にRubyやアジャイルの話をしていたのですが、ここではPragmatic Bookshelfについて私が聞いた話をまとめてみたいと思います。

　Pragmatic Bookshelfは、紙の書籍よりもボリュームは少な目ながらも、より素早いタイミングで話題の技術を取り上げて、PDF、epub、mobi形式でリリースするという電子書籍ベンチャーです。今のところ英語の書籍だけですが、Ruby系の人なら1冊や2冊ぐらいは買ったことがあるかもしれませんね。例えば、2011年４月にRuby on Railsが標準採用としたことで話題となった「CoffeeScript」の解説書は、Pragmatic Bookshelfでは2011年8月にリリースされていますが、老舗のオライリーがCoffeeScript本を出したのは2012年1月、同じくアジソンウェズリーが出すのは2012年7月の予定となっていますから、いかにPragmatic Bookshelfが早いかが分かります。

　電子出版なのだから早いのは当然と思われるかもしれませんが、実はPragmatic Bookshelfの出版の素早さ支えているのは、独自の入稿・編集システムです。「達人プログラマー」の共著者で、後に共同創業者となるAndy Huntさんと書籍を書いたとき、その本に掲載するコードサンプルの管理方法や原稿のバージョン管理について従来の出版社のやり方に飽きたらずに、自分たちでシステム化。レイアウトやタイプセッティングの仕事まで自分たちでやってしまったそうです。

　当時を振り返って、Daveさんは「自分たちは、出版について何も知らなかったので、あらゆる間違いをおかしてきた」といいます。素人の無知は怖い、という類の話かと思いますが、ともかく、このときに作り上げたシステムがPragmatic Bookshelfにつながっているという話です。

　Pragmatic Bookshelfの著者（多くはソフトウェア開発者）は、執筆に当たって、その書籍用のレポジトリ（入稿先のストレージ）とCUIの編集ツールのようなものを与えられるといいます。このツールにはJRubyが含まれていて、Ruby版のmakeコマンドとも言えるrakeコマンドを使って、書籍のバージョンアップ（追記、誤植の修正など）ができるそうです。誤植や誤記の修正というのは、紙の本だとそもそも重版がかかった場合に対応ということになりますし、「読者→著者→編集者→印刷所→書店→読者」とグルっと回ってこないと直りません。これがrakeコマンド一発で「読者→著者（rake）→読者」となる、ということですね。私もこれまで4冊ほど買っていますが、ときどき書籍のバージョンアップのお知らせがメールで届きます。ソフトウェアと違って、１度読んだところをバージョンアップされても読み返さないんだけどなぁと、やや矛盾も感じなくはありませんけど。

「古い出版社は出版とは何かが分かってないよ」

　出版や編集のイロハを知らなかったというDaveさんですが、一方、従来の出版社については手厳しい意見をお持ちです。「古い出版社は出版とは何かが分かってないよ」といいます。

　1冊の本が5年も10年も継続して売れる時代には、じっくり時間をかけて本を作っていました。そうしてできた書籍一覧リストこそが価値だと、従来の出版社は考えていた、と。でも、「もう書籍だけが選択肢じゃなくなったんだ」とDaveさんは言います。紙の本と原価構造やビジネスモデルが異なるので、ページ数（ボリューム）についての制約がありません。上記のCoffeeScript本ようにタイム・トゥー・マーケットをぐんと縮めることで需要を掴んでいる、というわけです。Pragmatic Bookshelfは、未完の状態であっても書籍を“ベータ版”として読者に届けることを始めた出版社の1つです。

　Daveさんは、「読者を犯罪者扱いしてはいけない」とDRMについても批判的です。Pragmatic Bookshelfは、“ソーシャルDRM”と呼ばれるアプローチを、最も早く取り入れた出版社の1つです。PDFやepubには購入者の名前が刻まれます。これが必要十分な抑止力となってカジュアルコピーを防ぎます。Pragmatic Bookshelfの読者はエンジニアたちなので、ものの数分もあればPDFファイルから名前を消し去ることもできるでしょう。この意味ではPragmatic Bookshelfの本は、完全にDRMフリーです（名前が刻まれる以外、物理的なコピーに制限はありません）。でも、今のところ、Pragmatic Bookshelfはこれで上手く儲けが出ているようです。うまく行っている理由が、個々の読者の良心によるものなのか、周囲の目によるものなのか、商品がニッチ市場対象だからなのか分かりません。

　どのぐらい儲かっているのか？

　これまで200タイトル以上の書籍をリリースして、すべての本が黒字。売れない本で3000から4000部、最も売れる本で十数万部といい、Daveさんは「本業より多く稼いでいる著者もたくさんいる」と言っています。日本の技術系出版だと、最近は初版で3000部も刷れれば御の字（売れれば、ではなくて、刷れればです）。1万部も売れたらベストセラーかと思いますが、まさにケタ違い。日本語圏と英語圏ではやはり対象読者数が1桁違うのだなと思います。ちなみに、Pragmatic Bookshelfでは章立ての構成や校正作業を行う編集業務は外部のプロに委託しているそうです。

　Pragmatic Bookshelfの本は紙版で30～40ドル、その電子版は3割引きの20～30ドルというところです。紙の本はこれまで100冊ぐらいしか売れてないそうなので、売上のほぼすべてが電子版ということでしょう。1冊当たり2万部ほど売れると仮定すると、Pragmatic Bookshelf全体でこれまでに累計400万部の販売実績。1冊25ドルとすると、1億ドル（80億円）の売り上げということになります。逆に1冊25ドルで2万部売れれば、1ドル80円として売り上げは4000万円。教えてもらっていませんが、著者の取り分は少なく見積もっても5割ぐらいでしょうか（ちなみに従来の出版社だと著者の取り分は7～15％程度）。とすると、2000万円。これなら昼間の仕事をやめて、本気で本を書こうという人も現れそうですよね。

　Daveさんが、RubyやRailsについて何を語ったか気になる方もいるかと思いますが、その話はまた改めて。

　「オレ、入社2週間で大きな決裁を通しましたよ！ まだ試用期間中だったのに（笑）」。JRubyのコミッターで、Rubyコミュニティで広く知られた大場光一郎さんに久しぶりにお会いしたら、ちょっと興奮気味にこうおっしゃるのですよ。具体的な数字は書けませんが、確かに、ふつうの企業なら1週間や2週間で決まるような金額ではありません。まして入社2週間の試用期間中の社員の提案です。

　大場さんは2011年12月に、日本で5本の指に入る大手SIerを退職し、ソーシャル・ネットワーキング・サービス「GREE」を運営するグリーに入社したというではありませんか。そして、あまりの2社のスピード感の違いに驚いているというのです。Developers Summit 2012（通称デブサミ）が終わった後の飲み会でお話を伺ったのですが、水を得た魚とはこのことかというほど楽しそうに、新しい仕事上のチャレンジについて話をされているのが印象的でした。

　大場さんといえば、日本のRubyistの間では「JRubyの人」、「エンタープライズRubyの人」として有名です。大場さんが六本木方面の会社に入社したらしいとは、私もうっすらと察していましたが、グリーだったとは知りませんでした。そして、転職を考えるようになったきっかけの1つが私の暴言だった（大場さんの転職報告ブログ）ということも知りませんでした……。

　ともあれ、入社したての試用期間中の社員が通したとはとても思えない「大きな決裁」の顛末は以下の通りです。

GitHubを社内で使う＝ソーシャルコーディングの採用

　従来のオープンソースの発展形ともいえる“ソーシャルコーディング”というムーブメントが起こっていることは、Rubyistの皆さんならご存知ですよね。ソーシャルコーディングをテーマにデブサミで講演した松田明氏によれば、GitHubが標榜する“ソーシャルコーディング”で起こったことは、人民によるソースコード所有が実現し、コミッタ階級によるアンシャンレジームが崩壊した革命なのだということになります（発表スライド）。ソーシャルコーディングとは、近代史にたとえていえばフランス革命に匹敵するオープンソース界の革命だと。……、ちょっとネタっぽい比喩だけを切り出してしまった感もありますので、元のスライドも是非ご覧ください。ネタっぽい感じもありますが、英国の「Gov.uk」のようなプロジェクトを見ていると（参考記事：英国政府、新ポータルGov.ukをクラウド、アジャイル、Rubyで開発。ソースはGithubで公開 - publickey ）、「人民によるコードの所有」とか「コードを読み書きする権利」といったものが、あながち絵空事とも言えない時代なのかなと思います。Gov.ukのレポジトリのコミット履歴を眺めると、委託された人々だとはいえ、作っている人々の顔が見えるわけですよ。パッチだってウェルカムなのでしょう。

　IT業界をウォッチしている私のようなジャーナリストの目にも、これは大きな潮流と映っています。1998年ごろ、それまでフリーソフトウェアと呼んでいたものを「オープンソース」と戦略的に言い換えてオープンソースムーブメントが始まったときと同じか、それ以上のインパクトをソフトウェアの世界にもたらすのではないかと感じています。ソーシャルコーディングを実践するコミュニティにあるのは、気軽にパッチをコミットし合う文化で、GitHubはそれを支える優れたプラットフォームです。パッチという形でコード片を投げ合い、行単位でコメントをし合うために必要な諸々の機能を提供しています。GitHubには、今やCI環境も統合されています。

　GitHubでは有料でプライベートレポジトリが持てますから、実はオープンソースだけでなく、企業内のプロジェクトで使われるケースも増えています。名前は書けませんが、「うちのプロダクトもコードはGitHubにありますよ」という話を聞く機会が増えました。私自身も、現在推進中の社内プロジェクトでGitHubのプライベートレポジトリを使っています。委託先の開発者たちがGitHub上で“ソーシャルコーディング”している様をリアルタイムで眺めつつ、ときどきpull requestを送ってみたりしています。コードと、それに付随する会話や議論、顔アイコンが一緒に並ぶことのメリットは計り知れないなと感じています。GitHubで日々コードと人の動きを追うことで、発注側としてプロジェクトやコードを所有しているという感覚が持てますし、実装方法に悩みながらもわいわいと作っている生の姿が見え、一緒にプロジェクトを進めてモノを作っていっているという感覚があります。

　というわけで、私はGitHubはソフトウェア開発のあり方を変えつつある、超イケてるサービスだと思っています。「Webのソーシャル化」という流れの中で必然的に変わってきた開発スタイルと見ることもできるかもしれません（3年ほど前に「ソーシャル化するOSS開発者たち」という記事を書きました）。そういう見方をするのなら、GitHubは「ソーシャル」「コーディング」の2者を融合させたプラットフォームの最先端ということになるかと思います。

　現場のRubyistの方々は、とっくの昔にこういうことを感じていて、「弊社でもGitHub採用を！」と社内で呼びかけ、実際に動いてみたという話を複数の方から聞いたことがあります。ただ問題もあって、とある大手ITコンサルでは、git/GitHubを採用するために、社内の説得、教育に1年かかったと聞いたこともあります。顧客のソースコードを預っているのだからGitHubとの間でNDAを結ばないとリスクが大きすぎてコードなんて置けないよ、という事情もあったようです。

　セキュリティ上の理由でGitHub上にソースコードが置けない場合、実は「GitHub Enterprise」という選択肢があります。これは一種の仮想アプライアンスで、適当なサーバにGitHubから提供されるOVF形式のイメージをマウントして起動すると、そのサーバがGitHubそのものになるというものだそうです。デーモン類もGitHubと同じものが動き、非同期のバッチ的なものもちゃんと動くそうです。バージョンアップでGitHub本家にキャッチアップできるといいますから、なかなか良い「プライベートクラウドサービス」だと思います。

書類なし、説得すべきはCTOの、ただ1人

　大場さんは、グリーに入社してすぐに「GitHub Enterpriseを採用すべき！」と社内で発言し、それから1週間足らずで採用に至ったそうです。私には結構な金額に思えるのですが、決裁には書類を1枚も書く必要がなかったと言います。

　「前職の経験から、これは稟議書に10個ぐらいハンコが並ぶ“スタンプラリー”の始まりかなと思ったんです。でも、実際にはCTOに説明をして、コーポレートの経理部長にGitHub Enterpriseのオンライン申し込みの最終画面にまで行ったPCを手渡してクリックしてもらっただけで、1枚も書類を書かなかったんですよ。このスピード感は驚きでした」

　最初にCTOにGitHub Enterpriseの説明をしたときには難色を示されたそうです。そこで「誰と誰を説得すればいいのでしょうか？」と聞くと、そのCTOは「うーん、オレかな？」とだけ答えたのだとか。

　一晩経った翌日、CTOが「あれ、いいんじゃない？」と言って採用が決定。コーポレートカードの番号を入力してボタンを押す経理部長に対しての説明も、ものの数分だけで完了したといいます。インフラチームの協力ですぐにVMも立ち上があり、GitHub Enterpriseの社内運用が始まったそうです。

　※追記：書類を書いていないのは発案者の大場さんであって、グリーの社内で稟議書類が回らなかったわけではありません。CTO秘書が稟議書を起こしたということです。一部上場企業なので、この辺は当然でしょうか。いずれにしてもすごい速さです。

　驚きのスピード感ですが、合理的すぎて私は鼻血が出そうです。大企業で10個もハンコが必要だったら、「ジットハブなんて聞いたことがないぞ。大丈夫なのか？」という人が2、3人はいそうです（GitHubはギットハブと読みます）。そうでなくても、「説明させたがる」「意見を言いたがる」「採用が難しい理由やリスクを並べたがる」の3つの“ガル”が待ち構えていそうな気がします、ガルって何だか分かりませんが。「フィージビリティ検証タスクフォース」とか、ナントカ委員会とかで関連部署総出の週1の会議体が発足して、“情報共有”と“勉強会”に数カ月かかりそうです。「オレ、先週のやつ出てないんで、情報共有よろしく」みたいなメールが飛んできて、プロジェクト担当としては思わず、「知らないとか、分からないとか、自分で勉強しないっていうなら判断しようがないんだから、せめて黙っててくれませんか」と一気呵成にメールにしたためて威勢よく送信ボタンを押す……代わりに、ぎゅぎゅぎゅっとメール消去ボタンを画面に押し込みつつ、サラリーマンの悲哀にすすり泣く。そんな姿が目に浮かびます。

　あ、上の段落は私の想像の翼の奔放なる飛躍によるものです。ブログだからって、スミマセン。調子に乗りすぎました。しかし一方、私の想像でしかない架空のシーンに「そうそう！」と画面の前で頷きすぎて液晶画面に頭を突っ込んでいる方も多いのではないかと思ったりしています。

　ちなみに、DeNAさんもGitHub Enterpriseを使っているそうですよ。複数の関係者の口ぶりからすると、クックパッドさんが採用する可能性もありそうです。

数千台単位のサーバを操る快楽!?

　大場さんは現在、数千台のサーバに対してソフトウェアをデプロイする作業を刷新すべく取り組んでいるそうです。今のところ、グリーではまだSubversionとGitが混在するリポジトリからコードを展開しているほか、多数のサービス間の整合性を取る必要があることから、デプロイ作業が職人芸になってしまっているという話です。これを、TwitterのようにP2Pを使ったインフラで置き換えたい、ということです。すごくチャレンジしがいがありそうですよね。グリーでは、自分で問題や課題を見つけて手を上げれば、それでプロジェクト担当になるという文化があるそうです。

　お話を聞いていると、「こんな職場があったのか」と言わんばかりに大場さんは本当に楽しそうにエンジニアリングの話をするのですね。前職のSIerでは、「エンジニアとしては給与水準がマックスに達していて、管理職になる以外にキャリアパスが見いだせなかった。グリーに転職して給料が上がった」ということですから、幸福な転職だったのだろうと思います。1000人のPGを率いて基幹システムを作るのもやりがいがあることなのでしょうけど、1人で1000台単位のサーバを操るのって、「新しい技術に触れること」「コンパイルが速いマシンを使うこと」というエンジニアの二大快楽に続く、クラウド時代の最高の愉快の1つではないかという気がします。P2Pデプロイインフラを設計して、それが実際に動くのを見届けるのって、壮大に計画した1万枚のドミノ倒しに似た快楽がありそうです。ドミノが途中で止まってしまったかのごとく、アプリのバージョンアップでデータに不整合が蓄積していく、決済系は問題はないが、ユーザーが不具合に怒り始めて運用チームの現場に緊急事態アラートがガンガン鳴り響く、、、エキサイティングなエンジニアリングじゃないですか！

　グリーぐらい規模が大きくなると技術的に楽しいチャレンジがあるのでしょう。そういうことを言うと、「でも、やってることがゲームでしょ。しかも、褒められたビジネスモデルじゃないじゃん」という反応が返ってきそうです。私もそこを大場さんに聞いてみました。元々大場さんはソーシャルゲームをやる人ではありませんでしたが、入社後に、外部から見ていたときと印象がガラリと変わったと言います。ひと言でいうと、ソーシャルゲームの多くは、良くできていて面白いということです。私自身には判断できるだけの材料もゲーム経験もありませんが、少なくとも大場さんがソーシャルゲーム業界をネガティブに捉えていないことが私には分かりました。

“遅行指標”グループからの離脱

　さて、だいぶお調子者風に書いてしまいましたが、真面目な話、大場さんの転職は、いまの日本のIT業界、あるいは日本のサービス業関連の企業社会の縮図のように私には思われるのです。硬直して成長が低い業界もしくは企業群から、より生産性が高い業界や組織へと人材が動き始めた、あるいは動くべきということです。サービス業は、外国に行って資源を掘り起こしたり大きな船を作るような産業と違って、ビジネスモデルと人材が全てというところがあります。クラウド時代になって、IT業界はますますこの傾向を強めています。

　日本のRubyistなら多くの人が知っていることですが、“エンタープライズRuby”を標榜していたと言っても良いRubyistが、大場さんを含めて3人ほど立て続けにWeb系の企業へ転職しました。エンタープライズ分野へのRubyの普及は難しかったということなのかもしれませんが、逆の見方もできるでしょう。

　例えば、マイクロソフトがNode.jsやHadoopをAzureで採用するというニュースが流れたとき、従来なら「マイクロソフトがNode.jsやHadoopを採用！ つまり、これらの技術は本物」と考えたのかもしれませんが、今は逆です。「エンタープライズで採用されるぐらいに良い技術」というのは古い発想で、今は「やっとエンタープライズも●●●を発見（採用）したのか」という順番に思えるのですね。もはやエンタープライズは技術者にとって、”遅行指標”なのではないかと。

　そう考えると、RubyのようなLLや、GitHubなど開発生産性を上げられるツールを採用できない「IT企業」のほうこそ、優秀な人材に見限られているのではないかという風にも思えてきます。人が会社を辞めるのは「この会社（業界）に未来はない」と悟ったときです。

　「選ぶ→選ばれる」という関係は、かつて「会社→人」「会社→技術」だったのでしょう。今は「人→技術（会社）」と逆向きのベクトルが強まっているようにも思えます。技術者にとって、現場経験は一種の投資です。どういう技術が使えるのか、どういう技術課題が与えられるのかによって10年後のスキルや実績に差が出ます。ですから、より技術的にチャレンジができるところへ技術者が流れるのは自然なことではないでしょうか。

　クラウドを作ったり、それを生かしてサービスを運用するというのは、コンピュータサイエンスに基づくまっとうなエンジニアリングが求められている分野です。ここでは大きな価値が生まれていると思います。

　以前、大手SIer幹部の方と雑談していたとき、こんなことをおっしゃったのを思い出します。「SIにコンピュータサイエンスなんて要りませんからね」。それはその通りなのでしょう。しかし、要らなくなってしまったのは、コンピュータサイエンスを適用する分野を掘り当てようとしてこなかった“SI”という業務のほうなのではないかと思えなくもありません。コモディティ化したSI業務に関するスキルは海外にアウトソースされ、案件はクラウドで低価格化が進んでいます。

　全く異なる2つの業種を一緒くたに論じてしまった感もあるかもしれませんが、私には大場さんの転職が“遅行指標”グループから先頭集団への移行に思えたのでした。大場さんが1年後のデブサミで、「GREEにおけるP2Pデプロイ・インフラの設計と運用」という講演をして他社のエンジニアからも喝采されるような日を楽しみにしています！

　2月16日、17日の2日間、東京・目黒でDevelopers Summit 2012（通称デブサミ）が開催されました。2日目の午前中に、IIJが現在クローズドβとして開発中のPaaS「MOGOK」の発表がありました。IIJの藤原秀一氏（プラットフォームサービス部 プラットフォーム開発課 課長/Rubyアソシエーション）によるサービス紹介です。

　MOGOK自体は、すでに昨年9月に概要が発表されていて、＠ITでも報じています。今回の講演で少しサービスの輪郭が具体的に見えてきました。箇条書きでまとめると以下の通りです。

• 現在クローズドβ版は50人ほどに使ってもらっている
• 2012年の1Qか2Q辺りにオープンβ、年内に有償サービス提供
• オンラインサインアップ（SDKをダウンロード可能）
• GitリポジトリをIIJ側に用意（1アプリあたり100MB）
• Gitリポジトリから実行環境への自動デプロイ機能
• 開発環境、本番環境としても使える
• リクエストルータがリクエスをさばくので、アプリ開発者はDBやWebサーバを個別に指定しなくても良い
• Webプロセス、DBプロセス、Jobプロセス（予定）の3種を提供
• CRuby 1.8.7または1.9.2
• LinuxとWindows向けのSDKを用意
• CUIツールの「mogok」コマンドが利用可能で、mogok create/mogok rake/mogok deployなどができる
• bundlerでRubygems.orgから任意のgemをインストール可能。GitHubからもgem入れたいという声もあるので、幅を広げていきたい
• アプリサーバはThin 1.2.11
• アプリサイズはメモリ200MBまで（今後拡張していく）
• DBサーバはMySQL 5.5
• InnoDBのみサポート対象
• 準同期レプリケーション構成（2台構成で運用している）
• ノンストップ機能（マスターがこけてもスレーブを自動昇格する機能）
• 複数世代のバックアップ機能あり
• DBサイズは100MB
• アプリのアクセスURL名は、mogok-sample.ruby.iijgio.comなどになる。

Herokuソックリ？

　ざっくりした印象としては「Herokuソックリ」です。Gitのレポジトリを使ってデプロイするところも、CUIのコマンドラインツールを使ってコードをpushするところも、コマンド名にherokuを使うのではなく、mogokと打つという以外は同じだなと思いました。目立つ違いといえば、Rubyの処理系をSDKとして利用者にパッケージして配布することでしょうか。Rubyの1.8.7もしくは1.9.2をRPMパッケージやWindows向けインストーラで用意していて、この辺りは、これまでRubyを使っていない利用者に配慮している感じがあります。現在、MOGOKに寄せられている機能要望としては、

• RESTで使えるクラウドストレージ
• Memcachedサービス
• CI環境の統合

などがあるそうです。

　Herokuソックリという風に見ると、MOGOKはちょっと周回遅れの印象もあります。Herokuはサードパーティーによるアドオンによるエコシステムが発達していますし、Facebookアプリ用のSDKなんかもあります。そして、3代目のCedarスタックになってからは、Ruby（Rackアプリ）だけでなく、Node.jsやClojure、Javaも動くポリグロットなPaaS環境を実現しています。また、Salesforce.comによる買収後にはDatabase.comと連携するなど、クラウド上での業務アプリケーション開発という面でも展開を見せています。

　こうした先行サービスにMOGOKがどう追いついていくのかも注目ですよね。今のところ、MOGOKのメリットとしては、サービスが東京のデータセンターにあって、高品質、低遅延が期待できることや、IIJというブランド名を出すと稟議書が通りやすそうだということとか（重要ですよ！）、日本語サポートを期待できることでしょうか。もう1つ、期待できるように思えるのは、今回IIJのMOGOKの開発には、ネットワーク応用通信研究所（NaCl）が関わっているということです。NaClといえば、まつもとゆきひろさんほかRubyコミッターも在籍する、Ruby技術者のトップ集団です。今後の展開に期待したいところです。

　2011年12月19日に集計が完了した「＠IT自分戦略研究所読者調査 2011年秋期版」で、今後身に付けたいスキルは何ですかとの問いに対して、「Ruby on Rails」を回答に含めた人の割合が30.2％となりました。昨年同時期の調査で24.2％だったものが大きく伸びています。現在保有しているスキルとして「Ruby on Rails」を回答に含めた人は、7.1％ですから、「今はまだやっていないけど、これからやってみたい技術」としてRuby on Railsの人気が高まっているものと見て良いのではないかと思います。Objective-Cも同様に人気で、市場からの開発者需要を反映しているのかもしれませんね。

　この調査は、＠IT（アイティメディア）が年に1度、継続して行なっているものです。ちょうど1年前に保有スキルとしてRuby on Railsを上げた人は2.8％、身に付けたいスキルとして上げた人は24.0％でした。つまり、昨対比で「2.8％→7.1％」（保有スキル）、「24.0％→30.2％」（習得希望スキル）と、「Railsができる人、できるようになりたい人」ともに伸びています。昨年の調査ではTwitterやFacebookでの呼びかけをしていなかった分、少し母集団が違っていて、平均年齢が今年は2.4歳ほど下がっています。その影響を差し引いても、傾向としてはRuby on Railsへの注目度が高まっているということは言えるかと思います。

　調査はWebアンケートで行いました。リンクは＠IT自分戦略研究所に置き、同Facebookファンページ、同Twitterアカウントでの呼びかけを行いました。調査期間は2011年11月14日～11月22日、サンプル数は550。回答者全体の平均年齢は36.9歳で、30代前半がボリュームゾーンとなっています。職種としては「システム分析・設計/SE」が21.6％、「プログラミング／テスト」が14.3％と多くなっています

（情報開示：私は＠IT編集部のスタッフとして、Ruby on Railsの資格試験「Rails技術者認定試験」に運営組織にメンバーとして参加しています）

　昨日（2011年12月15日）の夜、東京・六本木で、Heroku Drinkupのイベントが行われました。セールスフォース・ドットコムのイベント、「CloudForce 2011 Japan」のために来日していた、HerokuのMorten Bagai氏やKeith Rarick氏が会場に来て、日本のHerokuユーザーやRuby/Rails関係者らと交流していました。Herokuは今やポリグロット（多言語、多プラットフォーム対応）なPaaSなので、Node.js方面からの参加もあったようです。100人前後集まって、大変盛況でした。

　Heroku関係者や、Amazon Web Services（AWS）の方とお話しているときに、当然のように「Herokuは、いつ東京に来るのか？」が話題となりました。HerokuはAmazon EC2で動いていますが、東京リージョンでは動きません。もちろん、太平洋を往復する数百msの遅延を気にしなければ、日本から北米リージョンのHerokuを使うことに何の問題もないわけですが、遅延は小さいに越したことはありません。静的ファイルをCDNに置くなどの工夫も少なくて済むケースがあることでしょう。

　例えば、Cedexisという企業のMarty Kagan氏が公開した各種クラウドのレスポンスを可視化した資料（PDF）から2枚ほど以下に引用します。計測は2011月1月で東京リージョンが入っていませんが、傾向は分かります。当然、近いほど応答時間は短いですね。

　東京リージョンでHerokuのインスタンスが動く日が来るのか、それはいつなのかということについて、今のところ公式見解は発表されていません。しかし、Heroku関係者らいわく、東京リージョンに限らず、ヨーロッパからの要望も多いので、マルチリージョン対応は具体的に検討していて、2012年中にも提供できるのではないか、ということでした。公式見解ではありませんが、期待できますね。

　難しいのは、Add-onsのようです。MongoHQやMemcache、REDIS TO GOといったサービスは、同一データセンター内か、少なくとも地理的に近いところで動いてなければ意味がありません。Herokuのポテンシャルをフルに提供するには、これらサードパーティのサービスプロバイダにも一緒に東京リージョンサポートを開始してもらう必要があります。

　Add-onsの扱いも含めて、現在は、どうやってマルチリージョンサービスを提供するのが正解か、それを検討している段階といいます。HerokuはHTTPルーティングにErlangベースのルーティング・メッシュを構築していますが、これをグローバル、マルチリージョン対応で透過的に動かすことができればベストかもしれません。開発者はどのリージョンのデータセンターにデプロイするかを気にせずに、Heroku側が複数リージョン（複数データセンター）の動的バランシングをやってくれる、というモデルです。利用者の8割が日本からであるサービスで、10個のDynoを立ち上げると、自動的に8個のDynoが東京リージョンのEC2で動くというようなイメージでしょうか。しかし、データベースはどこに置くのよ、大陸間レプリケーションとかどうすんのよとか言い出すと、とてもシンプルな解があるように思えません。

　もっとも、ほとんどの利用者からしてみれば、グローバルな自動バランシングは不要かもしれません。Facebookアプリで、あっという間に全世界に数千万ユーザーというものなら別ですが、多くのサービスは特定言語、特定地域をターゲットとしているのではないでしょうか。そういうこともあって、Heroku Drinkupに参加していた、あるWebサービス開発者は、明示的に東京リージョンを選択する形でHerokuが使えれば十分だし、サードパーティのAdd-onsについても、徐々に増えていけばいいのではないかと話していました。

　AWSは12月14日に、南米リージョンとしてブラジルに新たに拠点をオープンしました。ますますHerokuのマルチリージョン対応のニーズが高まりそうですね。

　弊社アイティメディアでは、9月13日から9月30日までの期間でオンラインの仮想イベント「ITmedia Virtual EXPO 2011 -転換期のITとモノづくり-」を開催しました。この1のセッションとして、Rubyの生みの親である、まつもとゆきひろさんに1時間ほどお話をうかがいました。

　話の内容は、

• 【前編】
• エンタープライズ市場でのRubyの普及
• 「RiteVM」開発プロジェクトへの取り組み
• 【後編】
• エンジニア間でのRuby人気の秘密
• JavaScript vs Ruby

といったところです。冒頭で聞き手の私がエンタープライズに話を振りすぎたからか、最初のほうは、ちょっと眠たい感じになってしまいましたが、打倒Luaを掲げるRiteVMプロジェクトの野望を語り始めるあたりから、言語設計者としての、まつもとさんの真骨頂という感じの内容になっているかと思います。動画としては少し長めですが、ぜひお楽しみ頂けばと思います！

　釣りタイトルでスミマセン。こういうことなんです。

　Linuxの生みの親であるリーナス・トーバルス氏は、Linuxカーネルというホームランを打ち放ってオープンソース界の殿堂入りをしましたが、比較的最近になって分散バージョン管理システムの「Git」をサクッと実装して、これがまた大きなヒットとなっています。

　Linuxカーネルの開発に携わっている人なら、リーナスのエンジニアとしての腕を認めるところかもしれませんが、そうでない一般人には「幸運児」にも見えかねません。

　「みんなx86で動いて自由に使えるUnixが欲しかっただけ。そのタイミングでおもちゃとしてのLinuxが登場したからみんな飛びついた。ちょうどインターネットが流行し出してサーバも必要だったし、ふと見ればインテルのプロセッサが安いわけ。速いわけ。もうx86サーバでいいんじゃね？」

　と、時代の波に乗った印象があるからです。ところが、リーナスはLinuxだけではなく、Gitを世に出して一発屋でないことを証明してみせました。

　Gitの実用的で高速な実装は、エンジニアとしての腕を証明しましたし、分散開発という大きな潜在ニーズを汲み取ったというマーケティング的な面でも嗅覚を証明したと思います。LinuxもGitも自分が欲しかったものを作っただけかもしれませんけど、少なくとも一発屋ではなかったわけです。Linuxぐらい凄い業績だと、一発で何の問題もないとは思いますけどね。

組み込み市場向けプログラミング言語で再チャレンジ

　さて、我らがRubyの生みの親、まつもとゆきひろさんです。

　Rubyもホームランです。やはり時代の波に乗った感じもありますが、AwkやPerlと同列のスクリプト言語としてRubyが登場した1995年ごろには、「テキスト処理にもオブジェクト指向があったほうがいい」というまつもとさんの主張は、実は広く受け入れられませんでした。当時、オブジェクト指向はCADなど一部の“大きなソフトウェア”のための手法であると信じられていたからです。ところが、それから5年もすると、Javaの流行もあってオブジェクト指向は徐々に一般化しました。今やオブジェクト指向は時代の主流です。

　根っこからオブジェクト指向で、テキスト処理に強く、ほどよく関数型言語の良さも採り入れていたRubyは、時代の先を読んでいたと言えると思います。Rubyは、2004年にRuby on Railsというブームがあったから広まったという言い方をする人もいますが、Ruby on Railsを作ったデイビッド・ハイネマイヤー・ハンソン氏自身は、他の言語ではなくRubyを選んだのは必然だったと言っています。

　リーナスがLinuxに続いてGitで大きなヒットを飛ばしたのと同じことが、Rubyのまつもとさんにもできるでしょうか？ まつもとさんは現在、「RiteVM」というプロジェクト名のもとに、新しい言語処理系の開発に着手したところです。

　RiteVMは、組み込み向けのプログラミング言語です。基本的な文法やスタイルはRuby言語を踏襲し、言語としてはRubyとのことです。ただ、組み込みで使いやすいように設計・実装する予定だといいます。Rubyのフルセットと違い、モジュール化されていて、フットプリントは小さく、コンパイラを含まない実行形式も吐けるようになるようです。

まつもとさんに話を聞きました

　まだ取り組みは始まったばかりですが、ポテンシャルは非常に高いと思います。いま、組み込み系ではブラジル発のLua（ルア）という言語の人気が非常に高まっています。Cよりも抽象度が高く、組み込みスクリプト言語としても使いやすことなどから、iPhoneやゲーム業界などで使われているようです。Luaの文法については、「Programming in Lua」が参考になりますが、GCがあり、イテレータやクロージャが使え、リンクト・リストやキューといったデータ構造も組み込みという感じです。

　Lua人気は今後もまだ上がり続けると思います。組み込みといってもメモリ1バイト、CPUの1サイクルを削るのが至上命題というケースばかりでなく、書きやすさ、メンテナンスのしやすさが求めらるケースが増えているのでしょう。

　まつもとさんに言わせると、Luaでも、まだ抽象度が低く、オブジェクト指向も「JavaScriptと同じで、Luaのオブジェクト指向は内臓が見えちゃっているような感じ」だといいます。

　Rubyとほぼ同じカバー領域を持つPythonは、世界的には人気が高いものの、日本国内ではRubyのほうがプレゼンスが強いですよね。Pythonユーザーになるはずだった人のかなりの割合が、日本ではRubyユーザーになったのではないかと、まつもとさんは言います。同様に、今後10年でLuaが入り込むべき市場において、RiteVMが利用者をLuaから奪うというようなことが起こらないとも限りません。特に日本国内においては。

　もしそうなれば、リーナス同様に、まつもとさんも「やっぱり一発屋じゃなかったんだ」ということになるのかなと思います。今のところ私が聞いている限りでは、「組み込みにRubyだなんて、寝言は寝てるときにいってくださいよ」という反応もあるようです。1995年にオブジェクト指向なんて大げさだいう反応があったのと似ているかもしれません。5年後、10年後にはどうなっているでしょうか？

　さて、以上に書いた話は、実は動画インタビューの一部分を要約したものです。弊社アイティメディアでは「ITmedia Virtual EXPO 2011 -転換期のITとモノづくり-」と題して、オンライン上の仮想イベントを9月13日から30日の期間に実施予定です。このイベントの1つのセッションとして、まつもとゆきひろさんに1時間ほどお話をうかがいました。話の内容要は、

【前編】
●エンタープライズ市場でのRubyの普及
●「RiteVM」開発プロジェクトへの取り組み
【後編】
●エンジニア間でのRuby人気の秘密
●JavaScript vs Ruby

といったところです。最初のほうこそエンタープラズの話が続いたりしますが、話が進むに従って、JavaScriptやV8の話、ErlangVM（BEAM）上に「Elixir」というRuby風の言語が実装されているという話が飛び出すなど、エンジニアの方、プログラミング好きの方にもお楽しみいただけるような内容かと思います。是非、仮想イベントに“ご来場”くださいませ！

　昨日、何気なくつぶやいた以下のTweetが72人にRTされて、個人的な記録となりました（http://favstar.fm/users/knsmr/most_retweetedを見ると、RT数による私の過去のツイートのランキングが見られます）。私のTwitterのフォロワー数は2400人程度と、それほど多くありませんので、これは結構な数です。共感する人が多かったのかなと思ったので、ここのブログでも共有してみます。

　この発言は私自身が感じているところの表明ですが、直前のつぶやきで紹介したArsTechnicaのPeter Bright氏が書いた「Firefox update policy: the enterprise is wrong, not Mozilla」という記事の、大雑把な要約でもあります。

　ArsTechnicaの分析と主張は元記事を見ていただければと思いますが、簡単に言うと、こういうことです。

　Firefox 4、5のリリースと前後してMozillaが採用した新しいサポート方針について、企業ユーザーから不満の声が上がって来ました。Mozillaは古いバージョンのFirefoxを積極的に切り捨てて、セキュリティパッチの提供を行わない方針としました。Mozillaは、2011年中にFirefoxのバージョンを7にまで上げると発表していて、バージョンアップのペースはグッと上がりますから、急加速した感じは否めません。

　これは当然のように企業ユーザーの反発を招きました。業務アプリの多くは、ブラウザについて「サポート対象ブラウザ・バージョン」という形で通常「IE7/8、Firefox 3.5/4」などと限定し、各バージョンについて動作検証などを行うことが多いからです。IE6の市場シェアが未だに高いのは、IE6でないと動かない、あるいは動くかどうか検証されていない業務アプリの存在のために、企業の情報部門がIEのバージョンアップを許可していないから、という理由があります。

　ソフトウェアのモジュール化と連携は、インターネットの登場によって加速していると思います。ある機能を果たすために利用するミドルウェアやフレームワークのAPI、外部WebサービスのAPI、ブラウザのDOMやHTMLのAPI、そしてそれらをラップするライブラリ群のバージョンは、もはや固定しようがありません。数が多すぎるし、それぞれに日々進化すべきものだからです。ソフトウェアが稼働する広い意味でのプラットフォームとなったウェブやインターネットは、毎日変わり続けています。「変化（＝進化）すると困る」などと言って、特定バージョンのみを想定したソフトウェアを作るのは、もはや間違いなのではないでしょうか。ArsTechnicaのBright氏は、悪いのはMozillaじゃなくて、エンタープライズのほうだと言っていますが、私も同感です。

　検証に手間やコストがかかるのは分かります（テストを自動化しましょうよ）。過去の開発の経緯があるのも分かります。しかし、だからといって特定のブラウザを社員や納品先企業に使わせ続け、そのことによって、ほかのWeb開発者やデザイナにコストを転嫁していいわけがありません。

　Ruby on Railsの開発でテストの自動化が強調されるのは、Rubyが動的言語で型チェックが弱いからという理由だけではなく、ライブラリのバージョンを常にアップデートしていて、いつどこかが壊れても、すぐに原因を特定して修正できるようにという意味があるかと思います。ライブラリが変わらなくても、気付けばFacebookのAPIが変わっているかもしれません、それがウェブですよね。jQueryのバージョンは固定したほうがラクに思えるかもしれませんが、いずれ外の世界とのズレが大きくなって、どこかでビッグバン移行することになるでしょう。固定することのリスクは大きいし、固定部分から腐っていくのがウェブなんじゃないかと思います。この意味で、私には業務アプリの多くは腐っているように見えます。

　もちろんこういう話はバランスの問題なので、バージョンを固定するのが合理的なケースも多々あるでしょうけど、たくさんRTしていただいた背景には「もう、エエ加減にせえよ！」という現場の皆さんのフンマンがあるのかなと思ったのですが、いかがでしょうか。

　Ruby on Rails関連イベントの帰り道、会場としてご提供いただいた東京・青山にある日本オラクルのビルを振り返りつつ見上げながら、Rubyエンジニアたちはため息を尽きました。「どうやったら、こんなビルが建つぐらい儲かるんだろうね……」。確かに、ため息が出るほど立派なビルです。

　もう1つ、私の耳に残った言葉は、「でも、RailsのプロジェクトでOracle DBなんて誰も使わないよね」というものです。顧客から指定でもない限り、RailsによるWeb開発ではオープンソースのプロダクトを使うことがほとんどだと言います。オープンソース界隈の開発者の多くは、オラクルのことを遠い存在に感じているかもしれません。むしろ、オラクルのプロダクトや企業文化は、オープンソースと相容れないという風に思っている人も多いのではないでしょうか。私は別にリーナス・トーバルズのようにオープンソースだけが唯一正しいソフトウェアの作り方だというつもりはありませんが、2つの異なる大陸だ、というぐらいに距離があるように思います。ちょうど、ソフトウェア開発の世界にも全く性質の異なる5つの世界が存在するのだと、2002年にジョエル・スポルスキーが指摘した（Five Worlds）のと似た話で、特に大規模エンタープライズは、オープンソースとは違う大陸なのかなという風に思えます（そこに大きな橋を架けているレッドハットのような企業もありますが）。だからこそ、サン・マイクロシステムズがオラクルに買収されるというニュースが流れたとき、「初恋のあの娘も、ついにお金に困って金持ちに嫁ぐのか……。良い人だといいんだけど」という、ちょっと暗い空気がオープンソース界に流れたのだと思います。サンも昔からオープンソースに親和的だったということはありませんが、そこはオラクルとは比較にならないと思います。買収発表直後のJavaOne会場で、当時サンのオープンソース関連の戦略を担当していたサイモン・フィップスを捕まえて、あの製品やこの製品は、これからどうなるんだと私は詰め寄りました。彼は、それは自分にも分からないけど、やれること（GPL化など）はやったから大丈夫だ、と悲しそうな笑みを浮かべたのを思い出します。

　さて、そういう認識で「躍進 日本オラクル 全社最適化戦略」（岩淵明男著、出版文化社）という本を読んで驚きました。

　日本オラクルの社員はオープンということに対して、深い思い入れがある、という一節があるんです。オーマイゴッド！ 私は仰天しました。ちょっと待ってくれよ、と。オラクルがオープン!? えっ!?

　でも、1970年代後半に「ソフトウェアの時代が来る！」といって、当時メインフレームのおまけでしかなかったソフトウェアを主製品として起業したラリー・エリソンの慧眼を思うと、なるほどなと思えるのでした。富士通でKシリーズというオフコンに携わっていた中堅エンジニアが、あるとき雑誌を読んでいてUnixやC、TCP/IPという自分たちとあまりに違う技術の話ばかりしているのに不安を覚えていたとき、このオラクルのオープン戦略に感銘を覚えて転職したという話も、時代背景を考えると納得です。Oracle DBは特定ハードウェアではなく、いろんな計算機で動かすことができ、それは1970年代には特異なことだったというわけです。

　しかし時代は流れて、Jenkinsフォーク事件や、買収後のMySQLの騒動、あるいはAndroidを巡るGoogleとの訴訟沙汰を見ていると、「オラクルのオープン戦略」などと言われても、「えっ!?」という感じです。初期のオラクルが掲げた“オープン”は、あまりにも当たり前になってしまって、今ではオープンソース、オープンイノベーション、オープンコラボレーションと、適当な造語の1つもしたくなるぐらいに、IT業界はもっといろいろとオープンな世界になっています。オラクルはオープンだったのでしょうし、それは今も変わってないと思います。ただ、“オープン”の概念は相対的なもので時代とともに変わるものですよね。

　歴史は繰り返すのかもしれません。

　Oracle DBは、1970年代後半に限界が見えつつあったネットワーク型や階層型のデータベースに対して、エドガー・F・コッド博士が論文として発表したRDBMSを実装した先駆けでした。この辺り、1970年代の10年間に起こった初期のRDBMSの実装の歴史がどうだったか、その後のRDBMS市場でオラクルが勝ち残った理由が何だったのか、それは私にはよく分かりません。ただ、登場時のOracle DBが技術的にも戦略的にも革新的だったのは間違いないことでしょう。

　30年前のオラクルの革新性を、2011年に置き換えてみれば、私はMongoDBの10gen社になるだろうと思います。10genはRDMBSがボトルネックとなり得る、特に大規模なWebサービスという領域において、カラム指向でスキーマレスというNoSQLを最初からOSSで実装しています。そして商用サポートやトレーニング、コンサルというオープンソース時代のビジネスモデルを掲げています。地図で確認して驚いたのですが、10genは何とOracle本社の隣といっていい立地です。

　オラクルでは近年、DB製品のライセンスの売り上げ比率は落ち続けています。それはRDBMSがOSSとしてコモディティ化した一方、Oracle DBがロケット・サイエンスの高コスト製品を指向してしまったことが背景にあると思います。かつてオラクルは、DBによる「オペレーショナル・エクセレンス」を標榜してITを社会へ普及させました。現在は、「マネジメント・エクセレンス」を標榜し、一連の激しい企業買収を通してBIやCRMにフォーカスを移しつつあります。Webの急速な普及によって、各種NoSQLが解決しようとしているような新しい技術領域が登場しているとはいえ、RDBMSと、その上に作り込むビジネスアプリケーションによる社会貢献は、実際まだ始まったばかりなのかもしれません。

　私には米オラクル黎明期の話が新鮮だったと同時に、歴史上、同じ構図が繰り返し現れているのが興味深く思えました。HTML5、Amazon EC2、Ruby、Node.js、NoSQL、Hadoop、iPhone、jQuery Mobile、Facebookアプリ……、全然自分が日々触れているものとは違う技術の話ばかりがメディアに溢れているのに、果たして自分はこのままでいいのだろうか。そんなふうに感じている中堅エンジニアの方はいませんか。その姿は、当時売れていたにも関わらず、オフコンのKシリーズに疑問を感じてオラクルに転職したエンジニアの姿と重なるように、私には思われるのです。

　Amazon EC2の大規模障害で、あちこちのWebサービスがダウンしましたが、印象的だったのはEC2を責める論調が少なかったことです。Ruby向けPaaSのHerokuも同様です。このAWSの障害に起因したHerokuの障害について、Heorkuによるレポートが公開されていて、これを日本のHerokuユーザーのおぐらじゅんや（@junya）さんが抄訳されています。

　Herokuの当該文書を開くと、画面の真ん中に目立つ文字で、

HEROKU TAKES 100% OF THE RESPONSIBILITY FOR THE DOWNTIME AFFECTING OUR CUSTOMERS LAST WEEK.

と、顧客のダウンタイムについて、その全責任をHerokuが負うと書いてあります。また、

IaaSレイヤーでの障害は必ず発生するもの。その障害からユーザーを守ることがHerokuの責務であり、それらの事柄を抽象化することが我々の価値の1つである

と明言しているのがいいですね。この他にも、

• ブロックストレージはクラウド向きの技術ではない
• 1つのリージョン内の複数のゾーンに分散することは、我々が考えていたようなパーティショニングとはならない

など、今回の障害で学んだこともストレートに書いています。英語の原文はアップデート情報など非常に詳細で長文ですが、おぐらさんのほうは箇条書きで読みやすくまとまっているので、Rubyistの方には一読をお勧めします。

　日本Rubyの会とRubyコミュニティで作るオンラインのウェブ雑誌「Rubyist Magazine」（通称るびま）の最新号である第33号が4月5日火曜日に公開されました。技術解説やRuby関連イベントのレポートなど、非常に読み応えがあります。先日、晴れてRubyコミッタの仲間入りをした「リアル厨2」（4月に中学3年生に！）ことShota FukumoriさんによるCRubyのテスト並列化の記事も、タイムリーな感じです。

　Rubyistはもちろん、それ以外のプログラマの方々にも一読をお勧めしたいと思ったのが、チャド・ファウラー氏のインタビュー記事です。チャドさんはRails登場以前にふとしたきっかけでRubyを発見して取り組み、以来、著者、コンサルタント、スピーカーという立場で啓蒙してきたパイオニア的存在です。

　私が軽い衝撃を受けたのは、次のくだりです。

Rails以前を思い返してみると、Rubyistに広く受け入れられる決定版のコーディング規約なんて、とても作れるとは思えなかったね。ほんとうに色んな流派があったんだ。メソッド名をキャメルケースで定義する人たちもいれば、ライブラリのコードは単一のファイルにまとめる流儀の人たちもいた。パッケージ作成に至ってはinstall.rb派とsetup.rb派とRubyGems派がいたよ。

Railsは実際のコードで示すことでコーディングスタイルをうまく根づかせた。例えば「キーをシンボルとしたハッシュを追加オプションとして渡すメソッド」というのは一般的になったと思う。

　メソッド名の付け方に流儀！ まるでJavaScriptのような感じでしょうか。Pythonから来た人と、Javaから来た人とでメソッド名の付け方が違いますよね。「RubyがRailsと一緒に作法や思想込みで広まった」と高橋征義さんは指摘されていますが、それがどういう意味なのか、その一端が具体的なコード例とともに分かります。

　ちなみにチャドさんは元々はプロのジャズサックス奏者だったのに、今では世界的に知られたRubyistという、ちょっと変わった経歴の持ち主です。「情熱プログラマー――ソフトウェア開発者の幸せな生き方」という著書で、こんなことを指摘しています。ミュージシャンの世界では、何度も何度もヘタな音を出して練習を重ね、膨大な時間を費やして技術を習得する。それからステージに立つのが当たり前。一方、今のソフトウェア開発の世界では、実務の中で練習することが多い。開発者は限界ギリギリのところで頑張ることもあるかもしれないが、それは本来は練習でやるべきことじゃないのか、と。

　プログラマという枠を通り越した地点で、現代社会における仕事のあり方、生き方について、模範を示しながらガツンと言ってくれる感じが素敵です。

　で、るびまのほうですが、チャドさんのインタビューのほかにも、（はてブを見たところで）目を引いているのは、「RubyConf 2010のレポート」のようです。Railsを使う上で、今後ますます重要になってきそうな「Rackの仕様解説記事」も、個人的には注目しています。

　こんにちは、＠IT編集部の西村です。画面の前で思わず「サービスの時代が来た！」と叫びそうになったサービスが登場しました。Ruby関連で有名なThoughtbot社の「Copycopter」（コピーコプター）です。

　Copycopterは、ヒトコトでいえば、Webサイト（Webアプリ）で使われている各種文字列（コピー）のリソースを、そのアプリの外側にあるCopycopterのWeb UIを使って編集できるようにするだけのものです。Railsに元々あるi18nのAPIを流用することで、プロダクション環境のコードに変更を加えることなくダイナミックにWebサイトに反映できる「gemライブラリ＋サービス」のサービスです。Railsであれば、gemを入れて初期化時にAPIキーを設定すれば、後はビューの中でメッセージを国際化するのと同様に「t」メソッドを呼ぶだけのようです。

（Gemfileに追加）
gem "copycopter_client"

(初期化でAPIキーを設定)
CopycopterClient.configure do |config|
config.api_key = "81caded18444fc3b60e56622f927bcce"
end

（ビューでは国際化APIで文字列をリソース名で呼び出し）
<%= link_to t(".sign_up", :default => "Sign Up") %>

　Copycopterのサービスをアナウンスするブログのストーリーが冴えています。

開発者：はい、サインアップページはできましたよ。「サインアップ」をクリックするだけです。

クライアント：いい感じですね。でも「今すぐサインアップ」に変えてもらえます？

　ここで開発者はテキストを変更し、もしかしたらCucumberのシナリオも修正する必要があるかもしれません。で、ステージングサーバにデプロイして……、となるわけですが、これには続きがあります。

開発者：はい、「今すぐサインアップ」にしました。

クライアント：でもね、やっぱり元に戻すべきだと思うんですよ。

　そして、さらに1カ月後に……。

開発者：よしっ、サインアップページはプロダクション環境にデプロイできましたよ。

クライアント：そういえばサインアップといえば、何人かの人と話をして、やっぱり「今すぐサインアップ」とするのが結局いいのかなって思うようになったんですよね。

　私はコピー（文字列）をああでもないこうでもないと考える側なので、クライアントの気持ちはよく分かります。雑誌編集者時代には何度も何度も修正して、ページのレイアウト担当に「最終的に決まったものを教えてください！」とよくムッとされたものです。最終的に印刷されたページを見てみないと、分からないことってあるんですよね……。

　こうした修正作業は、それ自体は単純でも、五月雨式に修正依頼が来たり、「結局、元のままかよ！」と手戻り感があったりすると、「もう自分でやれっ！」と言いたくなりますよね、きっと。同様に、開発者の方々も、そういう気持ちになるんじゃないかと想像しています。開発者にしてみれば、文字列リソースなんか周辺視野にかろうじて入っているぐらいで、本質的ではないのだからとThoughbotの人もブログに書いています。でも、Webサイトを作る側にしてみれば、メッセージの言葉選びはとても重要です。恐縮しながら修正依頼をするのではなく、納得がいくまで自分でいじっていたいものでしょう。それを可能にするのがCopycopterでしょう。以下の画面は編集向けUIと、それが反映されたWebアプリの結果です。

　Copycopterのクライアントは300秒置きにサーバをポーリングしていて、変更があればローカルのリソースファイル（YAML）を更新するだけのようです。クライアント側もWeb側も、特別すごいハックという感じではないでしょう。でも、これって、世界中で同じ小さな問題を抱えているプロジェクトがあって、それを解決する今風のアプローチで、歓迎されるのじゃないかと思います。それを月額9ドル（3プロジェクト、4ユーザーまで）から月額49ドル（30プロジェクト、60ユーザーまで）で打ち出して来る、というところに個人的には新しい潮流を感じます。お客さんに対価をいただけるのは技術や実装というよりも、それによってどんな問題が解決するかということだ、というのが、よりハッキリ示されているように思うからです。そして、これまでプロジェクト単位だった「サービス＝対価」の粒度が下がってきているということかと思います。以下、価格表です。

　Copycopterが解決する問題は、自分たちでも解決できるものかもしれませんし、利用すべきソフトウェアもオープンソースでそろうでしょう。Herokuを使えば無償プランで十分でしょう。でも、実装のリードタイムやコスト、運用の手間を考えたら、こうしたサービスを選ぶ方が合理的というケースも多いのではないでしょうか。可用性の上がったサーバ（ネット）によって水平分業しているといってもいいかもしれません。誰もが同じ実装やインテグレーションを繰り返すのはムダです。gemだけ出して、「サーバの方は各自お好きにどうぞ」というのでは、世界中で同じ単調作業が発生します。

　KVSやNoSQLなどのストレージ技術が顕著ですが、ミドルウェアをどう使っていくかというときに、同一データセンター内でサービスとして提供・利用するという「Middleware as a Service」というべきもの（スミマセン、またXaaS用語を勝手に作っちゃいました）が注目ですよね。HerokuのアドオンやAWSの各種サービスですね。さらに、パフォーマンスがボトルネックとならないような、cronサービス、captcha代行サービスなどは、ふつうのWeb APIサービスとしていろいろ登場しています。gem＋サービスで開発者の「かゆいところをかいてあげる」ような有料サービスは、まだまだ開拓すべきフロンティアがあるのかもしれません。

　日本Ruby会議2011実行委員長の高橋征義さんがブログを更新して、今年のRuby会議の開催概要を紹介しています。詳しくは当該エントリを見てほしいのですが、概要は、

 
• 会期：2011年7月16日（土）、17日（日）、18日（月・海の日）
 
• 会場：練馬区立練馬文化センター （東京都：アクセス）
 
• 基調講演：まつもと ゆきひろ、デーブ・トーマス他
 
• Ustあり

というところです。昨年はつくばでしたが、今年は東京です。2006年以来続いてきたRuby会議は、今回が最終回です。今回で最後というのは何も参加者が減ったからというのではなく、むしろ逆で、「拡大する規模にともない、これまでと同様の枠組みでの開催には、さまざまな課題が生じてきている」からで、「総決算として、1つの大きな区切りをつける」ためだそうです。開催趣意書が公開されています。角谷信太郎さんの日記経由で知りましたが、スポンサー向けの案内（PDF）も公開されています。

　年の瀬も（ry

　早速、Ruby／Rails関連のトピックを、私の主観的なランキング形式で振り返ってみましょう（元ネタはRubyInsideのこの記事です）。

1位 Ruby 1.9.2、Rails3などリリースラッシュ

　8月にRuby 1.9.2とRuby on Rails 3がリリースされました。1.9.2というと、Ruby界隈の人でもなければ、なぜ騒ぐという感じかもしれませんが、ある意味ではこれこそがRuby 2.0正式版ですよね。もちろんRuby 2.0は今後登場予定で、matzさんは構想も話し始めていますが、1.8系との違いや寿命を考えたら1.9系はバージョン2と呼んでおかしくないもので、1.9.1がベータ版、1.9.2が正式版という印象です。

　そしてRails 3に関しては、「秒読み段階の「Ruby on Rails 3」登場の意味」という取材記事を書きましたが、まだまだ進化速度を緩めずにマイルストーンを達成。世代交代が始まった1年かなと思います。

　そうそう、3月にはRailsの弟分ともいうべきフレームワーク「Sinatra」もバージョン1.0となっていますね。

　処理系・フレームワークではありませんが、Railsで人気の高いテンプレートエンジンのHAML／Sassもバージョン3.0とメジャーバージョンが上がっています。RubyやRailsの文化を象徴する「無駄を省いたシンプルさ」を体現した文法ですが、この12月には、さらにSlimというテンプレートエンジンが出てきていて、HAMLを超える驚愕のシンプルさや驚愕の新発想があったりして、この辺りも面白いですね。

2位 各種Ruby実装がマイルストーンに

　マイクロソフトの「IronRuby」、ピュアRubyで書かれた「Rubinius」がそれぞれバージョン1.0となりました。ただ、IronRubyについては、ちょっと雲行きがあやしい感じです。マイクロソフトは一時期動的言語の取り込みに注力していて、IronRuby、IronPythonを喧伝し、スタープレイヤーも雇い入れていましたが、ちょっとトーンダウンしていますね。IronPythonについてはとんと聞かなくなりましたし、IronRubyの主要開発者だったJimmy Schementi氏はマイクロソフトを去りましたが、そのときに書いた8月6日付けのブログで、

Overall, I see a serious lack of commitment to IronRuby, and dynamic language on .NET in general.

と書いています。2009年に.NETのDLR（Dynamic Language Runtime）チーム自体が半分に減らされるなど、ちょっと苦しそうです。IronRubyはコミュニティの手に戻して、ということかもしれませんが、実は熱気があった割に.NET上のRubyランタイムにはニーズがなかったということなのではないかと個人的には見ています。.NET開発者にはC#がありますし、逆にRuby開発者は、ことさら.NET環境を使う理由もない、というところではないでしょうか。

　メジャーバージョンではありませんが、JRubyは進歩が激しいですね。夏にはバージョン1.5が出ています。8月末のRubyKaigi2010に来日したJRuby guysの1人、Charles Nutterによれば、バージョン1.6では、gem installでCのネイティブライブラリがJRuby環境にビルド・インストール可能になったり、Android上でも走ったりとマルチプラットフォーム化しています。Win32OLEもJRubyから呼べるようになるそうです。

　もう1つ、気になるRuby実装は「MacRuby」です。2009年末にLLVMをターゲットに大幅に書き換えられたMacRuby 0.5のベータ版がでていて、この12月にバージョン0.8が出ました。今後はバージョン1.0を目指して安定化に取り組むという話です。LLVMはJavaVMのように特定の言語に依存しない独自の命令セットを持つVMで、実行時の最適化も可能なコンパイラ向けインフラ技術です。CやC++、Objective-C、Fortranなどのフロントエンドコンパイラを使ってLLVM上で実行可能なコードを生成できます。MacRubyはJIT、AOT対応のほか、Mac独自の並列処理フレームワーク「GCD」（Grand Central Dispatch）に対応していることなどもポイントでしょう（Rubyのコンパイルや並列処理対応、MacRuby最新ベータ登場）。

　GCDは面白そうだと思うものの、「今さらCocoaで何を書くの？ ネイティブアプリ？」というのが個人的な感想でした。ところが、アップルがMac向けアプリの販売チャンネルをApp Storeに追加するという話になり、急に面白くなってきました。Mac App StoreでRubyアプリを提供可能となれば面白いですよね。例えばちょっとした画像系ソフトみたいなものは、MacRuby＋Cライブラリで書けるかもしれません。

　さて、ランキング形式で10個ぐらい書こうと思ったのですが、ついうっかり1位2位だけで燃え尽き感が出てきました。2010年の振り返りで指摘するべきものは、後は

• MongoDBブーム到来。対応プラグインのMongoidとMongoMapperはどちらがいいかが話題に。結局Mongoidが今はトレンドのようです
• Salesforce.comがHerokuを2億1000万ドルで買収すると発表（初出時、買収額を2桁多く間違えてました……すみません）
• まつもとさんが、Luaを意識した主に組み込み向けのRuby処理系の実装を始めると宣言！

ぐらいでしょうか。結局、全然ランキングになっていませんが、良いお年を！（まだ早い）