AbemaTVとFRESH!の開発スタイル
司会者：ではAbemaTVの開発スタイルについて、大﨑さんからお話いただきます。よろしくお願いします。
（会場拍手）
大﨑浩崇氏（以下、大﨑）：それではAbemaTVの開発スタイルについて、僕から発表させていただきたいと思います。
まず、自己紹介からいきますね。大﨑と言います。
2015年4月から映像配信プラットフォームのFRESH!のサーバーサイドエンジニア兼スクラムマスターという肩書きで新規開発などを行った後、2016年5月から7月までは、AbemaTVの開発フローの改善サポートをやっていました。2016年8月からは、AbemaTVのフロントエンドエンジニアとして活動しています。なので、FRESH!の設計とAbemaTV、両方の開発に足を突っ込んでいることになっています。
あと自己紹介としてもう1つ、「engineer meeting podcast」というエンジニア系Podcastをやっています。2年前から、弊社の社内の人たちを見つけてゲストに呼んで、1時間くらいしゃべっているものです。一応2年くらいやっていて、深夜ラジオ系のIT Podcastを目指していこうかなと思っています。
今回のアジェンダですが、AbemaTVとFRESH!の開発スタイルについてお話ししたいと思います。これをベースに、FRESH!とAbemaTVそれぞれの適応についての話を進めていきます。
ただし前提として、今回（の発表内容は）自分が所属していた時期が中心になります。そのため、FRESH!の場合は新規の立ち上げ＋数ヶ月、AbemaTVに関してはリリース後の運用についての話になっています。
基本的に開発スタイルは、メンバーや時期によって変わってくるので、FRESH!の開発方法も自分が所属していた頃と比較して、現在は少し変化しているとは思います。
全員で認識を合わせてから、スプリントを回す
まずは、基本的な開発スタイルについてです。 ベースはスクラムです。最初に準備をして、ある程度なにをやるかが決まってきてからスプリントを回す、というのをどんどんくり返して、最終的にゴールを目指す感じでやっています。
スプリントを始める前の準備に関しては、『アジャイルサムライ』にあるインセプションデッキが元になっています。最初に、メンバーが集まってインセプションデッキを作り、メンバー全体でどういうサービスをつくるかコンセプトを決めることで、目標の認識合わせをします。
例えば、FRESH!の場合、プロジェクトの立ち上がりが2015年4月1日で、2日と3日の2日間に分けて、インセプションデッキをひと通り話し合いながら作成しました。
インセプションデッキについて、くわしくは『アジャイルサムライ』の本をご覧いただければと思っています。その本の中では「コンセプトイメージ、ポスターを作る」という肩書になっているのかな？
「最初にコンセプトイメージを話し合いながら作っていこう」ということで、（スライド）この右側にあるのが、最初のFRESH!のもととなるコンセプトの画像です。このタイミングで、ざっくりと「12月頭にリリース」という見積もりを出しました。
結果的にはちょっとした方向転換はありましたが、2016年1月21日にリリースできました。今のFRESH!とこの画像を見ていただけると、なんとなくイメージが少し暗めで、雰囲気も合っている感じがしています。
最初に準備をして、その次にスプリントを回していきます。スプリントは、タイムボックスを2週間くらいの区切りにして、最初にスプリント計画ミーティング実施して、タスクの優先度決めや見積もりを行い、そこからスプリント内でやるべきタスクを計画します。
スプリント期間中は毎日15分くらいデイリースクラムを行って、チームの状況を確認します。いわゆる、朝会ですね。スプリントのレビューでは、成果や改善点などを確認します。
それが終わった後に、スプリントでの問題点や改善を「チームの振り返り」というかたちで行っていくフェーズになっています。
これは、よく使っているツールですね。チャットツールはSlack、チケット管理でJIRA、WikiでConfluence。同じくWikiでesa。ソースコード関連はGitHubを使っていたり、CIではCircleCI、Jenkinsも一部使っています。
あとはCodecovでプルリクのカバレッジの自動化……プルリクを送ったあとにカバレッジが自動的にコメントにつくというやつですね。これをやっています。最近は、asanaというガントチャートを使っていました。
今回に関しては、ツールの話は時間の都合で省略させていただきます。参考記事があるので、気になる方はそれをご覧いただければと思います。
スクラムは、チームの人数に適用させる
これまでお話してきた、いわゆる『アジャイルサムライ』などのスクラムの本に書いてあることをベースにしてるんですけれど、それをそのまま各プロジェクトに適用するのは難しいかもしれません。
なぜかというと、組織やチームの特性、個人、プロジェクトの置かれている状況などいろいろ（要因が）あるからなんですね。単純に本などで「スクラムがいいらしいぞ」と思って急に入ると、メンバーによっては拒絶されたり、乗り気でなかったりすることがあります。すでにあるルールや文化をうまく見ながら、適切なプラクティスを入れていくことが必要です。
スクラムをやろうと思ったとき、まず考えるものとして「チームの人数に適用する」があります。
今回のFRESH!とAbemaTVの場合。FRESH!は、開発進行中の人数が20人前後。開発以外では、ディレクターやプロデューサー、関係者を含めて10人前後でした。
AbemaTVでは、開発が30人以上。開発以外でAbemaTVのプロジェクトに関わっている人はかなり多く、コンテンツの調達や編成、番組制作担当といったものをすべて含めると、その規模は桁が違う感じになっています。
スクラムチームは10人……15人いればいいと思われるところですが、FRESH!やAbemaTV規模のプロジェクト人数では、プロジェクト全体でのスクラム開発は厳しいです。
FRESH!では、プロジェクト全体を「役割」で分割しました。サーバー、フロント、デザイナー、iOS、Android……という分け方をしていて、それぞれでスクラムチームとしてバックログを持っているかたちになっています。
そのバックログを作るため、各役割ごとのリーダーとプロデューサーが入って「だいたい、こういうことを、この時期にやりたいよね」というのを「board」で意識合わせをします。そして、boardの下にあるサーバー、フロント、デザイナー、iOS、Androidチームが優先順位を決めて実行していきました。
しかし、これがAbemaTVになると、人数が多すぎて管理が難しくなります。AbemaTVの場合は、横に「Project」というものを新しく作って、そこでも管理をしています。
縦にあるサーバー、フロント、デザインなどの役割に分けた場合、例えばサーバーに10〜15人など増えてくると、横の連携が弱くなります。やはり、サーバーやデザイナーとアプリチームがすぐに会話できるほうが、開発の効率がよかったりします。サーバーとフロントでAPI設計するときも、コミュニケーションコストをできるだけ下げたい気持ちもあります。
そこで、ある機能については「サーバー側の◯◯さん」と「フロント側の◯◯さん」を横に並べて、各機能ごとのプロジェクトを作りました。
「FRESH! 縦から横事件」が勃発
次に「状況に適応する」ということが大切です。ベースがスクラム開発とはいえ、スプリントを回すことばかりやっているわけではなく、状況によってガントチャートをひいて、スケジュールドリブンになったりすることもあります。それが、FRESH！の2015年11月頃の話です。
もともとFRESH!のリリース予定は昨年12月前半だったんですが、リリース予定の1か月前に急きょ縦デザインから横デザインに仕様を変更するというけっこう驚きの仕様変更を行うことになりました。
（会場笑）
「FRESH! 縦から横事件」なんですけれど。
（会場笑）
リリースの残り2スプリントで、これが決まりました。「どうしようか」となりながら、当初予定していた機能のリリーススコープはまだ一部分終わっていませんでしたが、それは全部外して……横対応に注力しました。そして、リリース日は基本的には変えないでいくことにしました。
これにはまず、最初にコミュニケーションをきちんととりました。「横デザインになると、どこが変わるんだっけ」をきちんと把握しないといけない。そのため、「デザインスプリント」と言われる手法を使って、最初に「どういうものをつくるのか」をデザイナーとアプリチームで半日ぐらい合宿して、ゴールの認識統一をしました。
そのあとは、もうクリティカルパスだけ。「いつまでに開発が完了していなきゃいけないよ」「そこからテストがこれだけかかりますよ」「リリースまでのこれがありますよ」「バッファーどれぐらいですよ」という、シンプルなガントチャートにして、あとはメンバーに任せる、がんばってもらう感じのことをやりました。
結果的に、開発は年内に終わったんですけれども、社内外の様々な調整も含めた結果、無事翌年1月にリリースしました。
FRESH!とAbemaTV、それぞれ落とし込み方が違う
次は「チームの考え方に適応する」です。チームも、人や個人と同じように、時と場合によって思考が変わります。
FRESH!チームとAbemaTVチームのどちらにも関わっていたので、それぞれで感じるところがありました。
FRESH!チームは、開発者自らで課題をみつけた上で、仕様を落とし込みたいという志向がすごく強いんですね。AbemaTVでは、ディレクター・プランナーが落とし込んでから開発に着手したい、という志向が若干強いように感じます。
というのも、関係者が多いので、そちらのほうが手戻りが少なかったりします。人が増えると「まとめる力」が必要になるので、効率がいいし、現実的にこうならざるをえないところもあったりして。
FRESH!の場合、自分たちで課題見つけて解析し、どういうものをやるかを決めて実装していきたいという感じでした。解析担当と計測の結果やGAなどを見ながら、KPIと呼ばれる指標に対して「どこを直したら、この数字が上がるか」というのを開発メンバー全員で考えながら、施策を出す会を設けたりしました。
その結果がGAで反映されて「これよかったね」「これはあまり変わらなかったね」と検証しながら、どんどん開発を進めていきました。
ただ、開発者目線だけだとKPIの単純な数字を上げるのはけっこう難しいです。たとえばMAUを上げるためには、単純にデザインがよければいいわけではありません。ちょっと思考として難しいので、非エンジニアといいますか、プランナーといった人の協力を得ながらやっていく感じになります。
メンバー間の目線合わせとしての「人事評価制度」
次に「人に適用する」ですね。
やはりチームにもタイプがあるんですけれど、開発者各個人でなにを重要課題としているかはさまざまです。チューニング寄りの人、かっこいいサービスを作りたい人、UX寄りの人、数字目線の人、あとは技術目線の人など。これを全部1つにまとめるのは大変ですし、あまりそこにコストをかけるのは……というところがあるので、「チームメンバーの目線をどこに合わせるのか」は難しい問題です。
AbemaTVでは、1つ目線を合わせるものとして「人事の評価制度」の意味付けをしていました。
今、評価制度はS1〜S6までありますが、左側の2つ、「S6」「グレード制度自体」は、サイバーエージェントの制度として元からあるものですが、AbemaTVでの意味付けをきちんと明確化しています。
色々な会社でグレード制を設けているところがあると思うんですけど。弊社ではS6にもなってくると、実績に加えて「ロールモデルになりえるか」という点も踏まえて、「皆のロールモデルになれるように頑張ってね」という意味づけをしています。
この制度の注目ポイントは、「自走できる」ですね。弊社の企業文化として、まず「自走できるエンジニアになる」というのが大きな目標としてあります。
自走のラインに「S3.5」があるんですけども、それに対しては「実現したいこと、曖昧な案件に対しても、仕事詰めやスケジュール調整も含めて自身で取り組み、無事にリリースまでもっていける」という定義付けをしています。
「S3.5」は、まずは若手のエンジニアはここを目指してほしい、という一定の基準です。「曖昧な案件でも」なので、自分でどんどん提案していくエンジニアになってほしいというところが、会社からのメッセージですね。
ここでいう「自走できる人」は、権限が与えられます。今まで弊社で次々と新たな技術に挑戦できたのは、「自走できるエンジニアにどんどん任せちゃえ」が文化として浸透しているからなんですね。自走できて権限を持っていれば、新しい技術分野にチャレンジすることも、弊社の文化として深く根付いています。
自走については、もう1つあります。今までJIRAのチケット管理やRedmineなど、いろいろなタスク管理ツールを使っていましたが、今はSlackというすごく便利なツールがあるご時世ですよね。
大きな機能開発に関しては、きちんとしたフローで計画しますし、その仕様共有を関係者みんなで行うのは当然ですが、正直なところ、お願いしたい人がSlackで「これを実装してよ」と言い、開発者側がリソースなどを確認し「これならすぐできるよね」「じゃ、次のリリースまでに入れておきます」という流れになれば、すぐに（そのタスクは）終わってしまいます。これが、自走できるエンジニアの立ち振舞いとしては理想だと考えています。
自走できるエンジニアは、勝手に課題を見つけて対応します。本当に自走できるエンジニアですごい人というのは、「困ったよ」と言ったら「実はこれ、もうできてるんですよ」みたいなことが往々にしてあるんですね。
そういった人は我々のチームにもいるんですけれども、そうなると、逆にスクラムで計画しようとすると、個人のパフォーマンスを出しきれない可能性があるんですね。マネジメントして統率をとって動くよりも、本当に自走できる人を立ててどんどん進んでもらうことをやったほうが、開発は進みやすいです。
あえて属人化し、あとからチームに共有する
AbemaTVでは、自走している人を集めています。メンバーに裁量権を与えて、最大限に能力を発揮できる環境を用意しています。そのためリモート開発も積極的に取り入れています。
図にするとこんな感じですね。
個人スキルを高めてもらうのは当たり前として、マネジメントコストが高い人に関しても、チーム開発の認識の共有とか開発効率底上げのプラクティスを利用しながら、だんだんと右上のほうで管理マネジメントコストも下げつつ、個人のスキルを伸ばすとともに、チームとしてどんどん新しい機能の開発やプロダクト改善を進めていく。そんなチームに進化させていこうというのが、今のAbemaTVの開発スタイルになっています。
そのため、AbemaTVでは、一般的なスプリントからいくつか省略している部分もあるんです。
例えば見積もりも、実はもう各チームにやる・やらないをお任せしています。デイリースクラム（朝会）も、チームにお任せして省いています。スプリントレビューも時間の関係でけっこう切り捨ていて、情報の共有などをしています。そういったスプリントのよくあるプラクティスも削って、少しでも開発に集中できる環境をきちんと作っていくことをやっているところです。
最後に1つだけ、デメリットについて挙げるとすると、個人に依存するので、属人化してしまいがち、という点です。
組織としては属人化ってあまり良くないのかもしれませんが、AbemaTVもFRESH!も、開発スピードを落とすよりも、まずはあえて属人化させた状態で開発を進めて、あとからチームに共有する体制のほうが文化として根付いています。情報の共有ために、チーム内の勉強会などをして、積極的に各メンバーが学習していくことも、活動として行っています。
最後にまとめですね。まとめとしてはAbemaTV、FRESH!の開発スタイルのベースはスクラム開発です。ただ、人数やチームの性質・状況によっては固執せずに、柔軟にやり方を変えています。
企業文化としては、自立できている人に権限を付与することで、大きく活躍できるような体制になっています。そして、まだ自立できていない人については、勉強会で教えるなどしてカバーし、底上げを狙っています。
ダーッとしゃべってしまいましたが、以上になります。備考としては、スライドに書いてあるものが参考になればと思います。ありがとうございました。
（会場拍手）
周りの人を説得できる自走が理想
司会者：ありがとうございました。では、質疑応答の時間に移らせていただきます。なにかご質問ある方、いらっしゃいますか？
質問者1：お話ありがとうございます。自走というものにすごく興味と共感を持ったんですけれども。マネジメント層から見た自走するエンジニアですが、例えば、自走するとなると、自分でやるから、先ほどお話していたように属人的になるかと思います。
自走するエンジニアをマネジメントする側に対して、なにか注意してほしいことや気をつけてほしいことなどあれば教えていただきたいなと思います。
大﨑：質問ありがとうございます。まず自走と言いましても、やはりエンジニアなので、自分がなにをやっているか、その理由をきちんと説明できる必要はあると思うんですね。
それが論理的に適っているのであれば、自走して自分が考えた「これやるぞ」があったとしても、ほかのエンジニアをきちんと説得できるようになってるはずなんですよね。
やはり思いつきでやるというよりは、「きちんと論理を立てて、周りの人を説得できるような自走の仕方」が望ましいのかなとは思います。
質問者1：それをちゃんと説明して、進めて……という感じで？
大﨑：そうですね。だから現状の弊社の開発現場で、自走しているエンジニアに対して周りの人がとやかく言うというのは、あまりないですね。
質問者1：わかりました。ありがとうございます。
質問者2：最初のほうに使っていらっしゃるツールの話があったと思うんですけど。ｗikiが2つ、Confluenceとesaを使っていらっしゃるというお話だったんですけど、それはどういう基準で使い分けていたりするんですか。チームごとに違う感じなのでしょうか？
大﨑：もともとは、esaが中心でした。というのも、開発側はマークダウンを書くのが好きといいますか、馴染みがあるので、esaを中心に書いていたんです。
一方ディレクターが仕様書を作成するときは、画像・スクリーンショットや、デザインのPDFの貼り付けを行うので、wikiにまとめるには、Confluenceのほうがリッチなエディターで見やすく編集しやすかったんです。使い分けとしては、esaは開発ドキュメント、Confluenceは仕様書のまとめですね。
質問者2：ありがとうございます。
司会者：ありがとうございました。では、発表は以上とさせていたきます。大﨑さん、ありがとうございました。
（会場拍手）
