$30 off During Our Annual Pro Sale. View Details »

事業をグロースさせるためにエンジニアができること / What engineers c...

yyh_gl
November 30, 2020

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

yyh_gl

November 30, 2020
Tweet

More Decks by yyh_gl

Other Decks in Programming

Transcript

  1. 本⽥ 雄亮(Honda Yusuke ) 本⽥ 雄亮(Honda Yusuke ) 所属:プラットフォーム事業本部 総合トップ開発部

    PointClub チーム 所属:プラットフォーム事業本部 総合トップ開発部 PointClub チーム ⼊社年:2019 年(新卒⼊社) ⼊社年:2019 年(新卒⼊社) Twitter: @yyh-gl Twitter: @yyh-gl 運営:DMM.go 運営:DMM.go 3 3
  2. 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
  3. PointClub チーム PointClub チーム 開発スタイル:アジャイル 開発スタイル:アジャイル チームメンバー:13 名ほど チームメンバー:13 名ほど

    バックエンド:6 名 バックエンド:6 名 ネイティブ,プロダクトデザイナー,グロース/ マーケティング など ネイティブ,プロダクトデザイナー,グロース/ マーケティング など 7 7
  4. " 最短距離でリリース" " 最短距離でリリース" 最短距離でのリリースを続けることで事業をグロースさせていく 最短距離でのリリースを続けることで事業をグロースさせていく 弊チーム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
  5. ⼿戻りはだいたい認識差異から⽣まれる ⼿戻りはだいたい認識差異から⽣まれる 例えば 例えば 仕様の認識差異 仕様の認識差異 → 表⽰したい情報が違う → 表⽰したい情報が違う

    技術的な認識差異 技術的な認識差異 → 必要な情報がAPI レスポンスに含まれていない → 必要な情報がAPI レスポンスに含まれていない と思ったら、使っている単語が違うだけでちゃんと渡してたり… と思ったら、使っている単語が違うだけでちゃんと渡してたり… このような状況では、話し合いや修正が必要になり、⼿戻りが発⽣ このような状況では、話し合いや修正が必要になり、⼿戻りが発⽣ ⼀発でばしっと決められると嬉しい ⼀発でばしっと決められると嬉しい では、なにをすればいいのか ▶▶▶ では、なにをすればいいのか ▶▶▶ 12 12
  6. なぜ仕様の認識差異が⽣まれる? なぜ仕様の認識差異が⽣まれる? 仕様の認識差異は、チームメンバー間(特にPO↔ エンジニア間)で、 仕様の認識差異は、チームメンバー間(特にPO↔ エンジニア間)で、 なにを作るかが⼀致していない場合に発⽣ なにを作るかが⼀致していない場合に発⽣ エンジニアが エンジニアがなに

    なにを作っているのか明確に意識できていれば発⽣しづらい を作っているのか明確に意識できていれば発⽣しづらい そして、「なにを作るか」は そして、「なにを作るか」はなぜ なぜ作るかが分かっていると理解しやすい 作るかが分かっていると理解しやすい 14 14
  7. まずは「なぜ」を統⼀ まずは「なぜ」を統⼀ なぜ なぜ作るかの認識を統⼀するために 作るかの認識を統⼀するために みんなでユーザーストーリーマッピングを作成 みんなでユーザーストーリーマッピングを作成 することが有効 することが有効 ユーザーストーリーマッピング:

    ユーザーストーリーマッピング: どういう機能が必要か、どのタイミングで提供すべきかといった情報を どういう機能が必要か、どのタイミングで提供すべきかといった情報を ユーザーストーリー(≒ユーザーにとっての価値)に対応させて表現可能 ユーザーストーリー(≒ユーザーにとっての価値)に対応させて表現可能 15 15
  8. 実際にこうした取り組みをやってみての感想 実際にこうした取り組みをやってみての感想 メンバー間の認識差異は少ない(… はず!) メンバー間の認識差異は少ない(… はず!) 加えて、なにをなぜ作るか理解していれば、各エンジニアから仕様部分での改善策が出てき 加えて、なにをなぜ作るか理解していれば、各エンジニアから仕様部分での改善策が出てき やすくなる やすくなる

    開発が始まってから、認識差異が⾒つかったとしても、 開発が始まってから、認識差異が⾒つかったとしても、 ユーザーストーリーマッピングやデザインという共通⾔語があるため、 ユーザーストーリーマッピングやデザインという共通⾔語があるため、 解決のための会話がスムーズに進む 解決のための会話がスムーズに進む 24 24
  9. API 定義レビュー API 定義レビュー API 定義に変更があったときはクライアントとバックエンドの両メンバーでレビュー API 定義に変更があったときはクライアントとバックエンドの両メンバーでレビュー API 定義にはOpenAPI

    (Swagger )を使⽤ API 定義にはOpenAPI (Swagger )を使⽤ クライアントとバックエンド間でAPI 定義に関する認識が常に⼀致 クライアントとバックエンド間でAPI 定義に関する認識が常に⼀致 29 29
  10. API 定義を確認する⽅法 API 定義を確認する⽅法 API 定義はSwagger UI を通して確認可能 API 定義はSwagger

    UI を通して確認可能 Swagger UI ⾃体はS3 でホスティングされており、いつでもだれでもアクセス可能 Swagger UI ⾃体はS3 でホスティングされており、いつでもだれでもアクセス可能 30 30
  11. ドキュメントを廃れさせないためにできること ドキュメントを廃れさせないためにできること 廃れたドキュメント=内容が現実と乖離しているドキュメント 廃れたドキュメント=内容が現実と乖離しているドキュメント したがって、常に" 現実" を基にドキュメントを作り続ければ廃れることはない したがって、常に" 現実" を基にドキュメントを作り続ければ廃れることはない

    弊チームでは以下のドキュメントについて、 弊チームでは以下のドキュメントについて、 コードを基に⽣成することで現実に則したドキュメントを⽣成 コードを基に⽣成することで現実に則したドキュメントを⽣成 API 定義 API 定義 DB スキーマ定義 DB スキーマ定義 加えて、継続的にドキュメント⽣成する仕組み(⽣成⾃動化)により、 加えて、継続的にドキュメント⽣成する仕組み(⽣成⾃動化)により、 ドキュメントを常に更新し、⾵化を防⽌ ドキュメントを常に更新し、⾵化を防⽌ ▶ ⾃動化周りの詳細は後述 ▶ ⾃動化周りの詳細は後述 34 34
  12. ここまでのまとめ ここまでのまとめ ⼿戻り防⽌を⽬的として、いろいろやってきた ⼿戻り防⽌を⽬的として、いろいろやってきた ユーザーストーリーマッピングやデザインレビューで仕様の認識を合わせ、 ユーザーストーリーマッピングやデザインレビューで仕様の認識を合わせ、 ⽇常的なレビューと廃れたドキュメントを作らない仕組み作りにより、 ⽇常的なレビューと廃れたドキュメントを作らない仕組み作りにより、 技術的な認識を合わせた 技術的な認識を合わせた

    ただし、これらの取り組みや仕組みを⼈の⼿作業だけで継続するのは難しいので、 ただし、これらの取り組みや仕組みを⼈の⼿作業だけで継続するのは難しいので、 簡素化してあげることが⼤事 簡素化してあげることが⼤事 つまり、⼈がやらなくて良い部分は機械に任せる つまり、⼈がやらなくて良い部分は機械に任せる 35 35
  13. 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
  14. より詳細は… より詳細は… 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
  15. 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
  16. おまけ:リリースノート作成を⾃動化 おまけ:リリースノート作成を⾃動化 リリース管理のために、PRD リリース時にリリースノートを作成している リリース管理のために、PRD リリース時にリリースノートを作成している 作成⾃体は 作成⾃体はgoreleaser/goreleaser goreleaser/goreleaser (https://github.com/goreleaser/goreleaser)

    (https://github.com/goreleaser/goreleaser) というGo 製ツールを使⽤ というGo 製ツールを使⽤ CI に組み込んでおり、タグPUSH をトリガーにリリースノートを⽣成 CI に組み込んでおり、タグPUSH をトリガーにリリースノートを⽣成 45 45
  17. まとめ まとめ 事業グロースのために最短距離でリリース 事業グロースのために最短距離でリリース 最短距離でリリースするための取り組みを紹介し、 それぞれ効果を実感 最短距離でリリースするための取り組みを紹介し、 それぞれ効果を実感 ⼿戻りをなくすための努⼒ ⼿戻りをなくすための努⼒

    みんなでユーザーストーリーマッピング作成 みんなでユーザーストーリーマッピング作成 みんなでデザインレビュー みんなでデザインレビュー みんなでAPI 定義レビュー みんなでAPI 定義レビュー ⾃動化によって上記の取り組みをサポート ⾃動化によって上記の取り組みをサポート API 定義のドキュメント化 API 定義のドキュメント化 DB スキーマ定義のドキュメント化 DB スキーマ定義のドキュメント化 (リリース作業) (リリース作業) 47 47