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
110
イテレーティブな開発で 不確実性を乗り越える
2025/2/19に開催したRecruit Tech Conference 2025の索手の資料です
Recruit
PRO
March 03, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
分散型と集中型で切り開くクラウドコスト最適化: リクルート横断プロダクトCroisのFinOps実践
recruitengineers
PRO
5
270
毎晩の 負荷試験自動実行による効果
recruitengineers
PRO
6
300
Transformerを用いたアイテム間の 相互影響を考慮したレコメンドリスト生成
recruitengineers
PRO
2
1.1k
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
200
問題解決に役立つ数理工学
recruitengineers
PRO
13
2.9k
Curiosity & Persistence
recruitengineers
PRO
2
220
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
480
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
240
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
520
Other Decks in Technology
See All in Technology
AIエージェントの開発に必須な「コンテキスト・エンジニアリング」とは何か──プロンプト・エンジニアリングとの違いを手がかりに考える
masayamoriofficial
0
280
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
130
[kickflow]20250319_少人数チームでのAutify活用
otouhujej
0
200
GitHub Copilot coding agent を推したい / AIDD Nagoya #1
tnir
2
3.9k
歴代のWeb Speed Hackathonの出題から考えるデグレしないパフォーマンス改善
shuta13
6
580
ECS モニタリング手法大整理
yendoooo
1
110
ウォンテッドリーのアラート設計と Datadog 移行での知見
donkomura
0
290
広島銀行におけるAWS活用の取り組みについて
masakimori
0
110
OpenAPIから画面生成に挑戦した話
koinunopochi
0
130
OCI Bastionサービス
oracle4engineer
PRO
1
120
信頼できる開発プラットフォームをどう作るか?-Governance as Codeと継続的監視/フィードバックが導くPlatform Engineeringの進め方
yuriemori
1
390
LLM時代の検索とコンテキストエンジニアリング
shibuiwilliam
2
1.1k
Featured
See All Featured
Scaling GitHub
holman
462
140k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
Building an army of robots
kneath
306
45k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
890
Six Lessons from altMBA
skipperchong
28
4k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Rails Girls Zürich Keynote
gr2m
95
14k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
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