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

Scrum Fest Osaka 2024で発表した内容です。
https://www.scrumosaka.org/
https://confengine.com/conferences/scrum-fest-osaka-2024/proposal/20059

■リンク
後回しにされがちな問題を改善するための「改善デー」「やさしさデー」のご紹介
https://tech.layerx.co.jp/entry/2023/12/27/171319
Q. 完成の定義と受け入れ基準の違いは何ですか？
https://www.ryuzee.com/faq/0077
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法
https://speakerdeck.com/moriyuya/product-management-rsgt2023
開発速度が速い #とは（LayerX社内資料）
https://speakerdeck.com/layerx/how-fast-is-the-development-speed
Startup in Agile #1 みんなの「身の丈アジャイル」プラクティスを語ろう！
https://startup-in-agile.connpass.com/event/320346/

Transcript

1. © 2024 LayerX Inc. スタートアップ企業が実践する 「⾝の丈スクラム」の現在地 あらたま @ Scrum Fest Osaka 2024
2. © 202４ LayerX Inc. 2 @ 株式会社LayerX バクラク事業部 💻 エンジニア→CTO→EM⇔エンジニア 🏈 スクラムによる開発は3社+αで経験 あらたま（新多真琴 / ar_tama） ⾃⼰紹介‧PR
3. 3 今⽇はこのチームの話をします 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を５秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を５秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
4. © 202４ LayerX Inc. 4 「バクラク申請‧経費精算」はこんなチーム - 共通のプロダクトゴールを持つ、2つのチームから組成（計約15名） - appチーム - エンジニア、デザイナー、PdM(PO) - webチーム ★今⽇はこちらのエンジニア視点の話が主 - エンジニア、デザイナー、QAE、PdM(PO) - それぞれにチームリーダー（エンジニア）を1名ずつアサイン - 上段の意思決定はPdMとリーダーで⾏う はじめに：チーム構成の紹介
5. © 202４ LayerX Inc. 5 - ユーザーに価値を最速最⼤で届けて、プロダクトゴールを達成したい！ - そのために⾼速でイテレーションを回したい！ ただし、スタートアップはないないづくし😢 - チームに⼈が⾜りることはない - 負債が返しきれることはない - ⼈の流動性を低く保つことができない - 環境の変化は我々を待ってくれない 私たちとスクラム
6. © 202４ LayerX Inc. 6 スクラムの理論「透明性、検査、適応」はまさに私たちの⽬的とも合致するはず - スタートアップが⼤企業に匹敵できるかもしれない鍵はアジリティ - 経験主義を地でいく、「FactBase」の考え⽅ 私たちとスクラム
7. © 202４ LayerX Inc. 7 私たちが直⾯した、スクラムによるチーム開発における「あるある」な課題を スクラムガイドや先⼈の知恵をたずねながら、あるいはガイドを再解釈しながら どう乗り越えようとしてきた‧しているかをシェアします 📣 いざ取り⼊れてみると、なかなかうまくいかない
8. CASE01. プロダクトバックログを 分裂させたくなる誘惑
9. © 202４ LayerX Inc. 9 ことのはじまり プロダクトバックログを分裂させたくなる誘惑 - プロダクトゴールを達成するための課題は⼭積み🔥 - 開発が進むと、プロダクトゴールとの相関が薄いアイテムが⽣まれる - ユーザビリティ向上のためにやったほうがいいこと - 脆弱性対応や技術的課題への対応 - → 緊急度‧重要度を同じ観点で測れず、POが順位を付けられない - 20%ルールを敷いても、⼤⽟施策や差し込み対応のバッファになりがち そうだ、観点ごとに複数のバックログを作って運⽤しよう💡
10. © 202４ LayerX Inc. 10 バックログ、分裂しちゃいました 📝 → 📝📝📝 プロダクトバックログを分裂させたくなる誘惑 - スプリントプランニングではメインのプロダクトバックログしか参照され ず、他のバックログからピックするルールが別途必要になる - 20%ルールを敷いてもバッファ扱いされがち（2回⽬） - たとえバックログを分割しても、⽚⼿間で進められない⼤きさの課題は結局 プロダクトバックログとの折り合いをつける必要がある おや、解決されないな…？
11. © 202４ LayerX Inc. 11 スクラムガイドをたずねる プロダクトバックログを分裂させたくなる誘惑 プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必 要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源であ る。 - バックログを複数持つことはガイドでは推奨されていないことが分かる - やるべきは「がんばって同じ尺度で判断可能にすること」？
12. © 202４ LayerX Inc. 12 私たちの現在地 プロダクトバックログを分裂させたくなる誘惑 - ⼩粒な「やりたい（あとはやるだけ）けどなかなか時間が取れない」タスク は、“改善デー”を毎⽉実施することで段階的に改善 - あまりにパツパツだと実施できないことも😢 - フェーズに合わせて柔軟に調整 - 腰を据えてじっくり取り組むような⼤⽟タスクは、価値基準を揃えてプロダ クトバックログに統合 出典: 後回しにされがちな問題を改善するための「改善デー」「やさしさデー」のご紹介
13. © 202４ LayerX Inc. 13 私たちの現在地 プロダクトバックログを分裂させたくなる誘惑 例: 技術的課題のアウトカム軸をPOとの共通⾔語に変換し、優先度を検討 - 時間軸や進め⽅についての材料があると⽬処が⽴てやすい - 余談：「開発⽣産性向上」は「ユーザー体験」「デグレ抑制」に双⽅に効く 指標として取り扱うことに 過去の技術的課題を加⼯したもの
14. CASE02. デグレ増殖問題
15. © 202４ LayerX Inc. 15 ことのはじまり デグレ増殖問題 - 仕様の複雑さや考慮漏れが原因で、以下の3で検知されるデグレが増えてきた - その結果、本番デプロイ前にバタバタしがち（コードフリーズとは…） 1. 開発、セルフチェック、コードレビュー 2. コードフリーズ 3. 検証（必要に応じて修正） 4. 本番デプロイ
16. © 202４ LayerX Inc. 16 スクラムガイドをたずねる→先⼈の知恵をたずねる デグレ増殖問題 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した 正式な記述である。プロダクトバックログアイテムが完成の定義を満たしたとき にインクリメントが誕⽣する。 - 「完成の定義」はすべてのプロダクトバックログアイテムに対して共通して 適⽤されるものらしい - 完成の定義を引き上げることはもちろん、プロダクトバックログアイテムそ れぞれの受け⼊れ基準が⼗分に揃っていないことも問題 - e.g. 押印稟議に新機能を追加したら、経費精算でデグレした！ 出典: Q. 完成の定義と受け⼊れ基準の違いは何ですか？
17. © 202４ LayerX Inc. 17 - 前提として、全てのケースを網羅‧⼿動で検証するのは難しい - 検証フェーズからではなく、タスク着⼿時からテスト観点を取り⼊れようと している - QAの⼯程を分けるのではなく、全てのフェーズに浸透させる - スプリントプランニングにもQAEが参加 - Playwrightなどの⾃動テストを、QAEだけでなくエンジニアも触れるように 整備‧布教 - ただし、開発フェーズへの⾃然な組み込みには⾄っていない… - 圧倒的伸びしろだらけ！やっていくぞ〜🔥 私たちの現在地 w/ デグレ増殖問題
18. CASE03. 専任スクラムマスターが 置けない問題
19. © 202４ LayerX Inc. 19 ことのはじまり 専任スクラムマスターが置けない問題 - スクラムマスターの必要性は、開発サイクルがうまく回っていないときほど 実感されやすい - 逆に“回ってしまっている”と軽視されがち - ことスタートアップにおいては、⼤抵ヘッドカウントに限りがあるため、 「専任スクラムマスターを置くか」＝「開発⼈員を削る覚悟があるか」の問 いになりがち - とはいえ、開発⼈員の誰かが⽚⼿間でやるのは現実的ではない… - だからロールが分けられているということでもある
20. © 202４ LayerX Inc. 20 スクラムガイドをたずねる 専任スクラムマスターが置けない問題 スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの 結果、（略）スクラムチームの有効性に責任を持つ。 ということは、以下のような要素がありそう - スクラムチームが進捗を出せる仕組みを作る - POのバックログ整備を⽀援する - プロダクトゴール‧スプリントゴールの定義、達成を⽀援する
21. © 202４ LayerX Inc. 21 ここでちょっと脱線 専任スクラムマスターが置けない問題 チームの構成要素が変われば、スクラムの運⽤⽅法も変わるはず - ⼈数 - インクリメントの総量と各イベントのコストが⽐例する - プロダクトの成熟度 - ⽴ち上げ期と安定期ではバックログの優先度判断も異なる - メンバーのプロダクトへの習熟度 - 新メンバーが多いと、バックログへの理解度もまちまち - ユーザー（価値を届ける先）との距離感 - 距離が近いほど経験主義を実践しやすい（時には開発さえ不要）
22. © 202４ LayerX Inc. 22 - ちょうど⼈の⼊れ替わり期で、新メンバーが半数 - 今までは「よしな」で回っていたスクラムの運⽤に軋みが⽣じ始めた - 問い - どうやったら皆が早く習熟して、プロダクトゴールを最速最⼤で達成で きるようになるだろうか？ - そのための仕組みづくり≒スクラムマスター業を誰か⼀⼈が兼任する以 外の⼿はないか？ → 全員が当事者だし、みんなでやるという選択肢もあるのでは🤔？（イマココ） スクラムガイドを再解釈する 専任スクラムマスターが置けない問題
23. © 202４ LayerX Inc. 23 私たちの現在地 専任スクラムマスターが置けない問題 ⽬的に⽴ち返りながら、チームリーダー/POを中⼼に皆で改善
24. CASE04. 「POがボトルネック」問題
25. © 202４ LayerX Inc. 25 ことのはじまり 「POがボトルネック」問題 - PO「⾃分がボトルネックで、エンジニアに開発タスクを渡せない」 - エンジニア「POが忙しそうすぎて⾒ていられない…何か巻き取れないかな」 - EM「エンジニアが前よりドメインにディープダイブしなくなったよね」 何か掛け違いが⽣まれていそう🤔？
26. © 202４ LayerX Inc. 26 整理してみた 「POがボトルネック」問題 - 確かに、エンジニアのドメインへの習熟に伸びしろはある - ドメイン理解に⾃信がないと⼿出しを躊躇してしまうのも分かる - あるいは、POのタスクがブラックボックス化しすぎていて⼿出ししにく いのかも - おそらく最短距離は「全部俺」で課題の発⾒から解決までを⾏うこと - ただし1⼈でできることは、多いようで少ない。だからチームがある - PO‧エンジニアとロールが分かれているからには、適切な線引きポイントが あるはず…！
27. © 202４ LayerX Inc. 27 スクラムガイドをたずねる 「POがボトルネック」問題 プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。 （略）プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもでき る。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの 決定を尊重しなければならない。 プロダクトに関する意思決定の責任を負うのはプロダクトオーナー。でも、「全 ての意思決定をPOにお任せ」ということではなさそう
28. © 202４ LayerX Inc. 28 先⼈の知恵をたずねる 「POがボトルネック」問題 過度な分業を避け、全員が⾃律的に意思決定‧⾏動できるだけの透明性が必要 出典: 「私考える⼈、あなた作業する⼈」を越えて、 プロダクトマネジメントがあたりまえになるチームを明⽇から実現していく⽅法
29. © 202４ LayerX Inc. 29 放置しているとまずいかも 「POがボトルネック」問題 全ての意思決定をPOにお任せしていると、⾃分たちで何も決められないチームに なっていく - 個々⼈のプロダクトバックログアイテムへの理解が不⼗分だと、スプリント バックログを消化する中で⽣じる様々なトレードオフを判断できない - 価値を⽣むまでの時間が「PO待ち」で増えていく - チームで検査‧適応のサイクルを回せない - POの意思決定の根拠が分からないと、プロダクトゴールやスプリントゴール の確からしさを検証できない - チームから透明性が失われる
30. © 202４ LayerX Inc. 30 私たちの現在地 「POがボトルネック」問題 - エンジニアの⼀番の強みは、あくまでもエンジニアリング - ただし、顧客への価値提供のラストワンマイルを担っているのもエンジニア - それでも…時間は有限…！ - 制約を踏まえつつ、ドメインにディープダイブすることを諦めない - POと同化しようとはしない - 背中を預け合いながら、⼿を伸ばし続けることこそが重要 - POの持っているディスカバリータスクも⾒える化していきたい - 「使われないものを作らない」
31. © 202４ LayerX Inc. 31 「使われないものを作らない」 「POがボトルネック」問題 出典: 開発速度が速い #とは（LayerX社内資料）
32. CASE05. スプリントプランニングに 時間かかりすぎ問題
33. © 202４ LayerX Inc. 33 スクラムガイドをたずねる スプリントプランニングに時間かかりすぎ問題 スプリントが 1 か⽉の場合、スプリントプランニングのタイムボックスは最⼤で 8 時間である。スプリントの期間が短ければ、スプリントプランニングの時間も 短くすることが多い。 - 2週間スプリント（10営業⽇）の場合は、最⼤4時間と解釈できる - 会議を抜いた1⽇あたりの最⼤作業時間を4時間としたとき、1⽇分の作 業時間に相当すると考えると、ちょっと抵抗がある - と思いながらも、いざやってみると意外と時間がかかるジレンマ
34. © 202４ LayerX Inc. 34 ことのはじまり スプリントプランニングに時間かかりすぎ問題 - ⼈やタスク量が増えてきて、スプリントプランニングの所要時間がだんだん 延びてきた - 前提として、会議にかかる時間は短ければ短いほどよい - 「⾃分、プランニングとっとと終わらせて開発したいっす」 - ⻑引くと、議論に積極参加しなくてもいいや→内職のコンボが起きがち - スプリントプランニングが⼤事なイベントであることは理解しているけど、 なんとかして効率化した〜い！
35. © 202４ LayerX Inc. 35 スクラムガイドをたずねる スプリントプランニングに時間かかりすぎ問題 トピック 1：このスプリントはなぜ価値があるのか？ トピック 2：このスプリントで何ができるのか？ トピック 3：選択した作業をどのように成し遂げるのか？ - トピック1, 2, 3が解きたい課題のWhy, What, Howに相当すると解釈 - ガイドを読む限りでは1→3ときれいに流れるように⾒えるが、実際には… - 何らかの⼯数⾒積もりがないと、選択されたプロダクトバックログアイ テム（の完成）がそのスプリントに収まるかを判断できない - ≒スプリントゴールの達成確度が読めず、スプリントの価値が不定に
36. © 202４ LayerX Inc. 36 スクラムガイドをたずねる スプリントプランニングに時間かかりすぎ問題 スプリントでは、プロダクトバックログを必要に応じてリファインメントする。 プロダクトバックログの内容を⾒積もり可能な状態まで（全員で）把握するのは 時間がかかるので、プランニングで全部を賄おうとしないほうがよさそう - どうやら「リファインメント」とやらの出番っぽい - ただしリファインメントの⼿法について、ガイドには明記がない - おそらく各社⼿探りなところ - 私たちも⼿探りでやっています…！
37. © 202４ LayerX Inc. 37 - リファインメントを2種類定義してみた - バックログ優先度決め - Why, What（トピック1, 2）について合意する場 - エンジニアも参加し、⼤体のHowにあたりをつけておく - バックログ仕様レビュー - How（トピック3）について全員で合意する場 - ⾒積もり（プランニングポーカー）もここでやる - ※Howが複数出た場合、Whatを再検討することも スクラムガイドを再解釈する スプリントプランニングに時間かかりすぎ問題
38. © 202４ LayerX Inc. 38 私たちの現在地 スプリントプランニングに時間かかりすぎ問題 エンジニアもWhyとWhatを深く理解し、「使われないものを作らない」ための Howを持った上で、スプリントプランニングに臨めるようになった - 場の⽬的や進⾏がシャープになり、ダイエット成功！ - スプリントレビュー‧プランニング合計で1h程度に短縮 - スプリントゴールへ意識が向きやすくなり、達成のためのコミュニケー ションが盛んに取られるようにもなった - ⼀⽅で、リファインメント2種の頻度や内容、進め⽅には改善の余地あり - 「全員の合意がないと開発できないの？重くない？」
39. © 202４ LayerX Inc. 39 CASE01. プロダクトバックログを分裂させたくなる誘惑 - 複数のプロダクトバックログを置くのではなく、価値基準を揃えてPOと⼀緒 に優先度を判断 CASE02. デグレ増殖問題 - タスクの着⼿時からテスト観点を取り⼊れて、QAを全てのフェーズに浸透 CASE03. 専任スクラムマスターが置けない問題 - 全員が当事者として、⽬的に⽴ち返りながらみんなで分担 まとめ - 私たちの現在地 スプリントプランニングに時間かかりすぎ問題
40. © 202４ LayerX Inc. 40 CASE04. 「POがボトルネック」問題 - エンジニアはPOと背中を預け合いながらも意思決定への理解を諦めない - 「使われないものを作らない」 CASE05. スプリントプランニングに時間かかりすぎ問題 - リファインメントを「なぜやるのか、何をやるのか」「どうやるのか」を合 意する場とする まとめ - 私たちの現在地 スプリントプランニングに時間かかりすぎ問題
41. © 202４ LayerX Inc. 41 私たちはこんな感じ！ みなさんは？ 根底にあるのは「ユーザーに価値を最速最⼤で届けたい。そのために⾼速でイテ レーションを回したい。だけど制約も多いから、スクラムのやり⽅も試⾏錯誤し ていこう」という姿勢 - チームの置かれた環境や、プロダクトの性質‧フェーズによってもアプロー チは異なるはず - みなさんの取り組みもぜひ教えてください！
42. © 202４ LayerX Inc. 42 私たちはこんな感じ！ みなさんは？ 根底にあるのは「ユーザーに価値を最速最⼤で届けたい。そのために⾼速でイテ レーションを回したい。だけど制約も多いから、スクラムのやり⽅も試⾏錯誤し ていこう」という姿勢 - チームの置かれた環境や、プロダクトの性質‧フェーズによってもアプロー チは異なるはず - みなさんの取り組みもぜひ教えてください！
43. © 202４ LayerX Inc. 43 最後に宣伝！8/6(⽕)にイベントやります！ スタートアップ企業のアジャイル実践者によるコミュニティを⽴ち上げました🔥 第⼀回のテーマは「わたしのチームの⾝の丈アジャイル」！