AbemaTV iOS開発チームの服部です。

私はIT業界に入り10数年経ちます。

昨年までは、昼は会社員としてiOSアプリを開発しつつ夜や週末はスタートアップ企業に技術協力したりハッカソンに出たりしていました。
ご縁を頂き、2017年2月にAbemaTVに中途入社しこの5月で早3ヶ月になりました。

入社後は主にビデオオンデマンド機能のAbemaビデオ開発担当になり、キャッチアップ、実装、リリースで怒涛の日々。

1000万ダウンロードを超えるアプリの開発チームに中途で入るということで正直少し不安でした。
が、実際のところ、とても働きやすく、凄腕のメンバーに囲まれエンジニアとしても滅茶苦茶成長できる環境でした！

あと30代後半エンジニアもまだまだ伸びしろありますよ。と言いたい！
(ちなみに別チームですが現役凄腕40代エンジニアもおります)

アプリの規模感や内容的にも国内では珍しく、なかなか得難い経験をしていると思います。
そんな情報を共有したいと思います。

そもそもAbemaTVとは

サイバーエージェントとテレビ朝日の出資により設立された株式会社AbemaTVが運営中のインターネットテレビサービスです。
ブラウザで視聴できる他、iOS、Android、AppleTVのネイティブアプリがあります。
Chromecast等を使用するとテレビの大画面で見ることもできます。

ユーザ登録不要。基本無料。

Web版はこちら。
iOSアプリはこちら。
Androidアプリはこちら。

ゴールデンウィーク期間には多数の利用ありがとうございました。
たくさんの方に利用してもらい嬉しいです。
楽しんで使って頂いている方に素晴らしい体験を提供できるよう今後も頑張っていきます。

最近の私のおすすめはDocumentaryチャンネルの名車再生！シリーズです。
物を直したり作る系のコンテンツがツボ。

技術スタック

以下のアーキテクチャ、技術、サービスを使っています。一部です。

実装

Swift
Flux
RxSwift
Protocol Buffer
SwiftGen

デザイン、運用周り

Github
Jenkins
Slack
JIRA
Confluence
esa
Sketch

Objective-cは未使用。

Githubを使ったプルリクエストとレビューを主体としたスタイルです。
平時は2週間のスプリント。

テキスト文言と画像リソースの扱いにはSwiftGenを使用。
Storyboardと画面は1対1で作成。コードでインスタンス生成し画面遷移。
どちらもテキスト直指定での生成箇所を極力減らす形。
ランタイム時ではなく実装・ビルド時にエラーを見つけたい。

RxSwiftに加えてReactiveCocoa/ReactiveSwiftの機能を一部輸入したりしています。

日々改善がなされていて、上記も変化していっています。

最近ではテストとCI周りの安定化・高速化がhotです。
私はそのあたりの知見が殆どないのですが、変更内容を後追いで理解進めています。

AbemaTV開発の特徴

1. ディレクター職

プラットフォームをまたいでサービスを提供することもあり、ディレクター職が設けられています。

iOS版に加えてAndroid版、Web版もあり、さらに番組編成も関わってくるため、その開発を統括する役割を担っています。
機能や文言や画面構成の調整をし仕様を固めていきます。

ここできっちり仕様を詰めてもらえるので非常に助かります。

逆にiOS固有の機能であったり制限であったりは、こちらから積極的にディレクターに共有する義務があると思っています。

他にも進捗確認や資料作成や打ち合わせ設定などなど。

海千山千の年長者が担当と思いきや、新卒2年目、3年目の若手の方が中心。
スピード感を持って大変な職務をこなしており凄いと思います。まじで。

2. 会議は最小限

会議は最少人数で時間通りに終わるという文化があります。

少なくとも私が参加せねばならない会議は殆どありません。
担当機能について関係するメンバーが集められてのオリエンテーションくらい。
その後の細かいやり取りはSlack上で行うか、席まで直接行って相談します。

また資料も共有資料を大画面に映しながら、リアルタイムで編集。
会議前に”人数分印刷して冊子作成”などはありません。
会議終了時にはアクションと担当が決定。
こうあるべき。好き。

3. オープンな情報共有

基本的に開発資料はすべて共有されています。
それに加え、資料作成時のやり取りもSlack上で行われており、リアルタイムで追うことができます。

例えば、社長会議の前には、デザイナチームが画面構成改善の叩き台を作り、意見が出されてブラッシュアップされ、開発局としてのこれで提案しますーというやり取りと資料が流れていました。意見や質問があれば適宜コメントできます。

機能実装の優先度が、リリース後の数値やビジネス上の判断でダイナミックに変わったりします。
下調べ済部分が後回しになったり、後回しとしていた内容が最優先になったり。

その時に上記のようなやり取りの流れを把握していると、実装担当としての納得感が違いますね。

ディレクターから実装担当者へ経緯を説明する手間も省けるし「え、なんで急にこの機能実装することになったの、そもそも必要ある？」の事故が減ります。

チームの空気: 心理的安全性を重んじる

チームの空気が大切にされていると感じました。
つまりは心理的安全性です。

新人としてもそうだと思いますが、中途でのチーム加入時の難しさがありますよね。

いくら幾許かの経験があるとはいえ使ったことがないツールの使い方は知らない。
とは言え、あまりに知らな過ぎると「この人大丈夫かなー」と周りを不安にさせてしまう。

質問したいけれど、聞いたら
「服部さんあの程度の事も知らないなんて」
「あれれ、質問から察するに、全然分かってなさそうだな」
と思われそうで。

ここでチームのマインドとして心理的安全性があったので、質問しやすい空気がありました。

心の支えとなったのがリーダーの姿勢でした。(正確な聞き起こしではないですが)
「ここにいる人は皆このサービスを良くしたいという気持ちがある。そのために皆で何ができるかだから」

知らなかったら恥ずかしいとか
ぶっちゃけそんな気持ちだらけなのですが
「自分が知らないならば他の人も知らないかも」
という言葉を胸に置くと楽になります。

メモを残して資料化したら自分の後に来るメンバーの役に立つはず。
そんなマインドセットだと気持ちがやや楽になりますしチームにも貢献できます。

もちろん、聞きやすい空気に甘えるだけではなく自ら意識して行動したこともありました。
基本的な事に思えるかもしれませんが、書き出してみます。

事前に使用技術をヒアリングし、サンプルを動作させたり手を動かしておく
マニュアル、資料には必ず一度目を通しておく
今やっていること、これからやろうとすることをこちらから相談しズレをなくす
即時に調べあたりをつけ、聞きやすい時間に聞く
抱え込まない
抱え込んだ感があったら正直に相談する

お互い困るのは、抱え込んで相談できなくなるパターン。
一度抱え込むと、”まずい、これだけ時間掛けたのだから挽回せねば”とハードルが高まっていきます。
過去、こういった失敗を何度かしてきたので、今回は特に意識しました。

幸いにも転職前に1ヶ月程休みが取れたので、群馬に一人開発合宿に行ったり、コワーキングスペースでポチポチとRxSwiftのサンプルを動かしたり、事前に公開されている資料を読んだりしました。
外部公開されている資料は全て目を通しました。

AbemaTV Developer Conference 2016 イベントレポート
 CA.swift #1 レポート
 CA.swift #2

結局現場に入ってソースを読み、動かさないと分からないことも多かったのですが
やっておいたことでキーワードや概念が頭に残り、理解の速度が早まりましたし、何よりも、資料に目を通しておくことで質問しやすくなりました。
これだけやって分からないのだから聞いても良いさ、と。

チーム人数が多いが故の苦労

iOSエンジニアチームは一番多いタイミングで最大11人になりました。
その人数で1つのアプリを作成した事がなかったので、そこでの作業は得難い経験。

皆の知見が持ち寄れ、機能単位で分担し、開発のスピード感が増す利点がありました。
一方、CI環境のテスト完了待ち、rebaseで死にそう、全員のソースレビューすることが時間的に難しい、といった難点も。

通常2,3件のプルリクエストレビュー待ちだった状態が、20件以上レビュー待ちとなってしまったり。

「あまりメンテされてないOSS人気リポジトリみたいっすね」
という発言もあって空笑いが起こったり。

現在はビルド、テスト時間共に大幅に改善され問題は解消されました。

海外ではiOSエンジニアだけで100人規模のチームの話もあるようで、そのあたりの運用が興味深いです。

余談: 私のスタートダッシュ方法

加入後1.5ヶ月くらいまでは、たとえ初歩的な事でも聞ける魔法の期間だと思っていて、開発のお作法や使っているツールや実装スタイルなどなど、勢いをつけて現場での常識を把握していきます。

iOSのプロジェクトだとして以下を確認。
資料があればそれを読みます。

システム構成
開発フロー
チケット(管理用ツール、ステータス変更方針、コメント書き方)
ライブラリ管理ツール(CocoaPods/Carthage、使用ライブラリ、取得元)
コミット(merge/rebase、粒度、コミットコメントの書き方)
アーキテクチャ

ソース読み込み

アーキテクチャと実装を往復し、デバッグ実行しながら動作を確認。
すべてに目を通す時間は無いので、あくまで全体の流れの把握のためです。

フォルダ構成
API通信(ネットワーク)関連のうち2つ程度
データ永続化・DB関連
定数クラス
AppDelegate内処理

あとは以下を口頭で聞いてしまいます。

Storyboardを使用するのか
xibを使用するのか
ソースコード内でのUI部品生成は積極的なのか限定的なのか
画面遷移はSegueで行うのかコードで行うのか
ViewやViewControllerが継承を是とするのか否か
エラー処理方針
ログ方針
開発環境と本番環境の分岐方法

ここまで一気にやって一安心する、的な。

最後に

ざっくりとAbemaTVの開発について、エンジニア目線から書き出してみました。

AbemaTV行動指針のエントリでも言及されていますが
「能力の高さより一緒に働きたい人を集める。」とあります。

心理的安全性があり知見を高め共有し合えるチームが理想的ですね。

今現在、周りの達人たちの知見を吸収するのに必死です。受け取っている物の方が多い感覚。
今後はよりチームに貢献し最高のサービスにしていきたい。

p.s.

入社後の1ヶ月時点ではCA.swiftにてこんな内容で話をしていました。
中途入社でAbemaTV iOS 開発チームに入り1ヶ月実際どうだったのか

Storyboard周りの実装パターンはこちらの本にまとまっています。
同じチームで働く鈴木大貴氏がその章を執筆。
モバイルアプリ開発エキスパート養成読本

Unityにおける通信APIを色々試して罠を踏んだ話

短期間でネイティブアプリ開発のノウハウを学ぶ合宿「ネイティブートキャンプ」〜Android編〜

AbemaTVに入社して3ヶ月経ちました

目次