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

2024/06/29に、開発生産性カンファレンスで発表した、橋本の資料です。

Transcript

1. スクラム開発導入による 他組織を巻き込んだ 開発生産性向上の取り込み (C) Recruit Co., Ltd. All rights reserved. 株式会社リクルート プロダクト統括本部 ビューティー開発ディレクション部 橋本健史 2024年6月29日
2. 2 (C) Recruit Co., Ltd. All rights reserved. 自己紹介 橋本 健史 株式会社リクルート プロダクトディベロップメント室 ビューティー領域開発ディレクション部 ビューティー開発ディレクショングループ • 2017年 株式会社野村総合研究所 新卒入社 • Webシステムの設計開発に携わる • 2020年 株式会社リクルート キャリア入社 • 『HOT PEPPER Beauty 美容クリニック』開発チーム所属 • 2020年〜 バックエンド開発担当 • 2022年〜 開発チームリーダー担当
3. 3 本日お話しすること リクルートの美容領域の1プロダクトである 『HOT PEPPER Beauty 美容クリニック』における開発生産性向上の取り組み 事例の紹介 『HOT PEPPER Beauty 美容クリニック』では、昨年度からスクラム開発による短期間のSprint ベースのプロセスを装着し、開発リードタイム短縮、リリース頻度向上を実現してきました。 本セッションでは、スクラム開発導入に至った背景や、他組織を巻き込んだプロセス変更の進め 方、リードタイム短縮のために行っていることを具体的な事例と共に紹介いたします。 (C) Recruit Co., Ltd. All rights reserved.
4. 4 (C) Recruit Co., Ltd. All rights reserved. アジェンダ 1. スクラム開発導入の背景 2. スクラム開発導入の進め方 3. 開発リードタイム短縮の取り組み 4. 取り組みの効果とまとめ
5. 5 (C) Recruit Co., Ltd. All rights reserved. アジェンダ 1. スクラム開発導入の背景 2. スクラム開発導入の進め方 3. 開発リードタイム短縮の取り組み 4. 取り組みの効果とまとめ
6. 6 (C) Recruit Co., Ltd. All rights reserved. プロダクト紹介 • 『HOT PEPPER Beauty 美容クリニック』 （以降、美容クリニック） • 場所や悩み、施術方法などから行きたい美容クリニックを検索し、カウンセリングの予約 をすることができるサービス • ホットペッパービューティーの新ジャンルとして2020年3月より提供開始 • クリニック掲載数約1800件 https://clinic.beauty.hotpepper.jp/
7. 7 プロダクトの状況と課題 • これまでのプロダクト戦略 • 初期リリース以降、即時予約機能、商品リニューアルを始めとする様々な機能の追加開発 を実施してきた • 作るべきものが明確であり、計画性が求められる案件が多かったことからウォーター フォール開発を採用して一括で開発〜リリースを実施していた (C) Recruit Co., Ltd. All rights reserved. https://jihiken.jp/newstopics/newstopics-63478/ https://clinic.beauty.hotpepper.jp/media/theme/sokujiyoyaku/index.html
8. 8 プロダクトの状況と課題 • 既存の機能開発チーム編成 • 案件の規模感に応じたチーム分け • 大規模案件開発チーム：案件毎にチームを組織し、エンハンス案件を計画的に実施 • 小規模案件開発チーム：固定チームで小規模なエンハンス・保守案件を実施し、毎月リリースを 行う (C) Recruit Co., Ltd. All rights reserved. どちらのチームもウォーターフォールの開発プロセスを採用
9. 9 プロダクトの状況と課題 • 今後のプロダクト戦略 • 目的不確実性が低い機能の開発は優先度高く対応してきたため、ある程度実施済みの状況 • これからは仮説検証を繰り返し、ユーザからのフィードバックを得ながら探索的に作るべ きものを見つけていきたいといった事業背景があった • 美容クリニックの抱えている課題 • 案件を遂行する上でウォーターフォールの開発プロセスしか選択肢がなく、開発リードタ イムが長くなってしまうことにより、小さく早く案件をリリースするということができな くなっていた (C) Recruit Co., Ltd. All rights reserved.
10. 10 開発リードタイムが長くなっていた要因 • ウォーターフォールの開発プロセス • 何を作るかの不確実性を減らした上で計画的に作っていく (C) Recruit Co., Ltd. All rights reserved. • 現状の美容クリニックにおいては、UI/UX改善のような施策においても、カスタマ要求に対して漏れなく 要件を敷き詰めることでニーズ解決の蓋然性を高め、不確実性を減らすスタイルになっていた →一度に開発する機能スコープが大きくなり、工数、工期が増える傾向に https://book.mynavi.jp/ec/products/detail/id=22141
11. 11 開発リードタイムが長くなっていた要因 • リソース効率重視の考え方 (C) Recruit Co., Ltd. All rights reserved. https://www.slideshare.net/slideshow/ver11-248298311/248298311#15 リソース効率 ・スループット的な速さ ・1リソースが生み出す価値を大きく ・価値を提供するまでのリードタイムは 長くなる フロー効率 ・リードタイム的な速さ ・価値を提供するまでの時間を小さく ・価値の提供に必要なリソースの量は増 える
12. 12 開発リードタイムが長くなっていた要因 • 既存の枠組みの中での改善 • ウォーターフォール開発の中でも工数・工期の短縮、スコープ削減の取り組みなどを行っ てきたものの、大きな効果は出ない状況 • また、開発リードタイムが長いことも一要因として、案件スコープが大きくなり、案件が 大規模化、さらなるリードタイム延伸へと繋がってしまっていた (C) Recruit Co., Ltd. All rights reserved. 開発リードタイ ムが長くなる 案件スコープが 大きくなる 案件の大規模化 ・スコープが大きくなる要因 ・まとめて作ったほうがオーバーヘッドが少なく リソース観点で効率がいいというリソース効率重視の考え方 ・リードタイムが長いことにより、スコープアウトした機能を すぐにリリースできないので、スコープを削りづらくなる ・その結果、スコープが肥大化し、案件の大規模化、 工数、工期が増大し、さらなるリードタイムの延伸へ
13. 13 開発リードタイムを抜本的に改善するために アジャイル手法の中でもプラクティスが確立されている スクラム開発の導入検討を開始 (C) Recruit Co., Ltd. All rights reserved.
14. 14 開発リードタイムを抜本的に改善するために • スクラム開発を導入するにあたりどのように他組織を巻き込みつつ、プロセス 変更を進めていったか • 短期間のSprintで開発〜リリースを繰り返すために行なっているリードタイム 短縮の取り組み (C) Recruit Co., Ltd. All rights reserved.
15. 15 (C) Recruit Co., Ltd. All rights reserved. アジェンダ 1. スクラム開発導入の背景 2. スクラム開発導入の進め方 3. 開発リードタイム短縮の取り組み 4. 取り組みの効果とまとめ
16. 16 美容クリニックの組織構成 (C) Recruit Co., Ltd. All rights reserved.
17. 17 スクラムを導入していく上での課題 企画組織の巻き込み方 (C) Recruit Co., Ltd. All rights reserved.
18. 18 なぜ？ • スクラム開発を導入する上で企画組織の協力は必須 • しかし、企画組織はスクラム開発経験者がほぼおらず、導入することで何がど う改善されるのか伝わりづらい状態 • その中で、ウォーターフォールに最適化されたプロセスをスクラム開発のプロ セスに変更することは心理的ハードルが高かった (C) Recruit Co., Ltd. All rights reserved.
19. 19 企画組織を巻き込みやすくするために工夫したポイント 成功事例を作り スクラム開発のメリットを 実感してもらうこと (C) Recruit Co., Ltd. All rights reserved.
20. 20 成功事例を作るために行ったこと • 案件の選定 • 成功確率の高い開発体制の構築 • 開発主導でスコープ調整 (C) Recruit Co., Ltd. All rights reserved.
21. 21 案件の選定 • 案件選定の軸は以下 • ToC 向けのCVR改善案件 • スコープが大きくなってしまっている案件 • 「価格帯で検索する機能を追加する」という案件が上記の軸に合致 (C) Recruit Co., Ltd. All rights reserved. 工数：17人月、工期：5ヶ月
22. 22 成功確率の高い開発体制の構築 少数精鋭のチームでパワーをかけて実績を作りにいく • スクラムへの理解が深いスクラムマスターアサイン • スキル、スタンス的にスクラム開発に適性がある開発メンバーを招集 • 対面でのコミュニケーションを重視 (C) Recruit Co., Ltd. All rights reserved. スクラムマスター 開発チーム 企画チーム（PO） 初期体制
23. 23 開発主導でスコープ調整 • 今回の取り組みの目的はスクラム開発を導入することではなく、小さく早く ユーザに価値を届けること • Sprint毎に価値のある単位で開発〜リリースができるように、スコープの刻み 方を検討 (C) Recruit Co., Ltd. All rights reserved. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
24. 24 開発主導でスコープ調整 スコープ分割の進め方 (C) Recruit Co., Ltd. All rights reserved. 1. 要件を分解し解決したい課題・要求と要件を紐付ける 2. 解決したい課題ベースで優先順位づけ 3. 最小単位でリリースできそうな要件を確定
25. 25 開発主導でスコープ調整 スコープ分割の進め方 1. 要件を分解し解決したい課題・要求と要件を紐付ける (C) Recruit Co., Ltd. All rights reserved.
26. 26 開発主導でスコープ調整 スコープ分割の進め方 2. 解決したい課題ベースで優先順位づけ (C) Recruit Co., Ltd. All rights reserved.
27. 27 開発主導でスコープ調整 スコープ分割の進め方 3. 最小単位でリリースできそうな要件を確定 (C) Recruit Co., Ltd. All rights reserved.
28. 28 (C) Recruit Co., Ltd. All rights reserved. 開発主導でスコープ調整 • 「単にこれだけ実装します」では企画チームの不安は解消できない • 分割した要件を順番にリリースする方向で相談 • 仮説検証とリリースをセットにしたディシジョンツリーを提示 →最小単位で開発〜リリースにTryしてみることを合意した
29. 29 具体の開発の流れ • 1週間のSprintにおける開発フロー (C) Recruit Co., Ltd. All rights reserved. 開発チーム全員でプロダクトを触り バグを見つけるイベント Sprint Reviewの形式の1つ Sprintで開発した成果物を実際に動く形でデモをしな がら共有し、ユーザー目線と近い形でステークホル ダーに見てもらうことで、フィードバックをもらい やすくする
30. 30 最初にスクラムを導入した案件における効果 スコープを分割し、最小単位の機能のみ開発することで、2週間でリリースでき る状態に持っていくことができた！ (C) Recruit Co., Ltd. All rights reserved.
31. 31 最初にスクラムを導入した案件における効果 5ヶ月で作れる機能で目指していた目標値を、2週間で作れる機能に限定 しても150%達成でき、必要最低限の機能に絞っても十分にユーザのニー ズを満たせることがわかった！ →成功事例ができた状態で正式にスクラム開発チームを立ち上げていき、 企画チームと一緒にプロセスの変更、装着を実施していった (C) Recruit Co., Ltd. All rights reserved.
32. 32 (C) Recruit Co., Ltd. All rights reserved. アジェンダ 1. スクラム開発導入の背景 2. スクラム開発導入の進め方 3. 開発リードタイム短縮の取り組み 4. 取り組みの効果とまとめ
33. 33 リードタイム短縮の進め方 • 1Sprintのタイムボックスを1週間に設定して開発を回すことを前提におき、既 存のやり方にとらわれずに1週間で開発を回すにはどうすればいいか検討して いった • 成功事例作りフェーズにおいて、1週間で動くものを作ることを最優先とし、 スピード最優先のプロセスで開発を実施していった • 検査と適応を繰り返しながら、開発フロー上のボトルネックに対処していくこ とで、リードタイム短縮に取り組んでいます (C) Recruit Co., Ltd. All rights reserved.
34. 34 リードタイム短縮の取り組み • １Sprint内における要件定義、設計開発、テストの3つのフェーズ おけるリードタイム短縮の取り組み事例を紹介いたします (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
35. 35 リードタイム短縮の取り組み (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト 要件定義フェーズにおけるリードタイム短縮の取り組み
36. 36 要件定義フェーズにおける取り組み 要求・要件定義成果物を簡素化し 走りながら要件を決めていく (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
37. 37 要求定義 要件定義 設計開発 要件定義フェーズにおける取り組み 従来の役割分担と開発フロー • 企画Tが要求定義を実施 • 企画T→開発Tに要求をインプットしてもらい、要件定義〜設計開発に進む (C) Recruit Co., Ltd. All rights reserved. 発生していたコスト ・漏れがない要求・要件を検討し、成果物を作成するコスト ・不備があった場合の手戻りコスト ・企画、開発間における要求・要件調整コスト 要件定義 設計開発 テスト
38. 38 要件定義フェーズにおける取り組み 要求・要件定義成果物を簡素化し、走りながら要件を決めていく • 案件の背景や課題、大まかなシステム要求のみ企画Tに決めてもらい、細かい要件は開発を進め ながら開発側で裁量を持って決めていくという動き (C) Recruit Co., Ltd. All rights reserved. • 開発側で案件の目的達成しつつ、低コスト、低難易度で実現できる要件を判断していく →要求・要件の検討、調整、手戻りコストを削減 要件定義 設計開発 テスト 要求定義 開発 設計 Sprint Plannning テスト
39. 39 要件定義フェーズにおける取り組み 開発側で要件を決めていく上でのポイント • Sprint Planningでコア価値を定義し、開発チーム内でGoalの認識合わせてお くことで、要件を決める上での判断軸に • 上記判断軸を元に、開発側で決められることは最大限開発側で決めるスタンス を持つ (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
40. 40 リードタイム短縮の取り組み (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト 設計開発フェーズにおけるリードタイム短縮の取り組み
41. 41 設計開発フェーズにおける取り組み 動くものを早く作る (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
42. 42 設計開発フェーズにおける取り組み 動くものを早く作るために工夫していること ①自律的に動けるようにする（自己組織化） ②タスクのボトルネックを解消する ③コミュニケーションを円滑化 (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
43. 43 設計開発フェーズにおける取り組み 自律的に動けるようにする（自己組織化） • タスクの優先順位の明確化 • 動くものを作ること＞リリースできる状態にすること • 他メンバーのタスク INREVIEW→DONE > 自分のタスク WIP→INREVIEW • タスクを可視化（カンバン） • タスクの進捗状況や依存関係の可視化 • 誰がどのタスクに着手しているのか、どのタスクがボトルネックになってるかを把握しやす くする (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
44. 44 設計開発フェーズにおける取り組み タスクのボトルネックを解消する • 依存関係によるボトルネック • 依存度の高いタスクを早く捌く • スキルの偏りによるボトルネック • ペアプロ、モブプロで知識の伝搬 • 経験が浅い技術、ドメインのタスクを積極的にとる (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
45. 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 要件定義 設計開発 テスト
46. 46 リードタイム短縮の取り組み (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト テストフェーズにおけるリードタイム短縮の取り組み
47. 47 テストフェーズにおける取り組み 案件特性に応じてリスクを取ったテスト削減 テスト仕様書等の中間成果物の削減 (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
48. 48 テストフェーズにおける取り組み • 従来のテストの考え方 • 基本的には各テスト工程でテストケース作成、レビュー、テスト実施を行なっていた (C) Recruit Co., Ltd. All rights reserved. 単体テスト 結合テスト 受入テスト 要件定義 設計開発 テスト
49. 49 テストフェーズにおける取り組み • 開発チームにおけるbugbash形式のテスト • みんなでシステムを触ってバグを見つけるイベント • 受け入れ基準を満たしていることを確認し、最低限の品質を担保 • バグを見つけたら褒める文化 • バグを見つけたらその場で直す • 企画チームによる受入テスト • Sprint Reviewで触ってOKとする場合も • QAチームによるテスト • 重要機能に影響がある場合のみ実施 (C) Recruit Co., Ltd. All rights reserved. 要件定義 設計開発 テスト
50. 50 • 開発チームがメインで関わるところ中心にお話しさせていただきま したが、案件創出や各種広報のフロー含めて、チーム全体でフロー の改善、最適化をおこなっております (C) Recruit Co., Ltd. All rights reserved.
51. 51 (C) Recruit Co., Ltd. All rights reserved. アジェンダ 1. スクラム開発導入の背景 2. スクラム開発導入の進め方 3. 開発リードタイム短縮の取り組み 4. 取り組みの効果とまとめ
52. 52 リリース頻度、開発リードタイムの変化 スクラム導入前後で 機能開発案件のリリース頻度が 1.6回/月から3.7回/月に 開発リードタイムは 最短1ヶ月から最短1週間に (C) Recruit Co., Ltd. All rights reserved.
53. 53 開発手法の変化 • 案件特性に応じた開発手法の選択ができるようになり、より効率的 に事業価値を向上させていけるようになった (C) Recruit Co., Ltd. All rights reserved. • 作るものが明確でまとめて一 気に作った方が効率がいい • 納期・計画重視 • 仮説検証を繰り返して、探索 的に機能を模索したい • 速さ・柔軟さ重視
54. 54 (C) Recruit Co., Ltd. All rights reserved. 作りすぎのムダの改善 • 毎週案件の優先度を見直し、優先度が高い機能を小刻みにリリースしていくこ とで、より使われる機能をユーザに届けることができる https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used
55. 55 まとめ 『HOT PEPPER Beauty 美容クリニック』の開発生産性向上の取り組みとして • 他組織を巻き込んだスクラム開発導入の進め方 • 短期間のSprintで開発〜リリースを実現するためのリードタイム短縮の取 り組み (C) Recruit Co., Ltd. All rights reserved.
56. 56 まとめ 他組織を巻き込んだスクラム開発導入の進め方 • 企画組織を巻き込む上で工夫したポイント • 小さく試し、成功事例を作る • 企画組織にメリットを感じてもらった上で、一緒にプロセスを変えていく • 企画組織からポジティブな反応を多く頂けており、その後の企画組織含めたプロセスの 変更を推進しやすくなったと感じております！ • 開発主導でスコープ分割を行い、スコープに関する考え方を揃えに行く • 「一番小さく価値を提供できる単位でリリースする」という認識が揃っているからこそ 1週間のSprintでの開発〜リリースが実現できている (C) Recruit Co., Ltd. All rights reserved.
57. 57 まとめ 短期間のSprintで開発〜リリースを実現するためのリードタイム短縮の取り組み • 1週間で動くものを作りに行くという目標をたて、既存のやり方にとらわれ ずにスピード最優先で開発を進められたのが良かったポイント • 一旦スピードに振り切って必要最低限のタスクだけ実施することで、今まで気づかな かったムダなプロセス、成果物に気づくことができる • 検査と適応を繰り返しながら、本当に必要なプロセスの見極めを行いつつ、 さらなるリードタイム短縮に取り組んでおります！ (C) Recruit Co., Ltd. All rights reserved.