レシピサービスにおける持続的なプロダクト開発プロセスについて / Sustainable Product Development Process in Cookpad

by Eisuke Oishi

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

レシピサービスにおける持続的なプロダクト開発プロセスについて大石英介・島朋代レシピサービス開発部 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 今日お話しすること

Slide 5

Slide 5 text

5 大規模サービスを支える組織と開発プロセスのリデザイン

Slide 6

Slide 6 text

6 レシピサービス？

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

10 377 約万品国内の投稿レシピ数国内の投稿つくれぽ数 2,500 約万件国内の月間利用者数 5,200 約万人 ※ レシピを見て作った人のおすすめレポート ※

Slide 11

Slide 11 text

11 レシピサービスが実現していること

Slide 12

Slide 12 text

12 なぜ、開発プロセスのリデザインが必要なのか？

Slide 13

Slide 13 text

Slide 14

Slide 14 text

14 そこから1年

Slide 15

Slide 15 text

15 なんか思うように開発が進まない...？🙄🥴🥺😰

Slide 16

Slide 16 text

16 時を同じくして…

Slide 17

Slide 17 text

Slide 18

Slide 18 text

18 なにかがおかしい・・・🤔

Slide 19

Slide 19 text

19 組織として、問題解決しないとマズい 🤯

Slide 20

Slide 20 text

20 問題の解像度を上げる取り組み

Slide 21

Slide 21 text

21 課題と指針を言語化

Slide 22

Slide 22 text

22 歴代の責任者と振り返る

Slide 23

Slide 23 text

23 メンバーと振り返る

Slide 24

Slide 24 text

24 浮き彫りになった3つの問題 🔎

Slide 25

Slide 25 text

・開発進行の属人化・期限ドリブン・情報の透明性のなさ 25 1. 無理を強いる開発進行

Slide 26

Slide 26 text

26 2. 技術的なコストを事業として考慮できていない・事業からの運用コスト・技術負債の認識がない・大規模プロジェクトによって残された負債

Slide 27

Slide 27 text

27 ・技術戦略の共有不足・アーキテクチャと組織の不一致 3. 技術戦略面のミスコミュニケーション

Slide 28

Slide 28 text

28 解決へ向けてのアクション

Slide 29

Slide 29 text

29 ・巨大なコードベース(cookpad_all) とマイクロサービス(20個以上) ・エンジニア30名、総勢50名の組織アクションの制約規模を考慮する開発を止めない・負債解消プロジェクトではない・持続的、組織的に取り組める体制を作る・ユーザーへ良いプロダクトを提供し続けることが目的

Slide 30

Slide 30 text

プロダクトバックログの20%は開発のためのアイテム 30 スクラムの導入機能開発を止めずに技術的課題を解決するプロセスの型をつくる開発スピードや効率をプロセスの側面から上げる

Slide 31

Slide 31 text

31 技術基盤組織をプロダクト開発組織と同じ組織に技術部から3つの基盤チームをプロダクト開発部へ編入検索基盤チームを新設

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

34 定期的な機能の棚卸しとクローズ判断通称「サービス継続確認会」成長戦略があるかどうかが継続・廃止の検討基準クローズアクションはバックログに積み実行する

Slide 35

Slide 35 text

35 アクションの結果

Slide 36

Slide 36 text

1. 無理を強いる開発進行 36 結果・スクラム導入で、コミュニケーションや意思決定がスムーズになった・定期的な振り返りにより、主体的にプロセス改善が可能になった・バックログで情報が透明化され、ゴールに対する解像度が向上した

Slide 37

Slide 37 text

2. 技術的なコストを事業として考慮できていない 37 結果・サービス継続確認会・プロダクトバックログにより、コストや技術課題を　見える化できた・事業責任者がプロダクトバックログを通じ、技術的なコストへの投資判断　をする仕組みができた・コストを踏まえた施策設計が行えるようになった

Slide 38

Slide 38 text

3. 技術戦略面のミスコミュニケーション 38 結果・技術基盤チームと機能開発チームが距離が近くなり、コミュニケーションコスト　が下がった・共通のゴールを持つことで、ミスコミュニケーションが起きづらくなった・事業方針と技術戦略の双方を考慮した組織づくりが行えるようになった

Slide 39

Slide 39 text

39 そして、今

Slide 40

Slide 40 text

40 あの日の行き詰まりを完全に乗り越えた

Slide 41

Slide 41 text

41 持続的なプロダクト開発環境とはプロダクトゴールや方針だけでなく、組織、システム、文化も一緒にアップデートされ続ける環境 🤝

Slide 42

Slide 42 text

42 ・エンジニア・技術部門にしか見えなかった部分を組織として見えるようにした・組織としてマイナスの価値の部分にちゃんと目を向ける考察: 技術的な情報非対称の解消

Slide 43

Slide 43 text

43 考察: 技術的な情報非対称の解消・エンジニア・技術部門にしか見えなかった部分を組織として見えるようにした・組織としてマイナスの価値の部分にちゃんと目を向ける

Slide 44

Slide 44 text

44 最後に

Slide 45

Slide 45 text

45 この取組みに関連する発表資料 ● このセッション後：宮崎「巨大なレシピサービスのアーキテクチャを最高にしたい」 ● ポスター展示：「今日、なにつくろう？　日本の毎日の料理を支えるレシピ検索」 ● Cookpad Lounge #14 レシピサービスの根幹を支える！検索エンジニア座談会 ● Cookpad Lounge #15 After Kaigi on Rails（スクラムについての話題） ● @ukstudio 今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022