Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
炎上プロジェクトに呼ばれたEMがPR数を10倍に増やしたときに得たものと失ったもの
Search
STORES Tech
November 26, 2025
Technology
550
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
炎上プロジェクトに呼ばれたEMがPR数を10倍に増やしたときに得たものと失ったもの
2025/11/26 STORES Tech Conf 2025 での発表資料です
https://storesinc.tech/conf/2025
STORES Tech
November 26, 2025
More Decks by STORES Tech
See All by STORES Tech
「決済」だけでは終わらない、決済手段追加の舞台裏
storesinc_tech
0
37
非エンジニアがAIで継続的に運用できる配送システムを作った話
storesinc_tech
0
75
経営統合がエンジニアに非連続な成長機会をもたらす理由
storesinc_tech
0
2k
Other Decks in Technology
See All in Technology
Oracle Cloud Infrastructure IaaS 新機能アップデート 2026/6 - 2026/8
oracle4engineer
PRO
0
190
Sigmaで作る業務アプリ
kazushiro_honma
0
130
Deployment の 先にある AI Agent 基盤 - kagent vNext、Agent Substrate、Hermes から読み解く Agent Runtime の現在地 / k8s-matsuri-2-ai-agent-platform-amsy810
masayaaoyama
3
270
20260912_スクラムにジェネラリストは必要か
ryugen04
0
390
2026/09/10 Spring Bootから Jakarta EE/MicroProfileへの移行
megascus
0
350
Microsoft 365 Copilot chat -tekoälypalvelun tietosuojaongelmat
hponka
0
830
Tab5をRubyで動くパソコンにする
kishima
2
360
20260906 「AWS運用入門」著者が教える、運用業務への生成AI活用入門
masaruogura
0
260
AIエージェントの自己改善をどう設計するか / How to Design Self-Improvement for AI Agents
22mi
20
11k
SQL文一行も書けない人事がCortexもろもろを使って人事業務を楽にしてみる
ponponmikankan
1
230
ASTを使って影響範囲を特定する
nealle
0
180
Podは生きているのにGoだけが落ちる:GOGCとGOMEMLIMITで追うInvisible OOM Killの謎
tkc66buzz
1
680
Featured
See All Featured
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
6
1.2k
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
930
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
270
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
1
2.9k
Building a Scalable Design System with Sketch
lauravandoore
464
34k
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
530
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
660
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
Paper Plane (Part 1)
katiecoart
PRO
1
11k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
270
Darren the Foodie - Storyboard
khoart
PRO
3
3.9k
My Coaching Mixtape
mlcsv
0
310
Transcript
炎上プロジェクトに呼ばれた EM がPR 数を 10 倍に増やしたときに 得たものと失ったもの 山下 隼人
自己紹介 山下 隼人 / ぴーやま / @phayacell • STORES に勤めて7年目
• 2024年7月からマネジャー任用 • そのうち6年くらい STORES ネットショップの開発 • 趣味は自作キーボード ⌨ リングフィットアドベンチャー 🏋 だいたい1,900日くらいやってる
今日のテーマ 炎上プロジェクトに呼ばれた EM がPR 数を 10 倍に増やしたときに 得たものと失ったもの
Pull Request のマージ数(2024年1月〜2025年11月)
Pull Request のマージ数(マネジャー任用以降 vs 炎上プロジェクト以降)
このセッションのゴール ひとりのエンジニアリングマネジャーが 炎上プロジェクトでの経験を通じて 自身のスタンス・信念・思想がどう変化したのか みなさんがご自身の環境や状況に照らし合わせて 考えるヒントを持ち帰っていただけること
このセッションで話さないこと こういうことは話しません • Pull Request 数を増やすテクニック • 開発生産性を上げるノウハウ • 炎上プロジェクトに対する一般論
• エンジニアリングマネジャーかくあるべし
Day 0: 招集直前
2025年3月以前 モバイルオーダー開発チームのマネジャー
モバイルオーダー開発チームのマネジャー マジですごいモバイルオーダーを作る • プロダクトマネジャー、ビジネスの責任者と モバイルオーダーのリリースに向けて仕様調整 • スクラムチームに対してはスクラムマスターの役割 • チームの「外側」から俯瞰して メンバー自身が改善サイクルを回せるようサポート
モバイルオーダー開発チームのマネジャー 自分で手を動かすことは少なかった • 自分が作ることよりも どうしたらチームの生産性が上がるのか考えていた • それ自体は悪くないはずだが 今になって思えば、そのために自分の手を動かさない選 択をしていた
Pull Request のマージ数は減少(1Q は手を動かそうと頑張っていたが)
Day 1: 危機発生
2025年4月1日の夕方 突然 CPO に呼ばれた
呼ばれた背景 2025年3月末に大きなリリースがあった • STORES プロダクトをつなぐ新プラン
STORES 新プランのリリース 「ひとつの STORES」を実現するために • 管理画面、オンボーディング、プランの統合 • STORES は会社合併してプロダクト数を増やしてきた歴史 があり、プロダクト間の壁も大きかった
• 2020年からずっと統合のために準備をしていた
STORES 新プランのリリース 「ひとつの STORES」を実現するために • ひとつのオンボーディングでサービスを 利用開始できるようになる • ひとつのプランでサービスを横断した 機能提供できるようになる
• STORES の歴史の中でも もっとも大きい影響のある悲願のリリース
STORES 新プランのリリース後 お客さまから多数のフィードバックがあった • 大きな変化に伴う反応 • つなげてはじめてわかったことが多かった • 新プランで利用開始するのに数十分も掛かる
ヤバい
ヤバい なんとか5分でオンボーディングできるように • サービスをはじめるための入力項目が多すぎる • 高い離脱率、ひとりでは完遂できないフォーム • これを解決するための緊急プロジェクト 通称「5min プロジェクト」に呼ばれたのです
4月1日17時、緊急参戦 • プロジェクト概要の説明を受け、開発環境の構築 • 当日(4月1日)18時の夕会に参加 • 翌日(4月2日)にリリースしたい マ? 話を戻して、呼ばれた当日
呼ばれたときの状況 見直し・作り直し真っ最中(3月27日〜) • 4つのプロダクトで別々だったオンボーディングを 丁寧につなぎ合わせている状態だった • ひとつめのオンボーディングが終わったら 次のオンボーディングをはじめる―― • 入力内容の重複も多数あり、累計で約
100 項目に
呼ばれたときの状況 見直し・作り直し真っ最中(3月27日〜) • 画面設計・データ構造の見直しから • 重複する項目は入力させない • すべてをひとつのシステムにのせ、まとめなければ
呼ばれたときのプロジェクトメンバー みんなが全速力で開発をしていた • デザインもない、フォームとバリデーションもない • API は疎通すらできていない • そんな状況からみんなすごい速度で開発をしていた
そして呼ばれた
そして作りはじめた
そして作りはじめた
そして作りはじめた
こんな感じで Pull Request を出し続ける日々がはじまります
Day N: 集中
たくさん Pull Request を出した
そのときの気持ち 時間が足りない、やりたいことまでの距離が遠い • STORES プロダクトをつなぐ新プラン • これまで個別プロダクトだったものをつなぐ • あらゆる歴史的背景を飲み込んで潰さないといけない課 題が噴出
そのときの気持ち プレッシャーもあり、焦っていた • 緊急事態に瀕してバイネームで呼ばれて 何も成果を挙げられないのは許されないと思った • チームを俯瞰して、では成果は出せない • 求められる役割が180度変わった気がした
ミーティングに出るのをやめた 参加予定だったミーティングの大半を欠席 • 状況は全社レベルで伝わっていた • どうしても必要なコミュニケーションは 他のマネジャーやメンバーに支えてもらった • その調整すら、その人たちにフォローしてもらった
STORES 全社集会(4月10日)でも開発 社員全員参加の会場でみんな揃って開発 • 開場前は近くのレンタルスペースでコーディング • 開場後は後方の席でコーディング
RubyKaigi(4月16日~18日)でも開発 愛媛でプロジェクトメンバーみんな揃って開発 • 昼は愛媛県県民文化会館でコーディング • 夜はコメダ珈琲店に集まって23時までコーディング • 深夜はホテルに帰ってからコーディング • 朝はドトールに集まって開場までコーディング
そんな無茶を支えてもらったおかげで、たくさん Pull Request を出せた
得たもの 失ったもの
ほとんどのミーティングを欠席して、得たもの 時間と環境 • まとまった開発時間 • 稼働日のほとんどをコーディング時間に充てられた • 成果を出せない言い訳ができる環境を排除 • 成果を出さないといけない環境に追い込めた
チームで没頭し続ける開発で、得たもの 強制的な能力の拡張 • 成果を出すことへの強烈な刷り込み • 自分で全速力のコーディングをしながら チームの成果量を最大化するように動かないと無理 • プロジェクト進行における 二兎を追う方法を強制インストールした感覚
チームで没頭し続ける開発で、得たもの 強制的な能力の拡張 • 目の前にはやりたいことだらけの Issues • これまでの開発経験を総動員して いかに早く実現まで辿り着けるかの勝負を毎時毎分 • 経験のないこともすぐにやれないと間に合わない
はじめて React を書いたし RDBMS は6年ぶり
ほとんどのミーティングを欠席して、失ったもの 信頼と信用 • 昨日までいたマネジャーが別プロジェクトに異動 • 定期 1 on 1 さえも2ヶ月ほどなくなり
ピープルマネジメントの放棄 • 義理もなにもかなぐり捨ててしまった
チームで没頭し続ける開発で、失ったもの 中長期・広範囲の目線の欠如 • 短期成果に集中するあまり俯瞰した目線がなくなる • プロジェクトメンバー以外の様子は見られなくなる • 年単位のロードマップはほぼ白紙まで戻り 改めて大規模な組織変更、開発体制へ
プロジェクトを終えて
たのしかった 最も開発に熱狂した期間だった • STORES のミッション「Just for Fun」を感じた • そもそもお客さまにご迷惑をおかけしていたし メンバーや周囲の人にもたくさんの迷惑をかけたので
端的に「たのしかった」なんて言っていいか迷うけど • それでも、振り返ると「たのしかった」が出てくる
なぜ、たのしかった? 疲弊よりも満足が勝っていた • タイトでドラマチックな開発 • 高速に課題を解き続けていく開発体験は エンジニアとしての報酬系をすごく刺激してくれた • ひたすら開発に集中できたし 開発生産量は明らかに異常な上昇をしていた
本当にごめんなさい メンバーにご迷惑ばかりおかけしました • たのしかったと開き直ってしまったけど ご迷惑をおかけして申し訳ないと思う気持ちも本当 • マネジャー不在になって大変な思いをさせてしまった • わたしたちが集中している間に起きた「しわ寄せ」に対応し てくれて、ありがとうございました
また、やりたい 今度はもっとうまく熱狂したい • 速度と量を出して開発ができたのはよかったこと • 集中しすぎて周囲にご迷惑をかけてしまったのは 反省しなければならないこと • 反省を活かして、よかったことを再現していきたい •
熱を上げて開発する体験を、もっとうまく、意思を持って再 現したいなと思っています
まとめ
再掲:このセッションのゴール ひとりのエンジニアリングマネジャーが 炎上プロジェクトでの経験を通じて 自身のスタンス・信念・思想がどう変化したのか みなさんがご自身の環境や状況に照らし合わせて 考えるヒントを持ち帰っていただけること
2025年にあった人生の転機です 仕事のスタイルが大きく変わりました before • マネジャーとして一歩身を引いて チームに活躍してもらうようサポートをする after • マネジャーも最前線で一緒に動いて チーム全員で活躍できるよう全速力で走る
どうやって熱狂を再現するか みんなで模索中です • 決して短期の成果にしたくない • 炎上プロジェクトをしたいわけじゃない 熱狂する開発プロジェクトをやりたい • 強弱はあるにせよ いつも「今日の開発もたのしかったなあ」と
熱狂的に課題を解き続ける開発組織でありたい
どうやって熱狂を再現するか みなさんは、どうしますか? ご清聴ありがとうございました