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

Transcript

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

   View Slide

2. ⾃⼰紹介
   ⾃⼰紹介
   2
   2
   

   View Slide

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

   View Slide

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
   

   View Slide

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

   View Slide

6. 開発体制
   開発体制
   6
   6
   

   View Slide

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

   View Slide

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

   View Slide

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
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. ⾃動化
    ⾃動化
    36
    36
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide