以前に「はてなとそっくり」なWebサービス開発会社として、開発のいろいろをお聞きした「リクルートコミュニケーションズ」が、エンジニアリングの対象を、アドテク分野にシフトし、最先端の分野でWebサービス出身のエンジニアたちがさまざまな工夫をしています。3年前と同じように、はてなチーフエンジニアの大西を交えて座談会を開催し、開発環境からキャリアパスのことまでいろいろとお聞きしました。記事の最後には、MacBook Pro Retinaディスプレイモデルが当たるプレゼントのお知らせもあります。
座談会出席者（上写真、左より）：はてな 大西康裕、リクルートコミュニケーションズ 大石壮吾さん、日馬康和さん、阿部直之さん、上田和孝さん
（※この記事は、リクルートコミュニケーションズ提供によるPR記事です）
大西 ご無沙汰しています。はてなチーフエンジニアの大西です。以前もこちらのリクルートコミュニケーションズさん（RCO、※当時の社名はリクルートメディアコミュニケーションズ〔RMC〕）にお邪魔して、開発手法やPerlのフレームワークによるWebアプリケーション開発についてお聞きしました。今日はお互いによりモダンになった開発プロセスの話などをできればと思います。
大石 お久しぶりです。私と上田は前回も出席していましたが、私はエンジニア部門の責任者をしています大石です。上田は開発の中心になっているエンジニアです。
大西 上田さんは、入社以来Perl一筋で、エレベータの中でも書いていたというほど、コードをバリバリと書く方だと記憶しています。今でもコードをどのくらい書かれているのか少し気になっています（笑）。
大石 今回新しく参加している日馬は、主にインフラを担当しています。阿部は、3年前の記事で弊社に興味を持って転職してくれた、期待のエンジニアです。トラッキングや、効果測定の仕組みを担当しています。
※3年前の対談の様子はこちらの記事を参照
Perlの自作フレームワークで作る、アジャイルなWebサービス
■ Webサービスの100倍のスループットが要求されます
大西 ご無沙汰していた3年の間に、皆さんの中で一番変わったことは何でしょう？
上田 一番違うのは、作っているサービスへのリクエスト数でしょうか。
日馬 秒間4万リクエスト以上、最近は5万リクエストに近い数字になってきました。圧倒的にトラフィックが増えています。
大西 え!? それはいったいどういうことなんですか？
大石壮吾さん（おおいし・そうご）
株式会社リクルートコミュニケーションズ ICTソリューション局 アドテクノロジーサービス開発部 部長
大石 3年前の私たちは、Webアプリケーションに最適化した仕組みで開発していました。今は、アドテク†1の分野でビジネスを立ち上げようとしています。開発チームの規模はWebサービスとアドテクでそれぞれ半々ぐらいですが、開発エンジニアは、この座談会に出席しているメンバーもそうですけど、アドテクのチームにシフトしています。
大西 なるほど、そうなのですか。はてなは、ずっとWebサービスをメインで作り続けているので、今回はアドテクについて教えてもらう立場ですね。よろしくおねがいします。具体的には、どういった分野を手掛けているのですか？
大石 まず、リスティング広告の配信エンジンを作りました。これはもう世の中に出ています。次の段階として、我々の会社はデータが集まる立場にありますから、DSP（Demand Side Platform）†2を手掛けようとしています。
大西 先ほどの「秒間4万リクエスト」という数字も、アドテクならではという感じですね。
上田 求められるスループットが、Webサービスとでは100倍ぐらい違うように感じます。
日馬 アドテクの世界ではリクエストの1つ1つを100ミリ秒以内に返さないといけないので、そういう制約もあって開発言語を変えたりもしています。
大西 もともと開発言語は、はてなと同じPerlでしたよね。そうすると今の仕組みではもう使ってないのでしょうか？
上田 広告のAPIサーバーも試作版はPerlで作ったんですが、C++やJavaと比較してみると、これはもうスクリプト言語では無理だということになって、あれほど嫌いだった（笑）Javaを始めました。
ただ、APIサーバはJavaですけど、普通のWebをJavaで作る気はさらさらなくて（笑）、仕組み全体の中でもポータル部分はPerlで作ってます。
阿部 Perlのフレームワークも、前回の座談会で紹介されていたものからバージョンアップしています。
■ GCが一瞬でも走らないように、CのようなJavaを書く
大西 するとAPIサーバーはJavaで動いているんですね。どういう経緯でJavaが選ばれたんでしょうか？
上田 最初は、既存のオープンソースソフトウェアを元に、C++で作っていました。ただ、C++は速いけど開発環境を維持するのが難しくて、このまま突っ走ると後を引き継いだ人が絶対に直せなくなる……。そういう気がしてきて他の言語を調べてみると、Javaがアドテク分野でもよく使われていて、意外と速いらしい。
上田和孝（うえだ・かずたか）さん
株式会社リクルートコミュニケーションズ ICTソリューション局 アドテクノロジーサービス開発部 テクノロジーサービス開発1グループ ソフトウェアアーキテクト
実際に、PerlとJavaで、ユーザーごとのCookieの中に入れるIDのユニーク性を保つロジックで比較してみると、生成できたIDはPerl版で1秒に7,000ぐらい。これが、Java版では1秒に24万を越えちゃって（笑）、こんなに速度が違うんだと痛感しました。
大西 秒間4万リクエストだけあって、速度がポイントだったんですね。それだけ速度にこだわると、フレームワークの選び方も変わってきますね。
上田 既存のフレームワークは利用しないで、完全自作です。HTTPを喋るところからMD5まで、あらゆるところに手を入れました。
大西 それはすごい。
上田 作っていて分かったことは、Javaはプリミティブ型†3、例えばint型を使っている範囲ではCとあまり速度が変わらないのですが、いろいろなオブジェクトを使って、GC（ガベージコレクション）†4が走りはじめると遅くなる。アドテクの「100ミリ秒縛り」があると、GCが一瞬走るだけでも痛いんです。
そこで、今はなるべくGCを走らせないよう「いかにメモリ管理をするか」という作り方をしています。Javaなのに、Cっぽい（笑）。それで、こちらがメモリ管理を忘れると、Javaが拾ってGCしてくれます。
大西 ますますすごいですね。
上田 ログの収集も当初はfluentd†5を使っていたんですけど、APIサーバー本体よりRuby製のfluentdの方がCPUを食うという状況だったので、ここも自作に切り替えています。
- ^3 プリミティブ型
- 各プログラミング言語が処理するデータ型のうち、基本的な型として仕様に記載されているもの。整数（本文中のint）、実数、文字などがある。
- ^4 GC（ガベージコレクション）
- プログラムが確保したメモリ領域が不要になったときに、自動的に解放する機能。開発者がメモリ管理に煩わされないメリットがあるが、GCの実施中にアプリケーションの性能が一時的に低下することもある。
- ^5 fluentd
- オープンソースのログ収集ソフトウェア。多くのプラグインによって、ログの収集や出力を柔軟に設定できる。MessagePack（バイナリシリアライゼーションフォーマット）でも知られる古橋貞之氏が、2011年に9月に公開した。
Fluentd: Open Source Log Management
■ アドテクでは、USが確実に日本より2年は進んでいます
―― 開発言語を変えるとメンバーの習熟などのリスク要因もあるかと思いますが？
上田 いや、コアの部分は1人で開発しているので、言語の違いはそれほど大きな問題ではありません。
大西 コアを1人で担当というのは意外に小規模開発ですね。
上田 アドテクは、情報が乏しくて、変化が速い。だから、作るものの仕様を決めるところが難しいので、人が大勢いれば速く進むというものでもないんです。
阿部 アドテクでは外部のサービスを使うことが多いのですが、接続先の仕様がよく変わります。Webのサービスも変化が速かったですが、アドテクではそれ以上ですね。
日馬康和（くさま・やすかず）さん
株式会社リクルートコミュニケーションズ ICTソリューション局 アドテクノロジーサービス開発部 テクノロジーサービス開発1グループ
日馬 ドキュメントが、1週間後には無意味になったり……。
阿部 外部からの強制力を伴って変化していくので、ものを作っていかないと付いていけません。1人1人が必死に追いかけています。
日馬 資料も日本語のものがなくて、USのカンファレンスや文献が主な情報源です。向こうの方が、確実に2年は進んでいますね。アドテクの技術分野に特化したカンファレンスも、日本にはまだありませんし。
阿部 スパルタ式に英語漬けになって勉強しています（笑）。
大石 アドテクの分野では、このところ金融工学のエンジニアが流れてきていますね。株式取引の入札システムのパフォーマンスをどう上げていくかといった技術の延長に、大量データをどう扱うかといったことがあります。
日馬 仕事の内容もデータにシフトして、ビッグデータを扱うアルゴリズムを考えたり、データサイエンティストと一緒に仕事をするようになりました。これも大きな変化ですね。
■ 違う職種とコミュニケーションできるツール選びは難しい
――データサイエンティストとエンジニアの役割分担はどうなっているのでしょう？
阿部 データサイエンティストはデータをいじる仕事を担当して、僕らは彼らとコミュニケーションを取りながら、広告をどう配信するかを一緒に考えています。
大西 違う職種の人が一緒に1つのチームを作って、上手くコミュニケーションを取りながら仕事が進められるのは理想的な形ですね。
日馬 そういうチームビルドもスムーズに進んだわけではなくて、初めのころはどこに向かうか定まっていませんでした。
上田 そもそも何を作れば良いのかすら分かっていなかったんです（笑）。
日馬 それで、アウトプットを強制しない会議を週に1回開くようにしました。認識を一致させることが目的なので、雑談から入って、お菓子も出しています。
大石 日常的なコミュニケーションが、意外と大事ですね。
大西 チームを立ち上げるときに、週1回のミーティングなどは必要ですね。コミュニケーションツールはどうされているんですか？
阿部 コミュニケーションツールは、基本的にはメールとBacklog†6を利用していますが、このあたりについては現在整理しなおしているところです。
大西 はてなでも拠点が東京と京都に分かれているので、コミュニケーションツールはずっと模索中です。いいチャットツールがあると聞けば試してみるのが課題のようになっていますが、エンジニアにとって良いものが営業には良くなかったりと、なかなか1本に絞れません。
阿部 私たちのオフィスでは同じフロアにほぼ全員いるので、今は会話が基本です（笑）。
大西 たしかに、IRC†7で相談して、GitHub†8でコードレビューをして、と文字ベースだけでもコミュニケーションを進められるのですが、最近は「直接コミュニケーションを取ることも大事」と思い直しています（笑）。コメントがぶっきらぼう過ぎると自分が傷つけられた感じになったり、心がギスギスしてきますから。
※はてなブログチームでのコミュニケーションについてはこちらの記事を参照
はてなエンジニア座談会 - 株式会社はてな
阿部 IRCやGitHubはエンジニアに特化していて、ほかの職種が入りづらいところがありますね。広告を扱っていると運用が避けられないので、オペレーターにとっても効率よいやり方でないといけないのが、一番頭の痛い部分です。
大西 はてなでは、デザイナーや、最近はサポートもGitHubを使っています。ユーザーからの問い合わせで動作の確認が必要になると、サポートがGitHubにIssueを立てて、エンジニアがコメントすると返信がメールで飛びます。
阿部 そういう話を聞くと希望が持てますね。今は、営業やオペレータに、課題をBacklogで上げてくださいという運用をしています。
座談会中に日馬さんのMacをメンバーが覗きこむ様子
- ^6 Backlog
- 株式会社ヌーラボが提供する、クラウド型のプロジェクト管理ツール。
Backlog [バックログ] - チームではたらく、すべての人のためのプロジェクト管理ツール - ^7 IRC（インターネット・リレー・チャット）
- 1988年に開発された歴史あるチャットシステム。ソフトウェア開発者やオープンソース関係者に根強く支持されている。
- ^8 GitHub
- ソースコードを共有・公開できるWebサービス。GitHub社が管理・運営し、分散型バージョン管理システムGitの機能を提供する。公開されているソースコードを自由に分岐・修正でき、プルリクエストで元に送るソーシャルコーディングの開発スタイルは企業内でも有用性が認識されており、有料サービスGitHub Enterprise（GHE）も提供されている。
GitHub
■ 「阿部さんがいないと誰もデプロイできない」という状況は排除する
大西 ソースコードのバージョン管理はどうしていますか？
阿部 3年前はSVN（Subversion）でしたが、今は全部Gitに載せています。GitHubに移行したいけど、これから検討というところです。
（※編集注：この座談会後、GitHub Enterpriseの導入を本格的に検討しはじめたそうです。）
日馬 リポジトリがオープンなので、お互いのコードを意外と見ていますね。上田さんのコードを他の人が見てたりするのが、品質管理につながってるように思います。
大石 同じプロジェクトだと、自分のサービスとして気になりますね。
――開発プロセス的にはどうですか？
阿部 かなり自由です。Scrumなどアジャイル開発の考え方を一部取り入れていますが、最近やっとチケットベースの開発になってきた感じです。
――スプリントの単位を設けては……？
阿部 いないんです。スクラムマスターもいません。
もともと、やりたいことや仕様が最初から明確ではないので。ディレクターやプランナーの要望に応えて作るわけではなく、エンジニアがとりあえず作ってみるという、研究開発的なやり方に合わせた作り方になっています。
日馬 サービスの検討と開発が一緒に走ったりします。
大石 リスティング広告のシステムも2か月ぐらいで作りました。作るべきものが見えてくると、それぐらいのスピードで作れます。
大西 「変化が速い」というお話でしたが、継続的に仕様変更が続くなかで、工夫している部分はありますか。
阿部 そんなに詳しくないエンジニアでも、ボタンひとつで本番環境にデプロイできるように、日馬さんにデプロイ周りを整理してもらいました。
阿部直之（あべ・なおゆき）さん
株式会社リクルートコミュニケーションズ ICTソリューション局 アドテクノロジーサービス開発部 テクノロジーサービス開発1グループ テクニカルリード
日馬 「阿部さんがいないと誰もデプロイできない」という状況は排除していこうというのが狙いです。
大西 デプロイがボタンひとつで誰でもできるくらい、属人的なものでなくなるということは、継続的デプロイの重要な部分ですね。
日馬 私たちの環境は、ほぼほぼすべてAWS（Amazon Web Services）上にあります。ツールとしてはAWS OpsWorks†9をカスタマイズしつつ使っていて、そこにJenkins†10が連携する形です。
システムごとにデプロイツールやセットアップツールが乱立するのは効率が悪いので、AWSという大きなものに載りつつ、自分たちに最適なプロセスを作っていこうとしています。
大西 サブシステムがたくさんあってもプロセスを共通化しないといけないという方向に、業界全体として向かってますね。はてなでも、サービスごとにデプロイの方法が違っていたのを、なるべく統一にしようとしています。
日馬 アプリをビルドしたら、CI（継続的インテグレーション）とユーザーテストが走る。インスタンスをデプロイしたら、ロードバランサの設定も変わる。最終的には、そういった一連の仕組みを作り上げたいです。ひとまず、ロードバランサ周りはもう出来上がっています。
大西 ブルーグリーン・デプロイメントみたいな実践手段ですね。
阿部 いくつかのプロジェクトでは、メインのリポジトリにコミットしたら、そのまま自動的にテストが走って、ステージング／検証環境にデプロイされるところまで実験的にローンチしたので、常に最新版で動く環境が実現できています。
今までは手作業でやっていたので、一回デプロイするのに小一時間ぐらいはかかっていました。
大西 はてなでは、テスト結果をIRCで通知するなど、継続的デリバリーの仕組みをコミュニケーションツールとジョイントすることが流行っています。最近のチャット系ツールにはChatWorkやHipChatなどがありますが、どれもAPIを備えていて、GitHubやJenkinsと連携しやすくなっていますね。
- ^9 AWS OpsWorks
- クラウドプラットフォームAWS（アマゾン ウェブ サービス）上でアプリケーションを管理・運用するDevOpsツール。2013年2月にリリースされた。
AWS OpsWorks （DevOps アプリケーション管理・自動化） | アマゾン ウェブ サービス （AWS 日本語） - ^10 Jenkins
- オープンソースの継続的インテグレーション（CI）ツール。アプリケーションのコンパイルやビルド、テスト、さらにデプロイまでを自動化でき、開発者の手間を軽減する。川口耕介氏が、米Sunで開発したHudsonからフォークする形で2011年2月にリリースされた。
Welcome to Jenkins CI! | Jenkins CI
■ アドテクは、エンジニアがビジネスに関与しやすい分野ですね
大石 私からメンバーに聞きたいのだけど、Webからアドテクにシフトして「ここが変わった」と感じることはありますか？
日馬 単純に面白いかどうかで言うと、データドリブンだけに、効果がすぐに分かるのは良いですね。黎明期ゆえに勝ちパターンがまだないので、新しい事を試みたり、試してみて止めたりもできます。
阿部 効果が出るまでのサイクルがすごく速い。少し試せば、すぐに結果が出ます。しかも、インプレッション数なりクリック数なりの数字で見えます。白黒つけるのが好きなエンジニアには、すぐ数値で見えるのは分かりやすい。
大西 リーンスタートアップが話題になって、効果を可視化して検証しようという流れがきていますが、UIを変更した効果などは検証が難しい。それに比べると、アドテクは効果がすぐ分かるのですね。
大西康裕（おおにし・やすひろ）
株式会社はてな チーフエンジニア／プロデューサー
日馬 常時がABテスト的です。日々、極端に速いペースで効果測定、最適化を繰り返しています。
阿部 Webの世界でも継続的デリバリーの考え方があって、「作って終わり」ではありませんでした。アドテクもそこは同様で、ここの違和感はありません。リリース後に、また次のリリースを用意して、細かく続けるのが今の流れです。
大石 アドテクは、エンジニアがビジネスに関与しやすい分野ですね。売り上げや収益を上げられるのは、価値を提供できているということだから、分かりやすい。
大西 お話を聞いていると、アドテクはエンジニアの活躍の幅が広いように感じますね。
上田 Webサービスでは絵心、というかデザインが重要です。仕事の流れでも、プランナーやディレクターから依頼されて作る形が多い。一方で、アドテクはずっと技術ドリブンですね。
阿部 Webより、クリエイティブとの距離が近くなったように思います。その広告の効果をどうやって出すのか、といったテクノロジーの話に落とし込みやすい。
大石 テクノロジー自体が売り物になりますね。そこが面白い。
阿部 ディレクタが思いつきで「こう作ってよ」と言ってきても、「それじゃ数字伸びません」とエンジニアからツッコミを入れたり。
日馬 僕たちの会社にはクリエイティブやコピーライティングの専門家もいるから、シナジーを狙えると面白いですね。一般に、クリエイティブが得意な広告代理店はテクノロジーに強くなかったり、アドテクベンチャーはクリエイティブの専門家とつながっていなかったりしますから、そこが優位性になる。
大石 テクノロジーを分かっていないとビジネスを進められないから、経営陣も勉強してますね。
一方で、アフィリエイトプログラムのように手軽に収入を得られる世界でもあるので、当然、グレーな手法が出てきたりします。グレーなやり方にどう対応するかも考えないといけない。
日馬 初期のインターネットでも、SPAMメールのように、仕組みが出来上がっていないが故の課題があったと思います。今のアドテクもそれに似た感じで、まださまざまな課題があるのが現状です。そのあたりもプログラマチックに学習で解決できないかを模索しているところです。
大西 そこでも機械学習の話が出てくるのですね。
上田 Webでは「機械学習、なにそれ？」でしたが、アドテクではすごく機械学習が身近になりました。やりたいこと、データを食べさせればできることが見えてくる感じです。
阿部 検索の未来みたいな感じです。人がどういう広告を選ぶか、は面白い世界です。
■ ずっとプログラムを書き続けられるキャリアがちゃんとある
――アドテク分野に来てほしいのは、どんなエンジニアでしょうか？
大石 まず、エンジニアとしてスキルを高めたい人ですね。アドテクの分野はまだまだ新しい技術やサービスが生まれる領域なので、0を1にできる発想の人を求めています。そこにはプログラミングだけでなく、数理科学の知識を応用し、プログラムで形にできる能力が必要です。そういう意味でエンジニアの実力としては、国内でもいい線をいっていると思いますね。データサイエンティストが組んだ理論を実装できる人なども、歓迎です。
阿部 僕は3年前の記事を見るまでリクルート系の会社のエンジニアがこんなにちゃんとやってると思っていなくて（笑）。記事から想像していたより、さらに自由にコードが書ける場所でした。
日馬 開発合宿やLT大会もあります。
大石 合宿は1泊2日ですけど事前準備が必要で、設定されていた例えば「集客」というテーマで発表してもらいます。
――阿部さん、転職されて実際にリクルートコミュニケーションズのエンジニアの印象はどうでしたか？
阿部 全員がCTO（最高技術責任者）みたいなイメージです。CTOは、ビジネス的な側面も含めて技術を見るのが役割だと思いますが、私たちもみんなが「自分が作っているもの」の何に価値を持たせるかを考えています。
自分たちのサービスを作らないといけないので、自分で自分のゴールを設定する側面があり、強い当事者意識につながっています。
大西 分かりやすい形で成果が出るのは、本気で機械学習をやりたい人にはいい職場かもしれませんね。履歴書に「機械学習をやってきました」と書いてWeb業界に入ったものの、活かせる現場がなくて今くすぶっている人に、アドテクはオススメかもしれない。
大石 スピードと自由な発想を大事にする環境を用意するよう心掛けています。勤務時間の縛りもないですし、過度な長時間労働もありません。エンジニアは、成果を出せれば評価が上がります。ずっとプログラムを書き続けられるキャリアがちゃんとあって、管理職以上にお金をもらっているエンジニアもいます。
大西 そうした風土の部分は変わらないのですね。私も、3年経っても上田さんがコードをバリバリ書いていたので安心しました（笑）。本日は長時間ありがとうございました。
取材・構成 星 暁雄（ITジャーナリスト）
エンジニア募集のお知らせ
リクルートコミュニケーションズは、エンジニアを募集しています。コード重視のキャリアパスや開発環境などの詳細は、下記ページよりご覧ください。
【追記】今回の取材のウラ話が「RCOアドテクLabブログ」に掲載されました。リクルートコミュニケーションズのオフィス風景も公開されています。
なぜか面接風景のように撮れてしまった座談会のヒトコマ
■ MacBook Pro Retinaモデルが当たるプレゼントのお知らせ！
※キャンペーンは終了しました。たくさんのご応募、ありがとうございました。
本記事をお読みいただいた方に、以下のMacBook Pro Retinaモデルを抽選で1名様にプレゼント。応募方法の詳細は下記応募要項をご覧ください。
- 13.3インチ Retinaディスプレイ
- 2.4GHzデュアルコアIntel Core i5
- 4GB 1,600MHz メモリ
- 128GBフラッシュストレージ（PCIeベース）
- Intel Iris Graphics
＜MacBook Pro Retinaモデルプレゼント応募要項＞
- 応募期間
- 2014年3月18日（火）から2014年4月1日（火）24時まで
- 賞品と当選人数
- 応募方法
- Twitter連携した上で、この記事をはてなブックマークに追加
- ※プライベートモードでご利用の方は対象となりません
- 当選発表
- 厳正なる抽選の後、はてなブックマーク開発ブログで、当選者様を発表させていただきます
- 賞品発送
- 当選発表後、はてなよりメールをお送りし、送付先情報（送付先住所、受取人氏名、電話番号）をお聞きします
- ※プレゼントの発送は日本国内に限らせていただきます
※当キャンペーンはAppleの提供・協賛によるものではありません。
MacBook ProはApple Inc.の商標です。
[PR]企画・制作：はてな
写真：小高 雅也
