炎上プロジェクトに呼ばれたEMがPR数を10倍に増やしたときに得たものと失ったもの

by STORES Tech

Slide 1

Slide 1 text

炎上プロジェクトに呼ばれた EM がPR 数を 10 倍に増やしたときに  得たものと失ったもの山下隼人  

Slide 2

Slide 2 text

自己紹介  山下隼人 / ぴーやま / @phayacell  ● STORES に勤めて7年目  ● 2024年7月からマネジャー任用  ● そのうち6年くらい  STORES ネットショップの開発  ● 趣味は自作キーボード ⌨  リングフィットアドベンチャー 🏋  だいたい1,900日くらいやってる 

Slide 3

Slide 3 text

今日のテーマ  炎上プロジェクトに呼ばれた EM がPR 数を 10 倍に増やしたときに  得たものと失ったもの 

Slide 4

Slide 4 text

Pull Request のマージ数（2024年1月〜2025年11月） 

Slide 5

Slide 5 text

Pull Request のマージ数（マネジャー任用以降 vs 炎上プロジェクト以降） 

Slide 6

Slide 6 text

このセッションのゴール  ひとりのエンジニアリングマネジャーが  炎上プロジェクトでの経験を通じて  自身のスタンス・信念・思想がどう変化したのか  みなさんがご自身の環境や状況に照らし合わせて  考えるヒントを持ち帰っていただけること 

Slide 7

Slide 7 text

このセッションで話さないこと  こういうことは話しません  ● Pull Request 数を増やすテクニック  ● 開発生産性を上げるノウハウ  ● 炎上プロジェクトに対する一般論  ● エンジニアリングマネジャーかくあるべし 

Slide 8

Slide 8 text

Day 0:  招集直前 

Slide 9

Slide 9 text

2025年3月以前  モバイルオーダー開発チームのマネジャー 

Slide 10

Slide 10 text

モバイルオーダー開発チームのマネジャー  マジですごいモバイルオーダーを作る  ● プロダクトマネジャー、ビジネスの責任者と  モバイルオーダーのリリースに向けて仕様調整  ● スクラムチームに対してはスクラムマスターの役割  ● チームの「外側」から俯瞰して  メンバー自身が改善サイクルを回せるようサポート 

Slide 11

Slide 11 text

モバイルオーダー開発チームのマネジャー  自分で手を動かすことは少なかった  ● 自分が作ることよりも  どうしたらチームの生産性が上がるのか考えていた  ● それ自体は悪くないはずだが  今になって思えば、そのために自分の手を動かさない選択をしていた 

Slide 12

Slide 12 text

Pull Request のマージ数は減少（1Q は手を動かそうと頑張っていたが） 

Slide 13

Slide 13 text

Day 1:  危機発生 

Slide 14

Slide 14 text

2025年4月1日の夕方  突然 CPO に呼ばれた 

Slide 15

Slide 15 text

呼ばれた背景  2025年3月末に大きなリリースがあった  ● STORES プロダクトをつなぐ新プラン 

Slide 16

Slide 16 text

STORES 新プランのリリース  「ひとつの STORES」を実現するために  ● 管理画面、オンボーディング、プランの統合  ● STORES は会社合併してプロダクト数を増やしてきた歴史があり、プロダクト間の壁も大きかった  ● 2020年からずっと統合のために準備をしていた 

Slide 17

Slide 17 text

STORES 新プランのリリース  「ひとつの STORES」を実現するために  ● ひとつのオンボーディングでサービスを  利用開始できるようになる  ● ひとつのプランでサービスを横断した  機能提供できるようになる  ● STORES の歴史の中でも  もっとも大きい影響のある悲願のリリース 

Slide 18

Slide 18 text

STORES 新プランのリリース後  お客さまから多数のフィードバックがあった  ● 大きな変化に伴う反応  ● つなげてはじめてわかったことが多かった  ● 新プランで利用開始するのに数十分も掛かる    ヤバい 

Slide 19

Slide 19 text

ヤバい  なんとか5分でオンボーディングできるように  ● サービスをはじめるための入力項目が多すぎる  ● 高い離脱率、ひとりでは完遂できないフォーム  ● これを解決するための緊急プロジェクト  通称「5min プロジェクト」に呼ばれたのです 

Slide 20

Slide 20 text

4月1日17時、緊急参戦  ● プロジェクト概要の説明を受け、開発環境の構築  ● 当日（4月1日）18時の夕会に参加  ● 翌日（4月2日）にリリースしたい    マ？  話を戻して、呼ばれた当日 

Slide 21

Slide 21 text

呼ばれたときの状況  見直し・作り直し真っ最中（3月27日〜）  ● 4つのプロダクトで別々だったオンボーディングを  丁寧につなぎ合わせている状態だった  ● ひとつめのオンボーディングが終わったら  次のオンボーディングをはじめる――  ● 入力内容の重複も多数あり、累計で約 100 項目に 

Slide 22

Slide 22 text

呼ばれたときの状況  見直し・作り直し真っ最中（3月27日〜）  ● 画面設計・データ構造の見直しから  ● 重複する項目は入力させない  ● すべてをひとつのシステムにのせ、まとめなければ 

Slide 23

Slide 23 text

呼ばれたときのプロジェクトメンバー  みんなが全速力で開発をしていた  ● デザインもない、フォームとバリデーションもない  ● API は疎通すらできていない  ● そんな状況からみんなすごい速度で開発をしていた 

Slide 24

Slide 24 text

そして呼ばれた 

Slide 25

Slide 25 text

そして作りはじめた 

Slide 26

Slide 26 text

そして作りはじめた 

Slide 27

Slide 27 text

そして作りはじめた 

Slide 28

Slide 28 text

こんな感じで  Pull Request を出し続ける日々がはじまります 

Slide 29

Slide 29 text

Day N:  集中 

Slide 30

Slide 30 text

たくさん Pull Request を出した 

Slide 31

Slide 31 text

そのときの気持ち  時間が足りない、やりたいことまでの距離が遠い  ● STORES プロダクトをつなぐ新プラン  ● これまで個別プロダクトだったものをつなぐ  ● あらゆる歴史的背景を飲み込んで潰さないといけない課題が噴出 

Slide 32

Slide 32 text

そのときの気持ち  プレッシャーもあり、焦っていた  ● 緊急事態に瀕してバイネームで呼ばれて  何も成果を挙げられないのは許されないと思った  ● チームを俯瞰して、では成果は出せない  ● 求められる役割が180度変わった気がした 

Slide 33

Slide 33 text

ミーティングに出るのをやめた  参加予定だったミーティングの大半を欠席  ● 状況は全社レベルで伝わっていた  ● どうしても必要なコミュニケーションは  他のマネジャーやメンバーに支えてもらった  ● その調整すら、その人たちにフォローしてもらった 

Slide 34

Slide 34 text

STORES 全社集会（4月10日）でも開発  社員全員参加の会場でみんな揃って開発  ● 開場前は近くのレンタルスペースでコーディング  ● 開場後は後方の席でコーディング 

Slide 35

Slide 35 text

RubyKaigi（4月16日～18日）でも開発  愛媛でプロジェクトメンバーみんな揃って開発  ● 昼は愛媛県県民文化会館でコーディング  ● 夜はコメダ珈琲店に集まって23時までコーディング  ● 深夜はホテルに帰ってからコーディング  ● 朝はドトールに集まって開場までコーディング 

Slide 36

Slide 36 text

そんな無茶を支えてもらったおかげで、たくさん Pull Request を出せた 

Slide 37

Slide 37 text

得たもの  失ったもの 

Slide 38

Slide 38 text

ほとんどのミーティングを欠席して、得たもの  時間と環境  ● まとまった開発時間  ● 稼働日のほとんどをコーディング時間に充てられた  ● 成果を出せない言い訳ができる環境を排除  ● 成果を出さないといけない環境に追い込めた 

Slide 39

Slide 39 text

チームで没頭し続ける開発で、得たもの  強制的な能力の拡張  ● 成果を出すことへの強烈な刷り込み  ● 自分で全速力のコーディングをしながら  チームの成果量を最大化するように動かないと無理  ● プロジェクト進行における  二兎を追う方法を強制インストールした感覚 

Slide 40

Slide 40 text

チームで没頭し続ける開発で、得たもの  強制的な能力の拡張  ● 目の前にはやりたいことだらけの Issues  ● これまでの開発経験を総動員して  いかに早く実現まで辿り着けるかの勝負を毎時毎分  ● 経験のないこともすぐにやれないと間に合わない  はじめて React を書いたし RDBMS は6年ぶり 

Slide 41

Slide 41 text

ほとんどのミーティングを欠席して、失ったもの  信頼と信用  ● 昨日までいたマネジャーが別プロジェクトに異動  ● 定期 1 on 1 さえも2ヶ月ほどなくなり  ピープルマネジメントの放棄  ● 義理もなにもかなぐり捨ててしまった 

Slide 42

Slide 42 text

チームで没頭し続ける開発で、失ったもの  中長期・広範囲の目線の欠如  ● 短期成果に集中するあまり俯瞰した目線がなくなる  ● プロジェクトメンバー以外の様子は見られなくなる  ● 年単位のロードマップはほぼ白紙まで戻り  改めて大規模な組織変更、開発体制へ 

Slide 43

Slide 43 text

プロジェクトを終えて 

Slide 44

Slide 44 text

たのしかった  最も開発に熱狂した期間だった  ● STORES のミッション「Just for Fun」を感じた  ● そもそもお客さまにご迷惑をおかけしていたし  メンバーや周囲の人にもたくさんの迷惑をかけたので  端的に「たのしかった」なんて言っていいか迷うけど  ● それでも、振り返ると「たのしかった」が出てくる 

Slide 45

Slide 45 text

なぜ、たのしかった？  疲弊よりも満足が勝っていた  ● タイトでドラマチックな開発  ● 高速に課題を解き続けていく開発体験は  エンジニアとしての報酬系をすごく刺激してくれた  ● ひたすら開発に集中できたし  開発生産量は明らかに異常な上昇をしていた 

Slide 46

Slide 46 text

本当にごめんなさい  メンバーにご迷惑ばかりおかけしました  ● たのしかったと開き直ってしまったけど  ご迷惑をおかけして申し訳ないと思う気持ちも本当  ● マネジャー不在になって大変な思いをさせてしまった  ● わたしたちが集中している間に起きた「しわ寄せ」に対応してくれて、ありがとうございました 

Slide 47

Slide 47 text

また、やりたい  今度はもっとうまく熱狂したい  ● 速度と量を出して開発ができたのはよかったこと  ● 集中しすぎて周囲にご迷惑をかけてしまったのは  反省しなければならないこと  ● 反省を活かして、よかったことを再現していきたい  ● 熱を上げて開発する体験を、もっとうまく、意思を持って再現したいなと思っています 

Slide 48

Slide 48 text

まとめ 

Slide 49

Slide 49 text

再掲：このセッションのゴール  ひとりのエンジニアリングマネジャーが  炎上プロジェクトでの経験を通じて  自身のスタンス・信念・思想がどう変化したのか  みなさんがご自身の環境や状況に照らし合わせて  考えるヒントを持ち帰っていただけること 

Slide 50

Slide 50 text

2025年にあった人生の転機です  仕事のスタイルが大きく変わりました  before  ● マネジャーとして一歩身を引いて  チームに活躍してもらうようサポートをする  after  ● マネジャーも最前線で一緒に動いて  チーム全員で活躍できるよう全速力で走る 

Slide 51

Slide 51 text

どうやって熱狂を再現するか  みんなで模索中です  ● 決して短期の成果にしたくない  ● 炎上プロジェクトをしたいわけじゃない  熱狂する開発プロジェクトをやりたい  ● 強弱はあるにせよ  いつも「今日の開発もたのしかったなあ」と  熱狂的に課題を解き続ける開発組織でありたい 

Slide 52

Slide 52 text

どうやって熱狂を再現するか  みなさんは、どうしますか？          ご清聴ありがとうございました 