フロントエンドをVue.jsでリプレイスする
榊原徹哉氏（以下、榊原）：最初に自己紹介になりますが。私は榊原徹哉といいます。好きな言語やフレームワークはVue.jsとか、Rubyが好きです。好きなものはガジェットです。例えば、indiegogoでおもしろいガジェットを漁ったりとか、家をスマートハウス化したりしています。最近の趣味はInstagramで、会社のInstagramを運営しています。良かったらフォローしてください。
今コークッキングという会社で働いているんですが、仕事は「TABETE」というB to B to Cのフードシェアリングサービスをつくっています。まず、その「TABETE」について説明します。飲食店さんが本当は食べて欲しいのに、急な天候の変化でお客さんが想定よりも少なかったり、Twitterでコース料理のドタキャンなどの理由で「食材や料理が余りそうだな」と感じた時に、お弁当としてTABETEに出品します。
ユーザーは出品情報を見て、サービス上でクレジットカード決済をして、指定された時間にお店に行けば、その料理をレスキュー、つまり手に入れることができます。TABETEは、「食べて欲しい！」という気持ちと食べる人（食べ手）を繋ぐサービスです。美味しい料理がお得に食べられるサービスなので、ぜひここにいるみなさまも使ってください。よろしくお願いします。
（スライドを指して）これは現在のTABETEを構成しているアーキテクチャの全体像です。ここに一応Firebaseを使っていたりするんですけど、WebとかAPIとか、バッチとか管理画面とか、そういうものはぜんぶRubyで書いています。先月「Ruby biz グランプリ」というRubyの特徴を活かして、新たなサービスを開発している企業を対象としたグランプリがあったんですけど、大賞をいただきました。
ちょっと待てと。「Rubyしか書いていないって言ってたけど、これってVue.js の勉強会だよね？」と思われた方がいると思うんですけど、 フルRubyで開発している現在のサービスのフロントエンドをVue.jsにリプレイスします！
フロントエンドをリプレイスする理由
ということで、仕切り直してTABETEをフロントエンドが理由でリプレイスする話です。
今日のアジェンダです。最初にリプレイスするきっかけの話をして、その次に言語・フレームワークの選定、最後にVue.jsを導入して良かったことなども話したいと思います。まず、リプレイスするきっかけについてです。そもそもリプレイスしようという話の発端は、現在のTABETEのデザインを一新するということが大きな理由です。
現在のデザインはデザイナーさんではなく、リリースのために取り急ぎCOOにデザインしてもらったものでしたが、最近ついに念願のデザイナーを雇うことができました。このタイイミングでTABETEの世界観をより一層出すために、サービスもデザインも一新することになりました。
さて、現在のベースはRubyなので、そこからフロントエンドの見えるところだけを改修するのか、それともすべてを一新するリプレイスをするのかという議論になりました。（スライドを指して）ここ1年のおおまかなスケジュールです。横軸が2018年の1月から2019年の1月で、時間軸です。
最初の3ヶ月ぐらいはサービスの開発やリリースをして、iOSのアプリ開発したり、管理画面をいきなりリプレイスしたりとか、あとはWebサービスの全国版対応やAndroid版の開発など、いろいろやっていました。スケジュールを見てわかるとおり、今運用されているサービスのほとんどの管理画面、API、フロントエンドは、全て3ヶ月で開発したものを用いています。
最初の構想として、リリースの1ヶ月前までは「データベースにアクセスするのは全てAPI経由でやろう」と思っていました。でも、リリースに向けて圧倒的な開発速度を求められたために、中途半端に「もうWebからもアクセスしよう」とか、直接データベースを叩き始めて、しかもロジックをWebアプリケーションのほうに書いたりとか、かなり可読性の悪いことになっていました。
ただ救いとしては、APIはけっこうきれいに書いていて、実は今のAPIを開発する前に、3種類ぐらいプロトタイプ実装をしていて、「どれが一番開発しやすいか」「変化に対応できるか」という議論を行っていました。その結果を反映したことで、突然の方針変更やシステム改修とかは速度感を求められるんですけど、そういうものにもついていけるようなソースコードになっていました。ただ今回はフロントエンドの話なので、その辺はちょっと省略させていただきます。
iOSアプリはWeb開発が終わったあとなので、サービスに必要なAPIのすべてを開発していました。その結果フロントエンドの改修コストは最小限になっていたためいつでも改修できるような状態でした。
ここまで説明したとおり、Webアプリケーションのソースコードが汚いということと、必要なAPIはすべて揃っていたので、改修ではなくリプレイスすることに決めました。
技術選定について
次は「どの言語で開発しよう」とか、「フレームワークをどうしよう」という時の話です。いきなりですが、サーバーはホスティングサービスを利用したいという思いがありました。現在のWebサーバーというのはGoogle Compute Engineというものに載せていますが、通常1台構成で運用しており、テレビ放送があるときにサーバーを手動で増やして、デプロイもCapistranoなどのデプロイツールを使っていないので直接サーバーに入って、ソースコードを直接引っ張ってきたりというような事をして対策をしていたんです。
ただ、APIのほうはGoogle App Engineにのっかっていて、メディア露出の際の負荷対策とかもオートスケーリングがあるのですごく楽だったんですけど、「今の現状をどうにかしたいな」という思いがあったので、Firebase Hostingを使い、同時にJavaScriptにリプレイスする事にしました。Firebase Hostingの導入は学習期間を含めて2時間程度でできるので、みなさんも試してみてください。
JavaScriptに書き換えることは決まりましたが、よく話題になるのがReact.jsにするか、Vue.jsにするかなどのよくある「宗教論争」です。（スライドを指して）これは日本ではなくて世界のGoogleトレンドでReact.jsとVue.jsを比較したものなんですが、Vue.jsのほうが人気があったりよく書かれているということなんですけど、Vue.jsはシンプルで少ないコード量でいろいろできたり、最初の学習コストがけっこう少ないので、Vue.jsを採用しました。
導入してよかったこと
最後に導入して良かったことについてお話しします。
まず初めに公式ドキュメントがとても充実しているのことに、すごく驚きました。フロントエンド界隈では普通なのかもしれないですけど、かなりリッチでした。例えば、サーバーサイドのドキュメントだと、サンプルを落としてきてがんばって起動して、いろんなコードを読んで、「あっ、必要なのはここか！」「じゃあ、いろいろ改変して試してみよう！」みたいな感じの流れなんですけど、Vue.jsはドキュメントを表示しているブラウザ上でいきなり実行や修正できる事に感動しました。
また、コミュニティがDiscordとかにもあるんですけど、とても優しいんです。しかも日本語で質問できるから、GitHubやStackOverFlowにがんばって英語に翻訳して投稿したけど、返事が返ってきてもよくわからないみたいなことが起きません。実際にチャット内に、「Enterキーを押したら送信されて悲しい」とか、「どうやってDiscordを触ればいいの？」みたいなことを書いている人がいるんですけど、「ググれ！」って言われるのかなと思ったら「改行はShift + Enterで」と言われていたりして。これって優しすぎますよね。
また、「決済はStripeを使いたいな」と思っていたので、「Stripe Vue.js」で検索したら、CodePenとかに、もうすでに動くやつがプラウザ上で動作するものが既にあったりしました。
この様に、Vue.js界隈の優しさや先人の知恵の膨大な量により、学習コストが開発速度に大きな障壁にならなかった事が使ってみて良かったと感じたポイントでした。やっぱりVue.jsは楽しいです。
最後になりますが、もともとサーバーサイドのエンジニアだったので、Googleやコミュニティに助けられながらですけど、フロントエンドの開発をするのはとても楽しいです。まだUIやUXの知識とかは全然足りていないんですけど、コミュニティに助けられてばかりなので、逆に貢献できる側になりたいなと思います。本日はご清聴ありがとうございました。良かったらTABETEを使ってください。
（会場拍手）
