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
18
技術的ミスと深堀り
recruitengineers
PRO
3
19
『ホットペッパーグルメ』における マルチプラットフォーム化の歩み
recruitengineers
PRO
2
10
『じゃらんnet』アプリ 改善活動の軌跡
recruitengineers
PRO
2
7
『スタディサプリ for SCHOOL』における Flutter導入とその成果
recruitengineers
PRO
2
9
よりよいビジネスの「実現」のために エンジニアリングを発揮する
recruitengineers
PRO
3
20
イテレーティブな開発で 不確実性を乗り越える
recruitengineers
PRO
3
8
株式会社リクルート 社内ISUCONの裏側
recruitengineers
PRO
1
13
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
22
Other Decks in Technology
See All in Technology
Goで作って学ぶWebSocket
ryuichi1208
3
2.7k
急成長する企業で作った、エンジニアが輝ける制度/ 20250227 Rinto Ikenoue
shift_evolve
0
130
クラウドサービス事業者におけるOSS
tagomoris
4
1k
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
82k
【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST
aeonpeople
2
610
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
5
370
Cracking the Coding Interview 6th Edition
gdplabs
14
28k
Share my, our lessons from the road to re:Invent
naospon
0
140
4th place solution Eedi - Mining Misconceptions in Mathematics
rist
0
140
いまからでも遅くない!コンテナでWebアプリを動かしてみよう!コンテナハンズオン編
nomu
0
150
Active Directory攻防
cryptopeg
PRO
8
5.4k
コンピュータビジョンの社会実装について考えていたらゲームを作っていた話
takmin
1
600
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
RailsConf 2023
tenderlove
29
1k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Visualization
eitanlees
146
15k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
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年分を いかに学んで追いつくか •アジャイルなアプローチは 外部環境の大きな変化にも対応できた •事前調整にしたくなるところも事後調整できないか考える