事業をグロースさせるためにエンジニアができること / What engineers can do to grow a business

Transcript

1. 事業をグロースさせるためにエンジニ 事業をグロースさせるためにエンジニ アができること アができること プラットフォーム事業本部 プラットフォーム事業本部 本⽥ 雄亮 本⽥ 雄亮 2020 年11 ⽉30 ⽇ 2020 年11 ⽉30 ⽇ PF-Meetup PF-Meetup
2. ⾃⼰紹介 ⾃⼰紹介 2 2
3. 本⽥ 雄亮（Honda Yusuke ） 本⽥ 雄亮（Honda Yusuke ） 所属：プラットフォーム事業本部 総合トップ開発部 PointClub チーム 所属：プラットフォーム事業本部 総合トップ開発部 PointClub チーム ⼊社年：2019 年（新卒⼊社） ⼊社年：2019 年（新卒⼊社） Twitter: @yyh-gl Twitter: @yyh-gl 運営：DMM.go 運営：DMM.go 3 3
4. DMM.go DMM.go DMM 社内のGo 活⽤事例を紹介 DMM 社内のGo 活⽤事例を紹介 第1 回⽬ 第1 回⽬ (https://inside.dmm.com/entry/2020/02/03/dmmgo-1) (https://inside.dmm.com/entry/2020/02/03/dmmgo-1) 第2 回⽬ 第2 回⽬ (https://inside.dmm.com/entry/2020/02/03/dmmgo-2) (https://inside.dmm.com/entry/2020/02/03/dmmgo-2) 4 4
5. 今⽇話すこと 今⽇話すこと 私が所属するPointClub チームにて、 私が所属するPointClub チームにて、 事業をグロースさせていくために⼤事にしている考え 事業をグロースさせていくために⼤事にしている考えを主題に置き、 を主題に置き、 エンジニアとしてなにができるのか、実際なにをしているのか エンジニアとしてなにができるのか、実際なにをしているのかを話します を話します やってみて得られた結果も共有できればと思います やってみて得られた結果も共有できればと思います 5 5
6. 開発体制 開発体制 6 6
7. PointClub チーム PointClub チーム 開発スタイル：アジャイル 開発スタイル：アジャイル チームメンバー：13 名ほど チームメンバー：13 名ほど バックエンド：6 名 バックエンド：6 名 ネイティブ，プロダクトデザイナー，グロース/ マーケティング など ネイティブ，プロダクトデザイナー，グロース/ マーケティング など 7 7
8. チームとして⼤事にしている考え チームとして⼤事にしている考え 8 8
9. " 最短距離でリリース" " 最短距離でリリース" 最短距離でのリリースを続けることで事業をグロースさせていく 最短距離でのリリースを続けることで事業をグロースさせていく 弊チームPO の⽯垣がiOSDC で発表 弊チームPO の⽯垣がiOSDC で発表 組織構造の⼒学を操作して、アプリ開発プロセスを最⼤化させる 組織構造の⼒学を操作して、アプリ開発プロセスを最⼤化させる (https://speakerdeck.com/i35_267/organizational- (https://speakerdeck.com/i35_267/organizational- structure-to-maximize-the-development-process) structure-to-maximize-the-development-process) 9 9
10. エンジニアとしてできること エンジニアとしてできること スピード感ある開発 スピード感ある開発 ⼿戻りをなくす ⼿戻りをなくす ⾃動化 ⾃動化 100% は無理でも最⼤限頑張る 100% は無理でも最⼤限頑張る 10 10
11. ⼿戻りをなくす ⼿戻りをなくす 11 11
12. ⼿戻りはだいたい認識差異から⽣まれる ⼿戻りはだいたい認識差異から⽣まれる 例えば 例えば 仕様の認識差異 仕様の認識差異 → 表⽰したい情報が違う → 表⽰したい情報が違う 技術的な認識差異 技術的な認識差異 → 必要な情報がAPI レスポンスに含まれていない → 必要な情報がAPI レスポンスに含まれていない と思ったら、使っている単語が違うだけでちゃんと渡してたり… と思ったら、使っている単語が違うだけでちゃんと渡してたり… このような状況では、話し合いや修正が必要になり、⼿戻りが発⽣ このような状況では、話し合いや修正が必要になり、⼿戻りが発⽣ ⼀発でばしっと決められると嬉しい ⼀発でばしっと決められると嬉しい では、なにをすればいいのか ▶▶▶ では、なにをすればいいのか ▶▶▶ 12 12
13. 仕様の認識差異をなくす 仕様の認識差異をなくす 13 13
14. なぜ仕様の認識差異が⽣まれる？ なぜ仕様の認識差異が⽣まれる？ 仕様の認識差異は、チームメンバー間（特にPO↔ エンジニア間）で、 仕様の認識差異は、チームメンバー間（特にPO↔ エンジニア間）で、 なにを作るかが⼀致していない場合に発⽣ なにを作るかが⼀致していない場合に発⽣ エンジニアが エンジニアがなに なにを作っているのか明確に意識できていれば発⽣しづらい を作っているのか明確に意識できていれば発⽣しづらい そして、「なにを作るか」は そして、「なにを作るか」はなぜ なぜ作るかが分かっていると理解しやすい 作るかが分かっていると理解しやすい 14 14
15. まずは「なぜ」を統⼀ まずは「なぜ」を統⼀ なぜ なぜ作るかの認識を統⼀するために 作るかの認識を統⼀するために みんなでユーザーストーリーマッピングを作成 みんなでユーザーストーリーマッピングを作成 することが有効 することが有効 ユーザーストーリーマッピング： ユーザーストーリーマッピング： どういう機能が必要か、どのタイミングで提供すべきかといった情報を どういう機能が必要か、どのタイミングで提供すべきかといった情報を ユーザーストーリー（≒ユーザーにとっての価値）に対応させて表現可能 ユーザーストーリー（≒ユーザーにとっての価値）に対応させて表現可能 15 15
16. ユーザーストーリーマッピング ユーザーストーリーマッピング 16 16
17. ユーザーストーリーマッピング ユーザーストーリーマッピング 17 17
18. ユーザーストーリーマッピング ユーザーストーリーマッピング 18 18
19. ユーザーストーリーマッピング ユーザーストーリーマッピング 19 19
20. ユーザーストーリーマッピング ユーザーストーリーマッピング 20 20
21. ユーザーストーリーマッピング ユーザーストーリーマッピング 21 21
22. ユーザーストーリーマッピングの恩恵 ユーザーストーリーマッピングの恩恵 今作っている機能が、ユーザーのどういったストーリーに紐づくのかが明確になる 今作っている機能が、ユーザーのどういったストーリーに紐づくのかが明確になる → → なぜ なぜその機能が必要なのかが明確になるので、迷⼦になりにくい その機能が必要なのかが明確になるので、迷⼦になりにくい 22 22
23. 「なに」を統⼀ 「なに」を統⼀ なに なにを作るかの認識を統⼀するために、みんなでデザインをレビュー を作るかの認識を統⼀するために、みんなでデザインをレビュー Figma 上でデザインを確認可能 Figma 上でデザインを確認可能 23 23
24. 実際にこうした取り組みをやってみての感想 実際にこうした取り組みをやってみての感想 メンバー間の認識差異は少ない（… はず！） メンバー間の認識差異は少ない（… はず！） 加えて、なにをなぜ作るか理解していれば、各エンジニアから仕様部分での改善策が出てき 加えて、なにをなぜ作るか理解していれば、各エンジニアから仕様部分での改善策が出てき やすくなる やすくなる 開発が始まってから、認識差異が⾒つかったとしても、 開発が始まってから、認識差異が⾒つかったとしても、 ユーザーストーリーマッピングやデザインという共通⾔語があるため、 ユーザーストーリーマッピングやデザインという共通⾔語があるため、 解決のための会話がスムーズに進む 解決のための会話がスムーズに進む 24 24
25. より詳しい話はPO ⽯垣の発表をどうぞ より詳しい話はPO ⽯垣の発表をどうぞ 組織構造の⼒学を操作して、アプリ開発プロセスを最⼤化させる 組織構造の⼒学を操作して、アプリ開発プロセスを最⼤化させる (https://speakerdeck.com/i35_267/organizational- (https://speakerdeck.com/i35_267/organizational- structure-to-maximize-the-development-process) structure-to-maximize-the-development-process) 25 25
26. 技術的な認識差異をなくす 技術的な認識差異をなくす 26 26
27. 技術的な認識差異をなくすために 技術的な認識差異をなくすために ⽇常的な認識合わせ ⽇常的な認識合わせ 廃らないドキュメント作り 廃らないドキュメント作り 27 27
28. ⽇常的な認識合わせ ⽇常的な認識合わせ 28 28
29. API 定義レビュー API 定義レビュー API 定義に変更があったときはクライアントとバックエンドの両メンバーでレビュー API 定義に変更があったときはクライアントとバックエンドの両メンバーでレビュー API 定義にはOpenAPI （Swagger ）を使⽤ API 定義にはOpenAPI （Swagger ）を使⽤ クライアントとバックエンド間でAPI 定義に関する認識が常に⼀致 クライアントとバックエンド間でAPI 定義に関する認識が常に⼀致 29 29
30. API 定義を確認する⽅法 API 定義を確認する⽅法 API 定義はSwagger UI を通して確認可能 API 定義はSwagger UI を通して確認可能 Swagger UI ⾃体はS3 でホスティングされており、いつでもだれでもアクセス可能 Swagger UI ⾃体はS3 でホスティングされており、いつでもだれでもアクセス可能 30 30
31. みんなでレビューすることで… みんなでレビューすることで… みんなで認識合わせをする機会（仕組み）を作ることにより みんなで認識合わせをする機会（仕組み）を作ることにより メンバー間の認識が⼤きくずれることをなくし、⼿戻りを防⽌ メンバー間の認識が⼤きくずれることをなくし、⼿戻りを防⽌ 加えて、異なる領域のメンバーがレビューすることで、 加えて、異なる領域のメンバーがレビューすることで、 様々な視点からの意⾒がもらえる（品質向上） 様々な視点からの意⾒がもらえる（品質向上） もしかして毎回openapi.yaml （ドキュメント）を⼿で更新してる… ？ もしかして毎回openapi.yaml （ドキュメント）を⼿で更新してる… ？ → API 定義ドキュメントをどうやって⽣成し、共有しているかは後述 → API 定義ドキュメントをどうやって⽣成し、共有しているかは後述 31 31
32. 技術的な認識差異をなくすために 技術的な認識差異をなくすために ⽇常的な認識合わせ ⽇常的な認識合わせ 廃らないドキュメント作り 廃らないドキュメント作り 32 32
33. 廃らないドキュメント作り 廃らないドキュメント作り 33 33
34. ドキュメントを廃れさせないためにできること ドキュメントを廃れさせないためにできること 廃れたドキュメント＝内容が現実と乖離しているドキュメント 廃れたドキュメント＝内容が現実と乖離しているドキュメント したがって、常に" 現実" を基にドキュメントを作り続ければ廃れることはない したがって、常に" 現実" を基にドキュメントを作り続ければ廃れることはない 弊チームでは以下のドキュメントについて、 弊チームでは以下のドキュメントについて、 コードを基に⽣成することで現実に則したドキュメントを⽣成 コードを基に⽣成することで現実に則したドキュメントを⽣成 API 定義 API 定義 DB スキーマ定義 DB スキーマ定義 加えて、継続的にドキュメント⽣成する仕組み（⽣成⾃動化）により、 加えて、継続的にドキュメント⽣成する仕組み（⽣成⾃動化）により、 ドキュメントを常に更新し、⾵化を防⽌ ドキュメントを常に更新し、⾵化を防⽌ ▶ ⾃動化周りの詳細は後述 ▶ ⾃動化周りの詳細は後述 34 34
35. ここまでのまとめ ここまでのまとめ ⼿戻り防⽌を⽬的として、いろいろやってきた ⼿戻り防⽌を⽬的として、いろいろやってきた ユーザーストーリーマッピングやデザインレビューで仕様の認識を合わせ、 ユーザーストーリーマッピングやデザインレビューで仕様の認識を合わせ、 ⽇常的なレビューと廃れたドキュメントを作らない仕組み作りにより、 ⽇常的なレビューと廃れたドキュメントを作らない仕組み作りにより、 技術的な認識を合わせた 技術的な認識を合わせた ただし、これらの取り組みや仕組みを⼈の⼿作業だけで継続するのは難しいので、 ただし、これらの取り組みや仕組みを⼈の⼿作業だけで継続するのは難しいので、 簡素化してあげることが⼤事 簡素化してあげることが⼤事 つまり、⼈がやらなくて良い部分は機械に任せる つまり、⼈がやらなくて良い部分は機械に任せる 35 35
36. ⾃動化 ⾃動化 36 36
37. API 定義のドキュメント作成を⾃動化 API 定義のドキュメント作成を⾃動化 下記タイミングで、CI にて、 下記タイミングで、CI にて、 その時点の最新コードからopenapi.yaml を⽣成し、S3 にアップロード その時点の最新コードからopenapi.yaml を⽣成し、S3 にアップロード 作業ブランチをPUSH 作業ブランチをPUSH API 定義に変更がある場合限定 API 定義に変更がある場合限定 master にPUSH （＝ STG リリース） master にPUSH （＝ STG リリース） STG のAPI 定義は常時、作業ブランチのAPI 定義は⼀定期間閲覧可能 STG のAPI 定義は常時、作業ブランチのAPI 定義は⼀定期間閲覧可能 37 37
38. より詳細は… より詳細は… API 定義の⽣成や共有については、 API 定義の⽣成や共有については、 以前、DMM.go で発表したので、よければ以下のスライドもご覧ください 以前、DMM.go で発表したので、よければ以下のスライドもご覧ください Goa を使ってAPI サーバ開発してみた Goa を使ってAPI サーバ開発してみた (https://speakerdeck.com/yyh_gl/develop-api-server-by-goa) (https://speakerdeck.com/yyh_gl/develop-api-server-by-goa) 38 38
39. DB スキーマ定義のドキュメント作成を⾃動化 DB スキーマ定義のドキュメント作成を⾃動化 k1low/tbls k1low/tbls (https://github.com/k1LoW/tbls) (https://github.com/k1LoW/tbls) というGo 製ツールを使⽤ というGo 製ツールを使⽤ 下記のようなシンプルな設定ファイル 下記のようなシンプルな設定ファイル .tbls.yml .tbls.yml を作成し、 を作成し、 dsn: mysql://root:mysql@localhost:3306/pointclub dsn: mysql://root:mysql@localhost:3306/pointclub docPath: /tmp/dbdoc docPath: /tmp/dbdoc コマンドを実⾏すると コマンドを実⾏すると $ tbls doc $ tbls doc DB スキーマ定義がsvg およびマークダウン形式で出⼒される ▶▶▶ DB スキーマ定義がsvg およびマークダウン形式で出⼒される ▶▶▶ 39 39
40. ⽣成物：テーブル⼀覧 ⽣成物：テーブル⼀覧 40 40
41. ⽣成物：テーブル詳細 ⽣成物：テーブル詳細 41 41
42. ⽣成物：全テーブルの関連 ⽣成物：全テーブルの関連 42 42
43. ⽣成物：概要（README.md ） ⽣成物：概要（README.md ） README.md README.md にDB 全体のスキーマ定義を出⼒ にDB 全体のスキーマ定義を出⼒ 43 43
44. DB スキーマ定義のドキュメントを共有 DB スキーマ定義のドキュメントを共有 ⽣成されたドキュメントは、 ⽣成されたドキュメントは、 アプリケーションコードとは別のGitHub リポジトリにPUSH アプリケーションコードとは別のGitHub リポジトリにPUSH ドキュメントはsvg およびマークダウン形式なので、GitHub と相性が良い ドキュメントはsvg およびマークダウン形式なので、GitHub と相性が良い 44 44
45. おまけ：リリースノート作成を⾃動化 おまけ：リリースノート作成を⾃動化 リリース管理のために、PRD リリース時にリリースノートを作成している リリース管理のために、PRD リリース時にリリースノートを作成している 作成⾃体は 作成⾃体はgoreleaser/goreleaser goreleaser/goreleaser (https://github.com/goreleaser/goreleaser) (https://github.com/goreleaser/goreleaser) というGo 製ツールを使⽤ というGo 製ツールを使⽤ CI に組み込んでおり、タグPUSH をトリガーにリリースノートを⽣成 CI に組み込んでおり、タグPUSH をトリガーにリリースノートを⽣成 45 45
46. ⾃動化により… ⾃動化により… ⽇常的な認識合わせにかかる⼿間を削減 ⽇常的な認識合わせにかかる⼿間を削減 廃れないドキュメントを実現 廃れないドキュメントを実現 ⼈にしかできない作業に集中 ⼈にしかできない作業に集中 ⼈的ミスの排除 ⼈的ミスの排除 46 46
47. まとめ まとめ 事業グロースのために最短距離でリリース 事業グロースのために最短距離でリリース 最短距離でリリースするための取り組みを紹介し、 それぞれ効果を実感 最短距離でリリースするための取り組みを紹介し、 それぞれ効果を実感 ⼿戻りをなくすための努⼒ ⼿戻りをなくすための努⼒ みんなでユーザーストーリーマッピング作成 みんなでユーザーストーリーマッピング作成 みんなでデザインレビュー みんなでデザインレビュー みんなでAPI 定義レビュー みんなでAPI 定義レビュー ⾃動化によって上記の取り組みをサポート ⾃動化によって上記の取り組みをサポート API 定義のドキュメント化 API 定義のドキュメント化 DB スキーマ定義のドキュメント化 DB スキーマ定義のドキュメント化 （リリース作業） （リリース作業） 47 47
48. Thank you Thank you プラットフォーム事業本部 プラットフォーム事業本部 本⽥ 雄亮 本⽥ 雄亮 2020 年11 ⽉30 ⽇ 2020 年11 ⽉30 ⽇ PF-Meetup PF-Meetup