Opening Keynote Part2.【DeNA TechCon 2021 Summer】/techcon2021summer_02

サービスが大きくなるまでみんなは見向きもしない。自分達の限界がサービスの限界。やらないことはトコトンやらない。誰の為の何の機能なの？本当にそれは差別化に繋がるの？今やるべきことなの？という考え方で少人数で開発を進めてきた Pococha。

巣ごもり需要の影響もありサービスとして大きくなってきた結果、みんなが手を差し伸べてくれる。自分達 + みんな（= 会社）の限界がサービスの限界になる。みんなに助けてもらいながら更にサービスを良くしていく。

そんな Pococha の歩みの中での技術課題や組織課題、何をして何をしなかったか？ Pocochaの立ち上げメンバーであり、Pococha 事業部システム部 部長の大石が話します。

Transcript

1. サービスの成長を実現するために リードエンジニアが持つべき考え方 Takahiro Oishi
2. 自己紹介 • ライブストリーミング事業本部 Pococha 事業部システム部 部長 ◦ 大石 貴広 • 10年以上にわたり、様々なサービスを立ち上げて、 終わりを見届け続けた • サーバサイド+ちょっとインフラ周りを見ることのできるエンジニア • Pocochaの立ち上げメンバーであり、リードエンジニア
3. 今日、お話しする事 5年にわたる Pococha の歴史の中で何をして、 何をしなかったか？を（一部）お話します。 リードエンジニアが何を悩んだかの一例をお伝えします。
4. Pococha のフェーズ • Phase1 立ち上げ期： 2017年1月〜2017年5月 • Phase2 仮説検証期： 2017年6月〜2018年5月 • Phase3 グロース期： 2018年6月〜2019年9月 • Phase4 ユーザー急増期： 2019年10月〜2021年4月 • Phase5 グローバル展開期： 2021年5月〜
5. Pococha のフェーズ • Phase1 立ち上げ期： 2017年1月〜2017年5月 • Phase2 仮説検証期： 2017年6月〜2018年5月 • Phase3 グロース期： 2018年6月〜2019年9月 • Phase4 ユーザー急増期： 2019年10月〜2021年4月 • Phase5 グローバル展開期： 2021年5月〜
6. Phase1 立ち上げ期
7. 立ち上げ期でエンジニアが悩むポイント • 最新技術でサービスつくるべき？ • どこまで自作して、どこまで外部ツール使うべき？ • コードを書くことに専念すべき？ • ドキュメントは書くべき？ • エンジニアは増やすべき？ • シャーディングは最初からすべき？
8. Phase1 立ち上げ期 (2017年1月〜2017年5月) • 2016年9月頃からプロジェクト発足 • 熱狂的なユーザーを探すための仮説検証を制限時間内にひたすら行う • プロダクトオーナー1名、デザイナー1名、エンジニア2名
9. Phase1 立ち上げ期でやった事 1. 自分の手に馴染んだやり方を使う 2. 実装しないで済ませる道を最優先で考える 3. コードを書く仕事以外もやる
10. Phase1 立ち上げ期でやらなかった事 1. ドキュメントを書く 2. 人を増やす 3. シャーディング
11. 立ち上げ期に Pococha で採用した方法 • 最新技術でサービスつくるべき？ 　⇒ 自分の手に馴染んだやり方を使う • どこまで自作して、どこまで外部ツール使うべき？ 　⇒実装しないで済ませる道を最優先で考える • コードを書くのに専念すべき？ 　⇒No。コードを書く仕事以外もやる • ドキュメントは書くべき？ 　⇒コードがすべて。あえて書かない • エンジニアは増やすべき？ 　⇒人はほぼ増やさない。共感してくれる人だけ。 • シャーディングは最初からすべき？ 　⇒Read/Writeだけ分けた。まだ入れない。
12. Phase4 ユーザー急増期
13. ユーザー急増期でエンジニアが悩むポイント • 専門知識がないと対応できない高難易度な問題をどうする？ • 何に注力して、何を諦めるべき？ • シャーディングはどこですべき？ • エンジニアは増やすべき？ • 機能やコードの断捨離はすべき？ • オンボーディング対応すべき？ • ドキュメントは書くべき？
14. Phase4 ユーザー急増期 (2019年10月〜2021年4月) • エンジニアだけで30名以上に増えていた • リブランディングを行いPocochaらしさを見つけた時代 • CM対応 • その後、突如として訪れる巣ごもり需要の影響 • それらの対応をしつつも進む、USリリースに向けてのグローバル対応
15. Phase4 ユーザー急増期でやった事 1. インフラ部門への運用移管 2. AI部門との連携 3. Amazon IVS導入 4. 新機能開発は止めて、 サービス安定化とグローバル開発に注力するという事業判断 5. シャーディング 6. 人を増やす
16. Phase4 ユーザー急増期でしなかった事 1. 機能・コードの断捨離 2. オンボーディングの整理 （しなかったというよりはうまくできなかった） 3. 積極的にドキュメントを書く
17. ユーザー急増期に Pococha で採用した方法 • 専門知識がないと対応できない高難易度な問題をどうする？ 　⇒インフラ部門への運用移管、AI部門との連携、Amazon IVS導入 • 何に注力して、何を諦めるべき？ 　⇒新機能開発は止めて、 　　サービス安定化とグローバル開発に注力するという事業判断 • シャーディングはどこですべき？ 　⇒対応した。詳細は過去の DeNA TechCon 2021 を見て！ • エンジニアは増やすべき？ 　⇒多様性大事。サービス志向、技術志向、 　　様々な人に入ってもらった
18. ユーザー急増期に Pococha で採用した方法 • 機能やコードの断捨離はすべき？ 　⇒やれなかった。後悔してる • オンボーディング対応すべき？ 　⇒うまくできなかった。整え始めた。 • ドキュメントは書くべき？ 　⇒少しずつ書き始めている。 　　DesignDocなど導入してる
19. まとめ
20. Phase1 立ち上げ期で やらなかった事はどうなった？ 1. ドキュメントを書く 2. 人を増やす 3. シャーディング
21. これからやっていくであろう事 1. マイクロサービス化 2. （重要な機能から）ドキュメントを書く 3. オンボーディング・教育など新しく入った人を支援する仕組み作り
22. Phase1 立ち上げ期で やらなかった事はどうなった？ 1. ドキュメントを書く 2. 人を増やす 3. シャーディング
23. つまり • （当たり前なのだが）フェーズが変われば 「やる事」「やらない事」は変わる • 変わる事は悪い事じゃない • 変化に適応できなくなる方が問題なのではないか？
24. 5年間を通じて学んだこと • 大きくなってきたからこそ 色んな人が力を貸してくれるようになった • サービスを大きくする為には ユーザーと向き合い価値提供をし続けるのみ • その為に、前提を疑いどんどん変わっていけばいい
25. 持つべき考え方 • 大きくなるまでは自分の限界がサービスの限界であるという認識 • 前提を疑い、変わる事を恐れない • その上で、どんどん周りに頼ればいい
26. ご清聴ありがとうございました