Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
イテレーティブな開発で 不確実性を乗り越える
Search
Recruit
PRO
March 03, 2025
Technology
3
46
イテレーティブな開発で 不確実性を乗り越える
2025/2/19に開催したRecruit Tech Conference 2025の索手の資料です
Recruit
PRO
March 03, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
問題解決に役立つ数理工学
recruitengineers
PRO
8
2.3k
Curiosity & Persistence
recruitengineers
PRO
2
120
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
250
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
100
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
97
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
150
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
2
83
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
93
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
97
Other Decks in Technology
See All in Technology
AWS CDK コントリビュート はじめの一歩
yendoooo
1
120
caching_sha2_passwordのはなし
boro1234
0
220
Redefine_Possible
upsider_tech
0
320
どっちの API SHOW?SharePoint 開発における SharePoint REST API Microsoft Graph API の違い / Which API show? Differences between Microsoft Graph API and SharePoint REST API
karamem0
0
110
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
210
Amazon GuardDuty Malware Protection for Amazon S3を使おう
ryder472
2
110
Compose MultiplatformにおけるiOSネイティブ実装のベストプラクティス
enomotok
1
210
大規模サービスにおける カスケード障害
takumiogawa
3
620
ペアプログラミングにQAが加わった!職能を超えたモブプログラミングの事例と学び
tonionagauzzi
1
150
20250328_RubyKaigiで出会い鯛_____RubyKaigiから始まったはじめてのOSSコントリビュート.pdf
mterada1228
0
180
OCI見積もり入門セミナー
oracle4engineer
PRO
0
120
大規模プロジェクトにおける 品質管理の要点と実践 / 20250327 Suguru Ishii
shift_evolve
0
290
Featured
See All Featured
For a Future-Friendly Web
brad_frost
176
9.6k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.6k
Optimizing for Happiness
mojombo
377
70k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.5k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Scaling GitHub
holman
459
140k
Docker and Python
trallard
44
3.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
29
2k
How to Think Like a Performance Engineer
csswizardry
22
1.5k
The Invisible Side of Design
smashingmag
299
50k
Transcript
イテレーティブな開発で 不確実性を乗り越える RECRUIT TECH CONFERENCE 2025 新規事業に挑む開発チームの在り方 索手 一平 株式会社リクルート プロダクトディベロップメント室
索手 一平 スポーツ観戦・筋トレ・サウナ・ビール 経歴 / Career 2016年にリクルートに新卒入社。 ビューティー領域にて『ホットペッパービューティー』 のAndroidアプリおよびそのAPIシステムのリプレイスプ ロジェクトを担当。
その後はアーキテクトとして『ホットペッパービュー ティーワーク』の立ち上げに携わる。 現在は『ホットペッパービューティーワーク』の 開発チームリーダー兼TechLead。 趣味 / Hobbies プロダクトディベロップメント室 販促領域エンジニアリング2ユニット ビューティー領域エンジニアリング部 ビューティープロダクト開発3グループ
『ホットペッパービューティーワーク』とは • 『ホットペッパービューティー』が提供する 美容業界向け求人マッチング&ソリューションサービス • 2023年2月にWeb版をリリース
『ホットペッパービューティーワーク』とは 2024年6月にiOS・Androidアプリ をリリース 🚀
今日お話しすること アプリ立ち上げプロジェクトについて イテレーティブな開発スタイルを通して 早期リリースをいかに実現したか
iOS・Androidアプリの立ち上げについて • 応募数増を目的として2023年8月にスタート 急遽プロジェクトを立ち上げ2024年6月には無事リリース 🎉 • 少しでも早く応募数増に寄与するため 最短でのリリース を 目指していた、つまり
デリバリー(D)の優先度が最も高い 状況
iOS・Androidアプリの立ち上げについて • 応募数増を目的として2023年8月にスタート 急遽プロジェクトを立ち上げ2024年6月には無事リリース 🎉 • 少しでも早く応募数増に寄与するため 最短でのリリース を 目指していた、つまり
デリバリー(D)の優先度が最も高い 状況 スコープ 開発チームの状況 プロジェクト開始時、大きく2つの課題があった
最小スコープがどこなのか確信を持てずにいた 立ち上げ時の課題: • 最短でリリースするためにはスコープの最小化は必須 • しかしユーザに受け入れられるだけの最低限のUXは 初期リリース時点で担保したい • 最低限のUXを保てるスコープがどこなのか確信が持てなかった スコープ
iOS・Androidエンジニアは他の開発チームから集める形で プロジェクトチームを組閣 ホットペッパービューティーワーク 開発チーム アプリ立ち上げ プロジェクトチーム iOS・Android エンジニア サーバサイド エンジニア
ディレクター デザイナー 他の開発チーム 立ち上げ時の課題: 開発チームの状況
• アサインされたサーバサイドエンジニアは iOS・Android開発に携わるのが初めて → iOS・Android開発の流れや考慮事項の知識・経験が不足 • iOS・Androidエンジニアは 『ホットペッパービューティーワーク』に携わるのが初めて → ドメイン知識・既存メンバーとの相互理解が不足
開発チームの知識・経験・相互理解が大きく不足していた 立ち上げ時の課題: 開発チームの状況
イテレーティブな開発スタイルの採用 • 『ホットペッパービューティーワーク』では 個々の案件単位ではウォータフォール(WF)寄りの 開発スタイルを採用してきた • WFは後続工程に向けて事前に要件・設計を整理するスタイル、 今回のプロジェクトとは相性が悪い ◦ スコープ変動時に整理した内容が無駄になりかねない
◦ 知識・経験が不足していては後続工程のイメージが困難 • そこで イテレーティブな開発スタイル を採用することに
イテレーティブな開発スタイル 作るべき機能を細分化し、それぞれをマイルストーンとして 一つ一つ「完成」させていく 検索条件モーダル 要件定義 設計 ・・・ 受け入れテスト TOP画面 要件定義
設計 ・・・ 受け入れテスト チュートリアル 要件定義 設計 ・・・ 受け入れテスト ・・・ 開発工程を 何度も繰り返す
イテレーティブな開発スタイルの狙いと効果(1/2) 開発チームを早期に成熟させること 開発工程を細かく繰り返し、機能完成までに必要な作業・論点の 学習サイクルを素早く回すことができる 効果 開発チームが早い段階から具体的な 完成イメージ・共通言語を得てスムーズに開発することが可能に 狙い
イテレーティブな開発スタイルの狙いと効果(2/2) 早期にスコープをFixさせること 部分的にでも完成した機能に触れることで UXへの解像度が高まり「最低限のスコープ」を早期に見極められる 効果 プロジェクト開始から4ヶ月(2023年12月)でスコープをほぼFix プロダクトへの自信が深まり スコープ削減の意思決定が可能に 狙い
開発スタイルを活かすための3つの工夫 1. 口頭コミュニケーションの促進 2. まず動くアプリを作る 3. 極端なやり方で必要なものを見極める
開発スタイルを活かすための3つの工夫 1. 口頭コミュニケーションの促進 2. まず動くアプリを作る 3. 極端なやり方で必要なものを見極める
口頭コミュニケーションの促進 • イテレーティブ開発は小さなゴールを短期間で達成していくスタイル 進行中の作業がブロックされないよう 発生した論点の早期解決が重要 → その場で一気に話を進められる 口頭議論と相性が良い • 相互理解が浅い状態でチームがスタートしていたため、
そこを深めていく意味でも相性が良かった
口頭コミュニケーションの促進 • プロジェクトとして専用の会議体を多く設けることで仕組みと して口頭コミュニケーションを促進、エンジニアのリーダー層 は毎日、プロジェクト全体では週3回 集まる場を設定 • 論点解決に向けた情報収集や意思決定をその場で完了するため プロジェクトの参加者はなるべく全員を会議に集める形で運用
開発スタイルを活かすための3つの工夫 1. 口頭コミュニケーションの促進 2. まず動くアプリを作る 3. 極端なやり方で必要なものを見極める
まず動くアプリを作る • 開発を始める際は「CI環境整備」「ライブラリの選定」など開 発基盤を整えるところから始めることが多いが、それらを後回 しにし 動くアプリ(実際のWeb APIを呼び出して、アプリが 動作する状態)の完成をチーム全体の最優先事項とした • 開発サイクルを一周しチームを成熟させることが
このプロジェクトにとって最も重要だと判断
この3要素を 「動くアプリ」の 要件とした 優先度はMiroに書き出して議論 予定していたタスクと その依存関係を洗い出し 個々のタスクを後回しにできな いかチームで議論
後回しにしたタスクの例 細かい開発フロー系は全般後回し ライブラリ選定も最初のマイルストーン に直結しないものは後回し 作業に1時間取れそうかを 基準にしていた
開発スタイルを活かすための3つの工夫 1. 口頭コミュニケーションの促進 2. まず動くアプリを作る 3. 極端なやり方で必要なものを見極める
極端なやり方で必要なものを見極める • プロジェクト開始当初は仕様書・設計書などの中間成果物を どこまで作るか迷っていたが、まずは「中間成果物一切無し」 という極端なやり方で開発に着手することに • 極端な方向に振ることで「本当に必要なもの」を見極めやすく なり、実際に行うことで 自信を持って判断することができる •
結果、最小限の成果物で効率よく開発を進める事が可能に
プロジェクト全体(アプリ立ち上げ)の結果 • 初期はリリース時期を「2024年12月」と見立てていたが 「2024年06月」と6ヶ月前倒しでリリース 🚀 • 不具合が発生することもほぼなく、 アプリリリース後の応募数は 事前の見立て通り大幅増 📈
プロジェクト全体(アプリ立ち上げ)の結果 • 初期はリリース時期を「2024年12月」と見立てていたが 「2024年06月」と6ヶ月前倒しでリリース 🚀 • 不具合が発生することもほぼなく、 アプリリリース後の応募数は 事前の見立て通り大幅増 📈
ビジネス効果を損なうことなく リリースを大幅に前倒すことができた
まとめ • UXの見極め・開発チームの成熟が必要な状況では イテレーティブな開発が有効 • イテレーティブな開発をうまく駆動するために「口頭コミュニ ケーションの促進」「まず動くものを作る」「極端なやり方で 必要なものを見極める」が効果的
Fin