AbemaTV モバイルアプリの開発体制と開発プロセスの話

Editor's Notes

• #4: では早速開発体制についてですが、
• #5: ということで早速開発体制についてですが、
• #6: 現在AbemaTVの開発局は約50名程度います
• #7: えー図にするとこのような感じで、左からDirector, Server Design, Web, iOS, Android, QAといたチームに分かれていて、それぞれのチームの代表でBoardメンバーが構成されています.
• #8: 今日はこの中で、iOSチームについての開発体制や開発スタイルについてお話したいと思います。
• #9: まずiOSチームの中でもチームが分かれていて ビデオチーム、グロースチーム、本質改善チーム、テレビデバイスチームと大きく4つに分かれていて、その他にどれに属さない案件、プロジェクトなどがあったりします。
• #10: iOSチームですが、
• #11: 現在10名体制で開発しています。 立ち上げ初期は４名程度だったのでだいぶ大きなチームになりました。
• #12: はい、みんなに顔出しOKもらったので載せておきますw
• #13: で、具体的には、先程お話したビデオ、グロース、本質改善、テレビデバイスチームはこのような形で分かれていて、その他の案件はケースバイケースでその時の状況で調整して対応しています。
• #14: AbemaTVの対応デバイスはPC, iPhone/iPad, Android/タブレット、 AppleTV, AndroidTV, Google Castがあります。
• #15: この中でiOSチームはiPhone, iPad, AppleTV, あとGoogle Castはテレビ側のrecieverとクライアント側のsenderがありますが、sender側が担当範囲になります。
• #16: iOSチームが管理しているcodebaseですが、
• #17: 代表的なレポジトリはiosとtvosの２つになります あとは共通のapiモジュールや あっprotocolBuffer使っているのですが、protoのswiftのレポジトリ 共通のscript郡のcmdshelfレポジトリなどがあります
• #18: これはcodeのfile数や行数を出したものですが
• #19: iosで約9万行、tvosで27000行、apiで3800行くらいですね
• #20: こちらはiosレポジトリのGitHubのinsightsになります
• #21: iosのレポジトリだと、これは9月19~ 10月19日の1ヶ月で162個のpull requestがマージされていて、営業で1日平均すると、、だいたい7~8個のpull requestがマージされています、 ちなみに一番右の全然commitしてないのはデザイナーで画像差し替えとか文言変更はデザイナーが対応してくれたりします
• #22: こちらはtvOSですが、おもに２人で開発していて
• #23: tvosのレポジトリだと、57個のpull requestが1ヶ月でマージされていて、営業で1日平均すると、、だいたい2~3個のpull requestがマージされています
• #24: こちらは共通のapiモジュールのレポジトリですが
• #25: こちらもちょくちょく変更がはいります
• #26: 何が言いたいかといいますと、まぁみんな仕事していますとw もとい毎日大量のコードが変更されていることがわかると思います
• #27: では、そういった開発をしているフローはどうなっているかというと、
• #28: こちらの図のような感じで、基本はスクラム開発でsprintを２週間に区切って開発しています。
• #29: もうちょっと細かくした図ですが、これは少し前に実践していたフローですが、 開発を二週間、QAを１週間で2週間ごとの申請でやっていました。 ただこれでやっていると問題がありまして、
• #30: ここの期間ですね。
• #31: 開発とQA期間の重複がつらいですと。 QA中にバグ対応などがお主に発生すると、次のsprintへの影響がもろにでてしまうのでこれは無理があるということで、
• #32: 改善しました。
• #33: 開発期間1週間、QA期間1週間という定義でやることにしました。 今のところこれでスムーズにいっています。
• #34: 長い開発はこのような形でsprintを跨いだ開発になります
• #35: 厳密に１週間/１週間にはならないときも、もちろんあるので、QA期間中から開発をはじめているものもあります。計画ミーティングごとに何をやるか決めますが、ある程度先のsprintの開発まで決めているのでこういった調整が容易になっています。
• #36: ではそもそもタスクはどうやって発生しているのかということですが、
• #37: パターン1として、、、、、いわゆるトップダウン的なものですね
• #38: パターン2は、、、、、といったボトムアップでタスク化することも多々あります。
• #39: ではどうやってタスクを見積もっているかということですが、
• #40: 一応タスクにストーリーポイントを付けています。1ポイントが軽微なもの、2ポイントが0.5スプリント、3ポイントが1スプリント、またはそれ以上といった定義しかしていません
• #41: ものすごいおおざっぱですねw この数値の付け方はスクラム開発だと変な定義だと思いますが、 AbemaTVは事業の流れによって案件の優先度がけっこう変わるので、ガチガチにポイントつけてSprintを回すのは向いてなくて、一人ひとりが今どれくらい案件を抱えていて、どのくらい重い開発をしているかを見える化する程度にしています。 ただここももう少しちゃんとポイント定義して回せるようにしていきたいと考えています
• #42: タスクの優先度定義ですが、
• #43: チケットを見ただけでこれは今回マストで入れないといけないのか、次に回してもいいのかエンジニアが判断できるようにしています。こういった共通言語の定義があることで、ディレクターなどとの会話がスムーズにいくといった利点もあります。
• #44: あと会議体ですが、
• #45: 大きく4つありまして、スプリント計画を行うスプリント計画ミーティング、スプリントの振り返りを行うスプリントレビュー、メンバー各自の案件ごとのミーティングとiOSチームの週一の定例をやっています。毎日の行うようなデイリースクラムはやっていません
• #46: あと使っているツールの紹介します
• #47: 使っているツールですが、いわゆる一般的なものでチャットツールのSlack、チケット管理にJIRA, ドキュメントツールにConfluenceとesa、ソースコード管理にGitHub、CI用にBitriseと自動化用にJenkinsとcmdshelfなどを使っています。
• #48: cmdshlefはオリジナルなので知らない人も多いかと思うので少し紹介すると
• #49: リモートリポジトリの実行可能ファイルをローカルファイルのように統合して扱えるようにするもので、iOSチームのトッシーさんという方がつくっていてSwift製です
• #50: こちら実際の例になります。
• #51: 最初の方でお話しましたが、iOSチームで管理している共通script置き場のcmdshelf-iosというレポジトリがあります
• #52: cmdshelfをinstallしてこのレポジトリをaddして、cmdshelf listを実行すると実行できるコマンド郡が表示されるようになります
• #53: listで表示されたものをcmdshelf runで実行できるといった形で、リモートのレポジトリのscript郡を手軽に使えてけっこう便利なものになります。
• #54: はい、次に開発スタイルですが、
• #55: こちらはContributing.mdのPullRequestsについての抜粋ですが、、、 といったルールも定義しています
• #56: これはPull Requestsのリストの抜粋ですが、ちょっと多いとか少ないとかの平均はわかりませんが、自分の経験上、けっこう活発なレビュー文化だと思います。
• #57: こちらはコーディング規約でGoodな書き方とBadの書き方というのを明示して、なるべくチーム内でコードの統一性を出すようにしています。
• #58: こちらはテストの実行結果ですが、現在2009ケースのテストがあり、極力テストは書くという方針ですすめています。ViewやViewControllerのテストはデザインや仕様も頻繁に変わる現状だとコストが大きいのと、ViewとModelを分離する設計にしているので、Viewのテストは書かなくてよい、Model層やロジックはテスト書くようにしましょうといった方針にしています。
• #59: 右の図はiOSの週一定例のシートですが、急ぎでないものは各自思いついた時に議題を入れてもらって、定例で結論を出してアクションしていくといったやり方をしています。あとはGitHubやSlack上での議論から開発ルールを更新していっています。
• #60: 次にブランチ戦略についてお話します
• #62: シンプルにこのような形になります。masterブランチがあってQA期間中はqaブランチを使うといったやり方にしています。
• #63: これにsprintの図を当てはめるとこのような感じです 左が仮でスプリント2.2.0、真ん中がスプリント2.3.0、右が2.4.0になります
• #64: 真ん中のスプリント2.3.0を例に見てみますと
• #65: 2.3.0の開発期間中はmasterブランチからトピックブランチを切ってmsterにプルリクしてmasterにマージします
• #66: 2.3.0のQA期間中はqaブランチからトピックブランチを切ってプルリクエスト、qaブランチにマージします
• #67: 2.3.0QA期間中のmasterブランチは2.4.0（次のversion)の開発ブランチになります
• #68: 2.3.0の申請が終わったらqaブランチをmasterにマージします。 ここは申請というよりは適時マージしているイメージになります
• #69: このブランチ戦略の良いところとしては、プルリクエストのmergeができないということがあまり発生しないということと、基本はGitHubフローでシンプルでわかりやすい点です。スクラム開発のsprintサイクルにうまくはまるのではないかと思います。
• #70: えー、Beta配信ということで、テスト用アプリの配信の自動化とフローについてです
• #71: 図のような感じになります
• #72: まず　Developerがプルリクエストします。
• #73: レビューを通ってmergeされると、bitriseがhookでjobを起動します
• #74: 対象ブランチは先程お話したmasterとqaを対象にしていて、Crashlyticsにuploadして、TesterやDesigner、Directorなどがすぐに確認できるようなっています。 あとはmasterとqa以外にqa-xxxxといった名前でブランチを上げると配信するようにしていて、特別なversionで何か確認してもらいたい時などにも配信できるようにしています
• #75: あとはQA期間中はTestFlightにも配信して、本番と同じ状態で確認できるようにしています
• #76: はい、あとはSlackの通知もいくつか自動化しているものを紹介します
• #77: いくつかピックアップしたいと思います
• #78: 左上はCocoaPodsのライブラリのアップデートある場合に〜通知しているものです
• #79: これは最新のqaビルドが配信されたよ〜といったお知らせで
• #80: Crashがけっこう起きてるよ〜といったお知らせ、
• #81: これは自前のbotですが、レビューがしばらくされてないプルリクエストがあるよとお知らせしているものです。
• #82: あとはp12の証明書が切れそうだよ〜とか
• #83: App Storeのレビュー評価
• #84: iOS11のbeta10でたよ〜といったAppleのRSSなどをSlackに通知しています。
• #85: はい、最後にQAの効率化についての取り組みについてです
• #86: 機能が多くなり複雑になってくると、QAの時間も比例して大きくなってきてしまいます。その効率化にも取り組んでいて、デバッグメニューを容易しています 現状のデバッグメニューの機能についていくつかピックアップすると
• #95: その他としてカンファレンスへの登壇や、チーム内でのランチ勉強会などを行うことによって直接だけでなく間接的に知見の共有になったりしています
• #97: はい、まとめです。AbemaTVは事業的に先を見据えたサービスなので、その場しのぎで開発していると長期的な開発のどこかで破綻してしまう可能性もあると思います。なのでAbemaTVのモバイル開発においても長期的な視点で、開発スピードとアプリの安定性、コードの品質を保った継続的な開発ができるように意欲的に取り組んでいます。 簡単になりますがまとめということで、発表を終わりにしたいと思います