STORES・STORES レジを支えるチーム開発文化 / Sustaining the team culture of STORES EC Regi
by
phayacell
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
ヘイ株式会社 STORES・STORES レジを支えるチーム開発文化 どのようにつくるか・なにをつくるか 山下 隼人
Slide 2
Slide 2 text
はじめまして、こんばんは 氏名:山下 隼人(やました はやと) Twitter, GitHub:@phayacell バックエンドエンジニアとして機能開発を担当しています 趣味は朝4時に起きて筋トレをすることです
Slide 3
Slide 3 text
遍歴 2011年4月:社会人になる 主に受託開発 2019年8月:ヘイ株式会社(当時 ストアーズ・ドット・ジェーピー)に転職 STORES で自社プロダクト開発に携わる 2021年7月:STORES レジの開発チームに参画 STORES レジのサービス開始1ヶ月後のジョイン 引き続き STORES の開発にも携わっている
Slide 4
Slide 4 text
STORES・STORES レジを支えるチーム開発文化 今日のテーマ
Slide 5
Slide 5 text
今日のテーマ STORES・STORES レジを支えるチーム開発文化 ● 顧客への価値提供を最短かつ着実に届けるため いろいろな工夫をチーム開発文化に取り入れています ● バックエンドエンジニア目線で「良い」と思っていることを ご紹介させていただきます
Slide 6
Slide 6 text
今日のテーマ - STORES・STORES レジを支えるチーム開発文化 チーム開発文化
Slide 7
Slide 7 text
「チーム開発文化」を2つに分解 ● どのようにつくるか ● なにをつくるか 今日のテーマ - STORES・STORES レジを支えるチーム開発文化
Slide 8
Slide 8 text
今日のテーマ - STORES・STORES レジを支えるチーム開発文化 どのようにつくるか - STORES なにをつくるか - STORES レジ
Slide 9
Slide 9 text
プロジェクトの進め方 どのようにつくるか
Slide 10
Slide 10 text
どのようにつくるか - STORES STORES(当時 STORES.jp)は2012年8月にサービス開始
Slide 11
Slide 11 text
どのようにつくるか - STORES サービス運営期間の長いサービス ● 歴史を積み重ねてきたプロダクトコードが生きている ● 機能開発、改善、改修を加えるのは大変(なこともある) 顧客への価値提供を最短かつ着実に届けたい ● 開発プロセスを工夫して、価値提供を早めていきたい ● つまり「どのようにつくるか」を考えることが主題
Slide 12
Slide 12 text
どのようにつくるか - STORES 前提:開発チームについて ● 採用プロセス:スクラム ● メンバ数:3名(時期、プロジェクトによる) チーム開発でやっている工夫 ● チーム全員でひとつの課題に向き合う ● モブプログラミング・プロトタイピング
Slide 13
Slide 13 text
チーム全員でひとつの課題に向き合う どのようにつくるか
Slide 14
Slide 14 text
どのようにつくるか - チーム全員でひとつの課題に向き合う チーム全員でひとつの課題に向き合う ● スプリントプランニングでチーム全員がタスクを見積もり Pull Request を出せるまで理解が深まっている状態を目指す ● 誰でもタスクに取り組める状態をつくり ボトルネックの排除やチーム開発の可用性を向上させる
Slide 15
Slide 15 text
どのようにつくるか - チーム全員でひとつの課題に向き合う 📝 具体的にやっていること ● タスク(Issue)の内容を読み合わせて 不明点があればその場で挙げ、ストーリーポイントを付ける ● その場で解決しなければ調査タスクをつくり出し 実装イメージできなければ、モブプロ・プロトタイピングを試みる(後述)
Slide 16
Slide 16 text
どのようにつくるか - チーム全員でひとつの課題に向き合う(ほぼモザイク)
Slide 17
Slide 17 text
どのようにつくるか - チーム全員でひとつの課題に向き合う 🎉 得られた効果 ● チーム全員が課題に対して同じ理解度を持つことによって いろんな観点から課題解決の方法を出せるようになった ● すでに理解している箇所になるので、コードレビューが早くなり 開発速度が向上した(手戻りなどのリスクも削減)
Slide 18
Slide 18 text
モブプログラミング・プロトタイピング どのようにつくるか
Slide 19
Slide 19 text
どのようにつくるか - モブプログラミング・プロトタイピング モブプログラミング・プロトタイピング ● ある程度動くコードを書いて、課題に対して議論をする ● 動くものを見ることで課題への理解度を上げ、不確定要素や懸念を洗い出す
Slide 20
Slide 20 text
どのようにつくるか - モブプログラミング・プロトタイピング 📝 具体的にやっていること ● 実装方針からふわっとしていたらモブプログラミング ある程度の方向性が決まっていればプロトタイピングでコードを書く ● チームメンバーでレビューする時間を設けて コードを眺めたり、実際に動かしてみたりして課題や懸念を話し合う ● このときに書いたコードはそのまま採用せず 取り組むべきタスクに落とし込んだら思い切って捨てる
Slide 21
Slide 21 text
どのようにつくるか - モブプログラミング・プロトタイピング(だいたいモザイク)
Slide 22
Slide 22 text
どのようにつくるか - モブプログラミング・プロトタイピング 🎉 得られた効果 ● 実際に書いてみないと判断できない課題に対する理解度が深まったので もし、何もせずにタスクに着手していたら 「あの機能にも影響してしまう」「このフローの考慮を入れなくちゃ」 と膨れ上がっていたかもしれない工数を未然に食い止められた ● 各自が持っている業務知識、歴史的経緯の把握など 多くの暗黙知を共有することができた
Slide 23
Slide 23 text
どのようにつくるか 小さなチームで大きな成果を〜STORES 新決済手段追加の舞台裏〜 https://tech.hey.jp/entry/2022/05/12/101620
Slide 24
Slide 24 text
プロダクト開発の工夫 なにをつくるか
Slide 25
Slide 25 text
なにをつくるか - STORES レジ STORES レジは2021年6月にサービス開始
Slide 26
Slide 26 text
なにをつくるか - STORES レジ サービス開始直後の新しいプロダクト ● 最新の最善を尽くしたプロダクトコードによってつくられている ● たくさんの足りていない機能があり、盛りだくさんの開発ロードマップ 顧客への価値提供を最短かつ着実に届けたい ● より大きな価値を選び、優先的に届けていきたい ● つまり「なにをつくるか」を考えることが主題
Slide 27
Slide 27 text
なにをつくるか - STORES レジ 前提:プロダクトについて ● iOS アプリ、Web ページの2つのフロントエンドがある ● レジ業務は iOS アプリで、バックオフィス業務は Web ページ チーム開発でやっている工夫 ● VOC(Voice of Customer)の活用 ● 週次で開発ロードマップの確認
Slide 28
Slide 28 text
VOC(Voice of Customer)の活用 なにをつくるか
Slide 29
Slide 29 text
なにをつくるか - VOC(Voice of Customer)の活用 VOC(Voice of Customer)の活用 ● オンボーディング・カスタマーサポート・セールスのメンバーから 直近リリースした機能に関する声、アカウント開設に至らなかった理由など 顧客の声を取り上げてもらい、みんなで議論して深堀りをする ● なぜそのような声があがるのか、根底になる課題とは 競合と比較して「STORES レジの強み」などを考える場として機能
Slide 30
Slide 30 text
なにをつくるか - VOC(Voice of Customer)の活用 📝 具体的にやっていること ● ユーザーから寄せられる機能要望・質問を集めて 特に要望頻度の高いものや課題感の強いものをピックアップして議論 ● 開発ロードマップで予定している機能開発で 解決できるものなのか・足りていないのか プロダクトをどうしていくか考えて、適宜反映させていく(後述)
Slide 31
Slide 31 text
なにをつくるか - VOC(Voice of Customer)の活用(まあまあモザイク)
Slide 32
Slide 32 text
なにをつくるか - VOC(Voice of Customer)の活用 🎉 得られた効果 ● 顧客の抱えている課題を一次情報として知り PM、エンジニア、セールス、カスタマーサポートなどの隔たりなく チーム全体で顧客への理解が深まった ● プロダクトをより使いやすくするためのヒントを得られている
Slide 33
Slide 33 text
週次で開発ロードマップの確認 なにをつくるか
Slide 34
Slide 34 text
週次で開発ロードマップの確認 ● つくるべき機能はたくさんあるため 顧客の抱えている「より強い課題」について考え見直し、修正していく ● VOC で深堀りした議論が活きてくる場になっており 「プロダクトとしてやらないこと」「やりたいけど今はやらないこと」 を明確にして納得感のある状態でチーム開発を行う なにをつくるか - 週次で開発ロードマップの確認
Slide 35
Slide 35 text
📝 具体的にやっていること ● 現在進捗中のプロジェクトの状況を確認して 前倒し・後倒しがあれば修正して、後続プロジェクトを調整する ● VOC などで開発優先度の前後があればロードマップに反映 なにをつくるか - 週次で開発ロードマップの確認
Slide 36
Slide 36 text
なにをつくるか - 週次で開発ロードマップの確認(ぜんぶモザイク)
Slide 37
Slide 37 text
🎉 得られた効果 ● 日々深まっていく顧客理解に応じて開発優先度を同期するため 開発チームが「自分たちのつくるもの」に対する納得感が生まれやすい ● 常に「自分たちのつくるもの」が整理されている状態が維持されているので 次にやる、その次にやるプロジェクトに向けて 先んじて手を打ちやすくなっている(仕様検討や設計・実装の考慮など) なにをつくるか - 週次で開発ロードマップの確認
Slide 38
Slide 38 text
STORES レジ のVOC駆動開発 https://note.com/chocoyama/n/n42fb50adde0f なにをつくるか
Slide 39
Slide 39 text
最近の課題
Slide 40
Slide 40 text
最近の課題 顧客の声だけではなく、定量的な指標も併せ持ちたい ● 取り上げられる顧客の声はとても定性的 ● 声があがらないところで困っているユーザーもいるかもしれない すでに喜ばれているから声があがっていないのかもしれない ● 問い合わせや要望の声だけを見ていると こうした「見えない部分」の意識が抜けてしまう恐れがある 絶賛取組中 ● 改善する機能の利用率・離脱率などの計測 ● 現状取りうる数値からの KPI 設定
Slide 41
Slide 41 text
まとめ
Slide 42
Slide 42 text
まとめ ● 顧客への価値提供を最短かつ着実に届けることを考えた チーム開発文化づくりをしている ● どのようにつくるか ○ チーム全員でひとつの課題に向き合う ○ モブプログラミング・プロトタイピング ● なにをつくるか ○ VOC(Voice of Customer)の活用 ○ 週次で開発ロードマップの確認
Slide 43
Slide 43 text
hey | エンジニア採用 https://hello.hey.jp/engineer おわりに - We are hiring!