私は、Rubyの生みの親、まつもとゆきひろ氏のインタビュワーを務めさせて頂きましたので動画を公開します。

　インタビューは20分の予定でしたが、会場からたくさん質問が出て盛り上がったので延長していたようです。動画は38分ほどあります。

　以下、いくつかまつもと氏の発言を箇条書きでご紹介します。

• 20年前のRuby登場時、「ふつうのプログラマはオブジェクト指向は知らなかった。縁のないものだったと思う」。C++でCADを作るような人とか、アカデミックな世界以外ではオブジェクト指向は普及していなかった。
• Rubyの仕様について検討する「Rubyコミッティー」を作れという提案に対して。「未来をどうするかという話をコミッティーでやってうまく行ったことなんてないので、ちょっとは学習しろよと思います（笑）」
• 2004年に登場したRuby on Railsも、たくさん出てきたWebアプリケーションフレームワークの中の1つで、広く普及するとは正直予想が付かなかった。
• RubyはWeb言語と言われる／見られることもありますが？ 「そんなことを言う人はRubyに関心がないので、いいんですよ。Web言語じゃないと気が付かない人は別にいいんです」。
• CとRubyは9対1の割合でプログラミングしている。Rubyのほうが楽しい。ただ、「プログラマは怠惰なので、手を抜くためには努力を惜しまない。1の部分で気分良く書くために、私はCでゴソゴソ書いている」。
• いまから20年後のご自身の姿は？ 「私の生涯のテーマは、いまと同じ状態をずっと続けること。20年後も現役プログラマでいたいなと思います」。
• いま全力で潰しておかないといけない言語は？ 「Luaとは戦っているかもしれませんけど、私はあまりに言語ラブなので、（言語を）潰すというのは考えづらい」。
• （上記の発言の直後に）「人類のためにJavaScriptは何とかしたほうがいい」
• RubyはWeb分野は制覇した。mrubyで組み込み制覇できる？ 「いや、わかんないですよね、そんなの（笑） ただ、その目的で使いたいときに、そのテクノロジーがあるかどうかは大切。Rubyが使いたいというとき、ふつうの人はRuby作らないですよね。そこに選択肢を提供できればとは思います」
• 国産言語、日本発のプログラミング言語と言われることに違和感は？ 「方便で、日本産と言ったほうがウケがいいときには「日本産だ」と、しれっと言うんですけどね。特にスーツを着た人の前だと、日本から来たんですよーみたいなことをいうと嬉しそうな顔をされるので（笑）。ただ、プログラマとしての私のアイデンティティは、Unixプログラマとか言語好き。その辺でアイデンティファイされたい。そういう側面でいうと、私はたまたま日本に生まれてたまたま日本語が得意なだけ。所属はプログラマ、国籍はプログラマという意識のほうが強い」

　Topazは正確にはPythonではなく、RPythonと呼ばれるPythonのサブセットの言語で書かれています。RPythonは2.7.3互換をなるべく保ちつつ、速度向上を目指した仕様・実装のようです。RPythonとPythonの互換性のページによれば、Django、Flask、SQLAlchemyなども動くようで、サブセットといっても互換性は高そうです。

　【追記1】ライブラリの互換性が高いのはRPythonのほうではなくPyPyのほうでした。訂正してお詫びします。

　【追記2】なぜPyPyが速いのか、ということについては、Ryotaro Ikeda氏の「流行りのJITコンパイラは嫌いですか?」という文書がコンパクトで参考になります。@objectxplosiveさん、情報ありがとうございます！

　RPythonのRはRestricted（制約ありの）の意味で、Pythonを型推論による静的型付け言語のように扱うために作られたようです。RPythonで書かれたコードはCやJVM上のバイトコード、CILなどに変換でき、かつJITが効くので、RPythonは多くの場合、CPythonよりも高速だということです。以下、PyPyのマイクロベンチマークの表を1つ引用します。平均して5.6倍とあります。

　つまり、RPythonを使って実装したTopazというRuby処理系もCRubyよりも速くなる可能性があるということかと思います。すでにあちこちで「全く科学的とは言いがたい」という前置き付きのベンチマークの結果をブログなどに貼る人が現れています。例えば、havenwoodさんのGistにある、差が6となる素数ペアをリストアップする（割とRubyっぽい？）コードの例だと、以下のような結果のようです。

• Topaz-dev: 9.65秒
• Ruby-1.9.3: 44.81秒
• Ruby-2.0.0: 44.09秒
• JRuby-1.7.2: 42.14秒
• Rubinius-2.0.0: 82秒
• MacRuby-0.1.3: 36.29秒

　速度面では、だいぶ期待できそうです。

　ただ、TopazはRuby 1.9.3互換ということですが、今のところ、ライブラリの大部分、標準メソッドの多くが未実装であるほか、スレッドやファイバ、call/ccは未サポート、メソッドの可視性制御も未サポートなど本当に始まったばかりのプロジェクトです（それでもリリース前に10カ月ほど取り組んでいたということですが）。

　RubyとPythonは似たところの多い言語ですが、エコシステムはかなり違っています。特に自然言語処理や統計処理、機械学習など研究者方面ではPythonの利用が多く、ライブラリも充実しています。普及タイミングの問題もあったのかもしれませんが、この違いはかつてのRubyとPythonの処理速度の差から来ていた面もあるのではないでしょうか。RubyはWeb系では活発で大きなエコシステムを持っていますが、こうしたPythonの多様さには一歩及んでいないというのが私の印象です。

　Topazのような「（制約付きながらも）速いRubyを目指す」プロジェクトが出てきたことで、これまでRuby界隈ではあまり見かけなかったようなライブラリや、既存ライブラリの移植が見られるようになるなら、これはRubyistや、「研究でもRubyが使いたいなぁ」と思っているような人にとっては朗報になるのではないかと想像しています。

　そして最近のDHHは、ブログもよく書いています。彼は歯に衣着せぬ発言でも知られています。強い主張を持った（opinionated）なフレームワークの作者らしく、DHH自身もきわめてハッキリと物を言います。攻撃的とまでは言いませんが、IT業界や技術動向などでは割と何かをクソミソにけなしたりということをします。

　DHHが何かをけなすときは、だいたい何らかの鋭い洞察とパンチの効いた皮肉が含まれていて、Twitter上のつぶやきや、ブログは読んでいて非常に面白いです。たとえ話も上手で、印象に残ることが少なくありません。

　そんなDHHのブログを読んでいて最近なるほどなと思ったのが、

プログラミング地獄への道は、時期尚早に適用された“ベストプラクティス”で敷き詰められている――DHH

という言葉です（Winning is the worst thing that can happen in Vegasというブログエントリに出てきます）。

　これは「地獄への道は善意で敷き詰められている」という有名な言葉をもじったものです。この言葉、私はマルクスがオリジナルかと思っていましたが、どうも違うようですね。ともあれ、この言葉の意味するところは、善意から出てきた社会運動や政策提言でも、社会や人類に多大な害悪をもたらす結果になることがあるということです。社会主義は、人間が人間を搾取しない平等を目指すとした「善意」から起こった思想でしたが、結果として著しい停滞や貧困、独裁による地獄が現前したことは歴史に見るとおりです。しかし、それは元々は高邁な理想や人々の善意から起こった政治運動であり社会実験だったわけです。「地獄への道は善意で敷き詰められている」という言葉は、「善意ほど恐ろしいものはない、心せよ」という警句として読めます。

ラスベガスで起こり得る最悪のこと

　さて、DHHの言葉ですが、ブログエントリのタイトルは「Winning is the worst thing that can happen in Vegas」（ラスベガスで起こり得る最悪のこと）となっています。要点は以下の通りです。

　ラスベガスのカジノでは、割と早い段階で客に勝たせるようにできている。しかし、長い目で見れば、ちゃんとカジノ側がその分も含めて全てを取り戻すようになっている。

　ちょっとした勝利の高揚感がギャンブルに対して人を盲目にさせるのです。同様に、「すばらしいアーキテクチャで抽象化できた」という小さな勝利の高揚感によって、プログラマは「早すぎる抽象化」の罠に陥ることがあるというのがDHHの主張です。

　未来コーディングはカジノのルーレットで賭けをするのに非常に似ているとDHHは言います。未来コーディングというのはDHHの造語だと思いますが、将来に必要となることを考えながら設計やプログラミングをすることですね。将来こういう機能が必要だろうとか、こういう風に抽象化しておけば、プログラムの柔軟性が高くなって将来に変更が必要になっても対処できるというような「先を見越したプログラミング」です。これをやり過ぎるなというのがDHHの言っていることだと思います。YAGNI（You ain’t gonna need it. そんなもん必要にならねぇよ）という言葉もプログラマーの間では良く知られていると思いますが、「将来必要になりそうだから」と思って実装する機能は実際には不要なことが多いので実装のシンプルさを優先させるのが吉、ということですね。

柔軟性という名の技術的負債

　技術的負債というのは、整理がつかないまま汚いと知りつつしてしまったコミットや、クイックハックのことばかりではない。もっと潜在的に蓄積してくるのが「柔軟性」という名の負債だ、とDHHは喝破します。

　未来コーディングはルーレットで賭けるのに似て、当たるも八卦当たらぬも八卦。このため、「こういう感じのやつが、もっと増えたときのため」と思って行う、「早すぎる抽象化」「早すぎる抽出」（premature abstraction and extraction）というのは、全て少しずつ蓄積していって、技術的負債となるのだといいます。1970年台に「早すぎる最適化は諸悪の根源だ」と言ったドナルド・クヌース博士の警句に通じる話ですね。

　抽象化や抽出（メソッドやクラスを独立させるようなことでしょうか）、あるいはアーキテクチャー（デザインパターンのようなものでしょうか）といったもので、存在自体がイケてないものというのはほとんどない。「善意」と同じで、「ベストプラクティス」に、それそのものが悪いものというのはない。ただ、必要性がないのに適用されたベストプラクティスは、ほとんどすべて悪である――。これがDHHの指摘です。何の問題もないコードなのに、いきなり「ナントカファクトリー」という名前のクラスを足すとか、基底クラスを継承しているクラスが1個しかないという話でしょうか。DHHは、使わない引数を実装したメソッドや、どこからも呼ばれないパブリックメソッドに対しても「ノー」と言います。

　「設計の世界において最も難しく、そして最も重要なことは、“ノー”と言える信念だ」（DHH）

と、ブログを締めくくっています。

　先を見越した設計、行き当たりばったりでない設計の大切さは言うまでもないのでしょうけど、それがアダとなり得るというDHHの言葉は含蓄があるように思いました。

• Ruby
• JRuby
• Node.js
• Clojure
• Python
• Java
• Gradle
• Grails
• Scala
• Play

ということになりました。すでにScalaやClojureといったJVM言語をサポートしていたので、意外に対応が遅かったような印象もあります。RubyコミュニティがC実装のRubyとUnixのプロセス並列によるスケーリングを好む傾向にあって、JRubyがRuby側からはさほど普及していないことが理由として挙げられるかもしれません。

　Herokuは2011年8月にJava対応を開始していて、すでにJRubyを動かすこと自体はできました。今回は公式サポート開始ということで、特別な設定をすることなく利用可能となったということです。

　既存のCRubyをターゲットとしたRailsアプリをJRubyでHerokuにデプロイする方法は、「Moving an Existing Rails App to run on JRuby」というドキュメントに書かれていますが、

• ローカルにJRubyをインストールしてRailsアプリの動作を確認
• JRuby非対応のgemがあったら何とかする
• Gemfileにjrubyを使うむね、宣言を書く
• pumaなどJRuby対応のWebサーバを使うよう変更する
• Procfileの起動コマンドを書き換える
• PostgreSQLのドライバを pg から JDBC対応の activerecord-jdbcpostgresql-adapterに変える

というような流れのようです。

　ちなみに、サードパーティー製のHeroku向け言語サポートが「ビルドパック」という仕組みで存在しています（リンク）。言語によらず、gitでコードをpushするとHeroku側でslugというバイナリにコンパイルされますが、ビルドパックというのは、このコンパイル手順を書いたスクリプトです。標準サポートのRubyやNode.jsも同様の仕組みを利用しているそうです。サードパーティ製のビルドパックには、DartやGo、Erlang、Perl、Lua、Meteorといった比較的メジャーなものから、EmacsLispやPhantomJS、R、Elixirといったエキゾチック（？）なものまであります。EmacsLispでWebアプリが作れるんですね……。EmacsLispで書かれたNode.jsのような非同期Webサーバ「Enlode」を使うそうです。

　ともあれ、JRubyを使うメリットは、Javaのライブラリが使えることと、CRubyのようにGIL（Global Interpreter Lock）が存在せず、スレッドを使った並列化で高速化がやりやすいことでしょうか。公式サポートとなったことで、JRubyの利用が増えるかもしれませんね。

　こう言われてブチ切れた経験があります。業務アプリのバギーな動作を社内のエンジニアに指摘したところ、テスト用の環境では動いているというのです。「いや、ぼくら本番環境のアプリを使っていて現に困っているので、それを直してほしいだけなんですけど」というと、「でも、ちゃんとステージング環境では動いています。お使いになっているのがChromeのようですが、Chromeでの動作検証はしていません（キリッ」というようなやり取りに絶望しました。原因はブラウザではなく、バージョンアップしたアプリ自体にあったのですが、ステージング環境では問題が発現しなかったんですね。

　というように、開発環境、ステージング環境、プロダクション環境（本番環境）の3つは、大小いろいろな違いがあって、完全に一致させることは難しいものです。手元の環境で動いているアプリが、プロダクション環境にデプロイしたらなぜか動かない、というような経験はアプリ開発者ならお持ちだったりするのではないでしょうか。

　「手元と本番でDBのバージョンが違ってて、マイナーバージョンの違いだから大丈夫だろうと思ったら挙動がビミョーに違ったし！ うぎゃー」とか、「本番のデータだと負荷が高まったときに、このパッチでタイムアウトの例外が多発するようになっていた！ ウキーッ」とか、「Rubyを最新のパッチレベルにしたら、実はマーシャリングのフォーマットが変更になっていて、DBをダンプしてリモート環境にロードするgemが動かなくなっていたよ！ むぎゅぅ」とか、「サードパーティ製のJavaScriptがなぜかHTMLの最後にスペースを勝手に入れてくれていて、おかげでフッターのレイアウト崩れてたし！ そんな忍びの術みたいなもん気付かんし！」とか、「手元では昔設定した環境変数を参照してたまたま言語設定がうまく動いているだけだった…… 本番は文字が化け化け！ ていうか、DBのマイグレーション失敗だし、オレもう終電逃し確定だし！」とか、「動かねぇ……。うごご、本番環境はLinuxなのに、MacのUnixコマンドの出力前提に初期化スクリプト書いたの誰だよ！ リバート、プリーズ！」とか、「ローカルのWebサーバはオッケーでも、サーバ上のNginxではリバースプロキシがRailsのBasic認証と相性が悪かった！ サノバビッチ、スパシーバ！」

とか、そういうことです。

●12ファクターアップとは？

　こうした悲しい事態を避けるために必要となるのが、「開発・本番等価」という考え方です。できる限り、両者の環境を一致させろということです。

　「開発、ステージング、プロダクションをできる限り近づける」というのは、“12ファクター・アップ”が掲げるマントラの1つです。12ファクターアップというのは、ネット経由で配布・提供される現代のモダンなアプリ（ソフトウェア）が満たしているべき12個の原則を書きだした一種の宣言文のことです。12ファクターアップは、ちょうどアジャイル宣言のように、原則を並べた宣言文書なので、特定のプラットフォームや開発言語などを想定はしていません。ただ、この文書をまとめたのはHeroku創業者メンバーの1人、アダム・ウィギンズ氏で、Herokuプラットフォームの開発や、Herokuがホストする数多くのアプリケーションを観察していて到達した原則集ということですから、意地悪な見方をするとHerokuの宣伝文書、もしくは目標宣言のように読めなくもありません。例えば、アーキテクチャやツール、開発スタイルに大幅な変更を加えることなくスケールが可能なことというのは、HerokuのDynoを想起させます。スライダーバーをググっと上げれば、ハイ終わりという。実際、＠ITが提供・運営しているQ＆AサイトのQA＠ITはHerokuで動かしていますが、.初期に想定以上のトラフィックが来たために慌ててDynoの数を2つから5つに上げた、ということがあります。

　ともあれ、やや宣伝めいたところのある12ファクターアップの文書ですが、これをまとめた背景に明記されているように、12ファクターアップという文書は、モダンなアプリ開発に関わる課題を論じるための「共通語彙」、もしくは「方法論」を定義するものでもあります。そういう意味では議論のスタートとしても良いものではないかと思います。

●「開発・本番等価」というルール

　どうやって開発・プロダクション環境の等価性を高めるのでしょうか？

　例えば、Web系開発者の間で、開発用端末としてMacが人気なのは、デプロイ先がLinuxサーバであることが多く、同じPOSIXならミドルウェアや言語処理系、ツール類で、ほぼ同じ環境が再現できることが挙げられると思います。iOS開発がプラットフォームを選ぶ（Macのみ）一方、Androidは何でも良いということも影響しているかもしれません。また、Linuxサーバで作業することが増えた結果、viやcurl、tailなどのコマンドラインツールの価値が見直されているというトレンドもあるように個人的には感じています。だったらなぜRuby on Rails開発者はあまりUbuntuを使っていないんだというツッコミもあるかもしれませんが、それは「設定がしたいんじゃなくて開発がしたいから」というのが1つの答えだと思います。

　さて、このブログに本論に移る前に、12ファクターアップの12の原則を和訳しておきます。

1. コードベース：バージョン管理された単一のコードベース、多数のデプロイ
2. 依存管理：依存は明示的に宣言して分離する
3. 設定：設定は環境に保存する
4. 補助サービス：補助サービスはリソースとしてアプリに付随させる
5. ビルド、リリース、実行：ビルドと実行は完全に別ステップとして分離する
6. プロセス：アプリは１つ、もしくは複数のステートレスなプロセスとして実行する
7. ポートバインディング：ポートバインディングを通してサービスを露出する
8. 並行性：プロセスモデルを使ってスケールアウトする
9. 廃棄できること：速いスタートアップタイムと優雅なシャットダウンによって堅牢性を最大化
10. 開発・本番等価性：開発、ステージング、本番をできる限り近づける
11. ログ：ログはイベントストリームとして扱う
12. 管理プロセス：管理者・管理のタスクは、（起動して実行したら終了する）1回きりのプロセスとして走らせる

　Rails開発者なら、ああ、1はGitのmasterのことだな、2はGemfileだななどと思うかもしれませんが、ほかのフレームワークでも似たような仕組みがありますよね。6～8番あたりはUnicornを思わせますが、いやいやプロセスじゃなくてスレッドが答えだという人たちもいることでしょう。そういえば、大量のUnicornが走っている某社のRailsアプリでは、個々のUnicornの寿命が数分という話を聞いたことがあります。メモリリークがひどくて、少し動かすと反応しなくなるので、ガンガン殺してまたリスタートさせるという話です。これは6番の極端な例かもしれません。外部からそのアプリにアクセスして見ている分には、別に問題なく動いているように見えるということです（現場の人には当然それが良いという認識はなく、何とかしないと、という話でした）。

●Herokuが「データベースのフォーク」を実現

　さて、12ファクターアップという文書は洞察に富んでいるので、一読の価値はあると思うのですが、ここでは開発・本番等価性の話をしたいと思います。

　というのも、HerokuとEngine Yardが、前後して開発・本番等価性を高める新機能をリリースしたからです。それぞれに見ると、「へぇ、便利」という程度のことかもしれませんが、ともに12ファクターアップがうたうモダンな開発スタイルを前進させる「PaaS進化の最前線」だと思うからです。

　1つは、2012年11月8日にHerokuがリリースしたデータベースのフォーク機能です（Herokuの関連ブログ）。Herokuが指摘するとおり、GitとGitHubは「フォーク」（分岐）という、時としてネガティブなニュアンスさえあったアクションを、この上なくカジュアルに手軽にしてしまいました。Gitでブランチを切るのはSHA-1の生成と、その40バイトのデータのファイルへの書き込みだけなので動作としても一瞬です。分散レポジトリなので名前の衝突問題も小さく、ガンガン好きなだけブランチが作れます。GitHub以前は“フォーク”といえばコードの所有権やコミットの場（リポジトリ）、その主体がある日を境に分岐するという話でした。意見や目的意識の違いや、開発者間の仲違いによってフォークは起こりました。しかし、GitHubでは、フォークはもっと気軽なもので、別の意味も帯びています。とりあえず、自分のところへコードベースを持ってきて、そこで何か作業をして、その結果を元へ戻すというようなときにフォークしてしまいます。こうすることで、いきなり本家のレポジトリでブランチを切ったりすることなく自由に実験的な開発とコミットができるのです。これはGitがもともと持っているDVCの性質ですが、GitHubはボタン一発でフォークできる手軽さを実現したところがスゴイと思います。

　Herokuがリリースしたデータベースのフォーク機能も、GitHubのフォークに近いニュアンスです。HerokuはPostgreSQLをサービスとして提供していますが、本番環境のデータベースをボタンのワンクリックでフォークできるようになりました。例えば、本番環境のデータを、ステージングへとクローンすれば、「ステージング環境ではマイグレーションが通ったのに本番環境で失敗した」ということが減るはずです。負荷テストをするにしても、本番環境のデータをフォークして流用すれば精度が高いでしょう。ステージングのほうのデータベースは、検証が終われば破棄すればよく、使った分以上に課金されることもありません。クラウドっぽいですね。

　データベースのフォーク機能は、また一歩、12ファクターアップを体現した機能と言えると思います。GitHubのフォーク機能と同じで、「それ、これまでにもダンプしてロードすればできたやん」という議論があるかもしれません。でも、ちょっと違うと思うのですよね。ボタン一発（あるいはCUIのコマンド一発）でできる手軽さがいいのだと思います。

●Engine Yardは仮想環境向けの開発環境を提供

　さて、もう1つ。

　Herokuの競合であるEngine Yardは「Engine Yard Local」を2012年11月16日に無償でリリースしました。Engine YardはRailsやNode.jsの開発環境として、ミドルウェア、フレームワークを全て含む独自のスタックを提供していますが、これをローカルの仮想環境で動かすことができるそうです。仮想環境に開発環境をセットアップする「Vagrant」と、OSSの仮想化ソフトウェアの「VirtualBox」を組み合わせてEngine Yard Localは実現されています。Engine Yard Localを使うと、同社のクラウドインフラと同様のOS、Webサーバ、アプリケーションサーバ、ロードバランサなどが手元に再現されます。

　Vagrant（ベイグラント：意味は「放浪者、浮浪者」）の公式サイトに行くと、ズバリ「開発・本番等価」という言葉が書いてあり、12ファクターアップのサイトへのリンクが貼られています。いまや本番環境では、DBサーバだけでなく、0mqのようなメッセージングサービスが動いていたり、Redisのようなインメモリのキャッシュクラスタが動いていたりするわけですが、いくらMac OS Xが「POSIXだから、まあ動きますよ」と言っても、こうした個別のアプリ依存のソフトウェアをMacPortsやHomebrew、あるいは手動で手元のマシンにインストールして設定・管理するのがだんだんつらくなってきているように思います。特に複数アプリに関わっていて設定の切り替えが必要だと絶望的になるのではないでしょうか。

　最近のマシンは高速なので、開発環境は、それ専用の仮想環境に入れてしまえばいい、というのがVagrantの発想です。確かにスッキリ！ サーバ側と全く同じ環境を実現！ すばらしい！ もうMacPortsじゃなくて、apt-getでいいんや！ とも思えますが、もちろんマイナス面もあります。

　例えば、現実の開発者というのは、熱風を吹き出しうなり続けるMacBook Airをなだめすかしたり、ぐるぐる回る虹色バルーンを呆然と見つめながらメモリ2GBのマシンで開発していたりするわけです。そういう環境で「仮想環境にOSとミドルウェア一式をぶち込めば万事解決！」と言われても、そんな重たそうなもの……、何のために軽快な動的言語やviを使ってるのかワカランぞということになりかねません。なんだかんだ言ってPC上ではゲストOSは二級市民です。ゲストOSが動いていると、なぜかホストOSのレジュームが失敗して、延々と黒い画面を見つめて祈った経験があるという嫌な思い出がある人もいるかもしれません（私ですが）。

　Vagrantでは、IaaSにおけるChefのように、ローカルの仮想環境に対してChefやPuppetが使えるそうです。「ちょっと手元にHadoopクラスタを作って実験してみたい」というような用途でも使われているといいます。あるいは、チーム開発の場合でも新メンバーに対してMacBook Proを買い与えて「さあ、以下の手順に従ってRuby、Rails、Postgres、Redisあたりを入れてください。おっと、PostgreSQLは以下のエクステンションのビルドも忘れずに」とやるよりも、仮想環境にポコンとその開発環境を再現できるようにVagrantを使うほうが良いかもしれません。

　Engine Yard Localは、Virtual Boxを前提としたVagrantの設定レシピ＋CLIツールということですが、無償で利用できるので、これまで「Engine Yardのスタックって試してみたいけど、Herokuと違って無償で手軽にというのがないしなぁ」と思っていたRails開発者にとっては、試用してみるいい機会かもしれません。気に入らなくても、スッキリと跡形なく消せるのも仮想環境を使うメリットですよね。もしかすると、これからRuby on Railsの開発をやってみたいという開発者にとっても、「とりあえず全部入りのRails開発環境を作ってくれる選択肢」として、Engine Yard Localは使えるかもしれません。RubyもRailsも、バージョン管理ツール、ライブラリ管理ツールなどの周辺ツールの知識が結構必要で、とりあえずやってみたい人にとってそれがハードルになっているようなことがあると思うのですよね。

●継続的デリバリー実現のためにPaaSは進化中

　ずいぶん長々と書いてきましたが、HerokuもEngine Yardも、ともに「開発・本番等価」という課題に取り組んでいて、これは偶然の一致ではなくPaaS市場のトレンドと言えそうです。次のステップは開発環境がクラウドに移る（元々のHerokuの事業はそうでしたが）ということかもしれませんが、ネットワークのコネクティビティの問題が解決しない限りはそれはなさそうです。

　言うまでもないかもしれませんが、「何のために開発・本番等価を目指すのか？」ということですが、それはアジャイル宣言の背後にある原則の先頭に書いてあるとおり、「価値のあるソフトウェアを早く継続的に提供します」という“継続的デリバリー”の実現のためかと思います。

　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 2.0のリリースマネージャ、遠藤侑介さんがメーリングリストに流したアナウンスによれば、2.0.0の主な新機能は以下の通り。

• Refinements
• キーワード引数
• Enumerator#lazy
• Module#prepend
• Hash への変換メソッド #to_h
• %i: シンボルの配列のリテラル
• 正規表現エンジンを Onigmo に変更
• DTrace サポート

　それぞれの機能について特に説明がなかったので、西村が分かる範囲で少し各機能について触れておきます。間違っていたらご指摘頂けると嬉しいです。

　Refinementsは既存クラスの挙動を変更したり、拡張するときの影響範囲を名前空間で限定する機能。Rubyはオープンクラスなので定義済みのクラスは、いつでも再オープンしてメソッドを追加・削除することができます。言語のコアライブラリの機能でも変更できて、Ruby on Railsのユーリティティライブラリ、ActiveSupportは割とやりたい放題というか、良い感じの拡張が入っています。例えば、ハッシュのmergeを逆方向にするとか、ディープにマージするというようなことはRuby言語の標準には入っていなくて、ActiveSupportに含まれます。こうした拡張機能は、Rubyコミュニティでゆるやかに共有されていて、小さなライブラリでもActiveSupportの一部を取ってきていたり、類似の拡張をすることがあります（多くの場合はlib/core_extとかlib/extといった辺りに入っていて、たいていはarray.rbとかhash.rbといったように標準クラスの挙動に手を入れています）。そうやって拡張したとき問題となるのが、名前の衝突です。名前が衝突するだけならまだしも、似たような挙動だったら嫌ですね。Refinementsは、オープンクラスの柔軟性と強力さを維持したまま、いわゆる“モンキーパッチ”の影響範囲を限定するために採用された機構です。

　キーワード引数は文字通り、メソッドの個々の引数に内容を示すキーワードを付与できる機能です。GitHubにミラーされているRubyのソースコードリポジトリのここにテストコードがあります。ちょっと抜き出すと：

def f1(str: "foo", num: 424242)
  [str, num]
end
 
f1                           # => "foo", 424242
f1(str: "bar")               # => "bar", 424242
f1(str: "bar", num: 111111)  # => "bar", 111111

という感じです。これまでRuby界隈ではハッシュのリテラルを引数の最後に渡すことで似たようなことはできていました。Rubyではメソッドの引数の最後では、ハッシュリテラルのブレースを省略でき、なおかつRuby 1.9からはハッシュはJSONぽく書けるので、以下のような記法が可能で、割と標準的な書き方でした。

def f1(value, options = {})
  if options.has_key?(:foo)
    foo = options[:foo]
  end
  # do something
end
 
f1(123, foo: "bar", bar: 111111)

　呼び出し側はいいですが、これだと呼ばれる側はoptionsのデフォルト値とマージしたり、個別に変数を取り出したりと面倒でした。キーワード引数が広まれば、こうした手間がなくなり、ずいぶん使いやすくなりそうです。

　Enumerator#lazyは遅延評価のための新しいAPIです。nagachikaさんのスライドを見ると分かりますが、mapやselect、zipなどコレクション全体を評価するようなメソッドの前に、(0..5).lazy.map などとして lazy を挟むことで遅延評価が可能になります。無限の要素を扱ったり、停止条件がいつ来るか個別にループしてみないと分からない（事前に調べるのが面倒）ようなケースでスッキリと書け、処理に必要なメモリ量も少なくて済みます。Rubyは1.8から1.9へのバージョンアップで、ずいぶん関数型の特徴を取り入れましたが、遅延評価が入ったことで、またそうした性質を強めているように感じられます。

　Module#prependは、既存クラスの挙動を変えるときに使えるようです。Railsの世界では長らく method_alias_chain を使って既存メソッドを呼ぶ前段階でゴニョゴニョっとやってからオリジナルのメソッドを呼ぶというようなことが行われていました。既存のライブラリに手を入れずに、ちょっとだけ動作を変更するということができます。Module#prependは、これをスッキリした形でRuby言語としてできるようにするもので、クラス（モジュール）の継承ツリーにモジュールを入れ込む仕組みです。Railsのソースコードの黒魔術感が減りそうな気がします。Module#include（ミックスイン）と似ていますが、この2つは継承ツリーの中でモジュールを差し込む場所が違っていますし、ミックスインは、どちらかと言えば多数のクラスに共通する挙動を引っ張り出してまとめておく仕組みとして使われています。

　シンボルの配列がリテラルに書けるようになりました（パッチ）。以下のような感じです。%w(apple banana) のような表記のシンボル版ですね。

%i[foo bar]  # => [:foo, :bar]

　ということで、Ruby 2.0の新機能のうち、いくつか紹介してみました。

【追記】アナウンスには含まれていませんが、Ruby 2.0ではVMの改善やFlonum採用によってパフォーマンスアップも図られているそうです（@unakさん、情報ありがとうございます！）。Flonumというのは、ここに議論がありますが、浮動小数点の埋め込み即値です。Rubyでは、これまでにも一定範囲に収まる整数（Fixnum）ではオブジェクトを生成せずに、ポインタにフラグを付けて値として扱う実装になっていましたが、64ビット環境では整数に加えて浮動小数点でも同じことを実現するようです。並の演算ならガッツリ速くなりそうですね！

　以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半では、多様性は善であるという話を引き継いで、JRubyやRubinius、MagLevを選ぶべき理由の話や、組み込み向けにmrubyを作っている理由などを話しています。そちらに興味がある人は是非オリジナルのトークをご覧ください。

●TwitterでPerl好きに絡まれた

　Rubyの開発を始めたのは1993年の2月です。Unixのスクリプト言語を目指しました。Unixのスクリプト言語が作りたかったというより、それが自分がいちばん使いそうなところだったからです。

　Perlの代替品というのを目指したのですが、ちょっとやり過ぎだったかな、と。（Perl由来の）ヘンな変数とか残ってますが、あれは失敗だった。でも、Perlの代替というのはRubyを作った本当の理由ではなくて、自分で作ったものが自分で使えるドッグ・フーディングが出来て楽しいというところで、実は代替しようとまでは思ってなかった。

　そう思って20年、（Rubyを）作ってきたんですね。

　で、最近Twitterで私に絡んできた人がいました。「Perlがあるのに、なんでRubyを作ったんだ」と言うんですね（笑）。PerlがあるのにRubyを作るなんて、重複だし、車輪の再発明だし、何より有限の労力の無駄遣いだというんですよ。だからRubyなんか存在しなかったほうが良かったのに、お前はなんてことをしてくれたんだ、と。多くのIT系の人たちはRubyのことをネガティブに思ってるよ、と胸を張って言われてですね……。

　……って、どう思いますか？ まあRubyカンファレンスでこれを言うって卑怯なんですけどね（笑） でも、かんべんしてよ、と思いましたね。

●リソースを集約できればコスト減、しかし失うモノは大きい

　確かに人類は70億人しかいないし、プログラマははるかに少ないんですね。プログラマの中で開発コミュニティに参加する、ライブラリを作る、CPANのモジュール登録者とか、となると、そういう人はさらに少ないんですね、確かに。で、当時、そうした人たちがみんなで協力して当時のPerlに対して努力する、集約ということを考えたら、“もしそれが可能だったら”、確かにそれはリソースを有効に活用したという話になりますよね。

　でもですよ、考えてみたら、われわれにとって最も大切なリソースはマンパワーではなくて、モチベーションだと思うんですね。

　モチベーションは誰かに制御されるようなものじゃない。世の中に新しいプログラミング言語を作ってみたいという人がいたとして、そういう人に「お前は新しいプログラミング言語を作るより、Rubyに貢献したほうが労力の無駄にならないよ」といって、プログラミング言語を作り出す夢を諦めさせたら、どうでしょう。それでリソースの無駄遣いは防げたかもしれないけど、われわれは大切なものを失っているのではないか、と思うわけですよ。

　われわれは機械ではないので、やりたいと思うときに、何かを達成できるんです。何かを達成するには、突き動かす内なる力が必要です。それはモチベーションによって現れるんですね。

　ある人はプログラミング言語に対して情熱を感じるかもしれないし、ある人はアプリに情熱を感じるかもしれない。ある人はスポーツかもしれません。何らかの情熱があって、それに突き動かされているときに偉大なことができるんじゃないかなという風に思うんですね。私の場合はプログラミング言語に対する愛です。世の中に存在するすべての言語を愛してるといっていいんですね。PHPも。

　モチベーションを笑ってはいけない。

　私は誰が何に情熱を持っても笑いません。まあ、「ちょっとそれは……」と言うことはあるかもしれないけど（笑） たとえそれが車輪の再発明であっても構わない。何でもやったほうがいいと思うんですね。それによって多様性が生まれます。私は多様性は良いものであると思っています。

●多様性はイノベーションに必要なコスト

　多様性にはコストがかかります。もしPerlしかなかったとしたら、Perlはより充実した言語になっていたかもしれません。そうやって理想の言語が作れるとしたら、そのときかかったコストは、Rubyのある世界より安かっただろうとは思います。でも、住みやすかったのか？ というと、そうではないのではないか、と思うんですね。

　何百、何千とあったはずの世に出なかったプログラミング言語、そうしたものは無駄だったのか？ それはイノベーションのコストではないか。

　この地上で、誰一人としてイノベーションのことを理解してないんですね。イノベーションを起こした人ですら、実は理解してない。

　よく私のところに来て、「なぜRubyは世界中で使われるようになったのですか」と聞く人がいるのですけど、内心は「分かりません」と答えたいんです。だけど、インタビュワーに嫌な顔をされるので、もっともらしいことを答えるんです（笑） 「コミュニティが～」とか適当なことをいろいろ言って。でも、分かりませんっていうのが正直な気持ち。分かりませんよ。

　再現性がないんですよ。イノベーションは再現できないんです。

　分かんないんだから、心配するのはやめて、コードを書いて幸せになろうと思うんですね。（日々コードを書くという）ミクロの世界で、“いま”充実して前に進んで行けばいい。中には成功するものもあるし、失敗するものもあるかもしれない。でも失敗しても「ぼくは幸せだったからいいや」と思えるんじゃないかと思うんですよ。楽しく野球をしている野球少年のところにいって、「きみはプロにはなれないよ」っていうのって、すごく暗い話じゃないですか。そういうことはしたくないですよね。日々楽しく野球すればいいじゃないですか。みんなにもハッピーになってほしいと思うんですね。

　（札幌Ruby会議2012のテーマである「We Code.」というメッセージにあるように）もし皆さんも、コードを書くということにアイデンティティを感じているなら、コードを書いているときが幸せですよね。アイデンティティのあるところに幸せがあるのですから。だから、つまんない議論とか、考察とか、調整とか、そういうめんどくさいことをやめて自由にコードを書きましょうよ。強制されずに、幸せに書きましょう。

TechCrunch Disrupt SF 2012で話すマーク・ザッカーバーグ氏

ネイティブかHTML5かという対立軸

　モバイルアプリの世界では現在、「ネイティブアプリか、HTML5か」という構図で技術が語られることが少なくありません。実際、両者には一長一短があり、ケース・バイ・ケースで使い分けられています。機能面や応答性ではネイティブアプリが有利ですが、HTMLを取り巻く開発環境は急速に進化していて、中長期的にはHTML5の普及が進むと見るのが一般的です。それだけに、ザッカーバーグ氏の発言は一種の「揺り戻し」という風に捉えられたようです。

　ところが、実際に成功しているモバイルアプリの中には「第3のアプローチ」ともいうべきハイブリッド型も多数存在しています。

500万DL超のクックパッドアプリは第3のアプローチ

　レシピ共有サイトのクックパッドが提供するAndroid向けのモバイルアプリは、そうした第3のアプローチを採るアプリの1つです。配布パッケージとしてはネイティブアプリとして実装されていますが、アプリ本体ともいえるUIは、ほぼHTMLとCSS、JavaScriptでできています。

　クックパッドでは、JavaScriptから利用できるAndroidネイティブ機能のバインディングをAPIとして独自実装することで、HTMLでありながらネイティブアプリと遜色のない機能性を実現しています。重要なことは、そのことによってネイティブアプリでは得られない価値をユーザーに提供している、ということです。

　すでに500万ダウンロードを突破したクックパッドのモバイルアプリの実装と運用について、同社エンジニアでAndroid用の社内向けAPIを開発した濱崎健吾さんに話を聞く機会がありましたので、以下にまとめたいと思います（濱崎さんは10月5日にクックパッドを退職しています）。

WebViewを2つ使ってメニューとアプリ本体を実装

　クックパッドのAndroid向けアプリは、多くのユーザーにはネイティブアプリに感じられることでしょう。メニュー部分をネイティブ側でキャッシュするなどネイティブアプリに近いUIを実現しているからです。クックパッド社内ですら、それが本質的にHTMLアプリであると気付かなかった人もいたぐらいだと言います。AndroidアプリはGoogle Playで配布していますし、アプリとして起動し、終了ができる、ふつうのAndroidアプリです。

　ただ、その実装は少し変わっています。

　クックパッドのAndroidアプリは、左右2枚のWebViewから成り立っています。WebViewとは、プログラマがWebKitブラウザのレンダリング領域をアプリ内で利用するためのモジュール。カンタンに言えば、アプリにブラウザを埋め込むための仕組みです。AndroidではWebViewと呼び、iOSではUIWebViewと呼びますが、ほぼ同じ仕組みです。

クックパッドのAndroid向けアプリ。横位置で見ると、メニューと本体部分が表示されるが、この2つは別々のWebViewを埋め込んで実現している。HTMLアプリであるからこそ、新機能はリリースした瞬間にユーザーが使っている画面のメニューにすぐに現れるという

右上の音声検索など一部分だけがネイティブアプリとして実装されていて、コンテンツを表示している部分やボタン類の多くはHTMLアプリ

　ネイティブアプリ内でWebViewを使えば、そこにWebサイトを表示できます。ポコンとWebサイトをはめ込むようなイメージですね。例えば、Twitterアプリでツイートに含まれるリンクをクリックしたときに、URLをWebViewに渡すことで、そのTwitterアプリ内でWebページを表示させることができます。

　WebViewの本来の使い方は、アプリ内からWebページを参照のために開くというものです。しかし、一部のモバイルアプリは、この仕組みを推し進めて、アプリのいちばん外側の部分だけをネイティブアプリとして実装し、中身をHTML5アプリとして実装するというアプローチを取っています。

　つまり、モバイル端末向けのHTML5アプリと言った場合、

• 端末標準のブラウザでURLを入力して使うサービスとしてのHTML5アプリ
• WebViewを経由して配布されるHTML5アプリ

の2種類があるということです。後者のWebView利用によるHTML5アプリは、どこまでをネイティブで実装するのかという点と、ネイティブ機能のJavaScriptバインディングを利用するかどうかという点で、中間形態といえる“ハイブリッド型”が存在しています。

　単純にHTMLアプリとしたのでは実現できない機能があります。例えば画像を編集した上でアップロードする仕組みや、カメラ機能の利用などです。Androidの音声検索APIもそうですが、ネイティブアプリとして実装しないと呼び出せないAPIがあります。

　そこで、一部分だけをネイティブとして実装して、大部分をWebView上のHTMLアプリとするアプローチを取ればいいというわけです。クックパッドが提供しているAndroidアプリは、まさにこうしたアプローチを採用したハイブリッド型です。

　現在、HTML5ではデバイス系のAPIが次々と実装されていますが、それらの標準化や実装は、まだ開発現場で使えるほどこなれていません。そのためネイティブの機能やAPIを間接的に利用する方式が出てくるわけですが、このアプローチは、実はAndroid OSでは公式ドキュメントに実装方法まで書いてあるサポートされたアプローチだったりします。あまり気付かないだけで、かなり多くのAndroidアプリがハイブリッド型で提供されているそうです。

　ここには、あまり語られることのない、iOSとAndroidのプラットホームとしての思想の違いがクッキリ現れているように思います。

WebViewでアプリを作る方法に「抜け道」を用意

　Android OSでは、WebViewのドキュメントのBuilding Web Apps in WebViewにあるように、addJavascriptInterfaceというAPIを使って、任意のJavaオブジェクトをWebKit上のJavaScriptから呼ぶことができます。基本的にAndroidのネイティブコードでできることは何でもできるので、ここは注意して利用しないとセキュリティ上の問題になります。クックパッドアプリでは、ドメインなどの制限によって正式アプリ以外からのアクセスを排除しているという話です。

　クックパッドでは、AndroidアプリのためにAPI群を用意したそうです。例えば、OSネイティブのダイアログを開く、画像編集機能を呼び出す、OSネイティブのノーティフィケーション領域にメッセージを送るといったことが、サーバサイドのプログラミング（Ruby on Rails）だけで完結します。

APIの例。上はログインボタンを表示させるAPIをRailsのビューから呼び出す例

ネイティブ機能で実装した「つくれぽ」をRailsアプリのフォームのボタンから呼び出した例

　濱崎さんの設計・実装したAPIでは、例えばbuttonのclass属性にapp_login_form_buttonと書いておけば、ログインフォームが表示されるボタンを表示することができます。app_の接頭辞のあるclass属性名は、実行時にアプリ内でJavaScriptによって展開されて、Javaオブジェクトへのブリッジを呼び出すコードとなります。クックパッドはサービス開発にRuby on Railsを使っているので、このAPIはRailsのヘルパーから簡単に呼び出せます。例えば、「link_to “ログイン”, class: “app_login_form_button”」などと書けいておけば、ネイティブのログインダイアログを呼び出すボタンを設置できる、というわけです。

　以下、少し騒がしい環境ですが、濱崎さん自身によるデモの映像です（札幌Ruby会議2012の懇親会で撮影しました）。どういうAPIがあって、何ができるか分かると思います。

iOSよりもAndroidのほうが開発速度がはるかに速い

　クックパッドがAndroidアプリを最初にリリースしたのは2011年1月で、翌2012年4月にはハイブリッド版をリリースしています。ちなみに、Titanium Mobileを試験的に使ってみたこともあるそうですが、「Titaniumでは標準でパッケージに含まれるオブジェクトが大きすぎて効率が悪い」（濱崎さん）という問題があったそうです。Titaniumを使おうとしたのは、開発言語がJavaに制限されることでRailsエンジニアが手出しできなくなるのを防ぐためだったといいます。

　JavaによるネイティブアプリからWebViewへの切り替えに対しては、当初クックパッドの利用者からはネガティブな反応が少なからずあったそうです。やはり応答性ではネイティブアプリにかなわないわけですから、当然といえば当然でしょう。しかし、その後、HTML5アプリへのスイッチは想像以上の効果をもたらし、クックパッドのAndroidアプリは500万ダウンロードを超えるほどになりました。

　特定モバイルプラットフォームのための開発者を必要とせず、開発言語も1本化されるというのは、HTML5の分かりやすいメリットですが、濱崎さんによれば、この選択には、それ以上の意味があったようです。

　ネイティブ機能が含まれているとはいえ、クックパッドのAndroidアプリの本体は、事実上Webアプリです。この結果、「今はクックパッドのモバイル向けアプリは、iOSよりもAndroidのほうがはるかに開発速度が速い」（濱崎さん）という現象が起こっているそうです。ネイティブのモバイルアプリでは「ビルド→リリース→利用者側でのアップデート」という段階がありますし、iOSの場合、さらに審査のプロセスも入ります。この結果、新機能がユーザーの手に届くまでに時間がかかります。

　一方、Railsアプリのようにサーバで開発が完結するWebアプリなら、新機能をリリースしたら、それはその瞬間に利用者に届きます。新機能は、まずWebアプリとして実装されユーザーに届くわけです。そして、もしそれが良いものであれば、ネイティブのモバイルアプリのほうでも実装されるわけですが、Android版アプリは、もはやWebアプリに近い速さでアップデートが行える開発体制になっているということです。

細かなイテレーションこそがユーザーの利益になるという信念

　リリースサイクルを短くすることのメリットについて、クックパッドでディレクターを勤める五十嵐啓人氏は「第28回HTML5とか勉強会」で次のように説明しています（プレゼンテーション動画）。

　クックパッドでは、各機能ごとに、どの範囲の利用者にリリースするのかを管理する「Chanko」という内製ツールを利用しています。Chankoを使うと、自社開発者だけに限定して新機能をリリースするのか、利用者100人だけに限定して機能を試すのかといったことを機能ごとに制御できるそうです。特定の条件に当てはまるユーザーを数人（ときにはたった1人！）だけに絞り込み、その人たちだけに向けて新機能をリリースし、A/Bテストを繰り返し、最適なUI/UXを模索して改善するということをしているそうです。

　「ユーザーの反応や行動を見ながら、機能の追加や修正を速いサイクルで回すことができる」というのが、デスクトップアプリを含むネイティブアプリとWebアプリの大きな違いです。アプリが実際にどう使われているかが開発者に分かるというのは極めて大きな違いです。リーンスタートアップのような手法が確立して、普及してきていますが、その背景には、こうしたWebアプリの特徴があるのです。

　このサイクルがモバイルアプリでもそのまま成り立つのは、Webアプリとして実装した部分だけです。ネイティブアプリとしてリリースした場合、実際にユーザーがどの機能をどの程度使っているのかは分かりません。Webアプリの開発・運用で常識となった「仮説→計測→修正」というサイクルを素早く回すことができないのです。

　メリット・デメリットがあるネイティブ実装、Webアプリ実装ですが、クックパッドの場合、ハイブリッド型にしようと決断した背後にあるのは「細かなイテレーションこそがユーザーの利益になるという信念だった」（五十嵐氏）といいます。ネイティブ実装からハイブリッドへ移行したとき、できるだけ従来のUIを踏襲したものの、「重たい、使いづらくなったという言葉もあり、会社に行きたくなくなるぐらいお叱りの言葉も受けた」（五十嵐氏）といいます。そうした意見が来ることはあらかじめ予想できたそうですが、それでもなおハイブリッド移行を決断したのは、それが最終的にユーザーの利益になると信じたからだと言います。

　モバイル端末上のネイティブアプリというのは、ユーザーから見た使い勝手が良い反面、これまでWeb業界が培ってきた方法論が一気に通用しなくなるという点で、クックパッドのような企業にとって、失うものが小さくないわけです。ハイブリッド型とすることで「アクセス解析が可能で、ビジネス判断が早くできるようになった」（五十嵐氏）といい、ハイブリッド型に切り替えてUI改善を進めたことで、回遊率向上（関連するレシピを見たり、ほかのコンテンツをついでに見たりすること）や、課金コンバージョン率の向上につながったそうです。

ハイブリッド型移行によるメリット

　リリースサイクルの高速化以外にも、ハイブリッド型のメリットはあるようです。

　例えば、ネイティブアプリでは、新機能のリリース可否の判断がシビアで保守的になりがち、という違いがあるといいます。Chankoを使えば、特定の機能をオフにすることはサービス提供側で簡単にできますから、新機能提供に関してよりアグレッシブになれるというわけです。実際にユーザーが利用するサービスそのもの、いわゆるプロダクション環境で実験的なことができるというのは、ユーザー側の明示的バージョンアップが必要なネイティブアプリでは考えられない特徴です。

　また、ネイティブ実装に比べ、アプリのクラッシュが減って安定したという点も見逃せません。もっともこれは、アクティビティの数が単純に減ったためだそうですが。

　逆にWebアプリでは実現が不可能で、ハイブリッド型なら実装できることとして、五十嵐氏は、ちょっと意外なポイントを挙げています。

　例えば、ユーザーが料理のレシピを見ているときに、端末が省電力モードに入って画面が暗くなると困ります。クックパッドのユーザーは両手が小麦粉でいっぱいになっていて端末の画面に触りたくないようなことがあるからだそうです。これは純粋なWebアプリで制御できることではありませんが、ハイブリッド型なら可能です。アプリの右上にある音声検索ボタンの部分も、ネイティブ実装となっているそうです。

WebViewの扱いに見る、OSの思想の違い

　クックパッドではWebView利用のハイブリッド型への移行は成功だったということですし、良い妥協点に思えます。しかし、WebViewに対する見方は、プラットフォームや立場の異なる開発者の間で温度差があるようです。

　すでに書いたようにiOSとAndroidではWebViewを使ったアプリの扱いが違います。iOSではJavaScriptでネイティブ機能をブリッジする開発者向けの仕組み自体は用意されているものの、審査に通る見込みが低いことからクックパッドでは同様のアプローチによるiOS向けアプリのリリースには至ってないそうです。Windows 8では、アプリの大部分をWebViewを使って実現したものについてはストアの審査で落とされることになるようです。

　守る立場にしろ、追いかける立場にしろ、プラットフォームそのものがビジネスとなっているiOSやWindows 8では、ベストなUXを実現できるネイティブアプリをできるだけ多く作ってもらうのがマーケティング上重要なのでしょう。ここには開発者やアプリを囲い込む古いタイプのプラットフォーマーの発想があるように、私には思えます。「ネイティブアプリがほしい」という利用者の声を最大限に聞くのが「ネイティブアプリ以外は落とす」という論理になるので、表向きはユーザー体験を第一に考える正論です。しかし、ソフトウェアの開発プロセスや提供形態に疎い利用者の声を聞くことが、良いソフトウェアやサービスの提供につながると限りません。それはクックパッドの例からも明らかです。ここには「一見正論でユーザーのことを大切にしているように思われるプラットフォーマーたちの我田引水」というダブルスタンダードがあるのではないでしょうか。常にHTMLアプリが良いとは思いませんが、開発者に対して選択肢としてWebView活用の道を閉ざすのはやり過ぎだ、と思うのです。

　ソフトウェア開発のリソースは有限ですから、全てのプラットフォームでネイティブアプリを提供するというのは現実的ではありません。だからこそMacでもWindowsでもiPhoneでも使えるWebアプリが主流になってきたのですから、これと同じことがモバイル市場でも起こると考えるべきでしょう。今さら誰もデスクトップアプリ（Windowsネイティブ）の天気予報アプリやカレンダーアプリなんてインストールしませんよね？

　……、と思わず、私見を述べてしまいましたが、この辺は大いに議論の余地があるところでしょうし、開発者によって相当な温度差があります。濱崎さんも、Android開発者には、いわゆるWebサービス開発者とは違う畑の人が多いように感じてらっしゃるそうです。

　そうそう、AndroidのWebViewといえば、端末やバージョンごとの互換性に難があるわけですが、Android 4.1以降ではChromeが搭載されます。キャリアやメーカーがあれこれ手を入れた結果、プラットフォームとしては分裂気味になったWebKit[s]との格闘も、いずれ終わるかもしれませんね。濱崎さんによれば、例えば画像保存しようとAPIを叩くと、Androidでは端末によって違うフォルダが開いたりするということがあったそうです。Android 4.1時点では、WebViewとMobile Chromeは別実装として動いているといいますが、今後、レンダリングエンジンの違いによる互換性の違いは小さくなっていくのではないでしょうか。

　さて、西村の私見も交えながら、濱崎さんのAndroid向けブリッジAPIと、その実装であるクックパッドのAndroidアプリについて紹介しましたが、実は濱崎さんはクックパッドを10月5日に退職したそうです。濱崎さんの退職後もクックパッドでは引き続きAndroidアプリサービスの改善が続けられるそうですが、濱崎さんは今後、これまでに得た経験を生かして、OSSやWebサービスとしてWebアプリ専門の開発者に向けた還元を何か出来ないか、その上でそれがビジネスにならないかと考えている、とのことです。

MobiRuby開発者の増井雄一郎さん

MobiRubyを使って開発したゲームの例

　動画の内容を簡単にまとめると、以下のとおり。

• MobiRubyはmruby環境でiPhone(iOS)アプリを開発できるSDK
• つまり、Rubyだけでアプリが書ける
• ネイティブ環境（Cocoa）のAPIが全て叩ける
• mrubyのVMをバンドルした形でアプリが配布される
• コンパイルしたアプリはAppStoreにも登録できる（すでに審査を通過したアプリもある）
• 現在はα版。来年のQ1にはプロダクションレベルに持って行きたい
• MITライセンスでオープンソースで進める
• マネタイズは全く考えていない
• RubyMotionとの違い
  • RubyMotionは有償の開発ツール
  • RubyMotionは完全にネイティブコードにコンパイルするので動作が速い
  • RubyMotionはRubyの動的な機能で使えないものがある
  • mrubyのほうはCRubyでできることは大体できる
  • mrubyはコアクラスについては含まれていないものもあるし、メソッドも少ないケースもある
• mrubyとCocoa環境のメモリ管理の整合性を取るのが現在の課題

MobiRubyアプリの概要

　mrubyというのは、Rubyの生みの親である まつもとゆきひろさんが開発中のRuby処理系の1実装です。フットプリントが小さく、処理系をアプリにリンクした形で利用することも想定されています。そういう意味ではMobiRubyはmrubyの正統な応用という感じです。mrubyの応用としては、ApacheのモジュールをRubyで書きたい、自動販売機の集計プログラムのようなものをRubyで書きたい、といったものがあるそうです。

　箕輪さんといえば、id:higepon で知られるハッカーです。趣味でOSや言語処理系を実装したり、IPAの未踏ソフトウェア創造事業で天才プログラマーと認定される一方、はてなやサイボウズといった著名Web企業に勤めるなど転職歴も華やかです。そんな蓑輪さんは今、2012年初頭に転職したTwitter Japanで、本社エンジニアらと、グローバルなWeb企業でサービス開発の最前線に立っています。

　Twitterエンジニアの日常とはどんなものか？ 開発スタイルやツール、その開発プロセスとは？ また、どうやってエンジニアとしての腕磨きをしてスキルアップしていくのか？ オススメの勉強方法は？ そんなことをお聞きしました。何より私が驚いたのは、ツイートを蓄積してルーティングするようなバックエンドの部分は別として、フロントエンドが、意外なほど「ふつうのRailsアプリ」として実装されているというお話でした。

　以下が主な内容です。全部で1時間とちょっと長めなので、ぜひビールでも片手にご覧くださいませ！

• 蓑輪太郎さんの現在の仕事 00:00:00
• コードレビューにはReview Boardを利用 00:03:53
• 何億人に使われる機能変更の初仕事 00:04:58
• 自分のコードに対して残る不安 00:06:19
• Twitterエンジニアのローカル開発環境 00:09:41
• 意外に普通!? Ruby on Railsによる開発 00:11:58
• 蓑輪さんの典型的な1日 00:13:08
• ビッグデータもカジュアルに扱う 00:17:01
• Twitterが求めるのは「歌って踊れるエンジニア」 00:17:43
• システムをブラックボックスと見ないこと 00:20:24
• 「まだ自分ではハッカーだと思っていません」 00:24
• C言語のポインタで挫折した経験も 00:24:52
• 大学の研究室でJavaに熱中 00:27:36
• Twitterではテスト駆動開発してる!? 00:30:03
• 設計、実装ともエンジニアの裁量が大きい 00:31:41
• 知識ゼロからOS開発に挑戦！ 00:33:03
• OS開発を始めたのは危機感から 00:35:09
• はてなに転職したワケ 00:37:49
• はてなでプロダクトを企画してリリース 00:39:29
• 弱点克服のため言語処理系の開発にも挑戦 00:42:26
• IPAの未踏に採択：Schemeでシェルを作る 00:45:06
• 言語処理系的なシェルは普及しない？ 00:46:38
• 技術書を読む上で大切なこと 00:48:43
• 自分の時間を「天引き」して勉強しよう 00:53:10

　技術評論社から『たのしい開発 スタートアップRuby』（大場寧子監修／大場光一郎／五十嵐邦明／櫻井達生）を献本いただいたので、ご紹介します。

　まず、まるまる技術評論社の書籍紹介ページにある概要から引用します。

　本書はRubyでたのしい開発を続ける4人の筆者による，新しいRubyの入門書です。Rubyは，コミュニティとコミュニティの根底にある文化の中で常に成長を続ける言語です。Rubyのポテンシャルを最大限に引き出すには，Rubyの文化を理解し積極的に関わっていく姿勢が不可欠です。本書はRubyの言語としての基本に加え，Rubyの世界にもっと深く踏み込んでいくための方法を紹介します。 　本書でたのしい開発への入り口を見つけてください。

　章立ては、以下の通りです。

Chapter1　「たのしい開発」を求めて
Chapter2　Rubyの基礎知識
Chapter3　Rubyを使ってみよう
Chapter4　Ruby on Railsとは
Chapter5　Railsを触ってみよう
Chapter6　Rubyの文化
Chapter7　自動化されたテスト
Chapter8　アジャイル開発とRuby
Chapter9　Rubyのコミュニティ
Chapter10 とある企業のRuby導入事例
Chapter11 「たのしい開発」の答え
Appendix　RubyとRailsをもっと知りたい方へ

　1、2章ずつを割いて取り上げているRuby/Rails/自動テスト/アジャイルといったトピックは、それぞれが1冊の入門書として取り上げて良いようなテーマでしょう。本書は、そうした個別の入門書数冊分の、それぞれ第1章と第2章をうまく抜き出してまとめ上げたような雰囲気があります。「Rubyで（たのしく）開発」とRubyistが言うとき、それは言語処理系のRubyのことだけを指しているのではなく、文化や習慣、開発ツールに込められた主義や思想、コミュニティの性質まで指しているのだ、という認識が、この一風変わった入門書の根底にあるのでしょう。

　オブジェクト指向もMVCもDRYもCoCもアジャイルも自動テストも、個別に見れば、どれもRubyやRailsの専売特許というわけではありません。ですから、こうしたことが当然という開発現場にいる人には、「なぜRubyの人たちは、やたらと“たのしい”という言葉を使うのだろうか？」という答えは分からないかもしれません。本書には、その答えがさまざまなアングルから個人的な体験談を交えてまとめられています。

　例えば、Chapter1の「「たのしい開発」を求めて」は、駆け出しだったプログラマの著者（執筆担当は櫻井氏でしょうか）が感じた矛盾の吐露から始まります。著者は、いわゆる上流工程、下流工程の分業から生じる多くの矛盾から、「納得出来ない非効率」を、もどかしく感じていたといいます。開発現場の士気が下がる中で不安を抱えた著者は現状改善に動きますが、うまくいきません。そうした頃に出会った「アジャイル開発」「ペアプロ」といった言葉が頭の片隅に残り、やがて著者はそうした「どこか遠い外国の話」のように感じられたことを実践している会社に転職します。そこで発見したのは、ペアプロの楽しさや、フラットでオープンなRubyのコミュニティだった、といいます。また、Chapter11では「「たのしい開発」の答え」として、道具、人、環境の3つの柱によって支えられる「文化」として、Rubyを取り巻く環境のキーワードを解説しています。例えば、Ruby界隈では「名前重要」ということが繰り返し言われます。クラス名、変数名、メソッド名について、「正しい名前」を付けるために延々と議論をするという文化が、Ruby界にはあります。それが何故なのか、具体例とともに書かれています。Chapter10の「とある企業のRuby導入事例」は、あるとき「Rubyは素晴らしい」と思った外資系コンサルティングファームの会社員が、いかに障壁を乗り越えてRubyを会社的に採用していったかという体験談が、失敗した取り組みも含めて生々しく語られています。

　コテコテの技術書でもスピリチュアルな信仰告白の書でもない絶妙なバランスのRuby/Railsの入門書として、これまでRubyを遠巻きに眺めていた人が手にとると、いろいろと刺激や発見があるかもしれません。

※記事初出時、サービス名をC4SAとご紹介しましたが、正式には「ニフティクラウド C4SA」です。訂正してお詫びいたします。

キャンバスはアプリの開発・運用環境

　端的に言うと、C4SAはニフティクラウドというIaaS上に構築されたPaaS環境です。ただ、一般的なPaaSと異なるのは「開発」「運用」、そして開発チームの「コラボレーション」も、全てブラウザ上で完結しかねない勢いの新しい世代の「アプリ開発環境」を目指している、というところで、とても意欲的なサービスです。

　アプリの構築・運用環境は「キャンバス」という単位で管理されます。標準でメモリ512MB、ローカルディスクが1GB使えます。月額945円で、日割りで計算されます（現在キャンペーン中で9月末までは無料）。DBは共有のMySQLが用意されていて、今後は専用DBやPostgreSQL対応も検討中とか。ユーザーは好きなだけキャンバスを立ち上げられ、キャンバスごとに、言語処理系やフレームワークが選択できます。ちょうどAmazon EC2のAMIのように、プリセットされた「開発・運用環境」が用意されています。現在は言語として、Ruby/PHP/Python/Perlをサポート。フレームワークとしてはRuby on Rails、CakePHP、Djangoが使えます。サーバアプリがインストール済みの環境としてWordPress、PukiWiki、concrete5（CMS）、CandyCane（プロジェクト管理）などといったキャンバスもあり、手軽にアプリを立ち上げたいというニーズに対応します。

　キャンバスの環境は随時追加予定で、C4SAユーザーが作成した環境をサービスとして有償でほかのユーザーに提供するマーケットのようなものも考えているといいます。Node.jsやJava対応もリクエストに上がっているそうです。

　ニフティクラウドですからインフラはVMwareです。その上にかなり独自に手を入れたLinuxを載せて、個別環境をLinuxのユーザー名によるプロセス分離でキャンバスを実現しているそうです。アプローチが、ややAndroidっぽいですね。C4SAでは、これまた仕組みは良く分かりませんが、アプリや環境をリスタートすることなく、メモリやディスクが随時増やせるそうです。スケールアップですね。アプリを横に並べて展開するスケールアウトについても、８月中には対応予定だそうです。

開発もサーバ側の各種設定もCLIもブラウザで

　C4SAがユニークなのはブラウザ上に開発・運用に関わる全てを載せようとしていることです。ファイルブラウザで任意のファイルを編集できますし、nginxの設定ファイル編集も言語処理系のバージョン変更も、ブラウザで完結します。各種ログも見れますし、デーモンの再起動もブラウザ上のボタン一発です。

　Ruby on Railsでいえば、git、rake、bundleなどのコマンドは、ブラウザ上に専用のGUIが用意されているか、もしくはブラウザ上のターミナルエミュレータのようなCLIで利用可能です。このCLIはsshではなく、ホワイトリスト方式のコマンド仲介ターミナルといった風です。ちょっと使ってみた感じ、「git init」ができても、「git commit」などとすると、エディタが起動できずにターミナルの設定がおかしいと怒られたりしました。公言はしていないそうですが、「タブレットで開発できるようになるのが目標」（クラウド事業部クラウドビジネス部 五月女雄一氏）ということですから、今後に期待ですね。

　デプロイはGitなどのリポジトリからのチェックアウト、もしくはWebDAV経由で行えます。WebDAVはデザイナ向けの機能で、チーム開発を意識したものですね。キャンバスは複数ユーザーで共有できますが、コラボレーション機能として、今後はチャット機能やSkypeアドオンなどを検討しているそうです。GitのチェックアウトやWebDAVは手軽でいいですが、Capistranoのような自動化ツールが使えないのは、プロの開発者にはちょっと不便かもしれませんね。ただ、「ニフティのC4SA専用の知識がないと使えないという風にしたくない」（五月女氏）という話で、専用コマンドを用意するようなことは考えていないそうです。

　C4SAのターゲットとしては、

• アプリを勉強したいけれども環境構築の障壁を越えられない初心者プログラマやデザイナ
• アプリ開発に没頭したいサンデープログラマ
• 技術はあるが時間がないエンジニア。PHPエンジニアがRailsを使う、あるいはその逆で環境構築までやっていられない
• インフラや環境を意識することなくビジネスレイヤですぐに利用したいスタートアップ

というような層を狙っているということです。

　今後は、ニフティらしく顧客管理機能、課金・決済機能の提供も検討したいということでニフティクラウド同様に、国内でもビジネスでのPaaS活用が本格化するかもしれませんね。「IaaSほどは安くないですが、ビジネスユースでは使われている、本気で使えるPaaS、お金稼ぎしても大丈夫ですよ、ということを感じてもらえるようなサービスにしたい」（五月女氏）とのことです。

　SRSは外国語学習者の語彙習得などに威力を発揮します。実際、SRSを取り入れたソフトウェアやサービスは多くあります。ただ、自分が欲しいものがなかったので、「Reijiro」というWebアプリをRuby on Railsで作りました（GitHubのリポジトリ）。機能追加をしながら4カ月ほど使っています。個人的に作ったアプリですが、もしかすると英語など語学を勉強している他の人の役に立つかもしれないと思って公開してみることにしました。

　Reijiroでは辞書として主に「英辞郎」を使います。特徴は以下のとおりです。

• 182万エントリと、膨大な実例を収録する英辞郎を利用（CD-ROM、もしくはオンラインコンテンツの購入が必要です。英辞郎の辞書データの著作権はEDPに帰属します）
• 各単語・用例の復習間隔を自動管理。1日、2日、4日、1週間、2週間、1カ月……、と徐々に復習間隔を伸ばすことで、最小の学習時間で記憶を定着させるSRS（Spaced Repetition System）を採用
• アルクが独自に選定した基礎語彙1万2000語を、全12段階のレベル別に単語帳に順次登録可能（レベル別データはインストール時に英辞郎CD-ROMから抽出します）
• サーバにデプロイして空き時間にスマフォやタブレットで利用可能（CD-ROMを購入した本人以外に閲覧可能な状態とするのは著作権侵害になります。念のため）

なぜ作ったのか？

　英辞郎は大変に良い用例集ですが、株式会社アルクが提供するオンラインの「英辞郎 on the WEB」は使いづらいところがあります。有償のPro版も少し使ってみましたが、やっぱり私のニーズには合いません。私は、単語の意味を素早く知りたいとかメールを書くにあたって用例を調べたいのではなく、調べた用例を丸ごと覚えたいのですね。

　一度引いただけでは覚えられないので復習が必要です。英辞郎 on the WEB Proでも単語帳機能があるので、復習自体は可能です。でも、最小の労力（時間）で効率的に覚えたいんですね。そこでSRSです。

　当初はローカルのMac上でだけ動かすつもりで作り始めたのですが、VPSに置いてみると想像以上に便利でした。英語を聞いたり読んだりしているときには、Chromeの検索エンジンとして登録してあるReijiroで辞書を引くようになりました。Reijiroで引いておけば、その単語・熟語は自動でクリップされます。クリップされた単語は、1日後、2日後……、と提示されるので、通勤や移動の空き時間にスマフォで復習できるので、とても良い感じです。いま、スマフォ用にjQuery Mobileのビューを足そうかと考えています。

　英辞郎が良いのは用例が豊富なことです。単語を調べた時、関連する用例や文例を眺めて、声に出して読むことが重要だと思っています。多くの単語帳アプリは「英単語：訳語」というフラッシュカード形式で、訳語だけを提示します。しかし、これではその語が作るイメージが分かりませんし、他の語と形作るネットワークが見えてきません。用例や文例で覚えないと自分で使える語彙になるように思えません。

　ちなみに現在、私の英語の推定語彙数は1万2000～3000語程度だと思います。「読む・聞く」では、あまり困りません。でも、書いたり話したりすると、結構残念な英語になります。語彙力を増やしてどうにかなるものではないかもしれませんが、ともかく向こう3、4年ぐらいで8000〜1万語ぐらい上積みしたいと思っています。自分で言うのもなんですが、無理せず効率的に語彙学習を継続できるという意味で、Reijiroは、すごくいいですよ。

　詳しい説明は、「Reijiro」をどうぞ。