今回はこのライブ配信アプリ「LIVEcommune」の開発チームにどんな技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！

DMMが映像配信のノウハウを活かしたライブ配信アプリ「LIVEcommune」をリリース！

白石：まずは、「LIVEcommune」がどのようなアプリなのか教えてください。

植田：今回開発したアプリ「LIVEcommune」は、配信者と視聴者を繋ぐ生配信アプリです。配信者をプレゼントで応援したり、嬉しいことや面白いことを「LIVEcommune」を通じて共有できます！一般ユーザーがスマホアプリのカメラで配信し、それをスマホユーザーが見てチャットなどでコミュニケーションをとって楽しむライブ配信アプリです。さらに、オンライン上で盛り上がっていただくスタンプ・アイテムを提供しています。

ライブ配信アプリはもうすでにレッドオーシャンになっており、日本だけでなく、中国をはじめるとするアジアでも盛り上がっている市場です。「LIVEcommune」はスピード感を持ってまずはユーザにとって絶対に必要な基本機能を厳選して開発を行いました。戦略的な機能はこれから実装をしていくといったところですが、動画広告やコンテンツ配信など各社マネタイズに工夫しているようです。

▲株式会社DMM.comラボ 植田隼人さん /「LIVEcommune」の開発リーダー、システムの取りまとめをしている

白石：この開発には何人くらい携わっているんですか？

植田：開発時はエンジニア、デザイナー、ディレクターなど、事業推進責任者含めると最大20人でした。今は10人ちょっとくらい。メンバー構成としてはリーダー、開発メンバー、サーバーサイド、iOSエンジニア、Androidエンジニア、ディレクター、デザイナーですね。

山本：iOSはXcodeと、当時の最新であるSwift 3.1で開発しました。あと、MVVMというアーキテクチャを取り入れて、RxSwiftというデータバインディングできるライブラリを使いました。RxSwiftはデータのやりとりから、コントローラーからモデルの間にビューモデルがあって、データのやり取りを簡単にすることができるライブラリです。

▲株式会社DMM.comラボ 山本修平さん / 「LIVEcommune」ユニットリーダー、iOSアプリエンジニアを務める

杉野：僕がエンジニアチームと大きく関わったのは、ぬるぬる動くスタンプのアニメーションのところです。はじめの要求としては3～4カ月くらいでiOS、Android、Webに書き出せるものを作ってほしいという要望もあり、デザイナーだけで完結できるAirbnbが出したライブラリでLottieというのを使いました。

After EffectsからiOS、Android、Webにそのまま反映できるので、ぬるぬる動くアニメーションが実現できました。データはJSON形式にしてアプリの方に送り、アニメを再生するのはRottyを使ってiOS、Androidに吐き出しています。Web版はこれから開発予定です。新しいことに挑戦したいという気持ちもあって、楽しかったですね。

▲株式会社DMM.comラボ 杉野さん /「LIVEcommune」のUIデザインとコンセプトメイキング、技術選定を担当

ロゴが変化するデザイン、ダイナミック・アイデンティティにチャレンジ

白石：デザインやロゴはどうでしたか？

杉野：今回良かったのは開発スタートしたときに、コンセプトやどういうアプリにしようというのがなかったんですね。搭載する機能だけが決まっていた。でも、コンセプトがあった方が機能を作る上での方向性も決めやすいと思ったので、デザインはコンセプトメイキングから入りました。こちらも開発と並行だったけど楽しかった。

コンセプトは「いつでもどこでも一体感を共有」「アプリを開くと新しい発見」「リアルタイムコミュニケーション」。この3つをロゴに落とし込みました。communeの語源は、親しく交わるとかコミュニティ、コミュニケーションからきています。

白石：丸くもこもこしているところがユーザーが交わっているところなんですね。

杉野：ライブアプリなので、再生を想起させるものを作りました。決めるのに2カ月くらいかかりました(笑)。イベントやメディアによってロゴの形や色が変化するダイナミック・アイデンティティという新しい概念も、これから取り入れようとしています。

▲ダイナミックアイデンティティ以外にもロゴの別案(パターン)も複数案出し、検討していったとのこと

WebのフレームワークはLaravel、データベースはAmazon Aurora、KVSはRedis

中里：僕はアプリの中でWebViewを使っているところや、API周りを担当しました。

アプリの中でユーザーが貯めたポイントを現金やiTunesカードなどの景品と交換できるのですが、そのユーザー認証や銀行口座などの入力、景品交換をする一連のページをWebViewを使って開発しています。

▲株式会社DMM.comラボ 中里勇輝さん /「LIVEcommune」Web/APIの開発を担当

白石：なぜ、WebViewで開発しようと思ったんですか？

中里：今後Web版が出たときに共有できるし、DMMの共通機能も使いやすかったからですね。

白石：APIはどの辺を使ったんでしょう。

中里：最初にフレームワークどうしようという話になったときに候補に挙がったのが、Laravel, CakePHP, FuelPHP。どれを採用してもチームの中で全員が使ったことがあるのがなかったし、どうせ学習コストがかかるのなら海外ではメジャーなフレームワークを使ってみたい。ということで、更新頻度も多く、海外ではメジャーだったのでLaravelを選びました。

白石：基本的にはPHPを使っているとのことですが、PHP7になって結構変わりました？

中里：メソッドを作る時に、引数などの型を完全に指定できるようになりましたね。指定したものと違うクラスが来たら、エラーになります。

あと、今回はAWS上に誰でも用意されたコマンドを打てば簡単に開発環境が作れる仕組みを作りました。これまで人によってバージョンが違うと動かなかったりエラーが出たりなど、ローカルで開発環境を作ってはまることが多かったんですが、今回はそういうことがなく、全員同じ開発環境がコマンド１発で作ることができました。

白石：どういうコマンドなんですか？

中里：AWS上でインスタンスを作って、ansibleでPHPやMySQLをインストールして設定するとAWS上に個人環境ができるというものです。ローカルでソースコードを書いて、シンクさせます。元を変えたら全員の環境がアップデートされます。新しいメンバーが参加しても、開発環境の準備で時間を取られることがなくなりました。

白石：反映が遅いということはなかった？

中里：ないですね。すぐに反映されます。

白石：データベースは何を使ってるんですか？

中里：AWSのAmazon Auroraと、KVSはRedisを利用しています。

データ通信のサーバーはSocket.IOで実装、言語はGoを採用

田仲：視聴中のチャットなどのデータ通信は、Socket.IOを利用しており、言語はGoを使用しています。たいていのものはSocket.IOで通信していますが、認証やセキュリティ的要件が必要なものは一回APIサーバーを挟んで通信していますね。

▲株式会社DMM.comラボ 田仲祐介さん /「LIVEcommune」配信サーバー、インフラ周りを担当

白石：重要な方はAPIを挟むんですね。

田仲：視聴者が画面をタップするとハートを送ることができるのですが、これらのデータの信頼性がそこまで重要でないものは速度を重視して、Socket.IOで完結させています。

植田：ちなみに去年くらいから、プラットフォーム上で使う言語はGoを採用するようになってきました。エンジニアが使いたい言語をチームで話し合って決めているので、自由度は高いです。

配信サーバーはWowzaで構築、チャット用サーバーはRedisで運用

白石：DMMさんがもともと自社で持っている映像配信のイメージが強いですが、そのプラットフォームを活用したのでしょうか。

植田：そうですね。社内のインフラチームにはサーバーの基礎の構築だけお願いしました。サーバーにAPIサーバーなどはの特定の情報は持たないようにして、AMIによる構築とで構築することによってオートスケーリングを組み合わせることによって、と組み合わせて障害が起きた際の復旧をインスタンスを自動化することができました。

ログはAWSのElastic SearchとKibanaを使っていて、チャット用のサーバーはRedisで運用しています。

田仲：配信サーバーの方はWowzaという製品を使って構築していて、そちらはAWSではなく、オンプレで構築しています。Wowzaは映像配信のデファクトスタンダードと言われているもので、一部モジュールの方はJavaで開発しています。

AWS Lambdaも少し使っているところがあるんですけど、そこはNode,Ruby,Pythonを使っています。

白石：田仲さんはオールラウンダーですね！配信サーバーだけはオンプレなんですか？

田仲：配信サーバーは要求されるスペックが高く、AWSで試算してみたらランニングコストがかなり高かったので、オンプレで構築しました。

田仲：当初WebRTCの採用も検討したんですが、少人数のグループでの映像配信には向いていると思うのですが、不特定多数に配信するこのサービスでは負荷対策の問題がありました。現在は、RTMPとHLSという技術を組み合わせて使用しています。

配信サーバーのリリース時は、使われていない配信サーバーから順に停止して入れ替えていくんですが、たいていの場合は人力で1台ずつリリースしていると聞きます。そこを自動化したことで、人的なコストとリリースにかかる時間を抑えることができました。

白石：配信はロードバランシングできるんですか？

田仲：視聴という意味では、配信サーバーからHLS形式でクラウドフロンドのCDNをはさんでます。配信のインプットはロードバランサーをはさむのは困難なことと、一度に大量のアクセスが来るものでもないので、振分ロジックをAPIサーバーの方で実装しました。それにより、配信負荷が均等になるように振分されます。

白石：大量のトラフィックが発生する視聴側はHLSで負荷分散をするわけですね。

ユーザー数に合わせたサーバーや開発体制の構築を

白石：最後に、今後サービスや開発の課題でチャレンジしていきたいことを聞かせてください。

田仲：当初予定していた視聴者数などの要件定義に耐えられるような構築したのですが、サービス開始直後ということもあり、まだそこまで利用されていない状態です。今後は利用状況に応じてスケーリングすることにより、ランニングコストの調整をしていきたいなと考えています。

植田：今回のプロジェクトでは、開発手法としてスクラム開発を取り入れました。社内でスクラム開発が増えてきているという背景もありますが、一番の理由は定期的に成果物を確認し合い、手戻りをなくしたいからです。

スクラム開発をやるにあたって、本やネットで調べて手探りでやってみましたが、わからないことがたくさんあったんですね。開発が一旦落ち着いてきたので、今度はもっと正規なスクラム開発をやってみようと思っています。

白石：ちなみにプロジェクト管理のツールは何を使ってるんですか？

杉野：JIRAを使っています。ドキュメント管理はConfluenceやGoogle Docsですね。あとはホワイトボードも活用しています。誰がどんな業務を抱えているのか、目で見てわかりやすいので。

山本：機能ドリブンで開発をしてきましたが、リリースしてわかったことや、自分たちが実際にユーザー側に立って使って感じたことを改善していきたいですね。

白石：DMMさんはエンジニアがチームで話し合って技術剪定をしているので、新しい技術にもチャレンジしやすい環境があって楽しそうですね。今日は興味深い話をいろいろ語っていただき、ありがとうございました！

LINEのニュースタブをReact.jsで開発しているフロントエンド、JavaとPerlで開発しているサーバーサイドのエンジニアの方々に、どんな開発技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！

今回お話を聞いた「LINE NEWS」開発チームの皆さん

LINE株式会社 前澤 春樹さん
Javaのサーバーサイド担当。200以上の媒体社様向け管理画面のコンテンツ入稿システム開発や、公式アカウントから発信されるメッセージ配信システムが主な担当。

LINE株式会社 森藤 賢司さん
Perlで作られている一般ユーザーから見えるニュースタブ、記事ページのバックエンドや社内向けの管理画面を担当。

LINE株式会社 大槻 友諒さん
フロントエンドエンジニア。WebViewでつくられているニュースタブの実装を担当している。React.jsなどの最新技術に触れることも多い。

LINE株式会社 富田 梓さん
マークアップエンジニア。デザイナーの作成したPSDをもとにしたCSSの設計と実装を行う。ニュースタブの他、PC/SPのWeb、キャンペーンページなどニュース関連全般を担当。

なぜ、ニュースタブはWebViewなの？

白石：今日は主にニュースタブにフォーカスしてお話を聞いていきますね。LINEのニュースタブは、なぜWebViewを使ったのでしょうか。

大槻：もともと記事ページはWebViewで作っていました。ニュースタブを作ろうという話になったときに、記事ページと同じ技術で作るほうが開発スピードも早いし、やりやすい。バージョンアップなども、そろえたほうがリリースしやすいということでWebViewで作ることになりました。

白石：じゃあ、ニュースタブ以外はネイティブでできているんですね。

大槻：そうです。トークやタイムラインなど、メインの機能はネイティブで実装されています。並んでるタブの中だと、ニュースタブだけがWebViewです。

白石：WebViewとネイティブといった複数の技術を混ぜるのって、大変だったんじゃないでしょうか。

大槻：ネイティブとWebView間でデータやイベントをやり取りする必要があって、そのための仕組みをアプリエンジニアと協力して実現しました。ユーザーにはLINEアプリの一部として見えるので、挙動やパフォーマンスに違和感が出ないようにするのが大変でした。

白石：WebViewだと、読み込みや表示が遅かったりしません？

大槻：いえ、結果的にそこまで遅いということはなかったです。Webだからの限界はありましたけど、WebViewだから特別つらいことはありませんでした。

LINEバイトやLINEギフトといったファミリーアプリにはすでにWebViewの技術が使われていて、知見があったことも役立ったんだと思います。

白石：React.jsを使っているとのことですが、SPA的な開発だとマークアップはそんなに必要じゃないと思うんですが、両方必要なのはどうしてなんでしょう。

富田：うちは分業体制をとっていて、僕と大槻さんが所属しているチームはフロントエンドを担当しています。案件によってJSとマークアップの両方を一人が担当することもありますが、newsでは規模の大きさもあって担当が分かれています。

デザインからHTMLを起こして、それを渡しているので、一般的に言われているReactを使うイメージとはちょっと違うかもしれません。

大槻：セマンティックなHTMLを書くとか、CSSを設計するといったところは完全にお任せしてします。一回組んだものを、パーツとして分解してJSXに落とし込んでいます。

白石：PCでも記事ページそのものは見られるんでしたっけ？

富田：記事ページは見られます。

白石：あ、レスポンシブ対応しているんですね。

富田：いえ、レスポンシブとかではなくて、PC専用に作っています。SNSなどでシェアされたURLはPCからでもアクセスできるため、PC用の記事ページを用意しています。

JavaとPerlでサーバー管理

白石：サーバーサイドでJavaとPerlという複数言語を使っているのはなぜですか？

森藤：もともとPerlで全体が作られていたのですが、社内の方針で最近はJavaで作ろうという流れになってきています。なので、最近のレポジトリとかはJavaで作ってます。まあ、歴史的背景です(笑)。

Perlはニュースタブと記事ページ、あと社内向けのCMSもPerlで作られています。

白石：へえ！CMSは自作なんですね。ちなみに、ReactはAPIを出すのに使ってるんですか？

森藤：はい、ニュースタブの部分は、全てAPIで実装されています。

白石：Reactでサーバーサイドレンダリングしているのでしょうか。

大槻：いえ、クライアント側でレンダリングしています。

APIでとってきたデータをローカルストレージにのせておいて、ネットワークがないところでも画面が真っ白にならないように工夫しています。

白石：JavaとPerlで分かれていますけど、システム間連携しているんですか？

森藤：データベースで連携しています。データベースはMySQLを使っています。

白石：MySQLをクラウド上で？

森藤：いえ、オンプレです。本番環境は、現在ほとんどオンプレのサーバーで動いていますが、最近構築したサーバーや開発環境はプライベートクラウドの「Verda」というサービスを使っています。

白石：えっ、どこかの製品を買うのではなく、自分たちで作ってるんですか。かっこいいですね。

森藤：DB周りはDBA（データベース管理者）のチームが運用しています。DBサーバーの構成は、マスター1台に参照やバックアップに使うスレーブが数台ある感じです。テキストで入稿するデータなので、データ容量が一気に増えて困ったとか、容量が足りなくなったという話も聞いたことがないですね。

白石：Javaで入稿システムを作っていらっしゃるんですよね。ScalaやKotlinなんかも使っているんでしょうか？

前澤：Javaだけです。最近のモダンな言語に比べると、やっぱりJavaは冗長というかすごいコード量を書かないといけないのは大変なんですが…。

白石：ぼくは昔Javaエンジニアだったのですごく気になるんですが、Javaのバージョンは何ですか？

前澤：Java 8です。

大槻：僕も前職では、エンタープライズ系のサービスをJavaで書いていました。その時はバージョンが古くて4でした。あと8をちょっと触ったくらい。当時はジェネリクスもアノテーションもなくて(笑)。

白石：僕はXML地獄でしたね(笑)。EclipseみたいなIDEとかは使ってますか？

前澤：Eclipseは使ってなくて、IntelliJ IDEAを使ってます。

React.jsを選択した背景は？

白石：フロントエンドのReact.jsはいつから使ってるんですか？

大槻：ニュースタブができてからなので、2017年2月からですね。

白石：苦労したこととかありますか？

大槻：React.jsだから苦労したことは特になかったんですが、どのライブラリにするかは結構検証しました。Vue.jsやRiot.jsなんかもいろいろ試してみたのですが、結局React.jsにしました。

Create React Appでベースを立ち上げた経緯もあって、最初の環境を整えるのはすごくスムーズでした。React.jsは結構書きやすくて、世の中で使われているアプリも多く、バージョンアップも早いし、安定していて信頼できました。

白石：なるほど。stateの管理とか、Reduxは使ってますか？

大槻：Reduxは最初は使おうと思ったのですが、意外と過剰なスペックがあってやめました。代わりにFlux Utilsを使っています。

足りない開発ツールはどんどん作る

白石：ほかにLINEさん独自の開発手法があれば教えてください。

大槻：フロントのアクセス解析はGoogle アナリティクスを使っているんですが、そのほかに社内で開発した「LINE Analytics」という解析ツールを使っています。JavaScriptのエラー部分もリアルタイムに収集できるので、リリース直後に増減を確認したりしています。

白石：LINEさんは結構社内で作る文化があるんですね。自分たちでも作るというのは、意思決定が必要だと思うんですが、どんなかんじで決めているんですか？

富田：その辺は結構自由にやらせてもらえる風土ですね。プロジェクトで使うツールだけでなく、たとえばメーラーやスケジュール管理といった社内システムについて内製する部署があります。既製品でもの足りなかったら、自分たちで作っちゃおうみたいな。

大槻：分業しているのでサーバーに触れること自体は少ないんですが、JSやCSSの配信ツールをフロントエンドチーム内で開発したりと、役割内で足りないものは作って配布させたりする人が多いですね。

サーバー側はCIも自前で作ってると聞きました。社内の承認フローがそれほどかたくないので、わりと気軽に自前で作ってます。

白石：CIもですか！Jenkinsとかを使わずに？

前澤：Perlでは内製のCIを使っていますが、JavaではJenkinsを使ってビルドしていて、ビルドした成果物をサーバーに配布するシステムは内製です。CDNのオリジンサーバーも自作してますね。

秒間2万のアクセスを捌くパフォーマンス

白石：パフォーマンスなんかもかなり気をつかっているんじゃないでしょうか。

森藤：はい。APIアクセスが秒間2万くらいのアクセスがあるので試行錯誤しています。APPサーバーの台数は約30台くらいなんですが。

森藤：去年の6月に高速化プロジェクトがあって、CDNを追加しました。CDNはAkamaiを使っています。クエリーをちゃんと書いてなかったりするとサービスが止まるので、SQLには気をつけてキャッシュに貯めるようにしていますね。

白石：フロントエンドのパフォーマンスで工夫した点はどうですか？

大槻：ニュースタブは縦に長いんですけど、DOMが増え過ぎるとメモリを食ってアプリがクラッシュしてしまう問題がありました。

iPhoneでは横スワイプでタブ移動できるので、左右のタブを予め描画している分よりDOMが多く、見えないDOMをいかに削除していくかなどの工夫をしています。

タスク管理・チーム間の共有ツールは？

白石：皆さんは所属する組織は違うとのことですが、「LINE NEWS」プロジェクトのタスク管理やチーム間の共有ツールはどうしていますか。

富田：ニュースチームのプロジェクトとして定例ミーティングをして、進捗管理しています。管理に使っているツールはJIRAですね。

白石：進め方はアジャイルですか？

富田：そんなにアジャイルぽくはないです。企画チームが20人くらいいて、案件ベースを作ってくれるので、早い段階で開発からもフィードバックしたり、企画と一緒に練ったりします。1週間のスプリント制でやっています。

白石：ニュースチームは全体で何人くらいいらっしゃるんですか？

前澤：企画や開発、制作、編集、アライアンス、モニタリング、PR・マーケティングなどを含めると、プロジェクトに関わっている人は100人を超えています。エンジニアは現在、バックエンドが8人、フロントエンドが4人です。

白石：大型プロジェクトですね。CIは自作されてるとのことでしたけど、DevOpsみたいな工夫ポイントはありますか？

前澤：これまでは五月雨で流動的だったけど、人が増えてきたので週1回のサイクルを整えたり、模索しているところです。

白石：ソースコードの管理やリリースのルールとかはどうでしょう。

森藤：ソースコードの管理はGitHubです。Perl側は最低2人レビュアーがいないとリリースやマージしちゃいけないことになっています。

急成長するサービスと開発体制に合った環境を構築

白石：最後に今後こうしたいという抱負や、チャレンジしたい目標を教えてください。

前澤：LINEのサービスが急速に成長して、エンジニアも増えているので、開発時期によってリポジトリやフレームワークの使い方も違ってきています。それを統一したいと思っているんですけど、結構大変そうです(笑)。

森藤：これまでのサーバーサイドはほとんどPerlだったんですけど、ここ数年みんなJavaを書くようになって、Perlを書くエンジニアが減ってきているんです。サーバー側をもっとJavaに置き換えていけたらと思ってます。

大槻：TypeScriptを導入も検討していきたいです。依存するライブラリの都合もあって、簡単ではないかもしれませんが。

富田：ニュースのプロジェクトが始まったのが2013年で、最近では更新が滞っているruby-sassやgrunt、compassといった古い環境に依存しており、日々の更新に忙しくてそういった根幹部分はなかなか手を入れることが難しかったんですが、最近のリリースで、タスクランナーに依存したコンパイルをやめたり、node-sassへの移行したりしました。

それに伴ってチームで使っている社内用のツールやsassのライブラリを更新しているので、今後も新しい技術についてそれらに生かせるか検証しつつ対応できればと思っています。

白石：LINEさんは独自の開発ツールをどんどんつくっていく行動力と技術力が素晴らしいですね。今日はいろいろ面白い話をありがとうございました！

LINEさんでは、9月28日(木) にエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2017」を開催するそうです。LINEの様々なサービスにおける技術領域でのチャレンジや開発体制などについて語られるとのことなので、興味のある方はぜひ参加してみてください。

社内のエンジニア向けツールをSaaS事業化

白石：まずは、皆さんの自己紹介からお願いします。

松木：はてなはIDで呼び合う文化なんです。僕は本名の松木を中国語読みにしたSongmu（ソンムー）と呼ばれています。3年前にはてなに入社して、Mackerelのディレクターと東京オフィスのチーフエンジニアを任せてもらってます。

元々はPerlのエンジニアですが、最近はGo言語を書くことが多くなってきました。共著で『みんなのGo言語』という本を書いてたりします。

　▲株式会社はてな チーフエンジニア 兼 Mackerelディレクター 松木雅幸（Songmu）さん

濱田：itchynyです。2015年4月に新卒として入社しました。「Mackerel」のアプリケーションエンジニアとして開発していて、リードエンジニア代行も務めています。

村田：村田（はてなID:murata_s）です。2013年4月に新卒として入社しました。「Mackerel」を担当して3年になります。最近はMackerelのデザインチームをまとめています。

▲株式会社はてな アプリケーションエンジニア 濱田健（itchyny）さん、アートディレクター 村田智（murata_s）さん

白石：今日ははてなさんのサーバー監視サービス「Mackerel」について、いろいろ聞かせてください。

松木：はてなはこれまではてなブログやはてなブックマークなど、カスタマー向けの事業が中心だったんですが、最近はそのバッググランドを活かした他社との協業も増えてきました。

例えば、KADOKAWAさんと共同開発した小説投稿サイト「カクヨム」、ソニーさんとの共同事業である「家電会議」、任天堂さんに開発協力した「Miiverse」などが最近のはてなの流れです。「Mackerel」もその流れの一つで、他社との協業サービスではないですが、カスタマ―向け(toC）で培った技術やノウハウを企業向け（toB）に活かしたサービスです。

はてなは今年16年目の会社ですが、かねてより、社内クラウド基盤を構築・運用し、1000台を越える仮想サーバーをスケールさせ、管理しながらサービスを提供してきました。そのための仕組みも社内で内製してきました。それがMackerelの前身となるツールです。

最近ではAWSやGCPなど、パブリッククラウド上で仮想サーバーを増減させるのが当たり前の世の中になってきたこともあり、前述の内製のサーバー管理ツールのノウハウを活かし、「Mackerel」というSaaSを新規開発し、B向けの新規事業として打ち出したんです。

「Mackerel」には、これまでのサーバー監視・管理ツールと考えを変える必要があると思って作っている部分があります。一つはクラウドの思想に沿った設計であること。昔と違って、今はサービスの状況に合わせてクラウドでのサーバーを増やしたり減らしたりすることは普通になってきました。

でも、サーバーを建てたらすぐ監視を開始しなくてはいけないし、サーバーから外したら監視も外さなければいけない。そういった運用コストを解消したいということ。

もう一つは、UI/UXの差別化。既存のサーバー管理・監視ツールはエンジニアだけが使うものが多く、それもあって、デザイナーがツールの開発に関わることは少なく、見た目や使いやすさが考慮されることはあまりありませんでした。しかし、「Mackerel」は使い勝手や見た目を考えて、いろんな人に使いやすいように工夫をしています。開発には専属のデザイナーが3人携わっています。

白石：グラフがメールで送られてくるといった点もそういったこだわりからなんでしょうか。

松木：はい、メールに限らず全般的にグラフの見せ方にはこだわっています。ブラウザの画面上でグラフを並べて見られるようにしている部分も直感的に見やすいように作っています。

白石：はてなさんは1000台を超えるサーバーを運営していたとのことですが、今はどうなんですか？自前のオンプレが主なのか、クラウドも併用しているのか。

松木：今は併用しています。「Mackerel」自体は自社のデータセンターのサーバーを使っています。新規サービスについてはAWSを使うことが増えていますね。

白石：オンプレのほうが規模が大きくなると、サーバーコストは安くなると思いますが、クラウドを併用する理由は何でしょう？

松木：安定していて、ゆるやかな成長が見込めるサービスは、見積もりやすいのでオンプレにメリットがあるのですが、新規サービスにはやはり素早く作る必要があるので、クラウドのほうが便利ですね。オンプレは改善を重ねる必要があったり、急激なサービス増強といったときに調達が大変なので。

コア部分はScala、サブシステムはGoで開発

白石：プログラミング言語は何を使っていますか？

濱田：サーバーのアプリケーションはScala、ユーザーがサーバーにインストールする監視エージェントであるmackerel-agentはGoで開発しています。外形監視とデーターベースインテグレーションのクローラーなどもGoで書いています。

松木：コアな部分はScalaで、サブシステムはGoで書くといったかんじです。

白石：それぞれ言語を変えてる理由はあるんですか？

松木：Mackerelは複雑なソフトウェアなので、コアの部分は抽象度の高い表現ができる言語を採用するのがいいだろうと。いろんな言語を検討したのですが、静的型付けができ、表現力が高いScalaを採用しました。

ただサブシステムやマイクロサービス的に作る場合など、局所的に少ない台数でパフォーマンスを出したいようなコンポーネントを開発する場合には、Goのほうがマッチしています。

濱田：mackerel-agentはWindowsを含めてどんな環境でも動かないといけないし、実行速度の面でもGo言語は優れていると思っています。サブシステムは本体のアプリケーションに比べると機能が少なく、コード構成が把握しやすくてデプロイも簡単なGo言語は適していると思います。

白石：シングルバイナリになるからとか？

濱田：そうですね。

白石：Scalaってやっぱり重いとかメモリ食うなどのトラブルが起きたりしますか？

松木：現実問題としてはありますね。コンパイル時間の問題もあります。本番ではサーバーを何台か立ててローリングでデプロイする形になるので、ミニマムで構成するにしてもそれなりにコストがかかる。ただ、パフォーマンス自体は悪くありません。開発時間はかかるけど、その分バグが起きにくいので、B向けにはマッチしていると思います。

グラフで直感的に状況がわかるUIデザイン

白石：デザインの話も聞かせていただきますね。UI/UXでこだわっているところ、思い入れがある点などについて聞かせてください。

村田：Mackerelは日常的に使う道具なので、ストレスなく直感的にグラフの傾向がつかめるようにデザインしています。複数のグラフが並んだときにも機能を落とさず使い勝手を保てるように、細かな部分にこだわっています。

このようなツールでは、何かをするためのボタンが多くなりがちですが、それは往々にして最初の学習コストを増やすことにつながります。使い始めたばかりの人でも理解しやすく、必要な時に必要な行動がおこせるような、良い意味で簡素なUIの提供を心掛けています。

最近ではitchynyさんと共同でアラートの絞り込み機能も作りました。

白石：グラフは何で作ってるんですか？

濱田：これはD3.jsで作ってます。グラフにマウスオーバーしたらこのようにメトリックの値が表示されます。

白石：へえ、すごい！これ、モバイルでも見れたりします？

村田：モバイル用のUIも用意しているので、お手元のモバイル端末で見ることができます。出先でアラートを確認したいということありますよね。そんなときに便利です。Mackerelの画面はレスポンシブ設計になっているので、タブレットサイズの端末でもご覧になれます。

白石：レスポンシブなデザインってどんなかんじで作っているんですか？

村田：開発内容にもよりますが、直接HTMLとCSSを触りながらデザインしていくことが多いです。画面上での表示内容は、単に表示サイズもそうですし、様々な利用状況や設定によっても大きく影響を受けます。

想定されるシステムの状態を思い描き、チームメンバーとコミュニケーションしながら進めていきます。GitHubのIssue上でのやり取りに加え、細かなところは口頭で直接会話をしたり、他の拠点にいるメンバーとはハングアウトを活用して議論したりもします。

松木：開発体制のことをもう少し詳しく説明します。東京はビジネスメンバー中心で、プロダクトオーナーやセールス、セールスエンジニアという体制で、開発エンジニアは一人です。京都に他の開発メンバーがいます。

Mackerelのリードエンジニアで開発の最初にコードの1行目を書いたエンジニアが愛知にいるんですが、今は育休中です。なので現在は、itchynyさんがリードエンジニア代行を務めています。

リードがリモートなのでオンラインでコミュニケーションするというスキルが発達しているんですよね。開発ログはちゃんと文章で残すし、気軽にビデオで会話しながらコミュニケーションをとるように意識しているし。

濱田：朝会はスタンダップミーティングの形式なので、10分かからないですね。リモートのコミュニケーションにはZoomというツールを使っています。

松木：Zoomは2年前から使っていて、いろいろ試してみたのですが、これが安定しているんですよ。最近はハングアウトも導入しています。定期的なミーティングとかはハングアウトを使ってやってます。

白石：Mackerelチームは、全員で何人いるんですか？

松木：今はビジネス系含めて16人います。そのうち開発は11人です。

白石：16人いて10分かからないというのは相当テキパキしてると思うんですが、どんな話をされてるんでしょう。

松木：各人がはてなのグループウェアに日報を書いているので、その共有を朝会でやっています。最近はそれも減らしていて、各自が話したいことをGitHubでIssuesを上げて、司会がランダムに読み上げていくだけなので、すぐ終わっちゃう。

村田：デザイナーの分科会もチームの朝会後にやってますね。

毎週必ず新機能をリリースしている

白石：開発ツールや開発の進め方について教えてください。

松木：開発ツールはGitHubとZenHubでカンバン、日々のコミュニケーションツールはSlackを使っています。

開発体制としては、スクラムぽい開発をしていて、2週間に1回開発会議をしています。だいたい5～6時間くらい、メンバーがそろって会議している。誰が何を担当するかなどを決めて、次の2週間はなるべく打ち合わせせずに、集中して開発してもらう。で、一番最後の日は振り返りをします。アジャイルの世界だと「出荷」っていうと思うんですけど、それをめでたいって祝うかんじです。

デプロイは週に2回火曜と木曜に行なっています。こだわっているのは毎週新機能を出すということ。正式リリースから、お盆や正月などを除くと毎週何かしらのリリースを出していることは、評価いただいています。

白石：毎週新機能出していることをどうお客さまにお伝えしているんですか？

松木：告知ブログを毎週日本語と英語で書いています。毎週メールでユーザー全員に告知メールも出しています。楽しみにしてくれるユーザーも多くて、Twitterを眺めていると、告知を見てコメントをしてくれている。祝日の関係で木曜に告知送ると、「今日金曜かと思ってあせった」と書かれていたり(笑)。

白石：巨大な機能を出すときはどうしているんですか。メインの開発ラインと別にしているとか？

松木：厳密なスクラムだと、大きいタスクでも小さな単位に区切ってスプリント内に収まるタスクにしてから始めることが多いようですが、それでは見積もりのオーバーヘッドも出てくる。大きめのタスクに関しては担当を決めて張り付いてもらうことが多いですね。

プロダクションに出していく前は、絶対にプルリクエストを送って誰か他のメンバーのレビュー受けてからマージするようにしています。そこで、一人の人に任せきりになって属人化することを避けてバランスをとっているかんじです。

白石：プルリクエストが巨大になるということはないですか？

濱田：それはそうならないように努めています。まずはテーブルスキーマの変更をレビューに出して本番に反映し、モデル層やAPIなどのレイヤー毎にプルリクエストを出し、順番にレビューしてもらい、リリースしていきます。プルリクエストのサイズを意識して、開発メンバーが誰でも見れるようにしています。

松木：基本的には、この人が見ないとプロダクションに出せないというやり方はしていません。全員がちゃんと全部レビューできるように務めている。リードエンジニアが育休とっていても、代行が問題なくできるのもそういうのがきちんとできているからなんです。

最近結構ほかのチームから新たにメンバーが異動して来たのですが、そのメンバーはMackerelのことを知らないので、逆に積極的にレビューしてくれたりします。全員がレビューするというのははてなのこだわりです。

グローバル展開に向け、初期段階からドキュメントを英語化

白石：フレームワークは何を使ってますか？

濱田：WebアプリケーションフレームワークにはPlay Frameworkを用いています。Lightbend社 (旧Typesafe社) の製品で、継続して開発されており、信頼性も高いと思います。フロントエンドでは、AngularJSを使っています。デザイナーさんにもAngularJSのテンプレートを触ってもらっていますね。

白石：デザイナーさんもプログラミングスキルをお持ちなんですね。すごいなあ。

濱田：データベースはPostgreSQLを使っています。はてなでPostgreSQLを使っているのはMackerelだけですね。採用理由には、外部キー制約を張ったりチェック制約を設定することでデータを固く守れる点や、JSON型があることでメタデータのようなデータも保持しやすいところにあると思います。

白石：Scalaを書くのに使っているのは？

濱田：エディタはVimを使っています。3人ともVimを使っていますね、たまたまですけど(笑)。

松木：あとはEmacs3人、IntelliJが2人ですね。

白石：ということは自由なエディタを使っていいんですね。

濱田：そうですね。私はIDEは使ってないんですが、使っているメンバーもいます。

白石：最後に、これからチャレンジしていきたいことを聞かせてください。

村田：今後もUIは継続的にブラッシュアップしていきたいですね。ユーザーさんの声を聞いて使いやすくしていきたいと思います。

松木：ユーザー数がどんどん増えているので今の10倍になっても負荷に耐えられる環境を作っていきたいです。課題としては、マイクロサービスで各種コンポーネントを起動してテスト環境や開発環境を作るのが大変なので解決したい。あとは、せっかくドキュメントを初期段階から全て英語化しているので海外でも使ってもらえるサービスにしていきたいですね。

白石：Mackerelは僕も使っているので、すごく興味深く聞けました。これからの新機能拡充も期待しています。今日はいろいろ面白い話をありがとうございました。

今回はさっそく森下さんにも加わっていただき、白石俊平編集長を聞き手に、CTOの髙橋侑久さん、フロントエンドエンジニアmizchiさん、デザイナーの東峰裕之さんに、「Qiita」の開発環境や開発スタイルなどについて聞いてみました。

特定領域でとんがってるスペシャリストが増えてきた

白石：まずは、自己紹介とQiitaの開発チームでの役割についてお聞かせください。

髙橋：IncrementsのCTOを務めている髙橋です。メンバーの中では一番古株ですね。Qiitaは最初、CEOの海野が開発していたのですが、それを引き継ぐかたちでQiitaのプロダクト開発からインフラまでのすべてを見てきました。

最近はJavaScriptのエキスパートであるmizchiのように、特定領域でとんがってるメンバーも増えてきているので、エンジニアの組織作りや環境整備に注力する時間が増えています。

白石：Qiitaはもともと海野社長がコードを書いてたんでしたっけ。

髙橋：はい。Incrementsは代表の海野が大学時代にビジネスコンテストで知り合った3人で創業したんですが、その共同創業者の1人が海野にプログラミングの相談をしたことがQiitaを開発し始めたきっかけでした。

Qiitaはプログラマのための情報共有のプラットフォームで、解決しようとしている課題は明確なんです。プログラムを書く時ってGoogleで検索したり技術書で調べず、頭の中の情報だけでコードを書く人はほとんどいないじゃないですか。

でも結局自分が知りたい情報が見つからなくて、時間を無駄にしている人は多いですよね。誰もが使える情報共有基盤を作って、そういう検索時間を圧縮できたら、日本のソフトウェア開発の生産性を高めていくことができると考えたのが、Qiita誕生のきっかけです。

Qiitaの開発は2011年に始まって、2012年に起業しているんですけど、最初は3人で始めたということもあって、リーンスタートアップみたいなかんじで開発していたんですよね。僕が入社したのは2013年4月。その時にエンジニアのコミュニティに支えられながら、自分が必要だと思っていたQiitaの下書き機能を開発しました。

白石：なるほど。当時も技術系の情報を発信するブログサービスは存在していたと思うんですが、Qiitaが大ブレイクしたことから考えても、まだ不十分だったところがあったんでしょうね。

mizchi：僕は基本的にはフロントエンドの人間で、2年前に教育系のベンチャーから転職してきました。最初は「Kobito」のWindows版をElectronで作ったり。SPA（Single Page Application）とネイティブAPIをたたくアプリを作ってたんですけど、去年の9月からQiitaの開発にも関わるようになりました。

Qiitaは2011年末くらいに開発されたものなので、ちょうどそのくらいの時期にフロントエンドのフレームワークに激動の技術進化があったりして、いろいろ古くなってしまったところをどうにか秩序をもたらせないかと対応してきました。最近やっと落ち着いて、機能開発などもかなりやれるようになってきたかなあという感じです。

例えばQiitaのホーム画面のフィードや編集画面、この前足したスライド機能など、どうしても局所的にJavaScript的な密度が高くなる箇所があるので住み分けし、モジュールとしてAPIがちゃんとお互い交流できるようにきれいに設計しています。

さらに、コンポーネントで密度を厚くし、複雑化したところからはみ出さないように作っていく。でもかなり行数も多いんで、できる範囲でとにかくきれいに区切って、ひたすら分割していくみたいなことをやってました。

東峰：デザイナーの東峰です。Incrementsではデザイナーの業務範囲が結構広くて、PMに近いことからデザインの実装まで一通り行います。ユーザーヒアリングも行くし、エンジニアとコミュニケーションとりながら企画やディレクションなども行うし、GitHubにPull Requestも出すという感じです。

前職はサイボウズでグループウェアを作っていたので、入社した頃は「Qiita:Team」を担当していましたが、最近はQiitaをメインに担当しています。

森下：8月にIncrementsに入社しました。前職はサイバーエージェントで、新卒で入社してフロントエンドエンジニアをやってました。UI周りの実装だったり、CSSの設計が得意領域で、自分でCSSのフォーマッターとかスタイルガイドジェネレーターを自作したりもしてます。

縛りをつけず、最新技術もいろいろ試す

白石：では、さっそく開発環境などの話を聞いていきたいと思います。まずは、Qiita全体のアーキテクチャについて教えてください。

髙橋：アーキテクチャとしてはオーソドックスにRuby on Railsを使っています。バージョンはまだ5にはしてなくて、4.2です。データベースはMySQLを使っています。

白石：フロントエンドの開発ツールやエディタは何を使っているんですか？

mizchi：エディタには特に縛りがないですね。最近はBabelを使ってるんですけど、FlowTypeというTypeAnnotationを付けるやつを部分的に足しています。全部ではないんですけど、新規で書いた分は型を付けながら進めている部分が多いです。世間的にはTypeScriptの方がメジャーだと思うんですけど、TypeScriptはスクラッチの開発じゃないとなかなか導入が難しいので。

最初CoffeeScriptで書かれていたものをJSに変換するコンパイラとかをかけながら、ガリっと書き換えた時期があって、その頃にBabelにして、RailsのSPRocketsを使ってビルドしてました。去年はそれもできるだけ捨てて、書き直してっていうのを延々やってましたね。

白石：たしかmizchiさんって、ブログでCoffeeScriptってヤバいみたいな記事を書かれてませんでしたっけ？

mizchi：CoffeeScriptはあまりメンテされなくなってきたのと、ES2015(ES6)がすごい進化してて、新しい機能を使う時にCoffeeScriptに縛られるのはかなりのリスクがあるなと。CoffeeScript好きな人は全然いいと思うんですけど、自分のようなフロントエンドを一応攻めないといけない人は、CoffeeScriptを使うのはリスクであると認識してます。

白石：先ほどTypeAnnotationを使っていると言ってましたね。型がないのがJavaScriptのいいところでもありますが、やっぱり規模が大きくなってくると型が欲しくなってきたというところでしょうか？

mizchi：これはいろいろ考え方はあると思うんですけど、JavaScriptってとてもテストが書きづらい言語なんですよね。End to End（E2E）だったり、独立させたNodeでユニットテスト書くなりしても、なかなか書きづらい。最近はとても分量が多くなってしまっている中で、その動作を担保するものとして、静的解析っていうのは有用なんじゃないかと。まあもちろん、静的解析するからといって、テストを全く書かないというわけではないんですけれど。

白石：FlowTypeで書いたものをテストケース書くとなったら、テストケース側は何で書くんですか？

mizchi：今はNodeでユニットテストできるようにしています。Reactのサーバーサンドレンダリングは基本的にテンプレートのテストやユニットテストならできるんで。E2Eが足りないのは分かっているんですが、決め手のフレームワークが今ちょっと足りてなくて…(今現在E2Eを導入してないのは)反省しているところがあります。

白石：フロントエンドのほうは、Reactを採用してるんですね。

mizchi：はい。昔はBackbone.jsで書いたものも大分残ってはいるんですけど、新規で書く部分に関しては、Reactで書いています。Reactがいいというよりはここが古くなったから捨てるということが密結合にならずに、個別のモジュールで一気に捨てられるような、代謝のしやすい設計をすることが大事だと思っています。

白石：CSSとReactあたりって、興味がある人が多いと思います。CSSモジュールとかいろいろ聞かせてください。

森下：前職でReactを使っていてたんですが、Reactアプリの中でCSSを書いていくことに対しては自分なりの意見を持っています。CSS Modules等のCSS in JS系ツールを触ってみたりしたんですけど、僕はJSのコンポーネントの単位とCSSのコンポーネントの単位って、1対1で対応するものではないと考えています。

それはデザインの再利用する単位と機能の再利用する単位が異なるからで、よくあるcomponentsディレクトリ配下に、index.jsとindex.cssがあるみたいな構成は結構難しいのかなと思っています。

CSS in JS系ツールは、CSSそのものやその設計手法にあまり詳しくない人が、なんとなくJSのコンポーネントの単位でスタイルの影響範囲を閉じたい、という場合は良いものだと思います。QiitaとQiita:TeamはHTMLのレンダリングを全てReactが行っているわけではないので、部分的にCSS in JSを導入するのもおかしいので使いたくないです。

白石：じゃあ、もうコンポーネントにスタイルは閉じない？

森下：そうですね、Reactのコンポーネントの単位ではCSSのコンポーネントは作らない。

白石：Web ComponentsでCSSを閉じさせられる、例えばShadow DOMとかだと思うんですけど、それはちょっとどうかなって思ってるかんじですか？

森下：Shadow DOMでスタイルの影響範囲に抑られるのはいいことだと思ってますが、そもそも装飾と機能を合わせたものをコンポーネントとしていろんなところで再利用していこうという考え自体が僕にはイマイチ…。

mizchi：そういえば昔、Web Componentsでピアシングってスペックがありましたね。

白石：ピアシング、それ知らないなあ。

mizchi：ピアシングって、外から中に対してCSSをかけるんですよ。でもそれがなんか難しすぎるからなくなったらしいんですよね。やっぱりそこの複雑さよりは、単純な方をWeb Componentsは取ったんだろうなっていう気はします。

白石：なるほど、scope属性みたいな感じで書いていけるんでしたっけ？

森下：あれも今は仕様が変わってて、scoped属性はなくなって、＠scopeっていうアットルール（＠規則）に変わりました。（注: このあと＠scopeルールもなくなった）

白石：そうなんですね。勉強になります。じゃあもうCSSは別に出しちゃって、WebとかそういったものでCSS付けるっていうみたいな感じなんですかね。

デプロイはAWS、ログ収集はBigQueryを利用

白石：ちなみに、バックエンドのほうの話も聞いてみたいです。

髙橋：デプロイ関係はAWSを使ってますね。あんまりAWS固有にベッタリみたいな感じにはしたくないと思っているので、データの収集などはGoogleのBigQueryを使っています。

白石：僕もBigQueryを使いたいんですが、使っているクラウドサービスはAWSなんですよね。Googleのほうはインターネット回線を通じて送っているんでしょうか？

髙橋：今は各アプリケーションサーバーごとにFluentdがあって、それを集約するFluentdサーバーからGoogleのBigQueryに一部分をバックアップとして保存しています。

よくデータ量が多そうですねって言われるんですけど、Qiitaの場合はユーザーがほぼエンジニアなので、トラフィック量という意味では、マスを相手にしているサービスと比較すると少ない部類です。実験しやすい環境なので、いろいろとやっています。

mizchi：監視はDatadogとNewRelicっていうアメリカのサービスを使っています。その2つを使って各種サービスのサーバーモニタリングをしています。

白石：Datadogは知らなかったです。範囲的にはNewRelicみたいなことを？

髙橋：NewRelicはどちからというとアプリケーションそのもののパフォーマンスを見るのが強いんですが、Datadogはサーバーのメトリクスの監視などをします。はてな社のMackerelとかなり近いです。

mizchi：本番環境をDockerによるコンテナベースの環境に移行しようというロードマップがあります。開発環境も本番環境と同じようにVagrantからDockerベースのものに移行しようと取り組んでいます。

白石：仮想環境あたりの話は詳しく聞きたいですね。

mizchi：最近Node.jsのネイティブバイナリをガンガン使ってます。今まで開発環境で使っていたCentOSに引きずられて使いたいツールが導入できないことがありました。例えば、FlowTypeのバイナリがCentOSというかRed Hat系のものがないからできなかったんですよね。Dockerになったことでミドルウェアを更新しやすくなったので開発しやすくなりました。あとVagrantではローカルのファイル変更を仮想環境側でうまく検知できない問題があったのですが、Docker for Macのファイル検知が賢いから、ファイル監視みたいなこともやってます。

本番環境がクラシックなEC2を使っていたので、ミドルウェアの更新はサーバー台数が増えてくるとなかなか簡単に行えなくなってきてたんですよね。そこの本番環境に引きずられて開発環境にも悪影響が出てたんですけど、それをDockerに持っていくことによって本番環境が切り替えやすくなるので、その分開発環境にも新しいコンポーネントを入れやすくなりました。

白石：ちなみに、そのVagrantからDockerへの切り替えていうのは、もう結構苦労しましたか。それとも割とすんなり？

mizchi：そうですね。Dockerなどに強いインフラエンジニアが入ってきたので、その人が主導してガンガン進めてくれている感じです。

白石：なるほど、まさに専門に特化してる方にどんどん移譲していってる段階なんですね。

試行錯誤を繰り返しながら、リモートワークを模索

白石：次は開発体制についてお聞きしたいのですが、そもそもQiitaは何人ぐらいのチームで開発しているんですか？

髙橋：エンジニアが10人、デザイナー3人、PM1人、バックオフィス4人と社長で、社員は現在19人です。社長の海野もエンジニアなんですが、現在は経営に集中しています。開発チームは大きく言うと3つで、QiitaとQiita:Team、そしてKobitoです。Kobitoはそれぞれのメンバーが兼任しています。Qiitaの開発チームは6人ですね。

東峰：QiitaとQiitaチームはかなりコードベースが共通なので、機能作り始めると両方考慮しなくてはいけないことも多いですね。

髙橋：Incrementsは全社的にリモートワークを導入しているのが、大きな特徴ですね。今日はインタビューがあるのでmizchiも来てますけど、基本的にはインターネットの向こうの人です。

白石：リモートワークは話題になっていましたね。実際、コミュニケーションとかうまくいくものですか？ツールなどはどんなものを使っているのでしょうか。

東峰：Google Hangoutsをベースにしています。多人数で繋ぐとどうしても重くなったりとか、回線状況によって接続がうまくいかないこともあるので。いくつかサービスを試しているところです。

白石：やはり常時接続にしているのでしょうか。

東峰：いえ、オフィス側だけですね。モニターとカメラがオフィスの真ん中にあるんですけど、それがHangoutで常にオフィスを映しています。そのチャンネルに入ってくれば、オフィスの様子が見えるように作っています。

白石：なぜ、オフィスだけ見せておくんですか。

東峰：実は社長の海野や髙橋、僕といったメンバーは学生時代にはてなでアルバイトしていた時期があるのですが、当時はてなでは東京と京都のオフィスを常時ビデオ会議で接続していたんですね。何かあるとそこにみんなが集まってくるという状態ができていて、その体験がすごくよかったからなんです。

リモートワークについてのリリースを出したのはつい最近なんですけど、2年近くトライアルはしてきました。週1だけリモートとか2週間スポットでフルリモートやってみたりとか。常に接続して定期的にキャプチャーを撮ってくれるSqwiggleというツールを使ってみたりもしました。でも常に見られてる感じがして嫌だっていう声があったり、マシンスペックもかなり使うので、最終的にはみんなが集まる場所としてのオフィスHangoutを作る形に納まりました。

mizchi：常時接続ってバッテリーの消費が激しいので、外に出歩いてる人にはかなり難しいんです。まあそれと別に僕は個人的にSqwiggle大嫌いだったのはあるんですが。

東峰：まあ実際、そういう人は多いと思うよ。

白石：リモートワークといっても、みんな自宅で仕事しているわけではないんですね。

東峰：そうですね。基本的に場所は自由なので、自宅以外にもカフェやコワーキングスペースとか、地方の実家に帰って作業してみたり、自由度は高いですね。

髙橋：リモートワークは各個人がベストパフォーマンスを発揮できる場所を自分で選んで仕事できるようにすることが目的であって、離れ離れになることが目的ではないので、あくまでも集まれる場所が必要なんですよね。そのために、オフィスのバーチャルな集会場みたいなかんじで常に開放し続けています。

白石：なるほど。リモートから見るとオフィスが全部映ってるんですね。これはHangoutじゃないですよね？

東峰：これはappear.inでやってます。スマホでも見れるんですよ。まるでオフィスにいるみたいな感じで話せるんですが、実際のオフィスには誰もいないということもあります(笑)。

白石：それシュールでいいですね。

東峰：髙橋が言った通り、やはり各自がベストパフォーマンスを出しているかということが大事なんですよね。振り返りもパフォーマンスがどれだけ上がったのかを見ていきたいと考えています。Incrementsはオンラインのコミュニケーションに慣れているメンバーが多いので、（リモートワークでも）できちゃうのはできちゃうんですね。特に大きな問題はないように見えるんですけど、本当に上手くいってるのかちゃんと検証したいので、あえてネガティブな面の洗い出しをするようにしています。

白石：オンラインコミュニケーションというものに対する経験値がみんな高いわけですね。Slackとかも使ってますか？

東峰：使ってますね。SlackとGoogle Hangouts、あとはQiita:Team。

髙橋：リモートワーク取り組み始めた目的の1つには、これから社会がリモートワークにシフトしていくなかで、率先して自分たちがその環境に身を置くことによって、リモート環境で働く組織の情報共有に必要な課題は何か、身を持って体験できることがあります。それをQiita:Teamの開発に還元していきたいですね。

東峰：我々はエンジニアを支援して世界を良くするっていうの社是なんで、新しいことにはどんどんチャレンジしていって、あまり保守的になりたくないと思っています。

OKRで組織目標を設定し、コミュニケーションを効率化

白石：ちなみにタスク管理のツールは何を使ってますか？

東峰：開発に関するものはGitHubとZenHub、Trelloを使ってます。

髙橋：あと最近では及川が入ってきたタイミングで、OKR（Objectives and Key Results）という取り組みを始めました。もともとはGoogleなどで使われていたフレームワークなんですが、会社に導入しようとしてもいきなりうまくはいかなかったんです。四半期単位でゴール設定するんですけど、1クオーター目、2クオーター目はもう全然ダメでしたが、3クオーター目の今になってようやくまともにOKRが回り始めてきました。

白石：では最後に、今後の課題や取り組んでいきたいことをお聞かせください。

mizchi：すごく根本的なことなんですけど、RailsとJavaScriptって相性が良くないんですよ。Railsから内部データ読んでJavaScriptをコードの自動生成するとか、いろいろ試しに作ってはみたんですけど、まあ言語が違うから。turbolinksが独立したJSパッケージもあるんですが、まだしっくりこないですね。個人的にはそこを突き詰めたいと思っています。

白石：言語の違いっていうところの問題が根源なんですかね。サーバーサイドがNodeだったらもっと上手くいくとか。

mizchi：僕はあんまりサーバーサイドにNode使いたいとは思ってない人間なんです。もちろんNode使えばReactのサーバーサイドレンダリングとかはすんなりいくんですけど、シングルスレッドを管理するコストの方が重いし。

髙橋：今のそのJavaScriptとRailsの繋ぎこみの部分というのは結局インターフェイスがRails側で統一できていないので、JS側で試行錯誤しなきゃならないっていうのが一番の問題点なんです。Facebookが最近公開したGraphQLみたいに、中間の緩衝地帯みたいなものを作ることによって、JSクライアントとバックエンド側がもっと上手くインテクレードできるような環境が作ることを考えたりしています。

mizchi：その2つの間で共通するハッシュや配列のフォーマットなどで会話しようと心掛けてるうちは多分上手くいくんですけど、そこからはみ出した瞬間上手くいかないなって感じがします。日付とか困りますね。Unixtimeにしてほしい。Datetimeのフォーマットは信用ならない(笑)。

髙橋：Incrementsの自慢はメンバーの質が高いこと。結局できる人を連れてくることが、最高の環境改善方法だと思っています。JavaScriptで迷ったらmizchiに聞けば、何でもかなりクオリティの高い回答が返ってくる。社内Slackで質問すれば社内の有識者からすぐにコメントをもらえるのがいいですね。

mizchi：僕としても多少無茶してもあんまり止められないっていうのは楽しいですね。勝手にこの前作ったスライド機能も、勝手に作って勝手に出したら、めちゃくちゃ評判良かったっていう。

白石：あれ勝手に作ったんですか？

mizchi：業務中に勝手に作ったんです。ベースは2時間で作りました。

白石：森下さんは入社してチャレンジしていることはありますか？

森下：BootstrapベースのCSSフレームワークを消して、Qiita独自のUIパーツなどを作っておきたいですね。そのスタイルガイドやメンテナンスみたいなことをやっていきたいと思っています。

白石：Qiitaのデザイン言語を作っていきたいみたいなかんじですね。

東峰：さすがに規模も大きくなってきて、多くのメンバーが協働でUIを作っていくのにBoostrapがあるだけではクオリティを保つことが難しくなってきましたから、Bootstrapを捨てるのがメインというよりは、ちゃんとうちに合ったフローやガイドラインを整理して、見た目も含めてトータルのUIデザインを管理できる状態にしていきたいと思っていて。その仕組み作りについては、森下を中心に一緒にチャレンジしていきたいですね。

白石：Qiitaはこれからもまだまだ成長していきそうですね。今日は興味深いお話をありがとうございました！

HTML5 Experts.jp白石俊平編集長が、根ほり葉ほり聞いちゃうシリーズ・第二弾は、トレタを訪問！CTOの増井雄一郎さん、サーバーサイドエンジニア沢田洋平さん、フロントエンドエンジニア堀口亮太さんにお話を聞いてきました。

iPadで予約を管理する飲食店向けアプリ「トレタ」

白石：まずは、トレタさんのサービスについてお聞かせください。

増井：トレタは飲食店が使う予約管理アプリケーションです。一般のエンジニアが触れる機会はほとんどないアプリですが、もしかしたらトレタのWeb予約のサービスは使ったことがある人もいるかもしれません。例えば、豚組しゃぶ庵のWebサイトから予約できるページ「yoyaku.toreta.in」はトレタが提供しています。

　▲豚組 しゃぶ庵の予約ページ画面

増井：飲食店向けの予約管理ツールは、主にiPadで提供しています。お店の人が電話を取って、iPadで予約を管理するというものです。飲食店の予約って95％が電話経由なんですよ。トレタにお客さまの電話番号を入力すると、その方が過去に何回来たかがわかるんです。オプションとして電話との連携もできるので、着信時にお客さまの名前を確認し常連さまであれば「いつもありがとうございます！」といったリピーター向けの挨拶もできるんです。

白石：着信もできるんですね、このアプリ。

増井：はい。あと「トレタマネージャー」というWeb版もあるんですが、それはHTML5で堀口が作っています。

堀口：フロントエンジニアの堀口です。前職はCanvasやFlashでWebブラウザのゲームを作る仕事だったので、HTMLやCSSは全くやったことがない状態からトレタのアプリのWeb版「トレタマネージャー」を作りました。

　▲株式会社トレタ 開発チーム フロントエンドエンジニア 堀口亮太さん

白石：Canvasっていうと、前職はグラフィック制作がメインだったんですか？

堀口：そうです。トレタに入社してからAngularやReactとか、Backboneを勉強し始めました。

沢田：トレタでサーバーサイドのAPIを書いている沢田です。トレタのエンジニア第一号入社で、増井が最初にプロトタイプを作ったあとくらいから、サーバーサイドをがっつりやってます。もともとRailsの経験があったのでRailsでAPIを書いています。管理画面やお問い合わせ画面は、いわゆるWEBアプリみたいな部分もあるんですけど、本体機能としては全部APIになっていますね。

　▲株式会社トレタ 開発チーム サーバサイドエンジニア 沢田洋平さん

安定性が大事。だから先進的な試みはやらない

白石：続いて、トレタさんの開発環境や開発ツールについて教えてください。

増井：開発環境はあまり特別なものや、先進的なものを使っていないんです。僕はReactの記事を書いたり講演で話したりもしているけど、社内でReactは全く使っていなくて。Angularも1.5で、そんなに頑張って2を使ってないし。サーバー側も普通にRuby on Railsで、サーバーサイドはAWS。特にエッジな技術は使っていません。今のスタートアップとして、少なくとも技術要件としてはよくあるかたち。むしろ先進的な試みはやらないようにしています。

　▲株式会社トレタ CTO 増井雄一郎さん

iPadはずっとObjective-Cだったんですけど、去年ぐらいからSwiftを導入し始めていて。Swiftは2014年には出ていたのですが、しばらく安定していなかったのでずっと見送っていました。去年Swift 2が出てやっと言語仕様が落ち着いてきたのと開発環境まわりも整ってきたので導入することにしました。これから新しく作るのは全部Swiftに移行していくので、今は両方同居しています。徐々に置き換えていく予定です。まあ、ざっくり言うとこんなかんじです。

増井：僕らが作っているのは業務ツールなので、5分止まるだけでも大問題なんですよ。新しい技術へのチャレンジや開発効率を上げることも大切なんですが、それ以上にサービスとしての安定性をどう確保するかというのが、サービスに使うライブラリや技術を採用する一番重要なKPI事項になるんですね。

白石：とはいえ、割と新しいところにキャッチアップされている気がします。Angularも1.4とか1.3じゃないわけですし、Swiftも使っている。そういうバランスってどうしているんですか？

増井：とにかく検証してますね。それこそエラー監視は細かくやっていますし、iOSのクラッシュ件数も毎日レポートを出しているんですよ。僕らのアプリケーションはB2Bなので、どのお店が、いつ使ったか、すごく細かくわかるようにしています。例えば、どのお店がどんな操作をしたときにアプリが落ちたかもわかる。新しいバージョンをリリースした後は監視をきちんとして、問題が少しでも増えているようであれば、コードを精査し追加リリースを行います。（※参考記事：クラッシュ分析について）

堀口：だからと言って、新しいものを入れるのを全部反対するわけではないんです。フロントでいうと、TypeScriptなんかは結構前から導入しています。それはAngular2にするんだったら、TypeScriptを使うことになるだろうし、そもそもTypeScriptを使うデメリットはない。むしろ安定性は上がるので。

増井：安定性が確保できることがとにかく大事。すごく新しい技術でも安定性が上がるのであれば、そちらを導入しますね。いろんなツールがあるので、安定性を確保したまま、どうやって足並みをそろえるかっていうのは気を使っています。

白石：ちなみに、新しい技術やツールを入れた場合、古いコードも残っているわけで、そこら辺って書き直したくなったりとかしないんですかね。それとも、同居させて、そのままずっと進むぞというかんじなんでしょうか。

沢田：それこそiOSはSwiftに書き換えていっているので、よくさわるところから中心に書き換えてもいます。リファクタリングは、ちょいちょい時間を取ってやっているので、クライアントも、サーバーサイドも。例えば、Rails本体のバージョンを上げる必要があるときに、強制的に前のを捨てなきゃならないときに一緒にとか。

白石：なるほど。捨てなきゃならないんですか。

増井：Railsは3年に1回メジャーバージョンアップがあって、半年に1回ぐらい、まあまあ中規模なバージョンアップがあるんですよ。で、セキュリティやパフォーマンス、それこそ安定性の問題とか改定されているので、少しずつ上げていっているんですけど、そのときには、常に古いコードをある程度見直さなきゃならない。新しいのをキャッチアップしつつ、今回のスプリントはリファクタリングだけやろうとかリファクタリング中心で、過去の古いコードを捨てようとかというのをやっています。

堀口：Web版は1プロダクト1人で作っているので、気が向いたら直していますね。

白石：すべてをAngular1.5でコンポーネント志向にしていく、とかあります？

堀口：おそらく、そこまではしないですね。対応すべきかまだ決めかねていますが、Angular2もあるし、状況を見極めて無理のない対応をしたいですね。

24時間体制でサーバー監視

白石：データベースは、何を使っているんでしょう。

増井：普通に、MySQLを使っていますね。ただデータの解析用のバックエンドとしては、BigQueryも使っています。

白石：ログの収集・監視などをBigQueryでやってるんですね。

増井：そうですね。fluent使ったり、BigQuery使ったり。あとMackerelとか。今っぽいサーバー解析ツールはひと通り使っています。PagerDuty、Pingdomも使ってますね。

白石：その辺をどのように使っているのか、詳しく教えてください。

沢田：Pingdomはサイトが生きているかどうかを外部からチェックしてくれるサービス。PagerDutyはそれがヤバいときとかに、実際に電話をかけてくれるというサービスです。

増井：これよくある組み合わせなんですが、サーバーのパフォーマンスが悪くなったり、落ちたりすると、Pingdomが検出をして、それをPagerDutyに伝えて僕らに電話をかけてくれるんですよ。トレタを利用する飲食店は、夜中も営業しているところもあります。僕らのサービスはビジネスツールなので、24時間体制でエンジニアが対応します。

白石：なぜ、メールとかじゃなくて電話なんですか？

増井：寝ていたら気づかないじゃないですか。まあ、鳴らないのが一番うれしいんですけど。

白石：なるほど（笑）。

増井：最初の頃は1カ月に一回ぐらい起こされていたよね、夜中に。

沢田：そうそう（笑）。夜中に電話が鳴って飛び起きてダッシュで向かうと誤報だったり。今はもうちゃんとインフラ担当がついているので、ここ半年くらい1回も鳴っていないんですけど。

増井：Mackerelは、はてなが提供しているサーバー監視ツールですね。

白石：New Relicも使ってるとのことですが、何か重なるものではないんですかね。

増井：ある程度重なるところもあるんですが、機能ごとに使い分けていますね。今はEngine Yard使っているんですけど、AWSを直接そのまま使うかたちで移行予定です。あと一部のシステムは、Herokuで動いています。結構いろんなツールを組み合わせて使っています。

沢田：Engine Yardはインフラ担当がいなかったときは結構便利だったんですけど、柔軟性に欠く部分もあります。これからは専任の人もいるので、AWSで全部やろうっていうことになったんです。

白石：ちなみに、その移行にあたって苦労したところとかは。

増井：やはりB2Bのビジネスツールなので、メンテナンスでも簡単に止めれないところですね。最低でも2週間から1カ月前に、お客さまに「5分止まります」「10分止まります」という告知をする必要があります。

あと僕らが今使っているツールは、AWSやiPadもそうですけど、これまでどちらかと言うと、コンシューマ向けと言われる分野で使われていたツールを使っています。今までのビジネスツールって見た目とかどうでもよくて、使ってれば覚えるからボタン増やして、マニュアル渡して覚えさせようっていうのが多かったんですけど、僕らのツールはそうじゃなくて。UIはマニュアルなしでも見て直観的にすぐわかるように使えるように作っています。

普通は業務系だと半年とか1年置きぐらいしかバージョンアップしないんですが、僕らは月1～2回はバージョンアップしているし、常に使い勝手を向上させています。そういうところはB2Cに近い感覚で作ってますね。

白石：ちゃんとデザイン面もこだわっていると。ちなみにこういうツールって、トレタが登場する前もあったんですか。

増井：そうですね。あるにはあったんですが、先ほど言ったように使って覚えなきゃならないというのがほとんどでした。飲食店って、人の入れ代わりが結構激しいんですよ。使って覚えても、覚えた頃にはもういないといったことが多い。うちの社長の中村はもともと飲食店を経営していたのですが、この予約業務でいろんなツールを試してみたもののどれも使いにくくて、非効率で。みんな同じ問題を抱えているはずだし、自分たちで作ったほうが早いというのが、トレタ起業のきっかけです。その前にもっとすごいツールがあったら、トレタは起業しなかったかもしれません。

白石：使いやすいUXにこだわっていて、それが強みということですね。

さまざまなツールを使い、検証を重ねる

白石：アプリケーションの分析は、どんなツールを使っているんですか？

増井：ログはBigQueryを基に、Googleスプレッドシートで簡単に分析するツールを作ってますね。あとクラッシュログの収集にはHockeyの開発版を使っています。

堀口：Web版だとGoogleアナリティクスを利用しています。あと、エラー通知や解析のためにBugsnagも使っています。

沢田：Bugsnagはサーバーサイドで使っています。サーバーのバグというのは、本当に致命的な場合もあるので、やばいのを見つけたら、即直す対応をしています。

増井：ビジネスツールの面白いところは、ユーザー数がある程度限られるおかげで、全員のお客さまにコンタクトが取れるんですよ。例えば、特定のお店だけなぜかすごくバグが起こってたケース。そこに電話をして聞いてみると、アンチウイルスのソフトを入れていて、それが悪さをしていたことが解明したことがありました。使っているお客さま全員がすごく使いやすいと思ってもらえるようなツールを作ることができるんですね。

そこはすごく面白いところで、突きつめられる楽しさはありますね。コンシューマ向けだとクラッシュの瞬間に電話して、「今、落ちたでしょう？」なんて聞くわけにはいかないじゃないですか。

白石：ドキュメント管理ツールなどは何を使っているんですか？

増井：esa.ioですね。Slackとも共有できるし、Googleのアカウントでログインするだけで、アカウント管理が要らないので、開発ドキュメントを残すためのツールとして使ってます。全社的にも使われていて、営業のドキュメント管理や定例の議事録もこれでやっています。情報共有は社内全体で行うので、かなり風通しよくやっています。ルール作りは大事なので堀口が一元管理してます。

堀口：タスク管理に関しては、GitHubのIssueとZenHubを使っています。（※参考トレタブログ）

増井：ユーザーサポートはZendeskをCRMに近いかたちで使っていますね。あと面白いツールとしては、teachmeかな。マニュアル作成ツールなんですけど、トレタの動画を使ったマニュアルを作ってます。（※参考：トレタ事例インタビュー）

異なる機能を搭載するWeb版とiPad版アプリ

堀口：最初にも言いましたが、トレタのアプリにはWeb版とiPad版があります。一部を除いて基本的には機能を搭載しているのですが、それはデバイスによってターゲットや、利用シーンが違うからなんですね。Web版のほうは現場ではなくバックオフィスや、チェーン店を運営している本部などで使われる位置付けで提供しています。

白石：iPadは現場の人向けですか？

堀口：そうですね。同じ機能を別々のデバイスで作っても、コストが2倍になるだけであまり意味がないので、意識して切り分けています。とはいえ、iPadにないWeb版の機能を使いたいという要望もあったりするので、ヒアリングしたり、今後のそれぞれのプロダクトの方向性を考えた上でやるべきか検討し、やる場合は最適なUI/UXを考えて出していきます。

増井：予約を取る機能は両方にあるんですが、Web版にしかないのは分析機能ですね。今日何人来たか、明日何人来るのかといったことから、去年と比べてどうかとかリピーターの状況などが知りたい人向け。iPadでも見ようと思えば、Safariを使って見ればいいんですけど。

白石：あ、なるほど。

増井：逆にWeb版は予約を取る機能があまり強くはないんです。逆に店舗で使うiPad版には手書きメモの機能があるんですよ。しゃべっている内容が全部録音されているんですよ。予約のフローもiPad版のほうが使いやすい仕様になっています。混乱しないように見た目や色合い、メニュー面、文言などは一緒にしているんですけど、機能はかなり違います。

白石：ちなみに堀口さん、前はCanvasでばりばりゲーム作ってたみたいな話をしていたのに、結局Angularをかなり使いこなしてるじゃないですか。

堀口：そうですね。勉強しました（笑）。

白石：さすがですね（笑）。

増井：JavaScriptは移り変わりの激しいものだし、Angularの古いのがわかるとかツールが使えるというより、プログラムへの理解度がある人に任せたかったんです。新しく勉強してもらってAngularにするかどうかから、Reactなのか、もしくは他のフレームワークなのかというジャッジも含めてやってもらいましたね。

ニーズに合わせて流動的に対応する開発体制

白石：Web・iPad版では機能が違うという話でしたが、開発の優先順位とか開発体制とかってどのように進めていったんですか？プロダクトマネージャーみたいな方がいらっしゃるんですか？

増井：いますね。デザインチーフの上ノ郷谷がプロダクトオーナーとしてデザインを主体にして、まず機能を考えて、それをエンジニアとみんなでどう実装していくかを話して進めていきます。

白石：そこには利用者からのフィードバックとか反映されるんですか？

増井：営業がお客さまから要望を聞いてきて書き込むフォームがあるんです。そこに書いたものは、開発リクエストとしてSlackに流れるようになっているんですよ。例えばバグがありましたとかこんな機能あったらいいなとかっていうのを聞いて書き込むと、Googleスプレッドシートと、Slackに書き込まれるようになっていて、1週間ごとに対応するか否かをジャッジします。

そのときに気を付けているのは、画面にボタンを追加してほしいっていう要望そのものよりも、なぜボタンを追加してほしいのか、何に困っているのかを聞いてもらうってことなんです。ボタンを追加することは簡単なんだけど、結局そこが解決できないと意味がない。そこを探るためには直接見せてもらったり、出張してコールセンターまでヒアリングしにいったりします。

堀口：こないだは長崎まで行ってきました。

増井：エンジニアも納得した上で、実装するかどうか決めているんです。理由がわからないものを実装するっていうことは、基本ないようにしているので。

白石：対応する優先順位って、どうやってつけてますか？

増井：うち、開発マネージャーがいないんですよ。だからエンジニアが集まったときに割り振りを決めていますね。そこにはもちろんビジネス・デベロップメントの人も参加したりとか。

白石：ちなみに今って、エンジニアは何人ぐらいなんですか。

沢田：エンジニアだけだと、10人ちょっと。デザイナーが4～5人います。ただエンジニアとデザイナーだけでは全然完結しなくって。セールスの人と話したり、サポートの人と話したり、結構いろんな人と関わりながら進める必要があって、結構閉じていないんですよね。すでに作るものが決まっているという開発は全然ないので。

増井：つい最近まではトレタのアプリをどう作るか、どれだけいいものを作るかだけにすごく集中していたんです。今はかなり機能は増えてきて、アプリとしては一定の完成が見えてきています。ビジネス環境がどんどん変わっている中で、現在はヤフーをはじめとするいろんな会社との連携をしているんですね。

僕らのシステムって、誰がいつ来るかはわかるんですけど、その人が何を食べていくら払ったかがわからないんです。だからPOSと連携してAPIを提供したり、結合テストしたりとか、開発がプロダクトを1個作るだけじゃなくて、どうやって活用していくかというフェーズに移っていますね。

白石：それだけ動きが早いと、今こういう開発体制がいいとか考えても、次の月には変わっていたりしそうですね。

沢田：そうですね。注力するプロジェクトが流動的に変化しますし、その時どきで最適解みたいなのを試行錯誤で見つけていくといったかんじです。

増井：今エンジニアの組織をどうするかっていうのは、試行錯誤中なんですよ。よくある話ですが、ちゃんと企画担当とマネージャーがいて、エンジニアは開発に集中できたほうがいいとか、エンジニアが企画から関わるほうがいいんじゃないかとか。ただある程度関わると、コード書く時間がどうしても減るんですね。だけど、納得感があって自分がそこから関われるほうがいいんじゃないかとか。正解があるわけじゃないんですけど。

トップダウンならそういうのが好きな人を採用するべきだし、ボトムアップが好きな人だったら、自己管理がきちんとできますっていう人を中心に採用するのかっていうのを考えています。

白石：今はボトムアップか、トップダウンかでいうと、きっとボトムアップなんでしょうね。でも、そのうち役割を固定していたほうがいいよね、という時期が来るかもしれないと。

増井：さっき言ったように外部連携するチームは、やっぱり他者があるので、その組織の提携する先に合わせてトップダウンにする可能性もあるでしょう。でも、その仕事が終わったら、またボトムアップのチームに戻ったりとか、チーム構成もすごく流動的ですね。

上の経営層も今いるエンジニアたちがトップダウンで言うことを聞かないというのはわかっています。やれと言われて、「何で？」と。「はい」とすぐには言わない。「えっ、何で？」という話から入るというのは理解されているので、仕事のしやすさに結構つながっていますね。

白石：そういう試行錯誤感は、エンジニアに共感が得られそうな気がします。いろいろ面白い話をありがとうございました。

増井：これからも試行錯誤しながら働きやすくいいプロダクトを作っていける会社をみんなで目指していきます！

HTML5 Experts.jp白石俊平編集長が、根ほり葉ほり聞いちゃうシリーズ・第一弾は、ピクシブを訪問！HTML5 Experts.jpのエキスパートでもある川田寛@_furoshikiさんと片倉@geta6さんにお話を聞いてきました。

クリエイターがやんちゃして遊べる基地ピクシブ

白石：まずはピクシブのサービスや、川田さんが今どんな業務を担当しているのか聞かせてください。

川田：ピクシブでは「創作活動をもっと楽しくする」という理念を持って、いろんなサービスを提供しています。イラスト・漫画・小説が投稿できる「pixiv」以外にも、ネットショップサービス「BOOTH」やグッズ制作サービス「pixivFACTORY」といったECサービス、お絵かきアプリ「pixiv Sketch」とか、いろいろな創作活動向けのサービスを提供しています。

▲ピクシブ株式会社　エンジニア　川田寛さん

私がメインとして担当しているのは　CtoCのECサービスです。同人イベントなどであつかわれる創作物の頒布を、どうやったらネットの力で便利に変えられるのかって、いつも考えてますね。主に「BOOTH」と「pixivFACTORY」を担当しています。

白石：グッズ化したり、販売できたりするサービスですよね。ピクシブならではの強みってあります？

川田：「創作活動をしている人」にフォーカスしているところでしょうね。そういう人たちに愛されるサービスにできていると思っているし、社内の空気としても、クリエーターに対する尊敬があって、彼らをどう幸せにできるのかを考えていたりして。

たとえばBOOTHだと、普通のECサービスじゃ採算があわないという理由で蔑ろにされてもおかしくないような作品を作っている人も、ちゃんと大切にできる。例えば、マニアックすぎて日の目を見ない人たちも気軽に参加できるし、投資できるような仕組みも作っています。普通なら500円くらいでしか売れない作品でも、その価値を認めた人は1000円とか1万円というように、購入者側の評価価格で購入できるような仕組みを作ったりとか。

朝思いついたことをすぐコードで書くスピード感

白石：川田さんは入社したばかりですけど、前職との違いをどう感じてますか？

川田：前は100年以上歴史があったりとか、受託をメインとしている企業だったので、ピクシブとは何もかもが真逆ですね。社員の年代も若いし、サービスもまだできて7年くらい。開発言語一つとっても、今まではJavaがメインだったのが、RubyやPHP、Scala、Goなど、前の会社だったら絶対に手を出さなかったような言語もガンガン使っています。

開発するものについても、大規模な受託案件で、1年以上先にリリースされるようなウォーターフォール型が多かったのですが、ピクシブは自社開発で、それこそ朝に思いついた良いアイデアはその日のうちにコードを書いて形にしてリリースしたりすることもあります。ユーザーに価値を提供していく上で、とにかくスピード感が命なので、そのために多くの権限を現場に委ねているというかんじがしています。

白石：全然違うんですね。コードを書くってことは、川田さんはプログラマ寄りの仕事なんですか？

川田：UIまわりが多く、フロントエンドエンジニアをやってます。サーバーサイドも書くときは書きます。うちの会社はフロントエンジニアが3人いますが、みんな特にフロントエンドだけをやっているという感じではありませんね。iOSとかAndroidを作るアプリエンジニアもいますが、あまり境目がなくて何でもやっているというかんじがします。前職はお客様対応みたいなのが絡むので、SEという言葉がぴったりハマるような仕事だったのですが、今は完全にエンジニアです。コードを書くことで、ユーザーへの価値を発揮しています。

白石：そうなると、仕様策定は誰がやるんでしょうか。

川田：大きな機能追加とかロードマップは、ディレクターがまとめたり経営層を巻き込んだりしていますが、そうでないものは現場で考えてスピーディーにやってしまいます。

　▲ピクシブ株式会社のオフィスには、いたるところに絵師さんのイラストが描かれている。

ポエムはesa、意見交換・情報共有はidobataで

川田：うちの会社にはポエム駆動開発というのがあるんです。コードがかけるだけじゃなくて、創作をする人に対して想いが強い人が入社してくる。エンジニアにも想いが強い人がいっぱいいるので、ポエムを通じて刺激されて作る。

白石：へえ。川田さんはどんなポエムを書いたんですか？

川田：新サービスとかユーザーの声とかいろんな話が絡んでてあまりまだ公表できない話も多いのですが。作品を扱っているサービスとしては、やはり、それを求めているユーザーとうまく繋いであげないことには、出展しているクリエーターやアーティストさんにとっても良くないわけで。そこをどう改善していけばいいのか、というお話をしていました。

社内ではesaというツールを使ってポエムを語るんです。このサービスはこうやったら成功するんじゃないかって書くと、みんなが反応を示していく。そうやってどんどんプロダクトを改善したり、新しく作り出したりしていますね。

白石：現場から上がってくるボトムアップなかんじがいいですね。

川田：何を作るのかとか、どう改善するかは現場から上げていけますね。経営層も「お前らでドラスティックに変えていってくれ」って言ってくれて。

白石：チーム体制は何人くらいでやってるんですか？

川田：うちのチームだと、BOOTHとpixivFactoryであわせて10名弱くらい。両方ともRailsなど同じ道具を使って作っているので、エンジニアはどちらもみている感じですね。

白石：アジャイルで開発しているんでしたっけ。

川田：うちのチームではアジャイルと呼べるほど、そこまできっちりしていません。どちらかといえばDevOpsが自然に機能しているという印象。大きな機能リリースに向けた開発はしているけれど、それだけをメインとしてやってはいられない。いま動いているものに問題があれば、そこで対応もしなくてはいけないので。サポートチームのフィードバックであったり、エゴサーチして問題を探って、idobataで即座に共有されたり。

白石：エゴサーチを開発チームがしているのはすごい。社内のコミュニケーションツールはSlackじゃないんですね。idobataって、Slackと比べてどうなんですか？使いやすいとか。

川田：Slackとidobataを使ってはいますが、うちのチームだとidobataの方がメインになりましたね。自分たちの使っている範囲で、機能面にそこまでの違いは感じてはいません。Slackはチームごとで導入してしまっているからか、会社全体として導入しているidobataのほうがオープンに議論が交わされてて。他のチームのスレをみて気軽に意見を言ったり、挙句にプルリクを作って後方支援することもあったり。プロダクトやチームを超えて議論がされていますね。

タスク管理はカンバン。具体的なタスクはGitHub

白石：タスク管理は何を使ってます？

川田：うちのチームだと、タスク管理はカンバン。ToDoリストとしてざっくりタスクをポストイットで並べてます。トラブルがあったらそっちを優先したり、技術的な問題で遅れることもあります。タスクも今まで見てきた中ではわりと独立性が高いとおもってて、エンジニアやデザイナー、ディレクターやサポート担当者など、全員にビルド/デプロイ権限があって、自分たちが主体になってデプロイにまでもっていく。とはいえ、リーダーが責任をとるとか、デプロイした人が責任をとるとかそういうものもなく、リスクはチーム全体でうまく運用方法を改善しながらカバーしていきます。

細かい機能とかコードレベルの話はGitHubです。プライベートのリポジトリ上に、Issue立てたり、PullRequest作ってMergeして、みたいなかんじです。よくあるGitHubの普通な運用方法になるとおもいます。

想いとか、こうやったほうがいいというポエムはesa、具体的なのはGitHubです。全体像はカンバンで、普段のコミュニケーションはidobataがメインです。

白石：ほかに開発体制で面白いトピックはありますか？

川田：開発体制とは違うかもしれないんですけど、前の会社ではコミュニケーション手段がほぼメールと電話だけだったんです。それがこの会社に来てからは、メールと電話は一切使ったことがない。一度もです。ツールをしっかり固めて、コミュニケーションコストを下げると、得られる情報量が大きくなって、結果としてチームを超えていろんな情報にアクセスできるんです。ツールひとつで、ここまで組織がフラットになれるものなんですね。

ただ一方で、まずいと思うところもあって。メールや電話といったツールは、一般的なビジネスでは必須のコミュニケーションツールですよね。オーバーヘッドはとてつもなく大きいのですが、使わなくなるとそれはそれで、マナーやルールがわからなくなって社会から取り残されていく不安も感じるんです。両方のバランスが重要と感じています。

白石：社員同士のやりとりは何を使ってるんですか？

川田：一部はSkypeですが、基本はidobataでオープンにしてます。idobataのタイムライン上には、社員同士のやりとりだけじゃなく、自動的にデプロイの情報が流れてきたり、サポートの状況とかが流れてきたりで、社員同士のやりとりが発生しやすいというかんじがしています。

インフラはコンシューマ向きの超安いサーバー？

白石：開発環境はどうですか？

川田：開発環境の話だと、うちにはちょっとした特殊なインフラがありまして。初期のpixivは社長が借金をして買ってきた大量のサーバーがあるのですが。コンシューマー向けの安いマザーボードを、ラックにくくりつけて使ってるんですよ。ほんとうにむき出しのままなんです(笑)。

さすがに今は本番環境をデータセンターに預けるようにしていますが、開発環境には未だにそのマザーボードむき出しのサーバーをインフラとして使ってるんです。インフラチームの図画工作スキルは、いまだに高いようですね(笑)。

インフラの話をもう少し突っ込んですると、pixivの場合はサービスの特性上、クラウドよりオンプレのほうが向いていてそっちが中心ですね。とはいえ、ところどころにクラウドは使われていて、新しいプロジェクトだとAWSみたいなクラウドも使われています。

データベースは、基本的にはMySQL使ってます。OSはLinux。新しいプロジェクトはRails使うことが多いんですが、「Rails最強!! Railsじゃないとダメだ！」みたいな人はいなくて、ツールとして使っているという印象です。

サービスはリリースした時の最新技術で

白石：HTML5 Experts.jpはフロントエンド開発者が主な読者なので、フロントエンド開発の話も聞かせてもらえますか？

川田：私が関わるBOOTHだと、マークアップはSlim、CSSはSASSやCoffeeScriptとか。Ruby書いている人にやりやすい環境で整っています。また、開発したのが2013年なので、CoffeeScript、Backbone.js、Marionette.jsなどを使ってます。いまだとReactあたりがもっと上手く問題を解決してくれたりするんでしょうし、SPA（Single page application）ももっといいやり方があるのでしょうが、当時の技術を使っているので…。

とはいえ、2007年に作られたpixivでも、CoffeeScriptが使われていたりはします。部分的に入れ替えも進んでいます。今年の6月にリリースしたお絵かきアプリ「pixiv Sketch」は、React.jsやBabelが使われています。もろ時代の影響を受けていますね。

白石：それだけフロントエンドの流れが早いってことですね。

フロントエンドだと、そこそこエッジな事例がきけそうな、pixiv Sketchのエンジニアを呼んでみますね。

ReactとFluxでサーバーサイドレンダリング

──ということで、geta6さんにご登場いただきました。

geta6：片倉@geta6です。「pixiv Sketch」の担当エンジニアをしています。

白石：ぜひ、フレームワーク周りで面白い話を聞かせてください。

geta6：ブラウザ版のpixiv Sketchは、Node.js上で動かしています。

　　▲ピクシブ株式会社　エンジニア　片倉弘貴さん

白石：Node.jsってことは、サーバーサイドから全然違うかんじなんでしょうか。

geta6：サーバーサイドは、RailsによるAPIサーバーと、Node.jsによるレンダリングサーバーで構成されていて。前者はgrapeを使用していてviewを持たずJSONしか吐かない仕様になっていて、後者はサーバーサイドでAPIを叩いてDOMを構築するReactサーバーになっています。

白石：なるほど。最近、Universal JavaScriptととも言われているIsomorphic Javascriptですね。それでサーバーサイドレンダリングしてるって、まさに最新ですね。

geta6：フレームワークは、Yahooさんが作ったfluxibleというのを使っています。サーバーとクライアントが同じコードで動くので、キツイ面もありますけど。

白石：fluxibleって、結構ヘビーだって聞きますね。

geta6：fluxibleは一人でさくっと開発する場合とか、SPA（シングルページアプリケーション）とかには向いてないかもしれません。ただ、pixiv Sketchみたいに複数人数で開発する場合は、ある程度がっつりしたコードを書けるし、メンテナビリティがあるので魅力的です。

良いところは、二重実装をしなくていいことですね。テンプレートをslim側で書いて、Backbone.jsからもってきて、Javascriptテンプレート内にテキストテンプレートをもう一個書いて…とか面倒なことはしなくていい。同じコードベースでAPIのリクエストとかすべてのことができるので、そこが便利です。

白石：サーバーとクライアントが同じコードで動くのがキツイと言ってましたが、具体的にはどんなところが大変なんですか？

geta6：Reactは、クライアント側の世界とサーバー側の世界で、呼ばれるメソッドが違うところがあるんです。componentDidMountっていうメソッドなんですが、それはクライアント側にしか呼ばれないので、その中ではCanvasの操作やDOMの操作が書けるんです。それがわかっていればそんなにつらくないけど、React始めたばかりだと、その辺がわからないのでつらいのかもしれないです。

白石：getaさんの勉強量は相当すごそうですね。

geta6：いつもはそんなに勉強はしてないんですけど、pixiv Sketch始めるときに、Reactが流行ってるって聞いて、どうしてもやりたいって言ったら採用されたんです。React全然知らなかったのに、採用されたので一から徹底的に勉強しました(笑)。

課題はパフォーマンス改善。野望はES6への乗り換え

白石：お二人が、今課題だと思ってることってありますか。

川田：まだ入社したばかりなので、あまり深く掴めていませんが。自分の関わっているサービスのパフォーマンスが悪いことが気になっていますね。RailsとかJavaScriptとか、いろんなところに悪さするのが潜んでいますね。

もう一つは闇のコードたち。締め切り間際で、アドホックに作りこんじゃったコードとかがたくさんありまして。たとえば、BOOTHは「APOLLO(アポロ)」という同人音楽をネット上で頒布する即売会イベントを開いていて、そういうイベント対応のために作りこまれて、めったに呼ばれないメンテされにくい闇のコードが眠っているんです。ある日とつぜん爆発しそうなので、なんとか阻止したいです。すでに若干、爆発しかけていますが…

こういう、サービス固有の問題みたいなのは山程ありますが、それ以外はとくに不安を感じてはいません。テストコードも書かれているし、最新のバージョンに上げていきましょうというモチベーションもある。機能追加や改善ばかりな企画屋さんがいるチームは世の中にいっぱいいるけど、うちはコードヘルスがサービスのライフサイクルやセキュリティにどんな影響を与えるのか理解されているし、バージョンアップしておかないと大変という感覚とか、エンジニアならわかる勘所を大事にしてくれています。上手くやれている感じがしています。

白石：今後チャレンジしたいことはどうでしょう。

川田：やっぱり、早くES6にしたいです。CoffeeScriptやめたい(笑)。

白石：でも、CoffeeScriptのほうが言語的な機能は上じゃないですか？

geta6：CoffeeScriptって1週間前に書いた自分のコードが読めなくなるんですよ。言語機能が強すぎて。特殊な記法が必要だし。ES6では普通に読めるから、メンテナンス性は高いですよね。

川田：CoffeeScriptって、少し大きくなってくると、ビルドした結果を想像しながら書かなきゃいけなくなることがある。Devツールで、ちょっとこの値どうなってるんだろうとかコンソールを叩き始めると、今までCoffeeScriptのコードを読んでたはずなのに、完全にJavaScriptに戻ってたり。

geta6：CoffeeScript書いてるより、JavaScript書いてるかんじが強いんですよね。インデントが効かないのも厳しい(笑)。

川田：そうなんです。以前、私はTypeScriptを使っていたんですが、あれはビルドした結果がストレートに想像できるのがいい。あと、将来を見据えるとやっぱりES6を推しちゃいますね。

Nodeのデプロイツールに定番がほしい

白石：getaさんはどうですか？

geta6：開発環境の課題は、Node.jsのデプロイツールとプロセスマネージャーに定番がないことですね。デプロイは、信頼性をとってcapistranoを使ってるんですよ。Nodeのデプロイツールはどれも機能が貧弱で手数も多いので、定番でいいのが出てこないかなって思ってます。

白石：プロセスマネージャーは何を使ってるんですか？

geta6：プロセスマネージャーはPM2を使ってます。capistranoからシンボリックリンク設置して、currentで新しいファイルをディレクトリに送るんですが、Nodeのファイルシステムが変わってから、シンボリックリンクを追跡して、デプロイ前のファイルのところで監視しちゃうようになったんです。そこでプロセスマネージャーが生きちゃってるので、デプロイしてもファイルが新しくならないんです。そこで一回殺すというのをやってるので、ダウンタイムが若干できてしまうっていう問題点があります。

白石：そういった課題の改善に取り組んでいるんですね。次にチャレンジしたいことはありますか？

geta6：API側はバックエンドのプロセスマネージャーがUnicornなんですけど、ラインがN個しかなくて、同時に来ちゃったらつまっちゃうんです。Node側でいいかんじでリクエストをバッファリングしてうまく送れないかと。受付サーバーをNodeにしてゆっくり流すというようなことをしたいです。

白石：なかなかエッジなプロジェクトになりそうですね。

geta6：requestIdleCallBackだっけ？あれも何かやってみたい。

川田：ピクシブで「東京 Web Performance」という濃い勉強会をやったんですけど、エッジすぎて人が集まらないかなと思ったら、エッジな人が結構集まってきて(笑)。第一回は「requestIdleCallback」を味見したんですが、広告やアナリティクスに割といいかんじで使えそうだったんで、全力で攻めるんじゃないかって話をしてました。ピクシブに思いのほか、いい影響を及ぼしそうな予感がしてます。

白石：じゃあ、そこも次のチャレンジになりそうですね。今日は面白いお話を聞かせていただき、ありがとうございました。