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

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

Eisuke Oishi
December 01, 2022

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

2022.11.25 Cookpad TechConf 2022 https://techconf.cookpad.com/2022/

Eisuke Oishi

December 01, 2022
Tweet

More Decks by Eisuke Oishi

Other Decks in Technology

Transcript

  1. View Slide

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

    View Slide

  3. 3

    View Slide

  4. 4
    今日お話しすること

    View Slide

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

    View Slide

  6. 6
    レシピサービス?

    View Slide

  7. 7

    View Slide

  8. 8

    View Slide

  9. 9

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  13. 13

    View Slide

  14. 14
    そこから1年

    View Slide

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

    View Slide

  16. 16
    時を同じくして…

    View Slide

  17. 17

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  21. 21
    課題と指針を言語化

    View Slide

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

    View Slide

  23. 23
    メンバーと振り返る

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  32. 32

    View Slide

  33. 33

    View Slide

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

    View Slide

  35. 35
    アクションの結果

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. 39
    そして、今

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  44. 44
    最後に

    View Slide

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

    View Slide

  46. 46
    ご清聴ありがとうございました😆

    View Slide

  47. View Slide