Slide 1

Slide 1 text

サービスの成長を実現するために リードエンジニアが持つべき考え方 Takahiro Oishi

Slide 2

Slide 2 text

自己紹介 ● ライブストリーミング事業本部 Pococha 事業部システム部 部長 ○ 大石 貴広 ● 10年以上にわたり、様々なサービスを立ち上げて、 終わりを見届け続けた ● サーバサイド+ちょっとインフラ周りを見ることのできるエンジニア ● Pocochaの立ち上げメンバーであり、リードエンジニア

Slide 3

Slide 3 text

今日、お話しする事 5年にわたる Pococha の歴史の中で何をして、 何をしなかったか?を(一部)お話します。 リードエンジニアが何を悩んだかの一例をお伝えします。

Slide 4

Slide 4 text

Pococha のフェーズ ● Phase1 立ち上げ期: 2017年1月〜2017年5月 ● Phase2 仮説検証期: 2017年6月〜2018年5月 ● Phase3 グロース期: 2018年6月〜2019年9月 ● Phase4 ユーザー急増期: 2019年10月〜2021年4月 ● Phase5 グローバル展開期: 2021年5月〜

Slide 5

Slide 5 text

Pococha のフェーズ ● Phase1 立ち上げ期: 2017年1月〜2017年5月 ● Phase2 仮説検証期: 2017年6月〜2018年5月 ● Phase3 グロース期: 2018年6月〜2019年9月 ● Phase4 ユーザー急増期: 2019年10月〜2021年4月 ● Phase5 グローバル展開期: 2021年5月〜

Slide 6

Slide 6 text

Phase1 立ち上げ期

Slide 7

Slide 7 text

立ち上げ期でエンジニアが悩むポイント ● 最新技術でサービスつくるべき? ● どこまで自作して、どこまで外部ツール使うべき? ● コードを書くことに専念すべき? ● ドキュメントは書くべき? ● エンジニアは増やすべき? ● シャーディングは最初からすべき?

Slide 8

Slide 8 text

Phase1 立ち上げ期 (2017年1月〜2017年5月) ● 2016年9月頃からプロジェクト発足 ● 熱狂的なユーザーを探すための仮説検証を制限時間内にひたすら行う ● プロダクトオーナー1名、デザイナー1名、エンジニア2名

Slide 9

Slide 9 text

Phase1 立ち上げ期でやった事 1. 自分の手に馴染んだやり方を使う 2. 実装しないで済ませる道を最優先で考える 3. コードを書く仕事以外もやる

Slide 10

Slide 10 text

Phase1 立ち上げ期でやらなかった事 1. ドキュメントを書く 2. 人を増やす 3. シャーディング

Slide 11

Slide 11 text

立ち上げ期に Pococha で採用した方法 ● 最新技術でサービスつくるべき?  ⇒ 自分の手に馴染んだやり方を使う ● どこまで自作して、どこまで外部ツール使うべき?  ⇒実装しないで済ませる道を最優先で考える ● コードを書くのに専念すべき?  ⇒No。コードを書く仕事以外もやる ● ドキュメントは書くべき?  ⇒コードがすべて。あえて書かない ● エンジニアは増やすべき?  ⇒人はほぼ増やさない。共感してくれる人だけ。 ● シャーディングは最初からすべき?  ⇒Read/Writeだけ分けた。まだ入れない。

Slide 12

Slide 12 text

Phase4 ユーザー急増期

Slide 13

Slide 13 text

ユーザー急増期でエンジニアが悩むポイント ● 専門知識がないと対応できない高難易度な問題をどうする? ● 何に注力して、何を諦めるべき? ● シャーディングはどこですべき? ● エンジニアは増やすべき? ● 機能やコードの断捨離はすべき? ● オンボーディング対応すべき? ● ドキュメントは書くべき?

Slide 14

Slide 14 text

Phase4 ユーザー急増期 (2019年10月〜2021年4月) ● エンジニアだけで30名以上に増えていた ● リブランディングを行いPocochaらしさを見つけた時代 ● CM対応 ● その後、突如として訪れる巣ごもり需要の影響 ● それらの対応をしつつも進む、USリリースに向けてのグローバル対応

Slide 15

Slide 15 text

Phase4 ユーザー急増期でやった事 1. インフラ部門への運用移管 2. AI部門との連携 3. Amazon IVS導入 4. 新機能開発は止めて、 サービス安定化とグローバル開発に注力するという事業判断 5. シャーディング 6. 人を増やす

Slide 16

Slide 16 text

Phase4 ユーザー急増期でしなかった事 1. 機能・コードの断捨離 2. オンボーディングの整理 (しなかったというよりはうまくできなかった) 3. 積極的にドキュメントを書く

Slide 17

Slide 17 text

ユーザー急増期に Pococha で採用した方法 ● 専門知識がないと対応できない高難易度な問題をどうする?  ⇒インフラ部門への運用移管、AI部門との連携、Amazon IVS導入 ● 何に注力して、何を諦めるべき?  ⇒新機能開発は止めて、   サービス安定化とグローバル開発に注力するという事業判断 ● シャーディングはどこですべき?  ⇒対応した。詳細は過去の DeNA TechCon 2021 を見て! ● エンジニアは増やすべき?  ⇒多様性大事。サービス志向、技術志向、   様々な人に入ってもらった

Slide 18

Slide 18 text

ユーザー急増期に Pococha で採用した方法 ● 機能やコードの断捨離はすべき?  ⇒やれなかった。後悔してる ● オンボーディング対応すべき?  ⇒うまくできなかった。整え始めた。 ● ドキュメントは書くべき?  ⇒少しずつ書き始めている。   DesignDocなど導入してる

Slide 19

Slide 19 text

まとめ

Slide 20

Slide 20 text

Phase1 立ち上げ期で やらなかった事はどうなった? 1. ドキュメントを書く 2. 人を増やす 3. シャーディング

Slide 21

Slide 21 text

これからやっていくであろう事 1. マイクロサービス化 2. (重要な機能から)ドキュメントを書く 3. オンボーディング・教育など新しく入った人を支援する仕組み作り

Slide 22

Slide 22 text

Phase1 立ち上げ期で やらなかった事はどうなった? 1. ドキュメントを書く 2. 人を増やす 3. シャーディング

Slide 23

Slide 23 text

つまり ● (当たり前なのだが)フェーズが変われば 「やる事」「やらない事」は変わる ● 変わる事は悪い事じゃない ● 変化に適応できなくなる方が問題なのではないか?

Slide 24

Slide 24 text

5年間を通じて学んだこと ● 大きくなってきたからこそ 色んな人が力を貸してくれるようになった ● サービスを大きくする為には ユーザーと向き合い価値提供をし続けるのみ ● その為に、前提を疑いどんどん変わっていけばいい

Slide 25

Slide 25 text

持つべき考え方 ● 大きくなるまでは自分の限界がサービスの限界であるという認識 ● 前提を疑い、変わる事を恐れない ● その上で、どんどん周りに頼ればいい

Slide 26

Slide 26 text

ご清聴ありがとうございました

Slide 27

Slide 27 text

No content