スクラム開発導入による他組織を巻き込んだ開発生産性向上の取り込み

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 (C) Recruit Co., Ltd. All rights reserved. 自己紹介橋本健史株式会社リクルートプロダクトディベロップメント室ビューティー領域開発ディレクション部ビューティー開発ディレクショングループ • 2017年株式会社野村総合研究所新卒入社 • Webシステムの設計開発に携わる • 2020年株式会社リクルートキャリア入社 • 『HOT PEPPER Beauty 美容クリニック』開発チーム所属 • 2020年〜バックエンド開発担当 • 2022年〜開発チームリーダー担当

Slide 3

Slide 3 text

3 本日お話しすることリクルートの美容領域の1プロダクトである『HOT PEPPER Beauty 美容クリニック』における開発生産性向上の取り組み事例の紹介『HOT PEPPER Beauty 美容クリニック』では、昨年度からスクラム開発による短期間のSprint ベースのプロセスを装着し、開発リードタイム短縮、リリース頻度向上を実現してきました。本セッションでは、スクラム開発導入に至った背景や、他組織を巻き込んだプロセス変更の進め方、リードタイム短縮のために行っていることを具体的な事例と共に紹介いたします。 (C) Recruit Co., Ltd. All rights reserved.

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 (C) Recruit Co., Ltd. All rights reserved. プロダクト紹介 • 『HOT PEPPER Beauty 美容クリニック』（以降、美容クリニック） • 場所や悩み、施術方法などから行きたい美容クリニックを検索し、カウンセリングの予約をすることができるサービス • ホットペッパービューティーの新ジャンルとして2020年3月より提供開始 • クリニック掲載数約1800件 https://clinic.beauty.hotpepper.jp/

Slide 7

Slide 7 text

7 プロダクトの状況と課題 • これまでのプロダクト戦略 • 初期リリース以降、即時予約機能、商品リニューアルを始めとする様々な機能の追加開発を実施してきた • 作るべきものが明確であり、計画性が求められる案件が多かったことからウォーターフォール開発を採用して一括で開発〜リリースを実施していた (C) Recruit Co., Ltd. All rights reserved. https://jihiken.jp/newstopics/newstopics-63478/ https://clinic.beauty.hotpepper.jp/media/theme/sokujiyoyaku/index.html

Slide 8

Slide 8 text

8 プロダクトの状況と課題 • 既存の機能開発チーム編成 • 案件の規模感に応じたチーム分け • 大規模案件開発チーム：案件毎にチームを組織し、エンハンス案件を計画的に実施 • 小規模案件開発チーム：固定チームで小規模なエンハンス・保守案件を実施し、毎月リリースを行う (C) Recruit Co., Ltd. All rights reserved. どちらのチームもウォーターフォールの開発プロセスを採用

Slide 9

Slide 9 text

9 プロダクトの状況と課題 • 今後のプロダクト戦略 • 目的不確実性が低い機能の開発は優先度高く対応してきたため、ある程度実施済みの状況 • これからは仮説検証を繰り返し、ユーザからのフィードバックを得ながら探索的に作るべきものを見つけていきたいといった事業背景があった • 美容クリニックの抱えている課題 • 案件を遂行する上でウォーターフォールの開発プロセスしか選択肢がなく、開発リードタイムが長くなってしまうことにより、小さく早く案件をリリースするということができなくなっていた (C) Recruit Co., Ltd. All rights reserved.

Slide 10

Slide 10 text

10 開発リードタイムが長くなっていた要因 • ウォーターフォールの開発プロセス • 何を作るかの不確実性を減らした上で計画的に作っていく (C) Recruit Co., Ltd. All rights reserved. • 現状の美容クリニックにおいては、UI/UX改善のような施策においても、カスタマ要求に対して漏れなく要件を敷き詰めることでニーズ解決の蓋然性を高め、不確実性を減らすスタイルになっていた →一度に開発する機能スコープが大きくなり、工数、工期が増える傾向に https://book.mynavi.jp/ec/products/detail/id=22141

Slide 11

Slide 11 text

11 開発リードタイムが長くなっていた要因 • リソース効率重視の考え方 (C) Recruit Co., Ltd. All rights reserved. https://www.slideshare.net/slideshow/ver11-248298311/248298311#15 リソース効率・スループット的な速さ・1リソースが生み出す価値を大きく・価値を提供するまでのリードタイムは長くなるフロー効率・リードタイム的な速さ・価値を提供するまでの時間を小さく・価値の提供に必要なリソースの量は増える

Slide 12

Slide 12 text

12 開発リードタイムが長くなっていた要因 • 既存の枠組みの中での改善 • ウォーターフォール開発の中でも工数・工期の短縮、スコープ削減の取り組みなどを行ってきたものの、大きな効果は出ない状況 • また、開発リードタイムが長いことも一要因として、案件スコープが大きくなり、案件が大規模化、さらなるリードタイム延伸へと繋がってしまっていた (C) Recruit Co., Ltd. All rights reserved. 開発リードタイムが長くなる案件スコープが大きくなる案件の大規模化・スコープが大きくなる要因・まとめて作ったほうがオーバーヘッドが少なくリソース観点で効率がいいというリソース効率重視の考え方・リードタイムが長いことにより、スコープアウトした機能をすぐにリリースできないので、スコープを削りづらくなる・その結果、スコープが肥大化し、案件の大規模化、工数、工期が増大し、さらなるリードタイムの延伸へ

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

23 開発主導でスコープ調整 • 今回の取り組みの目的はスクラム開発を導入することではなく、小さく早くユーザに価値を届けること • Sprint毎に価値のある単位で開発〜リリースができるように、スコープの刻み方を検討 (C) Recruit Co., Ltd. All rights reserved. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 具体の開発の流れ • 1週間のSprintにおける開発フロー (C) Recruit Co., Ltd. All rights reserved. 開発チーム全員でプロダクトを触りバグを見つけるイベント Sprint Reviewの形式の1つ Sprintで開発した成果物を実際に動く形でデモをしながら共有し、ユーザー目線と近い形でステークホルダーに見てもらうことで、フィードバックをもらいやすくする

Slide 30

Slide 30 text

Slide 31

Slide 31 text

31 最初にスクラムを導入した案件における効果 5ヶ月で作れる機能で目指していた目標値を、2週間で作れる機能に限定しても150%達成でき、必要最低限の機能に絞っても十分にユーザのニーズを満たせることがわかった！ →成功事例ができた状態で正式にスクラム開発チームを立ち上げていき、企画チームと一緒にプロセスの変更、装着を実施していった (C) Recruit Co., Ltd. All rights reserved.

Slide 32

Slide 32 text

Slide 33

Slide 33 text

33 リードタイム短縮の進め方 • 1Sprintのタイムボックスを1週間に設定して開発を回すことを前提におき、既存のやり方にとらわれずに1週間で開発を回すにはどうすればいいか検討していった • 成功事例作りフェーズにおいて、1週間で動くものを作ることを最優先とし、スピード最優先のプロセスで開発を実施していった • 検査と適応を繰り返しながら、開発フロー上のボトルネックに対処していくことで、リードタイム短縮に取り組んでいます (C) Recruit Co., Ltd. All rights reserved.

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

37 要求定義要件定義設計開発要件定義フェーズにおける取り組み従来の役割分担と開発フロー • 企画Tが要求定義を実施 • 企画T→開発Tに要求をインプットしてもらい、要件定義〜設計開発に進む (C) Recruit Co., Ltd. All rights reserved. 発生していたコスト・漏れがない要求・要件を検討し、成果物を作成するコスト・不備があった場合の手戻りコスト・企画、開発間における要求・要件調整コスト要件定義設計開発テスト

Slide 38

Slide 38 text

38 要件定義フェーズにおける取り組み要求・要件定義成果物を簡素化し、走りながら要件を決めていく • 案件の背景や課題、大まかなシステム要求のみ企画Tに決めてもらい、細かい要件は開発を進めながら開発側で裁量を持って決めていくという動き (C) Recruit Co., Ltd. All rights reserved. • 開発側で案件の目的達成しつつ、低コスト、低難易度で実現できる要件を判断していく →要求・要件の検討、調整、手戻りコストを削減要件定義設計開発テスト要求定義開発設計 Sprint Plannning テスト

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

43 設計開発フェーズにおける取り組み自律的に動けるようにする（自己組織化） • タスクの優先順位の明確化 • 動くものを作ること＞リリースできる状態にすること • 他メンバーのタスク INREVIEW→DONE > 自分のタスク WIP→INREVIEW • タスクを可視化（カンバン） • タスクの進捗状況や依存関係の可視化 • 誰がどのタスクに着手しているのか、どのタスクがボトルネックになってるかを把握しやすくする (C) Recruit Co., Ltd. All rights reserved. 要件定義設計開発テスト

Slide 44

Slide 44 text

Slide 45

Slide 45 text

45 設計開発フェーズにおける取り組みコミュニケーションを円滑化 • 出社、通話を推奨し、困ったらすぐに会話して解決 • ペアプロ、モブプロも積極的に実施 (C) Recruit Co., Ltd. All rights reserved. https://www.researchgate.net/publication/268603161_Psychosemantics_of_Employee's_Images_When_Identifying_a_Typology_Responsibility_and_Communication_of_Organisational_Changes 要件定義設計開発テスト

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

49 テストフェーズにおける取り組み • 開発チームにおけるbugbash形式のテスト • みんなでシステムを触ってバグを見つけるイベント • 受け入れ基準を満たしていることを確認し、最低限の品質を担保 • バグを見つけたら褒める文化 • バグを見つけたらその場で直す • 企画チームによる受入テスト • Sprint Reviewで触ってOKとする場合も • QAチームによるテスト • 重要機能に影響がある場合のみ実施 (C) Recruit Co., Ltd. All rights reserved. 要件定義設計開発テスト

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

54 (C) Recruit Co., Ltd. All rights reserved. 作りすぎのムダの改善 • 毎週案件の優先度を見直し、優先度が高い機能を小刻みにリリースしていくことで、より使われる機能をユーザに届けることができる https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used

Slide 55

Slide 55 text

Slide 56

Slide 56 text

56 まとめ他組織を巻き込んだスクラム開発導入の進め方 • 企画組織を巻き込む上で工夫したポイント • 小さく試し、成功事例を作る • 企画組織にメリットを感じてもらった上で、一緒にプロセスを変えていく • 企画組織からポジティブな反応を多く頂けており、その後の企画組織含めたプロセスの変更を推進しやすくなったと感じております！ • 開発主導でスコープ分割を行い、スコープに関する考え方を揃えに行く • 「一番小さく価値を提供できる単位でリリースする」という認識が揃っているからこそ 1週間のSprintでの開発〜リリースが実現できている (C) Recruit Co., Ltd. All rights reserved.

Slide 57

Slide 57 text

57 まとめ短期間のSprintで開発〜リリースを実現するためのリードタイム短縮の取り組み • 1週間で動くものを作りに行くという目標をたて、既存のやり方にとらわれずにスピード最優先で開発を進められたのが良かったポイント • 一旦スピードに振り切って必要最低限のタスクだけ実施することで、今まで気づかなかったムダなプロセス、成果物に気づくことができる • 検査と適応を繰り返しながら、本当に必要なプロセスの見極めを行いつつ、さらなるリードタイム短縮に取り組んでおります！ (C) Recruit Co., Ltd. All rights reserved.