logo

DeNA「ハッカドール」エンジニアに聞く--突き抜けたオタク特化のこだわりと開発の奇跡 - (page 3)

佐藤和也 (編集部)2015年04月10日 09時00分
  • 一覧
  • このエントリーをはてなブックマークに追加

リアルタイムで進化、ハイテンションだったリリース前後の秘話

--ハッカドールのリリース前には、ユーザーテストをかなり繰り返したと聞いてます。

広瀬氏:自分たちの考えた新しいサービスが、本当にユーザーにとっていいものなのかは、作り込めば作り込むほどわからなくなってきます。作り手の意識も大きくなってしまうのですが、実際に利用した感想を聞くと、作り手の視点になりすぎていたということに気付きます。これは僕の肌感覚で根拠はないのですけど、ユーザーテストは最低でも5回繰り返さないといいものにならないと感じています。ハッカドールもそれぐらいやりたいと進言しました。最初はボロボロだったのですが、改修を繰り返すうちに「便利です」という感想をもらえるようになってきましたね。

榎本氏:フロントサイドに見えるUIの部分だけではなく、バックエンドのレコメンドもいろんなことをやっています。特にパラメータのチューニング作業はかなり大変でした。例えば、いかにユーザーにマッチした記事を提供するかという軸と、ニュースアプリとして新しい記事を提供するかという軸の2つをいかにうまく両立させるかというところです。さじ加減を間違えると、最新の記事だけどその人にとっては微妙な記事が提供されるとか、マッチした記事なんだけど1カ月前のものが届くといったアンバランスなことが起きます。そのバランスをとるためのパラメータ調整をひとつずつ地道に行っていきました。

 それはリリースしたあとも調整は行っていって、日に日に記事の開封率が良くなっていきました。ユーザーテストでも向上しましたが、リリースしてからのほうがたくさんのデータが入りますので、すごくエキサイティングな環境でしたし、レコメンドの精度はリアルタイムで進化するといってもいい状況でした。

 今でこそA/Bテストを行って検証をしていますが、リリース初期はそれでは間に合わないということで、会議室も取らずにチームの脇にあったスタンディングのテーブルに6時間ぐらい集まって、パラメータを調整しながらその反応を聞いたりしていました。チームのスタッフもターゲットユーザーのひとりなので、調整した結果というのがある程度はわかるんです。「すっげーいいじゃん!」と叫んで周りから白い目で見られたりしましたけど(笑)。そんな状況でチューニングを施していました。

--ハッカドールのリリースタイミングはコミケ86の初日でしたけれども、それは予定通りだったのでしょうか。

岩朝氏:その日に決めてはいましたが、Android版の配信が間に合うかどうかは前日までわかりませんでした。企業ブースとして出展する手前もあってリリース日がずらせないからと、宣伝担当から間に合わなかった場合の対応を求められて、そのときはAndroid版「ごめんなさいアプリ」を出そうとも話をしていました。

広瀬氏:コミケで言う「新刊落ちました」風に、起動したらハッカドール1号が「ごめんなさい、間にあいませんでした」と謝るだけのアプリですね。

岩朝氏:それを判断するのが前日の16時までだったんですけど、なんとか間に合いそうという連絡があったんです。コミケの準備もあったのですが数時間だけぽっかりと空いた時間には神田明神に行ってリリース祈願をしました。みんな妙なテンションになっていて、プロダクトマネージャーが数十万円もするカメラを突然買ったりしてましたね(笑)。

榎本氏:0時リリースということもあって、エンジニアは泊まり込みで対応していました。僕にとって初めてメインで担当したサービスのリリースだったので、リリースのボタンを押す時は叫んでたりしてました(笑)。初動も良くてなおのことうれしかったんですけど、一部機能が働かないとかがあって、それはそれで大変でした。

岩朝氏:App Storeの「おすすめ」に載ったんですね。当たり前ですけど全然聞いてなかったので驚喜しましたし、それによって初動の加速度合いも大きくなりました。

榎本氏:エンジニア陣は仮眠しつつ状況をみながら、お昼ぐらいにコミケに行ったんです。大丈夫だと思ったのですけど、コミケでの告知などでさらにユーザーが増えたようで、会場から色々と対応していました。初動は予想以上でしたけど、サーバの負荷という意味では慌てる状況にはならなかったです。むしろいくつか動くべき機能が動いていないことがわかって、それの対応が主でした。負荷は少し経過してから出てきた問題になります。

岩朝氏:エンジニア陣はMobageなど大規模サービスを運営していた経験もあることからか、IT企業が通常考えるパフォーマンスチューンニングや負荷分散の考え方は、当たり前の「あ」の字の話なんだと思います。なので、カテゴリ特化型のサービスとはいえ、アーキテクチャとして何百万人が利用しても大丈夫という設計にはなっています。サーバもお下がりの2台しか使えなかったのですけど、止まることはありませんでした。

榎本氏:結果論ではありますけど、初動は1台であっても負荷の処理ができていました。負荷テストもやっていたので2台で大丈夫であろうとは思いましたけど、やはりやってみないとわからないですから、ドキドキしていたのは事実です。

見た目はかわらなくても内部的には作り直し

--リリース後でも改善や新機能追加で作業をされていると思いますが、大変さは変わりましたか。

広瀬氏:リリース直前が一番大変だったとはいえますが、今でも大変なのは続いています。むしろ考えることは倍以上に増えたかな。

榎本氏:リリース後は通常の運用と新機能開発を平行しながらスケジュール通りに動かしていくことに苦労しています。新機能も実装を前提に設計していなかったものもありましたので、いかに互換性を持たせながら新しい機能をいれるかという、設計的に難易度の高いことを不具合なくリリースするというのは、チャレンジングで大変です。

 最近だと、アカウントの引き継ぎ機能ですね。地味な機能かもしれませんが、そもそもログインログアウトの概念がないものだったので、どうやって実装しようかと。データもクライアントで保存させていた部分をサーバに移行させるといったことをしたり、裏側では泥臭い積み上げでできた機能ですね。

--見た目は同じでも、内部的には作り直しをしているのでしょうか。

広瀬氏:そうですね。コードについてはAndroid版は8割、iOS版は6割ぐらい捨てています。

榎本氏:サーバまわりのコードは1割程度しか捨ててないです。ただ、時間があったら5割ぐらいは捨てたいですね。記事のリストを出すという根幹的なAPIがあるんですけど、リリースしてから3回作り直しています。見た目は変わってないように見えても、内部は結構作り直しています。パフォーマンスに対する追求は常にしないといけないところですので。

 チューニングの話にもつながりますが、ニュースアプリとして最新の情報を提供することが命題としてあります。たとえば20時に配信する記事を余力を持って16時から計算し出すと、最新の記事が提供できなくなります。なので計算しだすタイミングをギリギリまで狭めるため、処理を高速化できる普通とは少し違うコードを書いています。また1日3回の配信をしていますが、配信時間にアクセスが集中するので、そこでいかにうまく運用していくかをインフラ周りの担当者とも協力して検証しています。今のところサービスを開始してから、記事配信ができなかったり間に合わなかったりしたことは一度もないですし、アクセスできないという時間帯もありません。裏側はバタバタとしていますが、安定したサービスが提供できていると思います。

岩朝氏:初期のころは遅れそうになったことが何度かありました。会議中にアラートが鳴ると、みんながやってきて間に合わせるんです。その光景はスクランブルに対応する司令局みたいに声を掛け合う感じで、一致団結している感覚でしたね。

CNET Japanの記事を毎朝メールでまとめ読み(無料)

-PR-企画特集

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]