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
事業状況の大きな変化を乗り越えるためのAirレジ オーダーのアジャイル開発
Search
Recruit
PRO
March 25, 2024
Technology
1
400
事業状況の大きな変化を乗り越えるためのAirレジ オーダーのアジャイル開発
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、金井の資料です。
Recruit
PRO
March 25, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
4
44
技術的ミスと深堀り
recruitengineers
PRO
3
43
『ホットペッパーグルメ』における マルチプラットフォーム化の歩み
recruitengineers
PRO
2
24
『じゃらんnet』アプリ 改善活動の軌跡
recruitengineers
PRO
2
20
『スタディサプリ for SCHOOL』における Flutter導入とその成果
recruitengineers
PRO
2
17
よりよいビジネスの「実現」のために エンジニアリングを発揮する
recruitengineers
PRO
3
58
イテレーティブな開発で 不確実性を乗り越える
recruitengineers
PRO
3
18
株式会社リクルート 社内ISUCONの裏側
recruitengineers
PRO
1
26
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
260
Other Decks in Technology
See All in Technology
設計を積み重ねてシステムを刷新する
sansantech
PRO
0
180
MIMEと文字コードの闇
hirachan
2
1.4k
どちらかだけじゃもったいないかも? ECSとEKSを適材適所で併用するメリット、運用課題とそれらの対応について
tk3fftk
2
220
Snowflakeの開発・運用コストをApache Icebergで効率化しよう!~機能と活用例のご紹介~
sagara
1
500
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
150
AI Agent時代なのでAWSのLLMs.txtが欲しい!
watany
3
320
Amazon Aurora のバージョンアップ手法について
smt7174
2
170
AIエージェント元年@日本生成AIユーザ会
shukob
1
240
あなたが人生で成功するための5つの普遍的法則 #jawsug #jawsdays2025 / 20250301 HEROZ
yoshidashingo
2
320
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
19k
DevinでAI AWSエンジニア製造計画 序章 〜CDKを添えて〜/devin-load-to-aws-engineer
tomoki10
0
180
JavaにおけるNull非許容性
skrb
2
2.7k
Featured
See All Featured
Facilitating Awesome Meetings
lara
52
6.2k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Statistics for Hackers
jakevdp
797
220k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.4k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
A Philosophy of Restraint
colly
203
16k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
570
Thoughts on Productivity
jonyablonski
69
4.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
51k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
520
Transcript
Airレジ オーダーのアジャイル開発 事業状況の大きな変化を乗り越えるための プロダクトディベロップメント室 販促領域エンジニアリングユニット 金井 優希
金井 優希 アニメ考察 好きなアイカツのアイドルは霧矢あおいちゃんです。 経歴 / Career 2017年リクルートホールディングス新卒入社。データサ イエンティストとして『じゃらん』の検索ロジックの開 発に関わったのち、エンジニアに転向し、『ホットペッ
パービューティーコスメ』の初期開発に携わる。 現在、『Airレジ オーダー』の開発リーダー兼飲食領域 TechLead 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 販促領域エンジニアリングユニット 飲食・ビューティー領域エンジニアリング部 飲食プロダクト開発3グループ
Airレジ オーダーとは お客様のスマホ モバイルオーダー 店内版 注文 予約管理 iPad / PC
配膳 売上分析・顧客管理 PC / iPad ※Airレジ オーダーを利用するには、Airレジとレストランボードが必要です。 基本機能が 円で使える、Airレジ、レストランボードとカンタン連携 0 調理 ・iPad(※ホール業務) ・iPhoneまたはiPod touch ハンディ iPhone または iPod touch キッチンモニター 注文と会計 iPad レシートプリンター 注文とお支払い iPad(※キッチン業務) 調理・配膳は、キッチンモニターまたはキッチンプリンターをお選びいただけます。 ※2 ※1
Airレジ オーダーとは お客様のスマホ モバイルオーダー 店内版 注文 予約管理 iPad / PC
配膳 売上分析・顧客管理 PC / iPad ※Airレジ オーダーを利用するには、Airレジとレストランボードが必要です。 基本機能が 円で使える、Airレジ、レストランボードとカンタン連携 0 調理 ・iPad(※ホール業務) ・iPhoneまたはiPod touch ハンディ iPhone または iPod touch キッチンモニター 注文と会計 iPad 注文とお支払い iPad(※キッチン業務) 調理・配膳は、キッチンモニターまたはキッチンプリンターをお選びいただけます。 ※2 ※1 レシートプリンター
Airレジ オーダーとは お客様のスマホ モバイルオーダー 店内版 注文 予約管理 iPad / PC
配膳 売上分析・顧客管理 PC / iPad ※Airレジ オーダーを利用するには、Airレジとレストランボードが必要です。 基本機能が 円で使える、Airレジ、レストランボードとカンタン連携 0 調理 ・iPad(※ホール業務) ・iPhoneまたはiPod touch ハンディ iPhone または iPod touch キッチンモニター 注文と会計 iPad iPad(※キッチン業務) 調理・配膳は、キッチンモニターまたはキッチンプリンターをお選びいただけます。 ※2 ※1 注文とお支払い レシートプリンター
Airレジ オーダーとは お客様のスマホ モバイルオーダー 店内版 注文 予約管理 iPad / PC
配膳 売上分析・顧客管理 PC / iPad ※Airレジ オーダーを利用するには、Airレジとレストランボードが必要です。 基本機能が 円で使える、Airレジ、レストランボードとカンタン連携 0 調理 ・iPad(※ホール業務) ・iPhoneまたはiPod touch ハンディ iPhone または iPod touch キッチンモニター 注文と会計 iPad iPad(※キッチン業務) 調理・配膳は、キッチンモニターまたはキッチンプリンターをお選びいただけます。 ※2 ※1 注文とお支払い レシートプリンター
Airレジ オーダーをなぜ作ったか 飲食店業務とコミュニケーションをリデザインする ハンディ キッチンモニター モバイルオーダー 店内版 ボトルネック
• モバイルオーダー店内版・ハンディ・キッチンモニターの一連の機能を次々に開発 • 一方で差別化機能としてハンディに通称”ぷんぷん機能”をリリース • 当時のNSMは「提供遅れ時間の削減」 2018~ 初期開発と 差別化機能 ↓
2020~ コロナ禍のテイク アウト需要対応 ↓ 2022~ afterコロナの人手 不足に対応 ハンディ(お待たせ状況) ハンディ(テーブル別お待たせ状況) 今お待たせ中の 商品があるお客様 お待たせなく提供できて いるお客様 お待たせした商品が あったお客様 今お待たせ中の 商品がある お待たせ商品 提供時間 お待たせ時間 来店中/退店済 お待たせなく 提供 ハンディ(ホール用注文アプリ) キッチンモニター (キッチン用調理管理アプリ) モバイルオーダー店内版 ▪通称ぷんぷん機能 このときは自社の優位性を強めていくのだと思っていた… これまでのAirレジ オーダー
2018~ 初期開発と 差別化機能 ↓ 2020~ コロナ禍の テイクアウト 需要対応 ↓ 2022~
afterコロナの人手 不足に対応 • コロナ禍で飲食店はテイクアウト・配達へシフト • ぷんぷん機能の開発は凍結→テイクアウト需要対応へピボット • ”Airレジ ハンディ”から”Airレジ オーダー”へブランド名を変更 あらゆる注文に対応できることを訴えた キッチンモニター(注文ブロック) ハンディ(お客様・人数) 伝票メモ 受け取り予定時刻 注文メモ 軽減税率 ▪当時の検討資料。イートインだけじゃない! ▪居酒屋やレストランだけでなくカフェ形態にも対応。 飲食の対応シーンを増やしていった。 ▪テイクアウト向けの機能追加 飲食領域は大打撃だった。こんなに状況が変わってしまうとは… これまでのAirレジ オーダー
2018~ 初期開発と 差別化機能 ↓ 2020~ コロナ禍の テイクアウト需要 対応 ↓ 2022~
afterコロナ の人手不足 に対応 • 中小店舗向けに展開してきたが、人手不足が深刻な法人大型店舗にも対応することに • ハンディとキッチンモニターの開発を停止し全員で異動 NECのPOSレジとの連携システムを4ヶ月足らずで開発 ▪NEC FoodFrontia 開発止めてと言われたときは「ほんとに???」と思った これまでのAirレジ オーダー
2018~ 初期開発と 差別化機能 ↓ 2020~ コロナ禍の テイクアウト需要 対応 ↓ 2022~
afterコロナ の人手不足 に対応 • 中小店舗向けに展開してきたが、人手不足が深刻な法人大型店舗にも対応することに • ハンディとキッチンモニターの開発を停止し全員で異動 NECのPOSレジとの連携システムを4ヶ月足らずで開発 ▪NEC FoodFrontia 開発止めてと言われたときは「ほんとに???」と思った これまでのAirレジ オーダー 大きな変化に開発チームは応えてきた。 なぜ対応できたのか?
それはアジャイル開発に こだわってきたから
なぜアジャイル開発するのか •我々は後発プロダクト ◦他社の注文管理プロダクトは20年以上の歴史がある ◦その歴史を最速でキャッチアップせねば •先発プロダクトは既に多機能化しておりMVPが分からない •我々は飲食店業務の素人である ◦要件を事前に定義することは困難 アジャイルなスタンスを大切にして システムと開発チームを作っていった結果 大きな変化に対応できた
ではアジャイル開発の組織とは? 組織と呼ばれるものの特徴は、基本的に分業と調整の二つである 沼上 幹(2004) 組織デザイン P16 ウォーターフォールでもアジャイルでも 組織的に働いていることに変わりはない。 組織的に働くとは、すなわち分業と調整をするということ。 •
分業=仕事を分担して取り組むこと • 調整=分業成果の統合と例外事象の対応 ウォーターフォールとアジャイルの分業と調整の仕方は…
分業と調整分業と調整の手法比較 • 分業形態: 各フェーズで分業 • 分業成果の統合: V字モデルに従うことで自 然に分業成果が統合される • 例外事象の対応:
そもそも起きないように綿密に計画 発生時はPMが頑張る • 分業形態: PO/SM/開発者で分業 • 分業成果の統合: スクラムモデルに従うこと で自然に分業成果が統合される (POが成果物を定義・開発者が適宜判断し統 合する) • 例外事象の対応: SMがデイリーやレトロで検出し対応 ※アジャイル手法としてスクラムを例に解説する
分業と調整分業と調整の手法比較 • 分業形態: 各フェーズで分業 • 分業成果の統合: V字モデルに従うことで自 然に分業成果が統合される • 例外事象の対応:
そもそも起きないように綿密に計画 発生時はPMが頑張る • 分業形態: PO/SM/開発者で分業 • 分業成果の統合: スクラムモデルに従うこと で自然に分業成果が統合される (POが成果物を定義・開発者が適宜判断し統 合する) • 例外事象の対応: SMがデイリーやレトロで検出し対応 ※アジャイル手法としてスクラムを例に解説する 例外事象の対応のスタンスが異なる そもそも問題が起きないようにするのがウォーターフォール 問題が起きる前提でSMという専門職を用意するのがスクラム
例外事象の対応スタンスは2つある • 事前調整=問題が起きる前にがんばる • 事後調整=問題が起きた後にがんばる 後発のプロダクトとして、MVPをリリースして使ってもらって学ぶ 事後調整的手段=スクラムを選んだほうが20年分を素早くキャッチアップできる ではなぜスクラム開発は事後調整的対応が可能なのか?
例外を許容する仕組みがスクラムに揃っているから スクラムが失敗するとき何が起きているのか? この辺の領域の例外は レトロで出たカイゼン案で潰 していく この辺の領域の例外は • レトロでカイゼン案を 出し自動化 •
SMがチーム外に仕事を 切り出す 等で対応する ステークホルダーとの交渉 ユーザーからの問い合わせ 新規参画者のアカウント発行 検討漏れ仕様の すり合わせ スクラム開発するということは 事後調整のための事前調整 をしているとも言える。 P286の図7-1を参考に作図 ユーザーからのFBを 反映した要件の変更
その反省って正しい? 職能を超えて意思決定する能力を 鍛えるべきなのに諦めてないか? SMやPOとして経験値を積む前 に諦めてないか? ディレクター「もっと要件固めてから開発と話そう」 開発「理論武装してPOと交渉しよう」 これって事前調整に逃げてない? ここで諦めてしまうと 変化に対応する能力が失われてしまう
例外に対して事後調整能力が足りなければ 当然、事前調整されてしまう • 綿密に計画するようになる • 決められたフォーマットでやり取りするようになる 「もうちょっとこのやり方でやってみよう」 「とりあえず話にいってみよう」 もちろんすべて事後調整にすることは無理。リスクと相談する必要がある。 なぜそこまで事後調整にこだわるのか? ネガティブ・ケイパビリティを持つ! ユーザーからのFBを反映 した要件の変更 ステークホルダーとの交渉
それがアジャイル開発だから 事前調整よりも 事後調整に価値を 置こうと決めた https://agilemanifesto.org/iso/ja/manifesto.html
アジャイルチームは動くソフトウェアから学ぶ POS連携の開発中のこと ミニハンバーガーだけが 注文できるシステムが まずできた まずは動かして 使ってもらう ↓↑ 事後調整する
まとめ •後発プロダクトとしてのアジャイル開発戦略 ◦先行プロダクトに対して遅れている20年分を いかに学んで追いつくか •アジャイルなアプローチは 外部環境の大きな変化にも対応できた •事前調整にしたくなるところも事後調整できないか考える