Re: スタートアップ企業が実践する「身の丈スクラム」の現在地 / Re: Current State of 'Right-Sized Scrum' Practices in Startups

Startup in Agile #1 みんなの「身の丈アジャイル」プラクティスを語ろう！ で発表した内容です。
https://startup-in-agile.connpass.com/event/320346/

前身はこちら:
スタートアップ企業が実践する「身の丈スクラム」の現在地
https://speakerdeck.com/ar_tama/current-state-of-right-sized-scrum-practices-in-startups

爆速開発文化を支えるProduct Engineerの 開発生産性向上の取り組み
https://speakerdeck.com/shnjtk/layerx-improve-development-productivity-of-product-engineers

Transcript

1. © 2024 LayerX Inc. Re: スタートアップ企業が実践する 「⾝の丈スクラム」の現在地 あらたま @ Startup in Agile #1
2. © 2024 LayerX Inc. Re: スタートアップ企業が実践する 「⾝の丈スクラム」の現在地 あらたま @ Startup in Agile #1
3. © 202４ LayerX Inc. 3 ℹ 45分のトークを20分に再編してお話しします󰝋💨 私たちが直⾯した、スクラムによるチーム開発における「あるある」な課題を スクラムガイドや先⼈の知恵をたずねながら、あるいはガイドを再解釈しながら どう乗り越えようとしてきた‧しているかをかいつまんでシェアします 📣 今⽇お話しすること
4. © 202４ LayerX Inc. 4 株式会社LayerX バクラク事業部 EM（エンジニアリングマネージャー） 📝ソフトウェアエンジニアとしてキャリアを積んだのち、株 式会社Cake.jpへ転職、執⾏役員CTOを務めた。2023年より現 職。 󰩵 全国津々浦々のサウナ探訪が趣味 🍡 ⽇本もちもち協会 代表 🏆 YAPC::Kyoto 2023 ベストスピーカー賞 あらたま（新多真琴 / ar_tama） ⾃⼰紹介‧PR
5. 5 今⽇はこのプロダクトの開発チームの話をします 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を５秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を５秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
6. © 202４ LayerX Inc. 6 バクラク申請‧経費精算（Web）はこんなチーム - 2021/04にリリースしたプロダクト - プロダクトライフサイクルとしては成⻑期にあたる - 沢⼭のお客様にご利⽤いただいており、ご要望も多数 - チームの構成 - EM、エンジニア、デザイナー、QAE、PdM(PO) - タックマンモデルでいうところの、混乱期〜統⼀期(※) - 直近でメンバーの⼊れ替わりがあり、リビルド→⾛り出し はじめに：プロダクトとチームの紹介
7. © 202４ LayerX Inc. 7 - プロダクト開発に対する私たちのスタンス - ユーザーに価値を最速最⼤で届けて、プロダクトゴールを達成したい！ - そのために⾼速でイテレーションを回したい！ - ただし、スタートアップはないないづくし😢 - そこでスクラムですよ - 「透明性、検査、適応」はまさに私たちの⽬的とも合致するはず - スタートアップが急成⻑するための鍵はアジリティ これにて解決！ 〜完〜 私たちとスクラム
8. © 202４ LayerX Inc. 8 - いざ取り⼊れてみるとうまくいかないことばっかり🥺 - それもそのはず - スクラムとはフレームワークであり、スクラムガイドはその定義 - チームにどう適⽤するかは我々に委ねられている - 結局のところ、置かれた環境を検査して適応していくしかない と思うじゃないですか
9. © 202４ LayerX Inc. 9 スクラムの運⽤⽅法は、チームの構成要素に依存する - ⼈数 - インクリメントの総量と各イベントのコストが⽐例する - プロダクトの成熟度 - ⽴ち上げ期と安定期ではバックログの優先度判断も異なる - メンバーのプロダクトへの習熟度 - 新メンバーが多いと、バックログへの理解度もまちまち - ユーザー（価値を届ける先）との距離感 - 距離が近いほど経験主義を実践しやすい（時には開発さえ不要）
10. © 202４ LayerX Inc. 10 4つの「あるある」なケーススタディを持ってきました - あくまでも、私たちの現在地のスナップショットです - ⽇進⽉歩‧朝令暮改上等でやり⽅を変えています - 前回の発表（6⽉末）から変わった部分のご紹介も持ってきました - プロダクトやチームのフェーズによっても変わるはず - このあと、皆さんのプラクティスを聞けるのがとても楽しみです！
11. CASE01. プロダクトバックログを 分裂させたくなる誘惑
12. © 202４ LayerX Inc. 12 ことのはじまり プロダクトバックログを分裂させたくなる誘惑 - プロダクトゴールを達成するための課題は⼭積み🔥 - 開発が進むと、プロダクトゴールとの相関が薄いアイテムが⽣まれる - ユーザビリティ向上のためにやったほうがいいこと - 脆弱性対応や技術的課題への対応 - → 緊急度‧重要度を同じ観点で測れず、POが順位を付けられない - 20%ルールを敷いても、⼤⽟施策や差し込み対応のバッファになりがち 観点ごとに複数のバックログを作って運⽤すると、どうなる？
13. © 202４ LayerX Inc. 13 プロダクトバックログを分裂させたくなる誘惑 - 結局、⽚⼿間で進められない⼤きさの課題はプロダクトバックログとの折り 合いをつける必要がある - 20%ルールを敷いてもバッファ扱いされがち（2回⽬） - いっそのことバックログもチームも分裂させてみる？ - メインのチームが忙しいとき、本当にサブチームから⼈を都合しようと したくならない？ - なるよね🥺 こうなる
14. © 202４ LayerX Inc. 14 スクラムガイドをたずねる プロダクトバックログを分裂させたくなる誘惑 プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必 要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源であ る。 - バックログを複数持つことはガイドでは推奨されていないことが分かる - やるべきは「がんばって同じ尺度で判断可能にすること」？
15. © 202４ LayerX Inc. 15 私たちの現在地 プロダクトバックログを分裂させたくなる誘惑 他の施策と価値基準を揃えて、優先度を検討 - 技術的課題のアウトカム軸をPOとの共通⾔語に翻訳する - 時間軸や進め⽅についての材料があると⽬処が⽴てやすい - ⼩粒なものは定期的に「改善デー」を設けてまとめて倒す 過去の技術的課題を加⼯したもの
16. CASE02. 専任スクラムマスターが 置けない問題
17. © 202４ LayerX Inc. 17 ことのはじまり 専任スクラムマスターが置けない問題 - スクラムマスターにまつわる永遠の問い - 「専任スクラムマスターを置くか」＝「開発⼈員を削る覚悟があるか」 - とはいえ、開発⼈員の誰かが⽚⼿間でやるのは現実的ではないシーンも… - だからロールが分けられているということでもある - まずは要素を抽出してみよう
18. © 202４ LayerX Inc. 18 スクラムガイドをたずねる 専任スクラムマスターが置けない問題 スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの 結果、（略）スクラムチームの有効性に責任を持つ。 - スクラムチームが進捗を出せる仕組みを作る - POのバックログ整備を⽀援する - プロダクトゴール‧スプリントゴールの定義、達成を⽀援する
19. © 202４ LayerX Inc. 19 私たちの現在地 専任スクラムマスターが置けない問題 - 全員が当事者というスタンスで、⽬的に⽴ち返りながら皆で改善 - 迷ったら最後はPdMとEMが決めると割り切る - ⚠ 「スクラムをうまくやるための改善」にしない。Be Agile!
20. CASE03. 「POがボトルネック」問題
21. © 202４ LayerX Inc. 21 ことのはじまり 「POがボトルネック」問題 - 「POはディスカバリー担当、エンジニアはデリバリー担当」 - 本当に？ - おそらく最短距離は「全部俺」で課題の発⾒から解決までを⾏うこと - ただし1⼈でできることは、多いようで少ない - だからチームがある - 適切な分担ポイントはどこだろう？
22. © 202４ LayerX Inc. 22 スクラムガイドをたずねる 「POがボトルネック」問題 プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。 （略）プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもでき る。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの 決定を尊重しなければならない。 プロダクトに関する意思決定の責任を負うのはプロダクトオーナー。 でも、「全ての意思決定をPOにお任せ」ということではなさそう…
23. © 202４ LayerX Inc. 23 先⼈の知恵をたずねる 「POがボトルネック」問題 過度な分業を避け、全員が⾃律的に意思決定‧⾏動できるだけの透明性が必要 出典: 「私考える⼈、あなた作業する⼈」を越えて、 プロダクトマネジメントがあたりまえになるチームを明⽇から実現していく⽅法
24. © 202４ LayerX Inc. 24 放置しているとこうなっちゃうかも 「POがボトルネック」問題 意思決定に携わらないと、⾃分たちで何も決められなくなっていく - プロダクトバックログアイテムへの理解が不⼗分だと、実装時に⾒えてくる 様々なトレードオフを判断できない - 価値を⽣むまでの時間が「PO待ち」で延びていく - チームで検査‧適応のサイクルを回せない - POの意思決定の根拠が分からないと、プロダクトゴールやスプリントゴール の確からしさを検証できない - チームから透明性が失われる
25. © 202４ LayerX Inc. 25 私たちの現在地 「POがボトルネック」問題 - エンジニアの⼀番の強みは、あくまでもエンジニアリング - ただし、顧客への価値提供のラストワンマイルを担っているのもエンジニア - 制約を踏まえつつ、ドメインにディープダイブすることを諦めない - POと背中を預け合いながら、さらに⼿を伸ばし合う - POも施策が⽣煮えの段階からエンジニアをどんどん巻き込んでいく - 「使われないものを作らない」
26. © 202４ LayerX Inc. 26 「使われないものを作らない」 「POがボトルネック」問題 出典: 開発速度が速い #とは（LayerX社内資料）
27. CASE04. スプリントプランニングに 時間かかりすぎ問題
28. © 202４ LayerX Inc. 28 スクラムガイドをたずねる スプリントプランニングに時間かかりすぎ問題 スプリントが 1 か⽉の場合、スプリントプランニングのタイムボックスは最⼤で 8 時間である。スプリントの期間が短ければ、スプリントプランニングの時間も 短くすることが多い。 - 例えば2週間スプリント（10営業⽇）の場合は、最⼤4時間と解釈できる - …⻑すぎない？ - 4時間あったら、実装したいよね？ - ⻑引くと、議論に積極参加しなくてもいいや→内職のコンボが起きがち - ⼤事なイベントではあるけど、なんとかしたい
29. © 202４ LayerX Inc. 29 スクラムガイドをたずねる スプリントプランニングに時間かかりすぎ問題 トピック 1：このスプリントはなぜ価値があるのか？ トピック 2：このスプリントで何ができるのか？ トピック 3：選択した作業をどのように成し遂げるのか？ - トピック1, 2, 3が解きたい課題のWhy, What, Howに相当すると解釈 - ガイドを読む限りでは1→3ときれいに流れるように⾒えるが、実際には… - ⼯数が⾒積もれないと、選択されたプロダクトバックログアイテム（の 完成）がそのスプリントに収まるかを判断できない - ≒スプリントゴールの達成確度が読めず、スプリントの価値が不定に
30. © 202４ LayerX Inc. 30 スクラムガイドをたずねる スプリントプランニングに時間かかりすぎ問題 スプリントでは、プロダクトバックログを必要に応じてリファインメントする。 プロダクトバックログの内容を⾒積もり可能な状態まで（全員で）把握するのは 時間がかかるので、プランニングで全部を賄おうとしないほうがよさそう - どうやら「リファインメント」とやらの出番っぽい - ただしリファインメントの⼿法について、ガイドには明記がない - おそらく各社⼿探りなところ - 私たちも⼿探りでやっています…！
31. © 202４ LayerX Inc. 31 - リファインメントを2種類定義してみた - バックログ優先度決め - Why, What（トピック1, 2）について合意する場 - エンジニアも参加し、⼤体のHowにあたりをつけておく - バックログ仕様レビュー - How（トピック3）について全員で合意する場 - ⾒積もり（プランニングポーカー）もここでやる - ※Howが複数出た場合、Whatを再検討することも スクラムガイドを再解釈する スプリントプランニングに時間かかりすぎ問題
32. © 202４ LayerX Inc. 32 私たちの現在地 スプリントプランニングに時間かかりすぎ問題 エンジニアもWhyとWhatを深く理解し、「使われないものを作らない」ための Howを持った上で、スプリントプランニングに臨めるようになった - 場の⽬的や進⾏がシャープになり、ダイエット成功！ - スプリントゴールへ意識が向きやすくなり、達成のためのコミュニケー ションが盛んに取られるようにもなった - ⼀⽅で…
33. © 202４ LayerX Inc. 33 私たちの現在地（New!） スプリントプランニングに時間かかりすぎ問題 リファインメント② バックログ仕様レビューについて… - 👦👧 < 全員の合意がないと開発できないの？重すぎない？ - バックログがここで滞留し、次のスプリントに載らないリスク - ただし新メンバーとの観点や⼯数感のすり合わせの場にもなっていた - こうなりました - 1. エンジニアがPOと伴⾛してHowの叩きを作る - 2. デイリースクラムに「Howの叩きを磨く時間」を⼊れて、最短で⽇次 の改善サイクルを回す
34. © 202４ LayerX Inc. 34 私たちの現在地（New!） スプリントプランニングに時間かかりすぎ問題 そのさらに後… - 👦👧 < デイリースクラムのトピック多すぎて消化できないね - 👦👧 < 皆ある程度習熟してきたし、合議‧同期でHowを磨く必要ないかも - こうなりました - 1. エンジニアがPOと伴⾛してHowの叩きを作る - 2. 必要に応じて他のメンバーのレビューも⼊れる - 3. Howの磨き込み時間はスプリントバックログ側で吸収する
35. © 202４ LayerX Inc. 35 私たちはこんな感じ！ みなさんは？ 根底にあるのは「ユーザーに価値を最速最⼤で届けたい。そのために⾼速でイテ レーションを回したい。だけど制約も多いから、スクラムのやり⽅も試⾏錯誤し ていこう」という姿勢 皆さんの「⾝の丈スクラム」のお話も、ぜひ聞かせてください！ このあとも引き続き学び合いましょう〜🥳
36. © 202４ LayerX Inc. 36 最後にPR: お隣のチームの試⾏錯誤、公開しています バクラクでは、フェーズの違う各チームがさまざまな取り組みをしています！