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
78
事業状況の大きな変化を乗り越えるためのAirレジ オーダーのアジャイル開発
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、金井の資料です。
Recruit
PRO
March 25, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
500
プロデザ! BY リクルート vol.18_リクルートのリサーチ実践組織「リサーチブーストコミュニティ」
recruitengineers
PRO
4
330
スマートフォン版サロンボードの 機能改善の土台づくり
recruitengineers
PRO
2
84
横断組織から見たリクルートのインフラの歴史と目指すべきクラウド活用像
recruitengineers
PRO
1
53
Datadog による 自己完結的アプリケーションモニタリング
recruitengineers
PRO
4
290
プロデザ! BY リクルートvol.17_『じゃらんnet』公式アプリの高速リニューアル事例を大公開
recruitengineers
PRO
6
210
自己完結な開発者組織を支える プラットフォーム作り
recruitengineers
PRO
4
340
検索エンジニアが考える、 生成AI時代の人間の付加価値とは
recruitengineers
PRO
3
210
エンジニア思考で解決! 家事育児を劇的に進化させる開発プロセス応用術
recruitengineers
PRO
3
140
Other Decks in Technology
See All in Technology
cgroup v2 で何が変わったのか / TechFeed Experts Night #28
tenforward
2
160
20240509 CloudWatch でいろいろなものを監視してみよう
masaruogura
1
120
iThome2024 Wailing Wall of Enterprise Security
notsurprised
0
290
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
12
7.9k
Kaggleで学ぶ系列データのための深層学習モデリング
yu4u
7
1.7k
AWS CLIの起動が重くてつらいので aws-sdk-client-go を書いた / kamakura.go#6
fujiwara3
6
2.9k
令和版ソフトウェアエンジニアの情報収集術 PHPカンファレンス香川2024
ysknsid25
4
880
技術力の伸ばし方を考える
khirata
0
140
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
0
2k
From here to resilience - a travel guide
ufried
1
160
本番環境で Cloudflareを 使ってみた話
miu_crescent
2
120
回り回って効いてくる副次的効果としての技術広報/techpr
nishiuma
1
180
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
30
6.4k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
352
28k
For a Future-Friendly Web
brad_frost
172
9k
Scaling GitHub
holman
457
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
Fireside Chat
paigeccino
22
2.7k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
67
14k
Designing Experiences People Love
moore
136
23k
How GitHub (no longer) Works
holman
305
140k
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年分を いかに学んで追いつくか •アジャイルなアプローチは 外部環境の大きな変化にも対応できた •事前調整にしたくなるところも事後調整できないか考える