ソーシャルプラットフォーム事業本部 comm戦略室 長田一登氏
「SCRUM OF SCRAM」を導入し、大所帯でも機能する開発体制に
「スマートフォン向けネイティブアプリ市場は、いまやB2C型Webサービスの主戦場の一つである。そして今後ますます面白くなっていく」
こう語るのは、ディー・エヌ・エー（DeNA）ソーシャルプラットフォーム事業本部comm戦略室の長田一登氏だ。
『comm』とは、DeNAが2012年10月23日にリリースしたコミュニケーションツールだ。高品質な無料通話や実名制という特徴を持つcommは、リリース初日にAppStoreの無料総合ランキング1位を獲得。テレビコマーシャルの効果などもあり、「2カ月強で500万超の登録ユーザーを獲得した」（長田氏）、人気急上昇中のスマートフォンアプリである。FacebookやTwitterが500万人のユーザーを獲得するのに、数年かかったことから、「これは私たちの想定よりも極めて大きな上振れだった。約半年で100万人ぐらいのユーザーを獲得できればいいなと思っていた」と長田氏は明かす。
モバゲーやECなど大規模なソーシャルサービスを展開しているDeNAだが、スマートフォン向けアプリではこれほど大規模なものはなく、「手探りの状態で大規模化への対応を図った」と長田氏。
では、どのように大規模なスマートフォンアプリの開発や運用体制を構築していったのか。まず長田氏が説明したのは、開発体制についてである。
commは、当時新卒1年目の長田氏が企画立案したサービスだ。2012年1月にプロジェクトがスタートしたときのメンバーは長田氏1人。それが4月には5人体制となり、「リリース直前には開発エンジニアに加え、デザイナーやマークアップエンジニア、企画職、ディレクターなどを含め15人体制となった」と長田氏は語る。
DeNAでは2011年夏より、アジャイル開発の手法の一つである『スクラム』を導入している。当然、commプロジェクトにもスクラムが導入されたが、「いろいろな問題を抱えることとなった」と長田氏。
第一が人数の問題だ。「スクラムは1チーム5～6人がベストとされているが、commは15人で1チーム。そのためさまざまなコミュニケーションロスが発生したが、リリースまではその状態で乗り切るしかなかった」（長田氏）という。
その上、プロダクトオーナー（PO）とスクラムマネジャー（SM）が「瀕死だった」というのだ。15人体制のスクラムにおいてもプロダクトオーナー（PO）とスクラムマネジャー（SM）はそれぞれ1人。しかもPOは通常のPO業務に加え、企画・仕様決め、UI/UXやデザインのディレクション、さらに法務部やCS部などとの調整業務もあったという。一方のSMも通常のSM業務に加え、開発リーダーも兼務。実はSMに就いていたのが長田氏である。「自分で実装やバグ管理もしていた。やることが多くてパンク状態だったが、リリースまではそれで乗り切るしかなかった」と振り返る。
そしてリリース後、怒涛の人員追加が行われ、1週間後には60人体制になったのである。「このままの状態では回るわけがない」──。大規模な開発体制に対応するため、まず導入されたのが『SCRUM OF SCRAM』である。
「ファンクションごとに4つのスクラムに分割し、各チームに1人ずつPOを配置。そして全体をまとめるチーフPOを設ける組織体制にしました。100点満点とはいえないが、60人という大所帯でもうまく機能する開発体制が整備できたと思う」（長田氏）
そして第二の対応策は、専任のSMを導入したことである。
「SM業務のみに専念するSMを2人導入。私は開発リーダー業務に専念できることとなり、開発効率が向上した」（長田氏）
インフラ・テスト・QAなども手探りで大規模化対応
開発体制だけではない。大規模なサービス規模に合わせたインフラの構築も行わねばならなかった。commは企画当初から1千万人規模のユーザーを想定しており、それを見越したアーキテクチャの設計を行ったというのだ。しかもTCP常時接続や非同期処理が必要となるcommは、一般的なWebアプリケーションと比べると作るのが複雑である。「DeNAではあまり経験していなかった領域だったので、余計難しかった」と長田氏は振り返る。すでに競合のサービスも登場している。それらに勝つためには「スケーラビリティ、アベイラビリティ、パフォーマンスという3要素をきちんと確保できるインフラを作らなければならなかった」（長田氏）という。
メッセージングの仕組みについては、スケールアウトが簡単にできるよう、疎結合でシンプルなコンポーネントに分割。また、すべてのコンポーネントを多重化している。
データストアについては「マスター/スレーブ/バックアップ構成の採用やデータベースシャーディングを前提とするのはもちろん、要所でMySQLへのアクセスを高速化するプラグイン、『HandlerSocket』を利用するなどMySQLを使い倒している」と長田氏は言い切る。余談だがHandlerSocketはDeNAの樋口氏が開発しており、ソースコードは同社HPで公開されている。そのほか、DNSはMyDNS（バックエンドにMySQLを用いたDNSサーバー）、Job QueueもDeNAの奥氏が開発したQ4M（Queue for MySQL：OSSのキューイングライブラリ）を採用。また一部、入出力が激しい箇所には、キーバリューデータストアのRedisも導入しているというのだ。
DNSについては、名前解決であらゆる向き先を分散。「この方法がいちばん柔軟で障害対応として得策だから」と長田氏はその理由を語る。しかしこうするとMyDNSの負荷も相当なもの。そこで、複数のノードにレコードを分散させるアルゴリズム『Consistent hashing』を実装し、DNSをローカルにキャッシュ。もしMyDNSが倒れても、24時間以内に復帰すれば問題のない仕組みを構築した。
通話において最も課題だったのは、日米間の通話で転送遅延が生じていたことだ。「最低でも150msec程度発生していた」と長田氏。そこで海外ユーザーの音声通話にはAmazon EC2を使用し、ユーザーに最適なリージョンを自動的に選択するようにしている。
「リリースしてから、負荷的に困ったことはまったく起こっていない」と長田氏は言い切る。
テストやQA（品質保証）体制の構築も容易ではなかった。まずはテスト。commリリース前後のテストでうまくいっていたのはサーバーの単体テストのみ。その他、クライアントの単体テストやサーバーおよびクライアントの結合テストについては「テストが書きづらい」「自動化の構築が難しい」などの問題が噴出。テストのカバレッジが上がらない上に、新機能が増えていくので、QA工数も継続的に増加していったという。
そこで「人数が60人に増えた時点でテスト方針の改善に着手した」と長田氏。サーバーおよびクライアントの結合テストについては、Calabash/Cucumberを用いたUI自動化テスト『Integrated UI Automation Test』を導入した。これに継続的インテグレーションツール『Jenkins』を使い、ミッドナイト・ヘッドレステストを実施している。またテストスクリプトの作成や環境全般のメンテナンスは、専任のテストエンジニアが行う運用体制も構築した。この結果、「全体のカバレッジが向上し、リグレッションQA工数が明らかに減った。しかし、これはあくまでも補完的な役割。サーバーの完全な結合テストはこれではできない」と長田氏は指摘する。
QAにおいても、リリース前後は問題が山積みだったという。その原因の大本となったのが、開発チームとQA部が明確に分離されていたことだ。
「その結果、コミュニケーション不全、QA部のやらされ感、バグ管理の破綻という状況ができてしまった」（長田氏）
この状況を打破するため、テスターのチーム張り付き制、バグ管理ツールJIRAを運用管理する専任ゲートキーパーを導入したのである。するとバグ件数は減少し、手戻りの少ない機能検証ができるようになったという。そのほかにも長田氏が解決を図らなければならなかったものがあった。それはクライアントでバグが起きても気づきにくい、ユーザーのアクティビティがわからない、各種性能指標が取れないというネイティブアプリ特有の問題である。これらの問題を解決するため、現在、クライアントログ収集やアクティビティの可視化ができるような仕組みを開発中だという。
最後に長田氏はcommの未来について次のように語り、セッションを締めた。
「リアルアイデンティティを軸としたクローズド・コミュニケーションのプラットフォームとして、EC事業やモバゲー事業、さらには2月末にリリースする音楽サービス事業『Groovy』などの新規事業ともシナジーさせ、さらなる発展をさせていくというのが私たちの狙いだ」
