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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Recruit
PRO
March 03, 2025
Technology
3
140
イテレーティブな開発で 不確実性を乗り越える
2025/2/19に開催したRecruit Tech Conference 2025の索手の資料です
Recruit
PRO
March 03, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
まなび領域における生成AI活用事例
recruitengineers
PRO
2
150
AI時代にエンジニアはどう成長すれば良いのか?
recruitengineers
PRO
1
230
AIを用いたカスタマーサポートの業務プロセス・組織変革の実現
recruitengineers
PRO
1
140
問い合わせ自動化の技術的挑戦
recruitengineers
PRO
2
240
「Air ビジネスツールズ」のクライアントサポートにおける生成 AI 活用
recruitengineers
PRO
0
100
AI活用のためのアナリティクスエンジニアリング
recruitengineers
PRO
1
140
SaaS事業のデータマネジメント事例
recruitengineers
PRO
0
130
Kaggleで鍛えたスキルの実務での活かし方 競技とプロダクト開発のリアル
recruitengineers
PRO
1
450
LLM のプロダクト導入における開発の裏側と技術的挑戦
recruitengineers
PRO
1
180
Other Decks in Technology
See All in Technology
Copilot 宇宙へ 〜生成AIで「専門データの壁」を壊す方法〜
nakasho
0
180
20年以上続く PHP 大規模プロダクトを Kubernetes へ ── クラウド基盤刷新プロジェクトの4年間
oogfranz
PRO
0
180
スケールアップ企業でQA組織が機能し続けるための組織設計と仕組み〜ボトムアップとトップダウンを両輪としたアプローチ〜
qa
0
260
20260323_データ分析基盤でGeminiを使う話
1210yuichi0
0
180
Phase06_ClaudeCode実践
overflowinc
0
1.9k
韓非子に学ぶAI活用術
tomfook
2
520
Phase09_自動化_仕組み化
overflowinc
0
1.6k
CloudFrontのHost Header転送設定でパケットの中身はどう変わるのか?
nagisa53
1
160
AIエージェント×GitHubで実現するQAナレッジの資産化と業務活用 / QA Knowledge as Assets with AI Agents & GitHub
tknw_hitsuji
0
220
Phase11_戦略的AI経営
overflowinc
0
1.5k
Laravelで学ぶOAuthとOpenID Connectの基礎と実装
kyoshidaxx
4
1.8k
LLMに何を任せ、何を任せないか
cap120
10
5.3k
Featured
See All Featured
Ruling the World: When Life Gets Gamed
codingconduct
0
180
How to Ace a Technical Interview
jacobian
281
24k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.8k
Raft: Consensus for Rubyists
vanstee
141
7.4k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
14k
Designing for humans not robots
tammielis
254
26k
Everyday Curiosity
cassininazir
0
180
My Coaching Mixtape
mlcsv
0
85
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
GraphQLとの向き合い方2022年版
quramy
50
14k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.2k
エンジニアに許された特別な時間の終わり
watany
106
240k
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