2014年2月19日（水）渋谷ヒカリエにて開催された、エンジニア向けイベント「ヒカ☆ラボ」から、注目のITベンチャー4社による技術勉強会の要素をレポートします。

「ヒカ☆ラボ」とは、レバレジーズ（⁠株⁠）が主催するエンジニア向けの無料イベント。プログラミングからUI／UX、グロースハックまで、エンジニアのスキルアップを幅広くサポートする大小様々なイベントを開催しています。

中でも今回のイベントは、有名ベンチャー4社が登壇する、大規模なものでした。各社から開発環境やサービス成長に伴う苦労など幅広い共有がありました。

プレゼンテーション形式で、資料はSlideShareにて公開されますので、本記事では要点をTIPS形式でまとめてお届けします。

オープニングはChatWork（⁠株⁠）

「チャットワークを支える技術」というテーマでChatWork（⁠株⁠）専務取締役CTOの山本正喜氏が登壇しました。

このコーナーでは、シリコンバレーにも進出している「チャットワーク」における運営とプロジェクト管理、フロントエンド（HTML5／JavaScript⁠）⁠、サーバーサイド（PHP⁠）⁠、モバイル（Titanium Mobile）について共有されました。

内容が濃く駆け足でしたが、ベンチャーならではの「やってみて調整していった」部分が、かなり感じられる内容でした。

運営とプロジェクト管理

サービス開発＆運営に17人、グロースに5人という体制で、グローバルチームもいるため、足並みを揃えないとユーザサポートもままならない。いろいろ試したうえで、落ち着いたのが週ベースのガントチャート。1カラム1周間で、デザイナーからマーケッターまで職種問わず全メンバーを網羅している。以前は日の単位や月の単位を試してみたが、更新が激しすぎたり、スピード感と合わなかったりで、週単位が最もフィットしたとのこと。3ヵ月先までしか予定を入れない。ビジネスの特性上、それ以上先まで入れてもほとんど変更になってしまうため、あまり入れない事が多い。

プロジェクト毎に、プロジェクトマネージャーではなく、プロジェクトディレクターというポジションが管理者となっている。ほとんどのコミュニケーションはチャットで、メールはしない。口頭確認やMTGは最低限にしておくことで、タスクの背景から全て履歴がテキストで残るため、国内外にメンバーがいる場合でも機能している。

社内に部活チャットというものがあり、スキルごとのチャットでスキルアップしていくことができる。それでも困ったときは、社外の専門家にチャットでコンサル的に聞くことができる。これが意外に安い値段で可能で、弁護士やマーケティング領域もカバーできるのでオススメ。

フロントエンド

チャットワークは、画面遷移のないフルAjaxアプリケーション。リアルタイム通信とHTML5によるリッチな機能を実装している。フレームワークはjQueryとBackbone.js（一部⁠）⁠。リアルタイム通信ではChannel APIを活用している。あまり知っている人は多くないが良いAPI。GoogleAppエンジンなので、どれだけアクセスが増えても勝手にインスタンスが増えていくので、便利。

HTML5ではWebNotifications（デスクトップ通知をブラウザ外で表示）を実装。チャットサービスでは必須である。Chromeが先行実装し、他ブラウザも後追いで実装されているが、ブラウザごとに微妙に挙動が違うので注意。ブラウザ上でのビデオ通話、画面共有を可能にするWebRTCを実装しているが、各ブラウザでの実装はまだまだ途中である。WebRTCをエミュレーションするプラグインを活用している。

モバイル

iOS／Android両アプリに対応し、Titanium Mobileでクロスプラットフォーム開発している。Titanium Mobileを採用した理由は、リリース初期の激しい機能アップデートに、ネイティブで書いていては間に合わず、そのときに見つけたのがTitanium Mobile。Web版とのコード共有化が出来るのではないかと期待したが、実際にはWebのネットワークと贅沢なスペックに対して、モバイルではコードの書き方がまったく違うため、コード共有の望みはかなわなかった。結局、ゼロベースでTitaniumのベストプラクティスに置き換えた。

安定したアプリが作れるようになったころにiOS7が登場し、TitaniumSDKが対応するまで何もできない状態に。ネイティブ化を決意し、絶賛開発中。

サーバサイド

アプリケーション部分はフルAjaxなので、ほとんどがAPIの通信処理。自社開発のフレームワークを活用している。インフラはオートスケーリング。ビジネスアプリなので平日はすごく負荷が高いが、休日はガックリ減る。なので、伸び縮みできる仕様が大事。監視はNew Relicがオススメ。絶対使ったほうが良い。

続いて（⁠株⁠）ブラケット

「STORES.jpの育てかた」というテーマで、牧野圭将氏が登壇しました。

実は（⁠株⁠）ブラケットのエンジニアが人前で話すのは始めてということでした。今後はAngularJSの解説など、いろいろなイベントを実施していくそうで、楽しみです。

チーム体制

エンジニア7名、デザイナー1名、機能分担はとくに無く、なんでもやる。2013年2月時点でエンジニアは2名だったが、サービス拡大に合わせて増員。

急成長する我々にはmongoDBのスキーマフリーが便利。ただし、簡単にデータを追加できる分、どんどんデータサイズが増えがちなので、要らないものを消していくことが大事。

コードはGitHubで管理。Jenkinsでテスト実行、ローカルからデプロイ。1日に8回くらいデプロイしている。

開発環境

インフラにはAWS。サーバの増減が素早く行えるので、TV放送などで突然トラフィックが増えても、対応がしやすい。STORES.jpの場合は、サービスそのものがTVに露出したり、参加している店舗がTVに取り上げられたりするケースがあるので重要。

スポットインスタンスなら安価なので、負荷テスト用にサーバをどんどん立てられるのも良い。

リソース、エラー監視にはNew Relic。iOSアプリでPush通知してくれるのも良い。我々には専任の常設監視チームが居ないが、監視はNew Relicにおまかせで、エラーが出たら対応している。

ログ監視にはMixpanel。欲しいデータだけを抽出して、見られるのが良い。Mixpanelは従量課金でアクセス数が増えると課金が増えていくため、GoogleAnalyticsで全体を見て、詳しく見たい所をMixpaneelで見るような使い方。

ABテストにはOptimizelyを活用。ブラウザからかなり手軽にテストの開始とスタートができるのが利点。統計的な判断もOptimzelyで判断できるので、便利。

情報共有はChatWorkとGoogleサイト。デプロイ連絡や改善報告、気になるサービスの共有はチャットワーク。エンジニアが日々改善している中で、反応速度の改善など地味な改善も、報告してみんなで喜ぶ。非エンジニア向けに使っているのがGoogleサイト。開発関係はGitHubなので、こちらではカスタマーサポートが円滑に回るような仕様共有や、社内ルールの共有など。

Dashboard。アクセス数や流通額などをリアルタイム表示しており、社員みんなが数字を意識する。

少ない人数でスピーディに開発するために自動化！　各種サービスにまかせる！　開発機能に集中！

情報共有はマメに。対エンジニア、非エンジニア向けを意識する。

3社目は（⁠株⁠）Lang-8

大手IT企業を辞めて（⁠株⁠）Lang-8という少人数ITベンチャーにJOINした佐々木氏が、世界展開しているサービスであるLang-8の開発体制について、「Lang 8についての話」と題して語りました。

「からあげ系エンジニア」としても有名な佐々木氏による、ソフトトーンながら、リアリティあふれるトークでした。New RelicとAngularJSは各社とも取り入れており、もはや標準と言えるのかもしれません。

Lang-8のサービス特徴について

Lang-8は語学学習のコンテンツを届けるのではなく、学習の場を提供するプラットフォーム型のサービス。相互添削型のサービスが特徴。90言語以上がやりとりされている。語学学習サービスと言う説明をしているが、添削をキッカケとして世界中の人と仲良くなれるサービスでもある。

開発チーム

メンバーは社長、デザイナー1名、エンジニア1名とアルバイト数名。正社員が3名という小規模な会社。規模が小さいがゆえに、なんでもやれるし、1人の影響範囲が大きい。

開発環境

Ruby on Rails、Redius、MongoDB、AngularJSなど。おそらくだいたいは他社さんと同じようなもの。その他HipChatCircleCI、、Mixpanel、New Relicなどを活用している。

Rediusの使い方。データ分析で特定日のアクセスしたユーザーのリストなどに活用。MongoDBは、チュートリアルなどの表示など一部に活用している。MySQLだとメンテが面倒なので、どんどん増えたり予想がつかないカラムができそうなものに関してはMongoDB。AngularJSはjQueryから移行。インフラはAWSで、おもしろいところだとAutoScallingを活用。

Lang-8は世界展開しているのでピークタイムがあまり無いが、世界の何処かで急にクチコミで話題になって負荷がかかったりするので、最初のセッティングさえしてしまえば、日本が夜中でも自動対応できる。

ベンチャーあるある

やりたいことがありすぎるが、人的リソースは常に足りない。タスク管理が非常に重要。Lang-8ではTrelloを使って大雑把な管理をしている。よく優先順位付けをやるが、結局どれも優先度が高いという結果になりがちなので、細かい優先度付けはしないで、ざっくり決めて定期的に優先度を見直しながらシンプルに上から対応していく。

デザイナーとの仕事の進め方では、PRではなるべく絵文字、なるべく画像を使っている。できれば直接話すのが理想だが、なかなかそうもいけない。

文字だけでやれるのが理想だが、なかなかそうもいけない。

チームでの取り組みとしてランチを一緒にたべたりするなど、アナログだがとにかく直接話すことを重視している。

短期間でやることがころころ変わるので、チーム運営において、背景理解なども直接話していくことで理解を得ることが出来る。直接話すのが、いまのところ万能。

まだまだ規模が小さいため、コードレビューがSPOFだったり、テストの分化がまだ根付いていなかったりする部分はある。あとiOSアプリを作りたいが、エンジニアがいないなど、まだまだ解決したい問題が山積みである。

最後はランサーズ（⁠株⁠）

「成長し続けるサービスを支える技術」と題して、急成長するサービスを支えるインフラ、開発体制というテーマでランサーズ（⁠株⁠）の現状や今後について共有されました。

急成長真っ最中の、ランサーズ（⁠株⁠）によるリアルな経験が魅力的な内容でした。実は2008年に創業されているため、インフラ系の変更など変化への対応についても学びが多いプレゼンとなっていました。

5年間の開発で得たもの

2008年の12月にリリースして、半年後、サービスがYahoo!　で紹介される。当時はさくらの1台サーバー体制だったので、急なアクセスに耐えられずダウン。急遽、静的コンテンツのみに切り替えて1週間がかりでサーバ移転。そんな事もあったが、PVは2倍以上になった。

初期の反省

高負荷でアプリが動く状態になっておらず、急成長で取りこぼしたユーザーが多かった。お金がないベンチャーとは言え、はじめからスケールさせる前提で設計しておくべきだった。いまならAWSがあるので便利。

インストール型アプリの開発と、得た学び

2011年12月に時間単位のタイムカードアプリを開発。サーバとの通信部分は独自のワンタイムキーを発行して、技術選定から1ヵ月半でリリース。初めてのPCインストール型アプリで、OSごとにかわる挙動に苦しんだが、自社サービスのランサーズでテスターを募って乗り切った。

AWSへの移転とメリット

広報に力を入れ、露出拡大していくに従い、スケーラビリティを優先してAWSを導入。移転直後にRDSで負荷を追い切れない障害が発生し、EC2に移転。原因はI/O負荷だった。まれにおきるものとして、EC2のリブート問題などもある。20台のサーバで3～4ヵ月に1回くらい発生していた。AWSに移転して良かったのは、ワールドビジネスサテライトで紹介された際に、リアルタイム1万2,000人という高付加になったが、事前にサーバ30インスタンスを用意して乗り切れた事。

スピード感を得るための自社サービス活用

自社サービスのランサーズの活用によるスピードアップが便利。Asteriskシステム構築、バナーデザインランディングページなど、フリーランサーの力を借りることでスピードアップする事ができている。

今後のランサーズ

1億PVを目指してインフラ整備など続けていく。

まとめ

注目のベンチャー4社が集うイベントでしたが、AWSのように4社共通で取り入れている技術もあり、非常に有意義な時間となりました。終了後の懇親会では、プレゼンよりも奥深い話も出ていたようで、参加されたエンジニアさんの満足度も高かったようです。登壇いただきました4社さまに、深く感謝いたします。

「ヒカ☆ラボ」では、今後も注目企業や技術者によるイベントを開催していきます。