事業をグロースさせるためにエンジニアができること / What engineers can do to grow a business

Slide 1

Slide 1 text

事業をグロースさせるためにエンジニ事業をグロースさせるためにエンジニアができることアができることプラットフォーム事業本部プラットフォーム事業本部本⽥雄亮本⽥雄亮 2020 年11 ⽉30 ⽇ 2020 年11 ⽉30 ⽇ PF-Meetup PF-Meetup

Slide 2

Slide 2 text

⾃⼰紹介⾃⼰紹介 2 2

Slide 3

Slide 3 text

本⽥雄亮（Honda Yusuke ）本⽥雄亮（Honda Yusuke ）所属：プラットフォーム事業本部総合トップ開発部 PointClub チーム所属：プラットフォーム事業本部総合トップ開発部 PointClub チーム⼊社年：2019 年（新卒⼊社）⼊社年：2019 年（新卒⼊社） Twitter: @yyh-gl Twitter: @yyh-gl 運営：DMM.go 運営：DMM.go 3 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

今⽇話すこと今⽇話すこと私が所属するPointClub チームにて、私が所属するPointClub チームにて、事業をグロースさせていくために⼤事にしている考え事業をグロースさせていくために⼤事にしている考えを主題に置き、を主題に置き、エンジニアとしてなにができるのか、実際なにをしているのかエンジニアとしてなにができるのか、実際なにをしているのかを話しますを話しますやってみて得られた結果も共有できればと思いますやってみて得られた結果も共有できればと思います 5 5

Slide 6

Slide 6 text

開発体制開発体制 6 6

Slide 7

Slide 7 text

PointClub チーム PointClub チーム開発スタイル：アジャイル開発スタイル：アジャイルチームメンバー：13 名ほどチームメンバー：13 名ほどバックエンド：6 名バックエンド：6 名ネイティブ，プロダクトデザイナー，グロース/ マーケティングなどネイティブ，プロダクトデザイナー，グロース/ マーケティングなど 7 7

Slide 8

Slide 8 text

チームとして⼤事にしている考えチームとして⼤事にしている考え 8 8

Slide 9

Slide 9 text

" 最短距離でリリース" " 最短距離でリリース" 最短距離でのリリースを続けることで事業をグロースさせていく最短距離でのリリースを続けることで事業をグロースさせていく弊チーム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

Slide 10

Slide 10 text

エンジニアとしてできることエンジニアとしてできることスピード感ある開発スピード感ある開発⼿戻りをなくす⼿戻りをなくす⾃動化⾃動化 100% は無理でも最⼤限頑張る 100% は無理でも最⼤限頑張る 10 10

Slide 11

Slide 11 text

⼿戻りをなくす⼿戻りをなくす 11 11

Slide 12

Slide 12 text

⼿戻りはだいたい認識差異から⽣まれる⼿戻りはだいたい認識差異から⽣まれる例えば例えば仕様の認識差異仕様の認識差異 → 表⽰したい情報が違う → 表⽰したい情報が違う技術的な認識差異技術的な認識差異 → 必要な情報がAPI レスポンスに含まれていない → 必要な情報がAPI レスポンスに含まれていないと思ったら、使っている単語が違うだけでちゃんと渡してたり… と思ったら、使っている単語が違うだけでちゃんと渡してたり… このような状況では、話し合いや修正が必要になり、⼿戻りが発⽣このような状況では、話し合いや修正が必要になり、⼿戻りが発⽣⼀発でばしっと決められると嬉しい⼀発でばしっと決められると嬉しいでは、なにをすればいいのか ▶▶▶ では、なにをすればいいのか ▶▶▶ 12 12

Slide 13

Slide 13 text

仕様の認識差異をなくす仕様の認識差異をなくす 13 13

Slide 14

Slide 14 text

なぜ仕様の認識差異が⽣まれる？なぜ仕様の認識差異が⽣まれる？仕様の認識差異は、チームメンバー間（特にPO↔ エンジニア間）で、仕様の認識差異は、チームメンバー間（特にPO↔ エンジニア間）で、なにを作るかが⼀致していない場合に発⽣なにを作るかが⼀致していない場合に発⽣エンジニアがエンジニアがなになにを作っているのか明確に意識できていれば発⽣しづらいを作っているのか明確に意識できていれば発⽣しづらいそして、「なにを作るか」はそして、「なにを作るか」はなぜなぜ作るかが分かっていると理解しやすい作るかが分かっていると理解しやすい 14 14

Slide 15

Slide 15 text

まずは「なぜ」を統⼀まずは「なぜ」を統⼀なぜなぜ作るかの認識を統⼀するために作るかの認識を統⼀するためにみんなでユーザーストーリーマッピングを作成みんなでユーザーストーリーマッピングを作成することが有効することが有効ユーザーストーリーマッピング：ユーザーストーリーマッピング：どういう機能が必要か、どのタイミングで提供すべきかといった情報をどういう機能が必要か、どのタイミングで提供すべきかといった情報をユーザーストーリー（≒ユーザーにとっての価値）に対応させて表現可能ユーザーストーリー（≒ユーザーにとっての価値）に対応させて表現可能 15 15

Slide 16

Slide 16 text

ユーザーストーリーマッピングユーザーストーリーマッピング 16 16

Slide 17

Slide 17 text

ユーザーストーリーマッピングユーザーストーリーマッピング 17 17

Slide 18

Slide 18 text

ユーザーストーリーマッピングユーザーストーリーマッピング 18 18

Slide 19

Slide 19 text

ユーザーストーリーマッピングユーザーストーリーマッピング 19 19

Slide 20

Slide 20 text

ユーザーストーリーマッピングユーザーストーリーマッピング 20 20

Slide 21

Slide 21 text

ユーザーストーリーマッピングユーザーストーリーマッピング 21 21

Slide 22

Slide 22 text

ユーザーストーリーマッピングの恩恵ユーザーストーリーマッピングの恩恵今作っている機能が、ユーザーのどういったストーリーに紐づくのかが明確になる今作っている機能が、ユーザーのどういったストーリーに紐づくのかが明確になる → → なぜなぜその機能が必要なのかが明確になるので、迷⼦になりにくいその機能が必要なのかが明確になるので、迷⼦になりにくい 22 22

Slide 23

Slide 23 text

「なに」を統⼀「なに」を統⼀なになにを作るかの認識を統⼀するために、みんなでデザインをレビューを作るかの認識を統⼀するために、みんなでデザインをレビュー Figma 上でデザインを確認可能 Figma 上でデザインを確認可能 23 23

Slide 24

Slide 24 text

実際にこうした取り組みをやってみての感想実際にこうした取り組みをやってみての感想メンバー間の認識差異は少ない（… はず！）メンバー間の認識差異は少ない（… はず！）加えて、なにをなぜ作るか理解していれば、各エンジニアから仕様部分での改善策が出てき加えて、なにをなぜ作るか理解していれば、各エンジニアから仕様部分での改善策が出てきやすくなるやすくなる開発が始まってから、認識差異が⾒つかったとしても、開発が始まってから、認識差異が⾒つかったとしても、ユーザーストーリーマッピングやデザインという共通⾔語があるため、ユーザーストーリーマッピングやデザインという共通⾔語があるため、解決のための会話がスムーズに進む解決のための会話がスムーズに進む 24 24

Slide 25

Slide 25 text

より詳しい話は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

Slide 26

Slide 26 text

技術的な認識差異をなくす技術的な認識差異をなくす 26 26

Slide 27

Slide 27 text

技術的な認識差異をなくすために技術的な認識差異をなくすために⽇常的な認識合わせ⽇常的な認識合わせ廃らないドキュメント作り廃らないドキュメント作り 27 27

Slide 28

Slide 28 text

⽇常的な認識合わせ⽇常的な認識合わせ 28 28

Slide 29

Slide 29 text

API 定義レビュー API 定義レビュー API 定義に変更があったときはクライアントとバックエンドの両メンバーでレビュー API 定義に変更があったときはクライアントとバックエンドの両メンバーでレビュー API 定義にはOpenAPI （Swagger ）を使⽤ API 定義にはOpenAPI （Swagger ）を使⽤クライアントとバックエンド間でAPI 定義に関する認識が常に⼀致クライアントとバックエンド間でAPI 定義に関する認識が常に⼀致 29 29

Slide 30

Slide 30 text

API 定義を確認する⽅法 API 定義を確認する⽅法 API 定義はSwagger UI を通して確認可能 API 定義はSwagger UI を通して確認可能 Swagger UI ⾃体はS3 でホスティングされており、いつでもだれでもアクセス可能 Swagger UI ⾃体はS3 でホスティングされており、いつでもだれでもアクセス可能 30 30

Slide 31

Slide 31 text

みんなでレビューすることで… みんなでレビューすることで… みんなで認識合わせをする機会（仕組み）を作ることによりみんなで認識合わせをする機会（仕組み）を作ることによりメンバー間の認識が⼤きくずれることをなくし、⼿戻りを防⽌メンバー間の認識が⼤きくずれることをなくし、⼿戻りを防⽌加えて、異なる領域のメンバーがレビューすることで、加えて、異なる領域のメンバーがレビューすることで、様々な視点からの意⾒がもらえる（品質向上）様々な視点からの意⾒がもらえる（品質向上）もしかして毎回openapi.yaml （ドキュメント）を⼿で更新してる… ？もしかして毎回openapi.yaml （ドキュメント）を⼿で更新してる… ？ → API 定義ドキュメントをどうやって⽣成し、共有しているかは後述 → API 定義ドキュメントをどうやって⽣成し、共有しているかは後述 31 31

Slide 32

Slide 32 text

技術的な認識差異をなくすために技術的な認識差異をなくすために⽇常的な認識合わせ⽇常的な認識合わせ廃らないドキュメント作り廃らないドキュメント作り 32 32

Slide 33

Slide 33 text

廃らないドキュメント作り廃らないドキュメント作り 33 33

Slide 34

Slide 34 text

ドキュメントを廃れさせないためにできることドキュメントを廃れさせないためにできること廃れたドキュメント＝内容が現実と乖離しているドキュメント廃れたドキュメント＝内容が現実と乖離しているドキュメントしたがって、常に" 現実" を基にドキュメントを作り続ければ廃れることはないしたがって、常に" 現実" を基にドキュメントを作り続ければ廃れることはない弊チームでは以下のドキュメントについて、弊チームでは以下のドキュメントについて、コードを基に⽣成することで現実に則したドキュメントを⽣成コードを基に⽣成することで現実に則したドキュメントを⽣成 API 定義 API 定義 DB スキーマ定義 DB スキーマ定義加えて、継続的にドキュメント⽣成する仕組み（⽣成⾃動化）により、加えて、継続的にドキュメント⽣成する仕組み（⽣成⾃動化）により、ドキュメントを常に更新し、⾵化を防⽌ドキュメントを常に更新し、⾵化を防⽌ ▶ ⾃動化周りの詳細は後述 ▶ ⾃動化周りの詳細は後述 34 34

Slide 35

Slide 35 text

ここまでのまとめここまでのまとめ⼿戻り防⽌を⽬的として、いろいろやってきた⼿戻り防⽌を⽬的として、いろいろやってきたユーザーストーリーマッピングやデザインレビューで仕様の認識を合わせ、ユーザーストーリーマッピングやデザインレビューで仕様の認識を合わせ、⽇常的なレビューと廃れたドキュメントを作らない仕組み作りにより、⽇常的なレビューと廃れたドキュメントを作らない仕組み作りにより、技術的な認識を合わせた技術的な認識を合わせたただし、これらの取り組みや仕組みを⼈の⼿作業だけで継続するのは難しいので、ただし、これらの取り組みや仕組みを⼈の⼿作業だけで継続するのは難しいので、簡素化してあげることが⼤事簡素化してあげることが⼤事つまり、⼈がやらなくて良い部分は機械に任せるつまり、⼈がやらなくて良い部分は機械に任せる 35 35

Slide 36

Slide 36 text

⾃動化⾃動化 36 36

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

より詳細は… より詳細は… 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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

⽣成物：テーブル⼀覧⽣成物：テーブル⼀覧 40 40

Slide 41

Slide 41 text

⽣成物：テーブル詳細⽣成物：テーブル詳細 41 41

Slide 42

Slide 42 text

⽣成物：全テーブルの関連⽣成物：全テーブルの関連 42 42

Slide 43

Slide 43 text

⽣成物：概要（README.md ）⽣成物：概要（README.md ） README.md README.md にDB 全体のスキーマ定義を出⼒にDB 全体のスキーマ定義を出⼒ 43 43

Slide 44

Slide 44 text

DB スキーマ定義のドキュメントを共有 DB スキーマ定義のドキュメントを共有⽣成されたドキュメントは、⽣成されたドキュメントは、アプリケーションコードとは別のGitHub リポジトリにPUSH アプリケーションコードとは別のGitHub リポジトリにPUSH ドキュメントはsvg およびマークダウン形式なので、GitHub と相性が良いドキュメントはsvg およびマークダウン形式なので、GitHub と相性が良い 44 44

Slide 45

Slide 45 text

おまけ：リリースノート作成を⾃動化おまけ：リリースノート作成を⾃動化リリース管理のために、PRD リリース時にリリースノートを作成しているリリース管理のために、PRD リリース時にリリースノートを作成している作成⾃体は作成⾃体はgoreleaser/goreleaser goreleaser/goreleaser (https://github.com/goreleaser/goreleaser) (https://github.com/goreleaser/goreleaser) というGo 製ツールを使⽤というGo 製ツールを使⽤ CI に組み込んでおり、タグPUSH をトリガーにリリースノートを⽣成 CI に組み込んでおり、タグPUSH をトリガーにリリースノートを⽣成 45 45

Slide 46

Slide 46 text

⾃動化により… ⾃動化により… ⽇常的な認識合わせにかかる⼿間を削減⽇常的な認識合わせにかかる⼿間を削減廃れないドキュメントを実現廃れないドキュメントを実現⼈にしかできない作業に集中⼈にしかできない作業に集中⼈的ミスの排除⼈的ミスの排除 46 46

Slide 47

Slide 47 text

まとめまとめ事業グロースのために最短距離でリリース事業グロースのために最短距離でリリース最短距離でリリースするための取り組みを紹介し、それぞれ効果を実感最短距離でリリースするための取り組みを紹介し、それぞれ効果を実感⼿戻りをなくすための努⼒⼿戻りをなくすための努⼒みんなでユーザーストーリーマッピング作成みんなでユーザーストーリーマッピング作成みんなでデザインレビューみんなでデザインレビューみんなでAPI 定義レビューみんなでAPI 定義レビュー⾃動化によって上記の取り組みをサポート⾃動化によって上記の取り組みをサポート API 定義のドキュメント化 API 定義のドキュメント化 DB スキーマ定義のドキュメント化 DB スキーマ定義のドキュメント化（リリース作業）（リリース作業） 47 47

Slide 48

Slide 48 text

Thank you Thank you プラットフォーム事業本部プラットフォーム事業本部本⽥雄亮本⽥雄亮 2020 年11 ⽉30 ⽇ 2020 年11 ⽉30 ⽇ PF-Meetup PF-Meetup