「その場しのぎ」は長期的な開発を破綻させる　AbemaTVの進化と変化を支えるチーム体制

AbemaTVの開発局は現在50名程度が在籍

波戸勇二氏（以下、波戸）：先ほどのサーバーサイドなどの音声の話とはちょっと毛色が変わって、今回はモバイルアプリのクライアントの話です。モバイルアプリの開発体制と開発プロセスの話ということで、始めたいと思います。

簡単な自己紹介ですが、AbemaTVでiOSエンジニアをやっている、波戸と申します。よろしくお願いします。

（会場拍手）

アジェンダですが、最初はざっくり「AbemaTVのiOSチームって、どうやって開発してるの？」。今、10人いるんですけど、どのような体制で開発しているのかをお話ししたいと思います。

まず開発体制ですが、AbemaTVの開発局は現在50名程度が在籍しています。図にすると、左からディレクター、サーバー、デザイン、ウェブ、iOS、Android、QAといった感じです。あと、各チームから代表者が出て、ボードのメンバーがいるというかたちになります。

iOSはその一部になるんですけど、その中でもチームが分かれています。ビデオチーム、グロースチーム、本質改善チーム、テレビデバイスチームと、大きく4つに分かれています。

iOSチームなんですけど、先ほど言った通り、現在は10名体制でやっています。立ち上げ当初は4名程度だったので、だいぶ増えたかたちになります。ここでは、みんなに顔出しOKをもらったので（スライドに）載せています。

先ほどの大きく4つに分かれていたところなんですけど、ビデオ、グロース、本質改善、テレビデバイスを（メンバーの顔写真で）分けると、こんな感じになります。

現状AbemaTVの対応デバイスは、PC、iPhone/iPad、Android/タブレット、Apple TV、Android TV/Amazon Fire TV、Google Cast。iOSチームが担当しているところはiPhone/iPad、Apple TVで、Google CastはTV側のレシーバーとクライアント側のセンダーがあるのでセンダー側の担当範囲になります。

毎日大量のコードが変更されている

iOSチームが管理しているコードベースですが、リポジトリがけっこうあります。大きく2つ、iOSとtvOSでリポジトリがあります。

その他にはAPIの共通のモジュールとプロトコルバッファを使っているんですけど、プロトコルバッファのSwiftファイル、共通のスクリプト群などを入れてるコマンドシェルフiOS、あとはモックや検証用のプロジェクト、ツールなどを管理しています。

これはコードのファイル数とか行数を出したものです。一昨日くらいに出したのかな。iOSが90,000行くらいですかね……。tvOSが27,000行で、APIも少し、3,800行くらいあります。

これはiOSリポジトリのGitHubのインサイトで、コミット数とかマージコミットも見れます。注目してほしいのはプルリクエスト数で、これは資料を作った日がバレちゃうんですけど、9月19日から10月19日の間で、プルリクエストが1ヶ月の間で162個マージされているといった感じです。営業日換算すると、だいたい毎日7〜8個のプルリクエストがマージされていることになります。

（図の中の）一番右に、すごくコミットしてない人がいるんですけど（笑）。これはデザイナーで、画像の差し換えや文言変更などを、デザイナーがプルリクエストしてくれています。

これはtvOSで、ちょっと少ないんですけど、57個のプルリクエストで、営業日換算で1日2〜3個のプルリクエストがマージされていて、APIもちょこちょこ入っています。

なにが言いたいのかといいますと、みんなしっかり仕事をしていますよ（笑）。というのは冗談で、毎日大量のコードの変更がされているということが言いたくて。そして、それらをどういったフローで開発しているのかをお話したいと思います。

タスク管理はスピードより「誰がどれくらい案件を持っているか」

基本的にはiOSチーム、AndroidやWebも大体同じなんですけど、スクラムで2週間ごとのスプリントで開発しています。もうちょっと細かくした図なんですけど、これは少し前に実践していたフローで、開発を2週間、QAを1週間というかたちで2週間ごとの申請でやっていました。

ただ、これはちょっと問題があって、「開発とQA期間の重複が辛いです」という声があがっていたんです。

QAの期間中にバグの対応とか多く入ると、次のスプリントにモロに影響が出てしまい少し無理があったので、改善しました。現在は開発期間1週間、QA期間が1週間という重複しない定義で行っています。今のところ、これでけっこうスムーズにいっていると感じています。

長い開発はスプリントを跨いだかたちになって、フライングというか、QA期間中から始まる開発も案件によってあります。計画ミーティングごとになにをやるか決めるんですが、ある程度の先のスプリントの開発まで決めているので、こういった調整が容易になっています。

あと、タスクがそもそもどのように決まっているのかというところなんですけど、パターン1はけっこう一般的です。プロデューサー、プランナーが立案して、それを実現させるための機能を考えて、タスクに落とし込む。いわゆるトップダウンといったタスクです。

パターン2はエンジニアがコードの品質やパフォーマンス、継続的な開発のための試作を洗い出してタスク化するというものと、モックを作っちゃって「どうですか？」とか言ったり、勝手に実装して「入れていいですか？」といったパターンもあります。

タスクの見積もりはタスクのストーリーポイントを付けているんですけど、これはスクラムに詳しい人だと「え？」と思われるかもしれないです（笑）。1ポイントは軽微なもの、2ポイントが0.5スプリント、3ポイントが1スプリントか、またはそれ以上という、けっこうおおざっぱな付け方をしています（笑）。

数値の付け方としては、AbemaTVは事業の流れがはやく、案件の優先度がコロコロ変わるので、ガチガチに付けるよりも一人ひとりがどれくらいの案件を抱えているのかという目安として、今は使っています。

タスク優先度の定義は、優先度は5段階でS、A、B、C、Dとあります。S、A、Bが上矢印、C、Dが下矢印というところです。上矢印はスプリント期間に開発完了、テスト、リリースが必須のもの。これが間に合わなければ、先ほどのスプリントで示した図の、定常リリースを遅らせる判断をするものになります。

CとDは「次に回してもいいよ」という定義をしています。こういった共通言語を定義していると、ディレクターとかの会話がスムーズにいったりする利点もあります。

活発なレビュー文化ゆえに、プルリクエストから議論なることも

会議体ですが大きく4つあって、スプリント計画と、スプリントの振り返りのスプリントレビュー、メンバー各自の案件のミーティング、iOSチームは定例週1でやっています。けっこうミーティングは少ない方なのではと思っています。

使っているツールを紹介しますね。けっこう一般的で、チャットツールのSlack、CI用のBitrise、チケット管理のJIRA、ドキュメントツールのConfluenceとesa、自動化でJenkinsを使っていて、cmdshelfも自動化の一環ですね。あと、コード管理のGitHubなどです。

cmdshelfについては知らない方もいるかもしれないので、少し紹介します。リモートリポジトリの実行可能ファイルをローカルにダウンロードして、ローカルファイルのように統合して扱えるツールで、iOSチームのトッシーさんという方が作ってくれています。

これは実際の例で、iOSの共通のスクリプトをリポジトリに入れています。左がリポジトリで、cmdshelf remote addでリポジトリのURLを追加すると、そこの実行可能ファイルが全て追加されます。

実行するときは、cmdshelf runでリストで出てきたやつを実行できるといったかたちです。メンバーが新しく入ったとき、どこにのあるのかわからないものなどを共通化しておくとけっこう便利になります。

続いて開発スタイルを紹介します。プルリクエストについてです。これはCONTRIBUTING.mdの抜粋ですが、プルリクエストなどをするときのガイドラインになります。最後のコミットのあと3人以上からOKをもらう、軽微な場合は2人以上でOK、極力テストコードを付ける、極力デザイナーの確認をとるなどといったことを定義しています。

AbemaTVは活発なレビュー文化で、これが平均より多いのか少ないのかわからないですが、感覚的にはけっこう多い印象です。そのため、プルリクエストのコメントから議論に発展することも多々あります。

コーディング規約として、これはObsevableの公開方法をGoodとBadみたいな感じで書いてあるんですけど、「こう書きましょう」みたいなプロジェクトで統一した書き方を目指しています。

“あえて2つ作る”ブランチ戦略

あとはテストですが、今テストケースが2,009ケースあって、極力テストは書く方針で進めているんですけど、基本UI周りは書いていません。そこは設計でカバーしていて、ビューにはロジックを書かずモデル層とかロジックの部分のテストは書くようにしましょうという方針にしています。

右の図は、iOSの週一定例シートの抜粋です。急ぎでないものは、各自思いついたときに議題に入れてもらって、定例で結論を出してアクションしていくやり方をしています。すぐに解決したいものはGitHubとかSlack上での議論で、開発のルールをどんどん更新していっています。

次にブランチ戦略ですが、基本はGitHubフローで、開発用のマスターブランチとQA用のqaブランチを2つ作っています。そして各自でトピックブランチをマスターqaから作って作業する流れをとっています。

シンプルにこのようなかたちになっていて、マスターブランチがあって、QA期間中はqaブランチを使う方法にしています。

これにスプリントの図を当てはめると、こういうかたちです。左が仮で、スプリント2.2.0で、真ん中が2.3.0、右が2.4.0。真ん中の2.3.0を見ますと、ここが開発期間。マスターブランチからトピックブランチを切って、マスターにプルリクエストしてマージするといった期間です。

2.3.0のQA期間中はQAブランチからトピックブランチを切って、プルリクエストしてQAにマージするかたちをとります。この期間中のマスターは、2.4.0の開発をしていることになります。そして2.3.0の申請が終わったら、QAブランチをマスターにマージする。申請が終わったらというよりも、適宜マージする形式です。

このブランチ戦略のいいところとしては、これを間違えるとプルリクエストのマージができないといった課題が発生しがちなので、そういったことがあまり発生しないこと。基本はGitHubフローなので、シンプルでわかりやすい。スクラム開発のスプリントサイクルにうまく当てはめやすいのかなと感じています。

Slackの通知は自動化しているものもある

次にベータ配信について、テスト用アプリの配信の自動化フローについてお話しします。

図のような感じになっていて、まずデベロッパーがGitHubにプルリクエストして、レビューを通ってマージされるとbitriseがフックしてジョブを起動します。ビルドしたら、継続的に「Crashlytics」でベータアプリを配信しています。

対象ブランチは、マスターとqa、先ほどお話したものですね。あと、マスターとqa以外にqa-xxxxxのようにqaハイフンで始まる名前のブランチをあげると、配信するようにしています。

これは特別なバージョンでなにか確認しておきたいために用意しているといったかたちになります。QA期間中はテストフライトにも配信していて、本番と同じ状態で確認できるようにしています。

Slackの通知についても、いくつか自動化しているものを紹介します。このあたりは……だいたいみなさんもやっていると思うんですけど、左上がCocoaPodsの、「ライブラリアップデートがあるよ」というときに通知してくれるものです。

これはベータ配信のときにお話した、「QAビルドが配信されたよ」というお知らせもSlackに流れます。あと、「クラッシュがけっこう起きてるよ」という通知もSlackに流していたり。（右上の）K.I.T.T.……これはなんだっけ？（笑）。

あ、これは自前のbotなんですけど、レビューがしばらくされていないプルリクエストを自動で見て、「これ見てね」とお知らせを流していたり、あとは「通知の証明書が切れそうだよ」など、App Storeのレビューも、Slackに流しています。

あとは、AppleのRSSとかも流していますね。これは「iOS11のベータ10がきたよ」というものです。

AbemaTVは事業的に先を見据えたサービス

次にQAの効率化についてお話したいと思います。機能が多くなって複雑になってくると、QAの時間も比例して大きくなっていくと思いますが、その効率化のためにデバッグメニューを用意しています。現状のデバッグメニューの機能について、いくつかピックアップしてご紹介します。

アクティビティーモニターは、CPUとメモリ使用率を表示するものですね。あと通知周り、通知のテストとかけっこう面倒くさいと思うんですけど、クライアントで設定して5秒後に送るとか、ローカルの通知のシミュレートをできるようにしています。

アプリの保存情報とかキーチェーンとか、データベース、画像キャッシュを削除できるようにしていたり。ユーザー区分とか、サービスによってけっこうやっていたりすると思うんですけど、1週間に何回起動したかとかそういった区分をステータスを変更してテストできるようにしています。

あとはアニメーションの速度を変更したり。動画のサービスなので、再生の動画のビットレートやレゾリューション、セグメントファイルの転送時間とか、AVPlayerから取得できるものは、ほぼオーバーレイで表示できるようにしています。

ログ出力確認ですね。これはGAログって書いてあるんですけど、3つくらい種類を送っていて。QAチームから、「ログを管理ツールから確認するのがけっこう大変です」という声があがったことがあったんです。

バグがあった時など、気づくのが遅くなるんですよね。そういった時にコンソールで、まずは動作としてちゃんと出ているかという早期のバグ発見に役立っています。

その他だと、iOSチームは社外のカンファレンスの登壇を積極的に行っていたり、隔週でチーム内ランチ勉強会を開催しています。10人いるので、隔週でやっているとそんなに負担にならないので、チームビルドというか、知見の共有という意味で良い取り組みになっているかなと思います。

（スライドの）これは開発風景ですね。

最後に、まとめです。AbemaTVは事業的に先を見据えたサービスなので、その場しのぎで開発していくと、長期的な開発のどこかで破たんしてしまうという可能性もあると思います。

なので、AbemaTVのモバイル開発においては、長期的な視点で開発スピードとアプリの安定性、コードの品質を保った継続的な開発ができるように、意欲的に取り組んでいます。ということが、今回の発表で伝われば良かったかなと思います。

以上簡単にはなりますが、まとめということで、発表を終わりにしたいと思います。ありがとうございました。

（会場拍手）