シェア
はてブ
2024年6月28日、ファインディ株式会社が主催するイベント「開発生産性Conference 2024」が、開催されました。本記事では、株式会社リクルートにて『HOT PEPPER Beauty 美容クリニック』の開発チームリーダーを務める橋本 健史さんによるセッション「スクラム開発導入による他組織を巻き込んだ開発生産性向上の取り組み」の内容をお届けします。
■プロフィール
橋本 健史（はしもと たけし）
株式会社リクルート 『HOT PEPPER Beauty 美容クリニック』 開発チームリーダー
SIerでWebシステム開発経験を経て、2020年リクルートに入社。『HOT PEPPER Beauty 美容クリニック』のバックエンドエンジニアとして開発に携わる。現在は『HOT PEPPER Beauty 美容クリニック』の開発リーダーを担当。
開発リードタイムの抜本的な改善のため、スクラム開発を導入
橋本：本日は「スクラム開発導入による他組織を巻き込んだ開発生産性向上の取り組み」というタイトルで発表させていただきます。よろしくお願いいたします。まず簡単に自己紹介させていただきます。
橋本 健史と言います。経歴としては、2017年に新卒で株式会社野村総合研究所に入社して、Webシステムの設計開発に3年間ほど携わっていました。その後、2020年に株式会社リクルートにキャリア入社し、そこからずっと『HOT PEPPER Beauty 美容クリニック』の開発チームに所属しています。最初の2年ほどはバックエンドエンジニアとして開発に携わり、2022年からは開発チームリーダーとして、開発チームのマネジメントなどを行っています。
本日お話しするのは、リクルートの美容領域の1プロダクトである『HOT PEPPER Beauty 美容クリニック』における開発生産性向上の取り組み事例です。このプロダクトでは、もともとウォーターフォール開発を採用していましたが、昨年度からスクラム開発を導入し、短期間のSprintで開発を回すことによって、開発リードタイムの短縮やリリース頻度の向上を実現してきました。
橋本：本セッションでは、スクラム開発の導入に至った背景や、他組織を巻き込んだプロセス変更の進め方、リードタイム短縮のために行っていることを、具体的な事例とともに紹介します。アジェンダとしては、1.スクラム開発導入の背景、2.スクラム開発導入の進め方、3.開発リードタイム短縮の取り組み、4.取り組みの効果とまとめ、といった流れでお話しします。
それでは最初に、スクラム開発導入の背景から説明していきます。まずプロダクトをご紹介すると、『HOT PEPPER Beauty 美容クリニック』（以下、美容クリニック）は、場所や悩み、施術方法などから行きたい美容クリニックを検索し、カウンセリングの予約ができるサービスです。
ホットペッパービューティーの新ジャンルとして2020年の3月から提供を開始しており、現在のクリニック掲載数は約1800件。PC版とスマホ版のサイトを提供しています。
橋本：これまで『美容クリニック』では初期リリース以降、即時予約機能や商品リニューアルをはじめとする、さまざまな機能の追加開発を行ってきました。これまでは作るべきものが明確で、かつ計画性が求められる案件が多かったため、ウォーターフォール開発を採用して、一括で開発からリリースまでを実施していました。
既存の機能開発チームの編成としては、案件の規模感に応じたチーム分けを行っていました。大規模案件を開発するチームは、案件ごとにチームを組織して体制をつくり、エンハンス案件を計画的に実施。小規模案件を開発するチームは、固定のチームで小規模なエンハンス案件や保守案件を実施し、毎月複数の案件をリリースしていくといった進め方をしていました。
このように案件の規模感に応じて体制や進め方を変えていましたが、どちらもベースとしてはウォーターフォールの開発プロセスを採用していました。
橋本：『美容クリニック』では、これまで作るべきものが明確で、目的不確実性が低い機能の開発は、優先度高く対応してきたので、ある程度実施済みの状況です。今後のプロダクト戦略として、ここからは仮説検証を繰り返し、ユーザーからのフィードバックを得ながら、探索的に作るべきものを見つけていきたいといった事業背景がありました。
一方で、『美容クリニック』の抱えている課題として、案件を遂行するうえでウォーターフォールの開発プロセスしか選択肢がなく、開発リードタイムが長くなってしまうことにより、小さく速く案件をリリースしていくことができなくなっていました。
開発リードタイムが長くなっていた要因について深掘りすると、ウォーターフォール開発では、先に何を作るかの不確実性を減らしたうえで、計画的に作っていくという特徴によるものでした。
『美容クリニック』においては、UI/UX改善のような施策においても、カスタマーの要求に対して漏れなく要件を敷き詰め、ニーズ解決の蓋然性を高めて、不確実性を減らすスタイルになっていました。その結果、一度に開発する機能のスコープが大きくなり、工数や工期が増えていく傾向がありました。
また、これまでリソース効率重視の考え方で開発を進めてきたことも、要因の1つだと思っています。これまで『美容クリニック』では、複数の案件を開発していきたい状況になったとき、リソース効率を意識して複数の案件を並行して開発を進めていました。その結果、1個1個の案件のリードタイムがあまり重視されず、1案件当たりのリードタイムが長くなってしまっていました。
橋本：既存の枠組みでの改善として、ウォーターフォール開発のなかでも工数・工期を短縮するような取り組みや、スコープをできるだけ削減していく取り組みを行ってきましたが、なかなか大きな効果が出ない状況でした。
また、開発リードタイムが長いことも1つの要因として、案件のスコープがより大きくなって案件が大規模化していき、さらにリードタイムが延伸するというサイクルにつながってしまっていました。
スコープが大きくなる要因としては、先ほどのリソース観点でまとめて作った方が効率が良いという考え方があることや、リードタイムの長さから、スコープアウトした機能をすぐにリリースできないので、スコープを削りにくいといった背景がありました。
このように、既存のウォーターフォール開発のなかでの大きな改善はなかなか難しいものがあったので、開発リードタイムを抜本的に改善するために、アジャイル手法のなかでもプラクティスが確立されている、スクラム開発の導入検討を開始しました。
スクラム開発で成功事例をつくり、企画組織を巻き込んでいく
橋本：ここからは、実際にスクラム開発を導入するにあたって、どのように他組織を巻き込みながらプロセスの変更を進めていったかについてお話しします。また、Sprintを1週間に設定しているのですが、その短い期間で開発からリリースを繰り返すための、リードタイム短縮の取り組みについてもお話していきます。
まずスクラム開発の導入の進め方についてですが、その前提として『美容クリニック』の組織構成をお見せします。少し省略している部分もあるので、あくまでイメージにはなりますが、組織としては大きく企画チームと開発チームに分かれています。
企画チームでは、プロダクト戦略に沿った案件の創出や企画を行ったり、案件のなかでプロダクトの仕様を決めたりしています。開発チームでは、案件のなかで開発からテスト、リリースまでを行ったり、システムの保守運用を行ったりしています。
橋本：スクラムを導入していくうえで工夫したポイントとして、企画組織の巻き込み方がありました。なぜかというと、スクラム開発を導入していくにあたって、企画組織のプロセスも大きく変わってくるので、企画組織の協力が必須だったからです。
ただ、企画組織はそもそも開発組織とは職能が違うため、導入することで何がどう改善されるのかが伝わりづらい状況でした。そうしたなか、ウォーターフォールに最適化されたプロセスを、スクラム開発のプロセスに大きく変更していくことは、心理的なハードルが高かったと思います。
そのため、企画組織を巻き込みやすくする工夫として、まずは成功事例をつくり、スクラム開発のメリットを実感してもらったうえで、本格的にスクラム開発を導入していくという進め方をしました。成功事例をつくるために行ったことは、スクラム導入のメリットを実感しやすい案件の選定や、成功確率の高い開発体制の構築、開発指導でのスコープの調整などです。
これを1つずつ見ていくと、案件選定の軸にしたのは、まずはtoC向けのCVR改善案件。これは小さく出して、ユーザーの反応を見てネクストアクションを決めるという、スクラムに適したやり方をとりやすいからですね。もう1つは、実際にスコープが大きくなってしまっている案件で、小さく速く出す効果をより感じやすいからです。
これらの軸に合致したのが、「価格帯で検索する機能を追加する」という案件で、こちらの案件で実際にスクラムを導入していくことを決めました。この案件は、検索条件のなかに料金を追加してクリニックを絞り込めるようにして、検索結果にも指定した料金のメニューを持つクリニックを表示させるというものです。
橋本：この価格帯で検索するという案件の裏には、実はたくさんの要件が詰まっていて、例えば検索ボタンを押す前にヒットするクリニックの件数を出したいとか、クリニックの検索画面だけでなく施術メニュー画面でも価格帯で絞り込めるようにしたいとか、あとはオプションのメニューは検索対象から除外したいといったものがありました。
もともとはこうしていろいろな要件が詰まっている状態で、一気にユーザーのニーズを解決しようとしていました。当初はこれらすべてをマスト要件でやりたいという話になっており、結果として工数も工期も大きくなっている状況でした。
次に、成功確率の高い開発体制の構築についてですが、ここは少しでも成功確率を上げるために、少数精鋭のチームでパワーをかけて実績をつくりにいきました。例えば、スクラムへの理解が深いスクラムマスターをアサインしたり、スキルやスタンス的にスクラム開発に適性がある開発メンバーを招集したりなどですね。
それから、パワーをかけるという部分に関しては、できるだけみんなで集まって、対面でコミュニケーションを取りながら効率的に開発していく取り組みをしました。
橋本：最後に、開発主導でのスコープ調整についてです。今回の取り組みの最終目的は、スクラムを導入することではなく、あくまで小さく速くユーザーに価値を届けることです。Sprintでパーツごとに作るのではなく、Sprintごとに価値のある単位で開発からリリースができるように、スコープの刻み方を開発側で検討しました。
スコープ分割の進め方としては、まず最初に要件を分解し、解決したい課題や要求と要件を紐づける。次に解決したい課題ベースで優先順位づけを行い、最後に最小単位でリリースできそうな要件を確定していくという進め方で行いました。
具体例をお話しすると、「指定した価格帯の施術メニューを持つクリニックが検索できる」という要件に対しては、「価格帯でクリニックを絞り込めない」という課題があったので、この紐づけを行います。
他にも、「検索対象から施術メニューオプションを除外したい」というのは、「メニューのなかにオプションメニューも一緒に入稿されていて、ユーザーにとって正しい検索が実現できない」という課題があり、それに対する解決策の要件であると。こういった形で、1個1個の要件に対して、要求を紐づけていく作業を最初に行いました。
橋本：その後、解決したい課題ベースで優先順位づけを行いました。今回は「価格帯でクリニックを絞り込めない」というのが最も大きな課題だと考え、これを一番高い優先度に持ってきています。
最後に、最小単位でリリースできそうな要件を確定していきます。こちらは既に要求と要件で1つずつに分かれているので、最小単位で価値が提供できる1つのボックスでリリースしていきましょうという話をしました。結果的には、上から2つのボックスを計2Sprintで開発していくということで、企画チームと調整していきました。
企画チームとスコープを調整するとき、単に「最初のスコープだけ作って出します」と伝えてしまうと、企画チームとしては他の要件をどうするのかという不安や、実際に出してみて効果が出なかったらどうしようといった不安があるかもしれません。
そのため、進め方の工夫として、分割した要件を順番にリリースしていく方向で相談しに行き、実際に出した後には指標を計測し、その結果をもとにネクストアクションを決めていくという、仮説検証とリリースをセットにしたディシジョンツリーを提示しました。これにより不安を解消しながら、最小単位で開発からリリースにトライすることを企画チームと合意していきました。
橋本：開発の流れとしては、基本的にスクラムのフローに則って進め、月曜始まり金曜終わりの1週間Sprintで開発をしています。月曜日にSprint Planningを行ったのち開発を行い、Bug Bashと呼ばれるテストを行います。これは開発チーム全員でプロダクトを触ってバグを見つけるイベントですね。
その後、Sprint Reviewの形式の1つとして、実際に動くものをデモ形式でプロダクトオーナーやステークホルダーに共有し、フィードバックをもらうDemo Dayというイベントを行います。そして、振り返りを行って、また次の週に行くという流れですね。
橋本：このような形で開発を行い、先ほどの価格帯で検索するという案件のなかで、スコープを分割して最小単位の機能のみ開発することにより、2週間でリリースできる状態まで持っていくことができました。
実際にリリースしてみて効果を計測したところ、2週間で作れる機能に限定しても、当初5ヶ月で作る機能で目指していたCVR目標値の150%を達成。結果的に必要最低限の機能に絞っても、十分にユーザーのニーズを満たせることがわかりました。当初5ヶ月で得ようとしたもの以上の効果を2週間で得ることができ、かなりインパクトのある成功事例になったと思います。
このような成功事例ができたことによって、企画チームからもスクラム導入に対してポジティブな意見がたくさん出てきて、プロセスの変更に巻き込みやすくなりました。その状態で正式にスクラム開発チームを立ち上げ、企画チームと一緒にプロセスの変更や装着を実施していきました。やはり小さく試して実績をつくり、巻き込みやすくしていくことが大事なポイントだったと思います。
3つのフェーズにおけるリードタイム短縮の取り組み事例
橋本：続いて、開発リードタイム短縮の取り組みについてお話しします。今回は1Sprintのタイムボックスを1週間に設定して開発を回すことを前提に置き、それに収めるにはどうすればいいかを逆算的に、既存のやり方にとらわれず考えていきました。
特に先ほどの事例では、1週間で動くものを作ることを最優先としていたので、一旦スピードに振り切って開発を行いながら、必要なプロセスを適宜取り込んでいきました。あとは、日々の振り返りで検査と適応を繰り返し、開発フロー上のボトルネックに対処することで、リードタイム短縮に取り組んでいくという形です。
ここでは1Sprintにおける要件定義、設計開発、テストの3つのフェーズにおけるリードタイム短縮の取り組み事例をご紹介します。まず、要件定義フェーズにおいては、要求や要件定義の成果物を簡素化して、走りながら要件を決めていくという取り組みを実施しています。
従来の役割分担での開発フローだと、企画チームがまず要求の定義を行い、それを開発チームにインプットし、企画と開発で要件定義を実施した後に、設計開発に進むという流れでした。これによって、各フェーズで漏れがない要求や要件を検討し、成果物を作るコスト、不備があった場合の手戻りコスト、企画と開発の間で要求や要件を調整していくコストなどが発生していました。
従来のウォーターフォール開発では、計画的に作っていくために各フェーズで漏れなく検討していくことも大事です。しかし、今回は1週間というタイムボックスのなかで動くものを作るため、今までのスピード感でやっていくのは難しく、要求・要件定義成果物を簡素化して走りながら要件を決めていきました。
橋本：具体的には、案件の背景や課題、大まかなシステム要求、画面のワイヤーフレームなどを、最初に企画チームに決めてもらいます。そして、それを開発チームが受け取り、Sprint Planningや設計開発を進めながら、細かい要件は開発主導で決めていくという動き方です。
早いタイミングで企画チームから要求を受け取り、開発を動かしながら要件を決めていくことで、要求や要件の検討にかかるリードタイムを減らすことができます。また、開発主体で要件を決めていくことで、案件の目的を達成しつつ、低コストや低難易度で実現できる要件を判断できるようになります。
開発側で要件を決めていくうえでのポイントとして、Sprint Planningでコア価値というものを定義しています。そのストーリーで達成したいゴールを、エレベーターピッチ形式でスクラム開発チームみんなで定義する作業で、先にゴールの認識を合わせておくことで要件を決める判断軸になります。
開発側で決められるところは最大限開発側で決めるというスタンスを持ち、すべて企画チームに判断してもらうのではなく開発側で判断し、一旦作ってみてSprint Reviewでフィードバックをもらうというやり方をしています。
橋本：続いて、設計開発フェーズにおけるリードタイム短縮の取り組みですが、こちらは「動くものを早く作る」ことに尽きます。そのための工夫としては大きく分けて3つあり、まずはチームのメンバーが自律的に動けるようにすること、タスクのボトルネックを解消すること、そしてコミュニケーションを円滑化することです。
1つずつ見ていくと、まず自律的に動けるようにすることに関しては、チームとしてのタスクの優先順位を明確化しています。例えば大きなもので言うと、その1週間のSprintのなかでリリースできる状態にすることよりも、まずはフィードバックを得られるように動くものを作ることを優先しましょうというルールを決めています。
タスクの捌き方に関しては、レビューを最優先とする取り組みをしています。レビュー中のものが溜まっていくと、タスクのスイッチングコストが増えたり、コンフリクトが発生しやすくなったりするので、できるだけ自分の作業よりもレビュー中のものを完了に持っていくことを優先するというルールを決めています。
それから、タスクの進捗状況や依存関係を可視化しています。誰がどのタスクに着手しているのか、どのタスクがボトルネックになっているのかを把握しやすくすることで、各メンバーが自律的に動けるようにしています。
橋本：続いて、タスクのボトルネックを解消することに関してですが、今までよくあったのはタスクの依存関係によるボトルネックと、スキルの偏りによるボトルネックでした。
依存関係によるボトルネックは、前のタスクが終わらないと次のタスクに着手できないといったものです。これが発生するのは仕方がない部分もあるので、まずは依存関係を見えるようにしたうえで、依存度が高いタスクをより早く捌いていくようにしました。
スキルの偏りによるボトルネックは、特定の人しかできないタスクがある場合、その人が空いていなければボトルネックになってしまうというものです。そのため、スキルの偏りをできるだけなくしていくための取り組みをしています。
例えば、ペアプロやモブプロを積極的に実施して知識を伝播していったり、経験が浅い技術やドメインのタスクを積極的に取るようにコーチングしたり。スキルの偏りはすぐに解決できるものではないですが、できるだけ偏りをなくすような取り組みをしています。
そして、コミュニケーションの円滑化に関しては、できるだけ効率的なコミュニケーションを意識しています。コミュニケーションの効率性は対面が最も良く、次にビデオ通話、次に通話と言われているので、出社してみんなで一緒に開発したり、困ったらすぐに通話をつないで解決したりするようにしています。あとは、ペアプロやモブプロも、困ったらすぐに一緒にやりましょうと声掛けしています。
橋本：最後に、テストフェーズにおけるリードタイム短縮の取り組みです。テストフェーズにおいては、案件特性に応じて取れるリスクを取ったテストの削減や、テスト仕様書などの中間成果物の削減を行っています。
従来のテストは、ウォーターフォール的に各工程でテストケースをしっかりと作ってレビューを行い、テストを実施するという進め方でした。そのため、仕様書を作成するコストがかかったり、各工程を踏んでいくことによるリードタイムがかかってしまったりしていました。
そのため、開発が完了したら、みんなでシステムを触ってバグを見つけるBug Bash形式でのテストを実施するようにしました。これを1Sprintあたり1～2時間くらい行い、そこで受け入れ基準を最低限満たしていることを確認し、最低限の品質を担保します。Bug Bashは、みんなで楽しみながら触っていく感覚で進めていき、バグを見つけたらすぐにその場で直します。
Bug Bashでのテストが終わったら、次に企画チームによる受け入れテストを行います。開発のスコープが小さいので、テストもすぐに終わることが多く、Sprint Reviewで触ってリリースOKとする場合もあります。それほど重要機能ではない場合は、その後すぐリリースという形をとっていますが、重要機能に影響がある場合は、しっかりQAテストを挟んでからリリースするという進め方をしています。
以上が、リードタイム短縮の取り組みのご紹介でした。本日は開発チームがメインで関わるところを中心にお話しさせていただきましたが、案件の創出や各種広報のフローも含めて、チーム全体でのフローの改善を行っています。
取り組み後、開発リードタイムが最短1ヶ月から最短1週間に
橋本：それでは、取り組みの効果とまとめに入りたいと思います。まず取り組みの効果として、スクラム導入前後での機能開発案件のリリース頻度が、もともと月1.6回だったものが月3.7回になり、1週間弱で新しい機能をリリースできる状況になっています。これには保守案件や障害対応のリリースは含めておらず、あくまで新しい機能でのリリース頻度です。
そして、1案件における開発着手からリリースまでの開発リードタイムは、もともと小さいもので最短1ヶ月だったのですが、最短1週間になりました。
橋本：開発手法の変化としては、案件特性に応じた開発手法を選択できるようになりました。例えば、作るべきものが明確で一気に作った方が効率が良いものや、納期が決まっているもの、計画重視のものは、これまで通りウォーターフォールで開発。一方、速さや柔軟さ重視で、速く出してユーザーの反応を見たい案件であれば、スクラムで開発しています。
それから、作りすぎのムダも改善されています。毎週案件の優先度を見直し、優先度が高い機能を小刻みにリリースしていくことで、より使われる機能をユーザーに届けることができるようになりました。
今までは、ある程度使えそうな機能をまとめて作って出していたので、作りすぎのムダが発生していた可能性が高いと考えられます。作った機能の45%はまったく使われず、19%の機能はめったに使われないといった話がありますが、そういった作りすぎのムダを省くことができていると思います。
橋本：それでは、最後のまとめになります。本日は、『美容クリニック』での開発生産性向上の取り組みとして、他組織を巻き込んだスクラム開発導入の進め方と、1週間のSprintで開発からリリースを実現していくための、リードタイム短縮の取り組みについてお話ししました。
企画組織を巻き込むうえでは、まずは小さく試して成功事例をつくり、企画組織にもメリットを感じてもらい、一緒にプロセスを変えていくところが工夫したポイントでした。実際に、企画組織からも多くのポジティブな反応があり、その後の企画組織を含めたプロセス変更を推進しやすくなったと感じます。
また、その成功事例をつくっていくなかでは、開発主導でスコープ分割を行い、スコープに関する考え方を揃えるという取り組みを行いました。一番小さく価値を提供できる単位でリリースするという認識が、企画チームと開発チームのなかで揃っているからこそ、1週間のSprintでの開発からリリースが実現できていると思います。
リードタイム短縮の取り組みでは、細かいものを含めるとさまざま行っていますが、まずは1週間で動くものを作るという目標を立て、既存のやり方にとらわれずに、スピード最優先で開発を進められたことがポイントだと思っています。スピードに振り切って必要最低限のタスクだけを実施することで、今まで気付かなかったムダなプロセスや成果物に気づくことができました。
『美容クリニック』の開発チームでは毎週振り返りを行い、検査と適応を繰り返しながら本当に必要なプロセスを見極め、さらなるリードタイム短縮に取り組んでいます。以上で発表を終わります。
なお、リクルートでは新卒採用とキャリア採用を積極的に行っておりますので、ご興味ある方がいらっしゃいましたら、ぜひこちらのリンクからアクセスしていただけますと幸いです。ご清聴ありがとうございました。
