Pocochaエンジニアチームが挑戦してきた課題とそこから生まれた価値観【DeNA TechCon 2021 Summer】/techcon2021summer-07

Slide 1

Slide 1 text

Pocochaエンジニアチームが挑戦してきた課題とそこから生まれた価値観荻　栄輔

Slide 2

Slide 2 text

自己紹介荻栄輔 / Eisuke Ogi ライブストリーミング事業本部Pococha事業部システム部副部長経歴・SIer、ベンチャー、スタートアップを経て、2014年DeNAに入社・複数の新規事業の立ち上げとクロージングを繰り返す・Pocochaにはイベント機能開発担当として2018年にジョイン・現在は主にマネジメントに従事

Slide 3

Slide 3 text

はじめにお伝えしておきたいこと

Slide 4

Slide 4 text

本発表では、Pocochaエンジニアチームが事業成長とともに直面してきた課題についてお話します。それらの課題はサービスの成長過程でありがちなものもあるかもしれません。しかし、そういった当たり前と思えるようなことでも、実体験を通してチームにシェアしたところ、一人ひとりの価値観の違いなど新たな気づきが得られたのでご紹介します。

Slide 5

Slide 5 text

発表の流れ 1章. 現在のエンジニアチーム 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有

Slide 6

Slide 6 text

Pocochaとは・2017年にサービスが開始したライブ配信アプリ・配信をするライバーと、コメントやアイテムで応援するリスナーの双方向コミュニケーション

Slide 7

Slide 7 text

Slide 8

Slide 8 text

現在のエンジニアチーム・Pocochaチーム全体の人数が約100名超・そのうち40名程度がエンジニア　Server：5割、iOS、Android、WebFront：5割・チーム外でもPococha担当として協力してもらっているメンバーもいる　infra、AI：10名程度

Slide 9

Slide 9 text

「エンジニア40人もいるの？大規模な組織なんだろうな…」

Slide 10

Slide 10 text

大規模な組織のイメージ・縦割りで決められたことを繰り返すだけ・お行儀よくてつまらない・自分の裁量が小さい etc...

Slide 11

Slide 11 text

実際のところは？

Slide 12

Slide 12 text

エンジニアチームの構成それぞれの専門領域をもったメンバーが大きなミッション単位のチームに所属し、施策毎にエンジニア1,2名で動くことが多い・プロダクトチーム（Pocochaの土台となる機能の開発）　Server、iOS、Android、WebFront ・イベントチーム（Pococha内で開催するイベントの開発）　Server、WebFront 　　　　　　　　　　　　　　　…これら以外にも複数のチームがある

Slide 13

Slide 13 text

Slide 14

Slide 14 text

一般的なスタートアップチームのように多くのメンバーが裁量を持って自発的に動けています！

Slide 15

Slide 15 text

一般的なスタートアップチームのように多くのメンバーが裁量を持って自発的に動けています！が…、さすがに40人にもなると、それぞれが自発的に動くためには考え方の軸になるものがないといけない

Slide 16

Slide 16 text

軸がないと… ・みんなが向いている方向がバラバラになってチーム崩壊・頑張ったのに「それ違くない？」って言われて評価されない・目指しているものが違うから議論が進まない etc...

Slide 17

Slide 17 text

なので、軸を定めました。

Slide 18

Slide 18 text

エンジニアチームで大切にしている価値観エンジニア一人ひとりが、 “サービスに何が必要かを理解して、それだけに向かってリーンに動く” “サービスをスケールさせ、　　　日本で世界で利用者に選ばれることを想定して技術課題解決に動く”

Slide 19

Slide 19 text

エンジニアチームで大切にしている価値観チームによっても独自に定義プロダクトチーム “対峙している領域の戦略や目的を理解した上で、今、本当に必要なものをリーンに作る” “常にユーザーの視点に立ち、自身がサービスを楽しみ、熱中する” イベントチーム “個に依存することなく、脱属人化に向けた工夫をする” “ミスを恐れず、担当するエンジニア領域の垣根を越えて自発的に触りに行き、最後までやり切る”

Slide 20

Slide 20 text

まとめ：1章. 現在のエンジニアチーム・エンジニアチームは約40名と結構多い・とはいえ、各チームや施策ごとに数名担当なので、　行動単位で見ると大規模なチームではない・各々が自発的に行動しており、　そのための軸（価値観）を定義している

Slide 21

Slide 21 text

これ以降の章では、・こういった価値観がどういった背景で生まれたものなのか・その時、どうやって価値観を共有してきたのかといったことを、サービス立ち上げ当初から振り返りながらご紹介していきます。

Slide 22

Slide 22 text

発表の流れ 1章. 現在のPocochaエンジニアチームについて 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有 6章. まとめ

Slide 23

Slide 23 text

サービス立ち上げ当初・DeNAの中に新規事業部署（スタートアップ村）があり、　Pocochaはその中で生まれたひとつ・事業起案者1人、エンジニア2人、デザイナー1人の4人でスタート・利用者の熱量の増大が確認されれば追加投資、　増大していなければクローズという環境を生き抜いてきた

Slide 24

Slide 24 text

仮説検証を進めていき… リリースされてから1年（今から3年半ほど前）・サービス利用者は多くないが確かな熱量を感じられる・チームメンバーは全体で10人超え・エンジニアは5人程度主要機能のひとつ「イベント」が生まれる・当時担当していたエンジニアは2名　Server：1、WebFront：1

Slide 25

Slide 25 text

イベントとは？期間限定で開かれる特別な催し物ランキングイベント　・リスナーのアクティビティ（コメントやアイテム使用等）に応じたポイント　　で順位を競う　・入賞者には様々な景品や権利が与えられるミッションイベント　・与えられたお題をリスナーと一緒にクリアしていく　　・「あけおめ！と19回いってもらおう」　・コイン（アプリ内通貨）がもらえる

Slide 26

Slide 26 text

この頃の状況荒れ地を手探りで進んでいく・12月になってからクリスマスのイベントをやりたいという話が出てくる　（もちろん作る）・イベントリリース5日前に技術的な問題が見つかっていちから作り直し、　そこから3日間で作ってリリース・イベント開催中に不具合が見つかって深夜の調査対応

Slide 27

Slide 27 text

この頃の状況イベント機能の開発について　・流用することを重視しない設計　・過去開催したイベントから流用できるコードは手動でコピペ　・毎回デザインが微妙に異なるため、地道にhtmlとcssを書く　・動作検証は全て自ら実施　・イベント終了後の集計作業といったことも半分は手作業月1本のイベントを開発する度にとにかく泥臭い作業

Slide 28

Slide 28 text

この頃の状況なぜ泥臭いことをしていたのか？　イベントという新機能が利用者に受けいれられるか、　また、Pocochaに必要なものなのかということを確かめるフェーズだった。　そのため、いかに早く仮説検証を回すかということが重視されていた。丁寧に作っても利用者に受け入れられなければ廃棄される運命。もちろん少ない時間で最適な設計やコードを書ける場合はそれがベスト。しかし、そんな実力は持ち合わせていなかったので、一番早く確実に実現できる形で動いていた。

Slide 29

Slide 29 text

仮説検証サイクルを高速にするためにエンジニアは単純に早く開発するだけではなく、企画者と同等に仮説検証に必要なものをジャッジする役目を担う。結果として厳しい要求やスケジュールになったとしても、企画者の言うことに振り回されているわけではなく、納得したうえで行動する。（振り回されることもあるけど）

Slide 30

Slide 30 text

こういった経験を価値観として言葉にしてみました。

Slide 31

Slide 31 text

こういった経験を価値観として言葉にしてみました。 “企画の真意を理解し、同じ目的意識を持った上で、双方が納得できるアウトプットを模索する”

Slide 32

Slide 32 text

仮説検証サイクルを高速にするためにエンジニアは単純に早く開発するだけではなく、企画者と同等に仮説検証に必要なものをジャッジする役目を担う。結果として厳しい要求やスケジュールになったとしても、企画者の言うことに振り回されているわけではなく、納得したうえで行動する。（振り回されることもあるけど）この頃は人数も少なく、ほとんどのエンジニアが新規事業立ち上げ経験者だったこともあってか、自然と同じアプローチをとっていた。

Slide 33

Slide 33 text

まとめ：2章. サービス立ち上げ当初・立ち上げ当初は生き残るために仮説検証をとにかく早いサイクルで　回すことが重視されていた・エンジニアは、企画者と同等に必要なものをジャッジする役割を担っている・この頃は特に意識しなくとも、みんなが向いている方向を　揃えることができていた（純度が高かった）

Slide 34

Slide 34 text

発表の流れ 1章. 現在のPocochaエンジニアチームについて 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有

Slide 35

Slide 35 text

仮説検証を繰り返す中でそれから半年ほど経過（今から3年ほど前）・イベントは利用者に受けいれられて根本の仮説検証は済んだ・Pocochaの利用者はだんだん増えてきた・エンジニア全体で10人程度　イベント機能担当エンジニアは4人程度

Slide 36

Slide 36 text

仮説検証を繰り返す中でそれから半年ほど経過（今から3年ほど前）・イベントは利用者に受けいれられて根本の仮説検証は済んだ・Pocochaの利用者はだんだん増えてきた・エンジニア全体で10人程度　イベント機能担当エンジニアは4人程度ここからさらに数カ月後のある日… 「毎月たくさんのイベントを提供したい！」　　　　　　　　　　　　　　と言われることになる

Slide 37

Slide 37 text

どうするか？・エンジニアを増やす？・頑張って一人あたりが開発できるイベント本数を増やす？

Slide 38

Slide 38 text

どうするか？・エンジニアを増やす？　→そんなにすぐにエンジニアは採用できない・頑張って一人あたりが開発できるイベント本数を増やす？　→能力によって品質に差が出てしまう

Slide 39

Slide 39 text

どうするか？・エンジニアを増やす？　→そんなにすぐにエンジニアは採用できない・頑張って一人あたりが開発できるイベント本数を増やす？　→能力によって品質に差が出てしまうそもそもマンパワーで解決しても、またすぐに頭打ちするのが見えている

Slide 40

Slide 40 text

イベントを効率よく開発するための仕組み化が必要

Slide 41

Slide 41 text

解決すべき課題とアプローチ・オペレーションの効率化・エンジニア工数の削減・品質の維持

Slide 42

Slide 42 text

解決すべき課題とアプローチ・オペレーションの効率化　→企画書及び仕様書の整備・エンジニア工数の削減　→少しのエンジニア工数でイベントが作れてしまうシステム、フローを実現・品質の維持　→QAの体制構築

Slide 43

Slide 43 text

解決すべき課題とアプローチ・オペレーションの効率化　→企画書及び仕様書の整備・エンジニア工数の削減　→少しのエンジニア工数でイベントが作れてしまうシステム、フローを実現・品質の維持　→QAの体制構築いきなりこんなことやろうとすると数ヶ月くらいかかる。

Slide 44

Slide 44 text

解決すべき課題とアプローチ実は企画から要望がでる前にすでに仕組みが整っていた。少し前にゲーム事業部から異動してきたエンジニアがいつのまにか進めていた。

Slide 45

Slide 45 text

解決すべき課題とアプローチ実は企画から要望がでる前にすでに仕組みが整っていた。少し前にゲーム事業部から異動してきたエンジニアがいつのまにか進めていた。目の前のことに必死で気がつけていなかったが、いつの間にか「仕組み化」が必要なフェーズに足を踏み込んでいた。

Slide 46

Slide 46 text

解決すべき課題とアプローチ当時どうしてそんな対応がとれたのか聞いてみると… 　・ゲーム事業部での経験があったのが第一で、構造的にPococha 　　にも当て込むことができると思った　・自分でイベントを作ったときにしんどかったのでもう嫌だと思った　・将来的なイベントの数は分からないが、月に4本くらいでも今の実装工数や　　諸々と比較して十分ペイするだろうと思った

Slide 47

Slide 47 text

Slide 48

Slide 48 text

こういった経験を価値観として言葉にしてみました。

Slide 49

Slide 49 text

こういった経験を価値観として言葉にしてみました。 “個に依存することなく、脱属人化に向けた工夫をする”

Slide 50

Slide 50 text

サービスの成長とともに課題は変化・これまでは利用者の熱量に向き合い、仮説検証サイクルをいかに早く回すか　といったところに重点がおかれていた・しかし、ある程度サービスが成長してくると、その先に行くためにはそれだけ　では足りない・その時や少し先の未来に出てくるであろう本質的な課題に対し、　ひとつひとつ確実にこなしていくことが大事

Slide 51

Slide 51 text

まとめ：3章. 仮説検証を繰り返す中で・サービスの成長とともに求められる課題は変化していく・それに合わせて求められるエンジニアのスキルセットも多様化・サービスの成長速度を把握し、それに合わせて仕組み化を進めることは大切・経験者は強い　（見つけるのは大変だけど…）

Slide 52

Slide 52 text

Slide 53

Slide 53 text

4章. 規模の拡大とリーンでいることまた2年ほど経過（今から1年前くらい）・サービスは順調に成長　イベント本数は90本/月に増加・エンジニア全体で30人程度　イベントチームエンジニアの人数はあまり変わらず5人程度　→「仕組み化」を進めていたので前章から変わらない人数でもイベント本数の増加に対応できていた

Slide 54

Slide 54 text

4章. 規模の拡大とリーンでいることまた2年ほど経過（今から1年前くらい）・サービスは順調に成長　イベント本数は90本/月に増加・エンジニア全体で30人程度　イベントチームエンジニアの人数はあまり変わらず5人程度　→「仕組み化」を進めていたので前章から変わらない人数でもイベント本数の増加に対応できていた仕組み化を進めている一方、まだ対応できていないところで問題が起きてしまうことも…

Slide 55

Slide 55 text

実際に発生した問題の例サーバ負荷による障害　・当時はインフラチームというものはなく、何人かの初期メンバーが暗黙的に　　インフラを担当していた　・イベント開催時はアクセスが急増するためサーバ負荷が非常に高い　・インフラ担当とイベントエンジニアの連携が取れておらず、　　対策がとられなかったため障害を発生させてしまった ※現在はインフラ専属チームも構成され、連携をとりながら対応しています。

Slide 56

Slide 56 text

なぜ起きてしまったか・当初からエンジニアの中では各々が主体的に上手くやっていくという文化が　あったが故に、対応範囲が曖昧な業務に関しては連携がとれていなかった・サービス規模が拡大し、各々が対応できる範囲の差も大きくなってきた　インフラ担当の視点　　「負荷の高そうなイベントがあったら自分で設定してくれるよね」　イベントチームの視点　　「インフラよくわからないけど、インフラ担当の人はこのイベントがあることを　　　知ってるから対応してくれるよね」

Slide 57

Slide 57 text

対策としてイベントエンジニアが負荷の高そうなイベントは予め負荷を見積もり、インフラ設定を見直すという動きをとることにした。　・組織化が進んできているとはいえど、その時はまだインフラ専属チーム　　はなく、インフラを担当してくれていたメンバーはそれ以外の業務負荷も　　非常に高かったため作業を依頼することに難しさがあった　・それなら自分たちでインフラの設定を触れるようになるのが　　今は最善という判断をした

Slide 58

Slide 58 text

こういった経験を価値観として言葉にしてみました。

Slide 59

Slide 59 text

こういった経験を価値観として言葉にしてみました。 ”ミスを恐れず、担当するエンジニア領域の垣根を越えて自発的に触りに行き、最後までやり切る”

Slide 60

Slide 60 text

こういった経験を価値観として言葉にしてみました。 ”ミスを恐れず、担当するエンジニア領域の垣根を越えて自発的に触りに行き、最後までやり切る” 「これって組織化とは逆行した内容なのでは？」

Slide 61

Slide 61 text

組織化と逆行している？・サービスが成長を続ける限り、組織・体制起因の問題は発生し続ける　・まだ整っていない荒れ地をどうやって進んでいくか、整えていくかという　　瞬間がなくなることはない・体制やフロー整備で対応できるようにするのがベストだが、状況によっては　それがすぐにできない場合がある　・そういった場合には、一見効率が悪そうでも現状を本質的に　　打開できる選択というものは有用

Slide 62

Slide 62 text

まとめ：4章. 規模の拡大とリーンでいること・サービスが成長を続ける限り、不確定な要素は尽きない・体制を整えていく過程で生じる問題に対応していくには、　その問題を自分ごととして捉え、主体的に解決に動くことが求められる・規模が拡大しても、必要に迫られれば与えられた役割や垣根を超えた　アクションをとることを大いに歓迎する文化がある

Slide 63

Slide 63 text

Slide 64

Slide 64 text

価値観の共有エンジニアチームが大切にしている価値観をいくつかご紹介しました。 “企画の真意を理解し、同じ目的意識を持った上で、双方が納得できるアウトプットを模索する” ”個に依存することなく、脱属人化に向けた工夫をする” ”ミスを恐れず、担当するエンジニア領域の垣根を越えて自発的に触りに行き、最後までやり切る”

Slide 65

Slide 65 text

Slide 66

Slide 66 text

価値観の共有エンジニア人数と共有方法の変遷　・1〜10人　　特に意識したことはない　　「みんなあっち向いてるね！」　・11〜39人　　1on1などで無意識にある程度シンクできていた？　　「みんなあっち向いてる…？若干斜めってる…？」　・40人〜　　「みんなどっち向いてるのかわからん」　　　→価値観を言語化して浸透させよう！

Slide 67

Slide 67 text

価値観の共有今、どうやっているか？　・今年の4月頃、各チームが暗黙のうちに大切にしていた価値観を言語化して　　文章に落とし込んだ　　・各チーム毎に全メンバーを巻き込んで過去を振り返り、話し合って決めた　・今後は定期的に過去を振り返りアップデートしていく

Slide 68

Slide 68 text

価値観の共有今、どうやっているか？　・今年の4月頃、各チームが暗黙のうちに大切にしていた価値観を言語化して　　文章に落とし込んだ　　・各チーム毎に全メンバーを巻き込んで過去を振り返り、話し合って決めた　・今後は定期的に過去を振り返りアップデートしていくとはいえまだ始めたばかり。ここからチューニングをかけていきます。

Slide 69

Slide 69 text

　　　　　　発表のまとめ

Slide 70

Slide 70 text

発表のまとめ・サービス立ち上げ時は全員が同じ方向を向けていた・しかし、組織規模が大きくなりメンバーの多様化が進むと、各々が自発的に　行動するためには考え方の軸になるものが必要・そこで、チーム毎メンバー全員で過去を振り返り、課題を乗り越えてきたとき　に大切にしていた価値観を文章化・定期的にアップデートしていくことで、メンバーへの浸透、　また、これからの事業フェーズに則した価値観を維持していく

Slide 71

Slide 71 text

No content