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

サービスが成長していくにつれてチーム規模も拡大してきたPococha。立ち上げ当初1名だったエンジニアはこの4年間で約40名まで増えました。

サービスや組織が拡大するにつれ、エンジニアリングで解決すべき課題は多種多様となり増え続けています。そんな中での数々の挑戦を個の体験では終わらせず、今後の事業やチームに活かす方法を模索しています。

立ち上げ当初のリーンな仮説検証フェーズからスケールさせていくフェーズの間で、チームとしてどのような挑戦があったのか、いちエンジニアの視点から振り返り、そこから生まれた価値観をご紹介します。

Transcript

1. Pocochaエンジニアチームが 挑戦してきた課題と そこから生まれた価値観 荻　栄輔
2. 自己紹介 荻 栄輔 / Eisuke Ogi ライブストリーミング事業本部Pococha事業部システム部 副部長 経歴 ・SIer、ベンチャー、スタートアップを経て、2014年DeNAに入社 ・複数の新規事業の立ち上げとクロージングを繰り返す ・Pocochaにはイベント機能開発担当として2018年にジョイン ・現在は主にマネジメントに従事
3. はじめにお伝えしておきたいこと
4. 本発表では、Pocochaエンジニアチームが事業成長とともに直 面してきた課題についてお話します。 それらの課題はサービスの成長過程でありがちなものもあるか もしれません。 しかし、そういった当たり前と思えるようなことでも、実体験 を通してチームにシェアしたところ、一人ひとりの価値観の違 いなど新たな気づきが得られたのでご紹介します。
5. 発表の流れ 1章. 現在のエンジニアチーム 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有
6. Pocochaとは ・2017年にサービスが開始したライ ブ配信アプリ ・配信をするライバーと、コメントや アイテムで応援するリスナーの双方向 コミュニケーション
7. 発表の流れ 1章. 現在のエンジニアチーム 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有
8. 現在のエンジニアチーム ・Pocochaチーム全体の人数が約100名超 ・そのうち40名程度がエンジニア 　Server：5割、iOS、Android、WebFront：5割 ・チーム外でもPococha担当として協力してもらっているメンバーもいる 　infra、AI：10名程度
9. 「エンジニア40人もいるの？大規模な組織なんだろうな…」
10. 大規模な組織のイメージ ・縦割りで決められたことを繰り返すだけ ・お行儀よくてつまらない ・自分の裁量が小さい etc...
11. 実際のところは？
12. エンジニアチームの構成 それぞれの専門領域をもったメンバーが大きなミッション単位のチームに所属 し、施策毎にエンジニア1,2名で動くことが多い ・プロダクトチーム（Pocochaの土台となる機能の開発） 　Server、iOS、Android、WebFront ・イベントチーム（Pococha内で開催するイベントの開発） 　Server、WebFront 　　 　　　　　　　　　　　　　…これら以外にも複数のチームがある
13. エンジニアチームの構成 それぞれの専門領域をもったメンバーが大きなミッション単位のチームに所属 し、施策毎にエンジニア1,2名で動くことが多い ・プロダクトチーム（Pocochaの土台となる機能の開発） 　Server、iOS、Android、WebFront ・イベントチーム（Pococha内で開催するイベントの開発） 　Server、WebFront 　　 　　　　　　　　　　　　　…これら以外にも複数のチームがある 行動単位で見るとそこまで大人数の組織ではない
14. 一般的なスタートアップチームのように 多くのメンバーが裁量を持って自発的に動けています！
15. 一般的なスタートアップチームのように 多くのメンバーが裁量を持って自発的に動けています！ が…、 さすがに40人にもなると、それぞれが自発的に動くためには 考え方の軸になるものがないといけない
16. 軸がないと… ・みんなが向いている方向がバラバラになってチーム崩壊 ・頑張ったのに「それ違くない？」って言われて評価されない ・目指しているものが違うから議論が進まない etc...
17. なので、軸を定めました。
18. エンジニアチームで大切にしている価値観 エンジニア一人ひとりが、 “サービスに何が必要かを理解して、それだけに向かってリーンに動く” “サービスをスケールさせ、 　　　日本で世界で利用者に選ばれることを想定して技術課題解決に動く”
19. エンジニアチームで大切にしている価値観 チームによっても独自に定義 プロダクトチーム “対峙している領域の戦略や目的を理解した上で、今、本当に必要なものをリーンに作る” “常にユーザーの視点に立ち、自身がサービスを楽しみ、熱中する” イベントチーム “個に依存することなく、脱属人化に向けた工夫をする” “ミスを恐れず、担当するエンジニア領域の垣根を越えて自発的に触りに行き、 最後までやり切る”
20. まとめ：1章. 現在のエンジニアチーム ・エンジニアチームは約40名と結構多い ・とはいえ、各チームや施策ごとに数名担当なので、 　行動単位で見ると大規模なチームではない ・各々が自発的に行動しており、 　そのための軸（価値観）を定義している
21. これ以降の章では、 ・こういった価値観がどういった背景で生まれたものなのか ・その時、どうやって価値観を共有してきたのか といったことを、サービス立ち上げ当初から 振り返りながらご紹介していきます。
22. 発表の流れ 1章. 現在のPocochaエンジニアチームについて 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有 6章. まとめ
23. サービス立ち上げ当初 ・DeNAの中に新規事業部署（スタートアップ村）があり、 　Pocochaはその中で生まれたひとつ ・事業起案者1人、エンジニア2人、デザイナー1人の4人でスタート ・利用者の熱量の増大が確認されれば追加投資、 　増大していなければクローズという環境を生き抜いてきた
24. 仮説検証を進めていき… リリースされてから1年（今から3年半ほど前） ・サービス利用者は多くないが確かな熱量を感じられる ・チームメンバーは全体で10人超え ・エンジニアは5人程度 主要機能のひとつ「イベント」が生まれる ・当時担当していたエンジニアは2名 　Server：1、WebFront：1
25. イベントとは？ 期間限定で開かれる特別な催し物 ランキングイベント 　・リスナーのアクティビティ（コメントやアイテム使用等）に応じたポイント 　　で順位を競う 　・入賞者には様々な景品や権利が与えられる ミッションイベント 　・与えられたお題をリスナーと一緒にクリアしていく 　　・「あけおめ！と19回いってもらおう」 　・コイン（アプリ内通貨）がもらえる
26. この頃の状況 荒れ地を手探りで進んでいく ・12月になってからクリスマスのイベントをやりたいという話が出てくる 　（もちろん作る） ・イベントリリース5日前に技術的な問題が見つかっていちから作り直し、 　そこから3日間で作ってリリース ・イベント開催中に不具合が見つかって深夜の調査対応
27. この頃の状況 イベント機能の開発について 　・流用することを重視しない設計 　・過去開催したイベントから流用できるコードは手動でコピペ 　・毎回デザインが微妙に異なるため、地道にhtmlとcssを書く 　・動作検証は全て自ら実施 　・イベント終了後の集計作業といったことも半分は手作業 月1本のイベントを開発する度にとにかく泥臭い作業
28. この頃の状況 なぜ泥臭いことをしていたのか？ 　イベントという新機能が利用者に受けいれられるか、 　また、Pocochaに必要なものなのかということを確かめるフェーズだった。 　そのため、いかに早く仮説検証を回すかということが重視されていた。 丁寧に作っても利用者に受け入れられなければ廃棄される運命。 もちろん少ない時間で最適な設計やコードを書ける場合はそれがベスト。 しかし、そんな実力は持ち合わせていなかったので、 一番早く確実に実現できる形で動いていた。
29. 仮説検証サイクルを高速にするために エンジニアは単純に早く開発するだけではなく、企画者と同等に仮説検証に必要 なものをジャッジする役目を担う。結果として厳しい要求やスケジュールになっ たとしても、企画者の言うことに振り回されているわけではなく、納得したうえ で行動する。（振り回されることもあるけど）
30. こういった経験を価値観として言葉にしてみました。
31. こういった経験を価値観として言葉にしてみました。 “企画の真意を理解し、同じ目的意識を持った上で、 双方が納得できるアウトプットを模索する”
32. 仮説検証サイクルを高速にするために エンジニアは単純に早く開発するだけではなく、企画者と同等に仮説検証に必要 なものをジャッジする役目を担う。結果として厳しい要求やスケジュールになっ たとしても、企画者の言うことに振り回されているわけではなく、納得したうえ で行動する。（振り回されることもあるけど） この頃は人数も少なく、 ほとんどのエンジニアが新規事業立ち上げ経験者だった こともあってか、自然と同じアプローチをとっていた。
33. まとめ：2章. サービス立ち上げ当初 ・立ち上げ当初は生き残るために仮説検証をとにかく早いサイクルで 　回すことが重視されていた ・エンジニアは、企画者と同等に必要なものをジャッジする役割を担っている ・この頃は特に意識しなくとも、みんなが向いている方向を 　揃えることができていた（純度が高かった）
34. 発表の流れ 1章. 現在のPocochaエンジニアチームについて 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有
35. 仮説検証を繰り返す中で それから半年ほど経過（今から3年ほど前） ・イベントは利用者に受けいれられて根本の仮説検証は済んだ ・Pocochaの利用者はだんだん増えてきた ・エンジニア全体で10人程度 　イベント機能担当エンジニアは4人程度
36. 仮説検証を繰り返す中で それから半年ほど経過（今から3年ほど前） ・イベントは利用者に受けいれられて根本の仮説検証は済んだ ・Pocochaの利用者はだんだん増えてきた ・エンジニア全体で10人程度 　イベント機能担当エンジニアは4人程度 ここからさらに数カ月後のある日… 「毎月たくさんのイベントを提供したい！」 　　　　　　　　　　　　　　と言われることになる
37. どうするか？ ・エンジニアを増やす？ ・頑張って一人あたりが開発できるイベント本数を増やす？
38. どうするか？ ・エンジニアを増やす？ 　→そんなにすぐにエンジニアは採用できない ・頑張って一人あたりが開発できるイベント本数を増やす？ 　→能力によって品質に差が出てしまう
39. どうするか？ ・エンジニアを増やす？ 　→そんなにすぐにエンジニアは採用できない ・頑張って一人あたりが開発できるイベント本数を増やす？ 　→能力によって品質に差が出てしまう そもそもマンパワーで解決しても、 またすぐに頭打ちするのが見えている
40. イベントを効率よく開発するための仕組み化が必要
41. 解決すべき課題とアプローチ ・オペレーションの効率化 ・エンジニア工数の削減 ・品質の維持
42. 解決すべき課題とアプローチ ・オペレーションの効率化 　→企画書及び仕様書の整備 ・エンジニア工数の削減 　→少しのエンジニア工数でイベントが作れてしまうシステム、フローを実現 ・品質の維持 　→QAの体制構築
43. 解決すべき課題とアプローチ ・オペレーションの効率化 　→企画書及び仕様書の整備 ・エンジニア工数の削減 　→少しのエンジニア工数でイベントが作れてしまうシステム、フローを実現 ・品質の維持 　→QAの体制構築 いきなりこんなことやろうとすると数ヶ月くらいかかる。
44. 解決すべき課題とアプローチ 実は企画から要望がでる前にすでに仕組みが整っていた。少し前 にゲーム事業部から異動してきたエンジニアがいつのまにか進め ていた。
45. 解決すべき課題とアプローチ 実は企画から要望がでる前にすでに仕組みが整っていた。少し前 にゲーム事業部から異動してきたエンジニアがいつのまにか進め ていた。 目の前のことに必死で気がつけていなかったが、いつの間にか 「仕組み化」が必要なフェーズに足を踏み込んでいた。
46. 解決すべき課題とアプローチ 当時どうしてそんな対応がとれたのか聞いてみると… 　・ゲーム事業部での経験があったのが第一で、構造的にPococha 　　にも当て込むことができると思った 　・自分でイベントを作ったときにしんどかったのでもう嫌だと思った 　・将来的なイベントの数は分からないが、月に4本くらいでも今の実装工数や 　　諸々と比較して十分ペイするだろうと思った
47. 解決すべき課題とアプローチ 当時どうしてそんな対応がとれたのか聞いてみると… 　・ゲーム事業部での経験があったのが第一で、構造的にPococha 　　にも当て込むことができると思った 　・自分でイベントを作ったときにしんどかったのでもう嫌だと思った 　・将来的なイベントの数は分からないが、月に4本くらいでも今の実装工数や 　　諸々と比較して十分ペイするだろうと思った 今後数年は耐えられそうな仕組みを構築するにとどめている
48. こういった経験を価値観として言葉にしてみました。
49. こういった経験を価値観として言葉にしてみました。 “個に依存することなく、脱属人化に向けた工夫をする”
50. サービスの成長とともに課題は変化 ・これまでは利用者の熱量に向き合い、仮説検証サイクルをいかに早く回すか 　といったところに重点がおかれていた ・しかし、ある程度サービスが成長してくると、その先に行くためにはそれだけ 　では足りない ・その時や少し先の未来に出てくるであろう本質的な課題に対し、 　ひとつひとつ確実にこなしていくことが大事
51. まとめ：3章. 仮説検証を繰り返す中で ・サービスの成長とともに求められる課題は変化していく ・それに合わせて求められるエンジニアのスキルセットも多様化 ・サービスの成長速度を把握し、それに合わせて仕組み化を進めることは大切 ・経験者は強い 　（見つけるのは大変だけど…）
52. 発表の流れ 1章. 現在のPocochaエンジニアチームについて 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有
53. 4章. 規模の拡大とリーンでいること また2年ほど経過（今から1年前くらい） ・サービスは順調に成長 　イベント本数は90本/月に増加 ・エンジニア全体で30人程度 　イベントチームエンジニアの人数はあまり変わらず5人程度 　→「仕組み化」を進めていたので前章から変わらない人数でもイベント本数の増加に対応できていた
54. 4章. 規模の拡大とリーンでいること また2年ほど経過（今から1年前くらい） ・サービスは順調に成長 　イベント本数は90本/月に増加 ・エンジニア全体で30人程度 　イベントチームエンジニアの人数はあまり変わらず5人程度 　→「仕組み化」を進めていたので前章から変わらない人数でもイベント本数の増加に対応できていた 仕組み化を進めている一方、 まだ対応できていないところで問題が起きてしまうことも…
55. 実際に発生した問題の例 サーバ負荷による障害 　・当時はインフラチームというものはなく、何人かの初期メンバーが暗黙的に 　　インフラを担当していた 　・イベント開催時はアクセスが急増するためサーバ負荷が非常に高い 　・インフラ担当とイベントエンジニアの連携が取れておらず、 　　対策がとられなかったため障害を発生させてしまった ※現在はインフラ専属チームも構成され、連携をとりながら対応しています。
56. なぜ起きてしまったか ・当初からエンジニアの中では各々が主体的に上手くやっていくという文化が 　あったが故に、対応範囲が曖昧な業務に関しては連携がとれていなかった ・サービス規模が拡大し、各々が対応できる範囲の差も大きくなってきた 　インフラ担当の視点 　　「負荷の高そうなイベントがあったら自分で設定してくれるよね」 　イベントチームの視点 　　「インフラよくわからないけど、インフラ担当の人はこのイベントがあることを 　　　知ってるから対応してくれるよね」
57. 対策として イベントエンジニアが負荷の高そうなイベントは予め負荷を見積もり、 インフラ設定を見直すという動きをとることにした。 　・組織化が進んできているとはいえど、その時はまだインフラ専属チーム 　　はなく、インフラを担当してくれていたメンバーはそれ以外の業務負荷も 　　非常に高かったため作業を依頼することに難しさがあった 　・それなら自分たちでインフラの設定を触れるようになるのが 　　今は最善という判断をした
58. こういった経験を価値観として言葉にしてみました。
59. こういった経験を価値観として言葉にしてみました。 ”ミスを恐れず、担当するエンジニア領域の垣根を越えて 自発的に触りに行き、最後までやり切る”
60. こういった経験を価値観として言葉にしてみました。 ”ミスを恐れず、担当するエンジニア領域の垣根を越えて 自発的に触りに行き、最後までやり切る” 「これって組織化とは逆行した内容なのでは？」
61. 組織化と逆行している？ ・サービスが成長を続ける限り、組織・体制起因の問題は発生し続ける 　・まだ整っていない荒れ地をどうやって進んでいくか、整えていくかという 　　瞬間がなくなることはない ・体制やフロー整備で対応できるようにするのがベストだが、状況によっては 　それがすぐにできない場合がある 　・そういった場合には、一見効率が悪そうでも現状を本質的に 　　打開できる選択というものは有用
62. まとめ：4章. 規模の拡大とリーンでいること ・サービスが成長を続ける限り、不確定な要素は尽きない ・体制を整えていく過程で生じる問題に対応していくには、 　その問題を自分ごととして捉え、主体的に解決に動くことが求められる ・規模が拡大しても、必要に迫られれば与えられた役割や垣根を超えた 　アクションをとることを大いに歓迎する文化がある
63. 発表の流れ 1章. 現在のPocochaエンジニアチームについて 2章. サービス立ち上げ当初 3章. 仮説検証を繰り返す中で 4章. 規模の拡大とリーンでいること 5章. 価値観の共有
64. 価値観の共有 エンジニアチームが大切にしている価値観をいくつかご紹介しました。 “企画の真意を理解し、同じ目的意識を持った上で、双方が納得できるアウトプットを模索する” ”個に依存することなく、脱属人化に向けた工夫をする” ”ミスを恐れず、担当するエンジニア領域の垣根を越えて自発的に触りに行き、最後までやり切る”
65. 価値観の共有 エンジニアチームが大切にしている価値観をいくつかご紹介しました。 “企画の真意を理解し、同じ目的意識を持った上で、双方が納得できるアウトプットを模索する” ”個に依存することなく、脱属人化に向けた工夫をする” ”ミスを恐れず、担当するエンジニア領域の垣根を越えて自発的に触りに行き、最後までやり切る” せっかく定義してもチームメンバーに浸透しないと意味がない
66. 価値観の共有 エンジニア人数と共有方法の変遷 　・1〜10人 　　特に意識したことはない 　　「みんなあっち向いてるね！」 　・11〜39人 　　1on1などで無意識にある程度シンクできていた？ 　　「みんなあっち向いてる…？若干斜めってる…？」 　・40人〜 　　「みんなどっち向いてるのかわからん」 　　　→価値観を言語化して浸透させよう！
67. 価値観の共有 今、どうやっているか？ 　・今年の4月頃、各チームが暗黙のうちに大切にしていた価値観を言語化して 　　文章に落とし込んだ 　　・各チーム毎に全メンバーを巻き込んで過去を振り返り、話し合って決めた 　・今後は定期的に過去を振り返りアップデートしていく
68. 価値観の共有 今、どうやっているか？ 　・今年の4月頃、各チームが暗黙のうちに大切にしていた価値観を言語化して 　　文章に落とし込んだ 　　・各チーム毎に全メンバーを巻き込んで過去を振り返り、話し合って決めた 　・今後は定期的に過去を振り返りアップデートしていく とはいえまだ始めたばかり。 ここからチューニングをかけていきます。
69. 　　　　　　 発表のまとめ
70. 発表のまとめ ・サービス立ち上げ時は全員が同じ方向を向けていた ・しかし、組織規模が大きくなりメンバーの多様化が進むと、各々が自発的に 　行動するためには考え方の軸になるものが必要 ・そこで、チーム毎メンバー全員で過去を振り返り、課題を乗り越えてきたとき 　に大切にしていた価値観を文章化 ・定期的にアップデートしていくことで、メンバーへの浸透、 　また、これからの事業フェーズに則した価値観を維持していく