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

by ar_tama

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

3 今⽇はこのチームの話をします稟議・支払申請・経費精算仕訳・支払処理効率化法人カードの発行・管理帳票保存・ストレージ帳票発行 * 経費精算のSlack連携は申請内容の通知のみ・AIが領収書を５秒でデータ化・スマホアプリとSlack連携あり・領収書の重複申請などミス防止機能・AIが請求書を５秒でデータ化・仕訳・振込データを自動作成・稟議から会計までスムーズに連携・年会費無料で何枚でも発行可・インボイス制度・電帳法対応・すべての決済で1%以上の還元・AIが書類を5秒でデータ化・あらゆる書類の電子保管に対応・電子取引・スキャナ保存に完全対応・帳票の一括作成も個別作成も自由自在・帳票の作成・稟議・送付・保存を一本化・レイアウトや項目のカスタマイズも可能

Slide 4

Slide 4 text

© 202４ LayerX Inc. 4 「バクラク申請‧経費精算」はこんなチーム - 共通のプロダクトゴールを持つ、2つのチームから組成（計約15名） - appチーム - エンジニア、デザイナー、PdM(PO) - webチーム ★今⽇はこちらのエンジニア視点の話が主 - エンジニア、デザイナー、QAE、PdM(PO) - それぞれにチームリーダー（エンジニア）を1名ずつアサイン - 上段の意思決定はPdMとリーダーで⾏うはじめに：チーム構成の紹介

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

CASE01. プロダクトバックログを分裂させたくなる誘惑

Slide 9

Slide 9 text

© 202４ LayerX Inc. 9 ことのはじまりプロダクトバックログを分裂させたくなる誘惑 - プロダクトゴールを達成するための課題は⼭積み🔥 - 開発が進むと、プロダクトゴールとの相関が薄いアイテムが⽣まれる - ユーザビリティ向上のためにやったほうがいいこと - 脆弱性対応や技術的課題への対応 - → 緊急度‧重要度を同じ観点で測れず、POが順位を付けられない - 20%ルールを敷いても、⼤⽟施策や差し込み対応のバッファになりがちそうだ、観点ごとに複数のバックログを作って運⽤しよう💡

Slide 10

Slide 10 text

© 202４ LayerX Inc. 10 バックログ、分裂しちゃいました 📝 → 📝📝📝 プロダクトバックログを分裂させたくなる誘惑 - スプリントプランニングではメインのプロダクトバックログしか参照されず、他のバックログからピックするルールが別途必要になる - 20%ルールを敷いてもバッファ扱いされがち（2回⽬） - たとえバックログを分割しても、⽚⼿間で進められない⼤きさの課題は結局プロダクトバックログとの折り合いをつける必要があるおや、解決されないな…？

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 202４ LayerX Inc. 12 私たちの現在地プロダクトバックログを分裂させたくなる誘惑 - ⼩粒な「やりたい（あとはやるだけ）けどなかなか時間が取れない」タスクは、“改善デー”を毎⽉実施することで段階的に改善 - あまりにパツパツだと実施できないことも😢 - フェーズに合わせて柔軟に調整 - 腰を据えてじっくり取り組むような⼤⽟タスクは、価値基準を揃えてプロダクトバックログに統合出典: 後回しにされがちな問題を改善するための「改善デー」「やさしさデー」のご紹介

Slide 13

Slide 13 text

Slide 14

Slide 14 text

CASE02. デグレ増殖問題

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 202４ LayerX Inc. 16 スクラムガイドをたずねる→先⼈の知恵をたずねるデグレ増殖問題完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。 - 「完成の定義」はすべてのプロダクトバックログアイテムに対して共通して適⽤されるものらしい - 完成の定義を引き上げることはもちろん、プロダクトバックログアイテムそれぞれの受け⼊れ基準が⼗分に揃っていないことも問題 - e.g. 押印稟議に新機能を追加したら、経費精算でデグレした！出典: Q. 完成の定義と受け⼊れ基準の違いは何ですか？

Slide 17

Slide 17 text

© 202４ LayerX Inc. 17 - 前提として、全てのケースを網羅‧⼿動で検証するのは難しい - 検証フェーズからではなく、タスク着⼿時からテスト観点を取り⼊れようとしている - QAの⼯程を分けるのではなく、全てのフェーズに浸透させる - スプリントプランニングにもQAEが参加 - Playwrightなどの⾃動テストを、QAEだけでなくエンジニアも触れるように整備‧布教 - ただし、開発フェーズへの⾃然な組み込みには⾄っていない… - 圧倒的伸びしろだらけ！やっていくぞ〜🔥 私たちの現在地 w/ デグレ増殖問題

Slide 18

Slide 18 text

CASE03. 専任スクラムマスターが置けない問題

Slide 19

Slide 19 text

© 202４ LayerX Inc. 19 ことのはじまり専任スクラムマスターが置けない問題 - スクラムマスターの必要性は、開発サイクルがうまく回っていないときほど実感されやすい - 逆に“回ってしまっている”と軽視されがち - ことスタートアップにおいては、⼤抵ヘッドカウントに限りがあるため、「専任スクラムマスターを置くか」＝「開発⼈員を削る覚悟があるか」の問いになりがち - とはいえ、開発⼈員の誰かが⽚⼿間でやるのは現実的ではない… - だからロールが分けられているということでもある

Slide 20

Slide 20 text

© 202４ LayerX Inc. 20 スクラムガイドをたずねる専任スクラムマスターが置けない問題スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果、（略）スクラムチームの有効性に責任を持つ。ということは、以下のような要素がありそう - スクラムチームが進捗を出せる仕組みを作る - POのバックログ整備を⽀援する - プロダクトゴール‧スプリントゴールの定義、達成を⽀援する

Slide 21

Slide 21 text

© 202４ LayerX Inc. 21 ここでちょっと脱線専任スクラムマスターが置けない問題チームの構成要素が変われば、スクラムの運⽤⽅法も変わるはず - ⼈数 - インクリメントの総量と各イベントのコストが⽐例する - プロダクトの成熟度 - ⽴ち上げ期と安定期ではバックログの優先度判断も異なる - メンバーのプロダクトへの習熟度 - 新メンバーが多いと、バックログへの理解度もまちまち - ユーザー（価値を届ける先）との距離感 - 距離が近いほど経験主義を実践しやすい（時には開発さえ不要）

Slide 22

Slide 22 text

© 202４ LayerX Inc. 22 - ちょうど⼈の⼊れ替わり期で、新メンバーが半数 - 今までは「よしな」で回っていたスクラムの運⽤に軋みが⽣じ始めた - 問い - どうやったら皆が早く習熟して、プロダクトゴールを最速最⼤で達成できるようになるだろうか？ - そのための仕組みづくり≒スクラムマスター業を誰か⼀⼈が兼任する以外の⼿はないか？ → 全員が当事者だし、みんなでやるという選択肢もあるのでは🤔？（イマココ）スクラムガイドを再解釈する専任スクラムマスターが置けない問題

Slide 23

Slide 23 text

Slide 24

Slide 24 text

CASE04. 「POがボトルネック」問題

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 202４ LayerX Inc. 26 整理してみた「POがボトルネック」問題 - 確かに、エンジニアのドメインへの習熟に伸びしろはある - ドメイン理解に⾃信がないと⼿出しを躊躇してしまうのも分かる - あるいは、POのタスクがブラックボックス化しすぎていて⼿出ししにくいのかも - おそらく最短距離は「全部俺」で課題の発⾒から解決までを⾏うこと - ただし1⼈でできることは、多いようで少ない。だからチームがある - PO‧エンジニアとロールが分かれているからには、適切な線引きポイントがあるはず…！

Slide 27

Slide 27 text

© 202４ LayerX Inc. 27 スクラムガイドをたずねる「POがボトルネック」問題プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。（略）プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。プロダクトに関する意思決定の責任を負うのはプロダクトオーナー。でも、「全ての意思決定をPOにお任せ」ということではなさそう

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 202４ LayerX Inc. 29 放置しているとまずいかも「POがボトルネック」問題全ての意思決定をPOにお任せしていると、⾃分たちで何も決められないチームになっていく - 個々⼈のプロダクトバックログアイテムへの理解が不⼗分だと、スプリントバックログを消化する中で⽣じる様々なトレードオフを判断できない - 価値を⽣むまでの時間が「PO待ち」で増えていく - チームで検査‧適応のサイクルを回せない - POの意思決定の根拠が分からないと、プロダクトゴールやスプリントゴールの確からしさを検証できない - チームから透明性が失われる

Slide 30

Slide 30 text

© 202４ LayerX Inc. 30 私たちの現在地「POがボトルネック」問題 - エンジニアの⼀番の強みは、あくまでもエンジニアリング - ただし、顧客への価値提供のラストワンマイルを担っているのもエンジニア - それでも…時間は有限…！ - 制約を踏まえつつ、ドメインにディープダイブすることを諦めない - POと同化しようとはしない - 背中を預け合いながら、⼿を伸ばし続けることこそが重要 - POの持っているディスカバリータスクも⾒える化していきたい - 「使われないものを作らない」

Slide 31

Slide 31 text

Slide 32

Slide 32 text

CASE05. スプリントプランニングに時間かかりすぎ問題

Slide 33

Slide 33 text

© 202４ LayerX Inc. 33 スクラムガイドをたずねるスプリントプランニングに時間かかりすぎ問題スプリントが 1 か⽉の場合、スプリントプランニングのタイムボックスは最⼤で 8 時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。 - 2週間スプリント（10営業⽇）の場合は、最⼤4時間と解釈できる - 会議を抜いた1⽇あたりの最⼤作業時間を4時間としたとき、1⽇分の作業時間に相当すると考えると、ちょっと抵抗がある - と思いながらも、いざやってみると意外と時間がかかるジレンマ

Slide 34

Slide 34 text

© 202４ LayerX Inc. 34 ことのはじまりスプリントプランニングに時間かかりすぎ問題 - ⼈やタスク量が増えてきて、スプリントプランニングの所要時間がだんだん延びてきた - 前提として、会議にかかる時間は短ければ短いほどよい - 「⾃分、プランニングとっとと終わらせて開発したいっす」 - ⻑引くと、議論に積極参加しなくてもいいや→内職のコンボが起きがち - スプリントプランニングが⼤事なイベントであることは理解しているけど、なんとかして効率化した〜い！

Slide 35

Slide 35 text

© 202４ LayerX Inc. 35 スクラムガイドをたずねるスプリントプランニングに時間かかりすぎ問題トピック 1：このスプリントはなぜ価値があるのか？トピック 2：このスプリントで何ができるのか？トピック 3：選択した作業をどのように成し遂げるのか？ - トピック1, 2, 3が解きたい課題のWhy, What, Howに相当すると解釈 - ガイドを読む限りでは1→3ときれいに流れるように⾒えるが、実際には… - 何らかの⼯数⾒積もりがないと、選択されたプロダクトバックログアイテム（の完成）がそのスプリントに収まるかを判断できない - ≒スプリントゴールの達成確度が読めず、スプリントの価値が不定に

Slide 36

Slide 36 text

© 202４ LayerX Inc. 36 スクラムガイドをたずねるスプリントプランニングに時間かかりすぎ問題スプリントでは、プロダクトバックログを必要に応じてリファインメントする。プロダクトバックログの内容を⾒積もり可能な状態まで（全員で）把握するのは時間がかかるので、プランニングで全部を賄おうとしないほうがよさそう - どうやら「リファインメント」とやらの出番っぽい - ただしリファインメントの⼿法について、ガイドには明記がない - おそらく各社⼿探りなところ - 私たちも⼿探りでやっています…！

Slide 37

Slide 37 text

© 202４ LayerX Inc. 37 - リファインメントを2種類定義してみた - バックログ優先度決め - Why, What（トピック1, 2）について合意する場 - エンジニアも参加し、⼤体のHowにあたりをつけておく - バックログ仕様レビュー - How（トピック3）について全員で合意する場 - ⾒積もり（プランニングポーカー）もここでやる - ※Howが複数出た場合、Whatを再検討することもスクラムガイドを再解釈するスプリントプランニングに時間かかりすぎ問題

Slide 38

Slide 38 text

© 202４ LayerX Inc. 38 私たちの現在地スプリントプランニングに時間かかりすぎ問題エンジニアもWhyとWhatを深く理解し、「使われないものを作らない」ための Howを持った上で、スプリントプランニングに臨めるようになった - 場の⽬的や進⾏がシャープになり、ダイエット成功！ - スプリントレビュー‧プランニング合計で1h程度に短縮 - スプリントゴールへ意識が向きやすくなり、達成のためのコミュニケーションが盛んに取られるようにもなった - ⼀⽅で、リファインメント2種の頻度や内容、進め⽅には改善の余地あり - 「全員の合意がないと開発できないの？重くない？」

Slide 39

Slide 39 text

© 202４ LayerX Inc. 39 CASE01. プロダクトバックログを分裂させたくなる誘惑 - 複数のプロダクトバックログを置くのではなく、価値基準を揃えてPOと⼀緒に優先度を判断 CASE02. デグレ増殖問題 - タスクの着⼿時からテスト観点を取り⼊れて、QAを全てのフェーズに浸透 CASE03. 専任スクラムマスターが置けない問題 - 全員が当事者として、⽬的に⽴ち返りながらみんなで分担まとめ - 私たちの現在地スプリントプランニングに時間かかりすぎ問題

Slide 40

Slide 40 text

© 202４ LayerX Inc. 40 CASE04. 「POがボトルネック」問題 - エンジニアはPOと背中を預け合いながらも意思決定への理解を諦めない - 「使われないものを作らない」 CASE05. スプリントプランニングに時間かかりすぎ問題 - リファインメントを「なぜやるのか、何をやるのか」「どうやるのか」を合意する場とするまとめ - 私たちの現在地スプリントプランニングに時間かかりすぎ問題