Slide 1

Slide 1 text

© 2024 LayerX Inc. Re: スタートアップ企業が実践する 「⾝の丈スクラム」の現在地 あらたま @ Startup in Agile #1

Slide 2

Slide 2 text

© 2024 LayerX Inc. Re: スタートアップ企業が実践する 「⾝の丈スクラム」の現在地 あらたま @ Startup in Agile #1

Slide 3

Slide 3 text

© 2024 LayerX Inc. 3 ℹ 45分のトークを20分に再編してお話しします󰝋💨 私たちが直⾯した、スクラムによるチーム開発における「あるある」な課題を スクラムガイドや先⼈の知恵をたずねながら、あるいはガイドを再解釈しながら どう乗り越えようとしてきた‧しているかをかいつまんでシェアします 📣 今⽇お話しすること

Slide 4

Slide 4 text

© 2024 LayerX Inc. 4 株式会社LayerX バクラク事業部 EM(エンジニアリングマネージャー) 📝ソフトウェアエンジニアとしてキャリアを積んだのち、株 式会社Cake.jpへ転職、執⾏役員CTOを務めた。2023年より現 職。 󰩵 全国津々浦々のサウナ探訪が趣味 🍡 ⽇本もちもち協会 代表 🏆 YAPC::Kyoto 2023 ベストスピーカー賞 あらたま(新多真琴 / ar_tama) ⾃⼰紹介‧PR

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

© 2024 LayerX Inc. 6 バクラク申請‧経費精算(Web)はこんなチーム - 2021/04にリリースしたプロダクト - プロダクトライフサイクルとしては成⻑期にあたる - 沢⼭のお客様にご利⽤いただいており、ご要望も多数 - チームの構成 - EM、エンジニア、デザイナー、QAE、PdM(PO) - タックマンモデルでいうところの、混乱期〜統⼀期(※) - 直近でメンバーの⼊れ替わりがあり、リビルド→⾛り出し はじめに:プロダクトとチームの紹介

Slide 7

Slide 7 text

© 2024 LayerX Inc. 7 - プロダクト開発に対する私たちのスタンス - ユーザーに価値を最速最⼤で届けて、プロダクトゴールを達成したい! - そのために⾼速でイテレーションを回したい! - ただし、スタートアップはないないづくし😢 - そこでスクラムですよ - 「透明性、検査、適応」はまさに私たちの⽬的とも合致するはず - スタートアップが急成⻑するための鍵はアジリティ これにて解決! 〜完〜 私たちとスクラム

Slide 8

Slide 8 text

© 2024 LayerX Inc. 8 - いざ取り⼊れてみるとうまくいかないことばっかり🥺 - それもそのはず - スクラムとはフレームワークであり、スクラムガイドはその定義 - チームにどう適⽤するかは我々に委ねられている - 結局のところ、置かれた環境を検査して適応していくしかない と思うじゃないですか

Slide 9

Slide 9 text

© 2024 LayerX Inc. 9 スクラムの運⽤⽅法は、チームの構成要素に依存する - ⼈数 - インクリメントの総量と各イベントのコストが⽐例する - プロダクトの成熟度 - ⽴ち上げ期と安定期ではバックログの優先度判断も異なる - メンバーのプロダクトへの習熟度 - 新メンバーが多いと、バックログへの理解度もまちまち - ユーザー(価値を届ける先)との距離感 - 距離が近いほど経験主義を実践しやすい(時には開発さえ不要)

Slide 10

Slide 10 text

© 2024 LayerX Inc. 10 4つの「あるある」なケーススタディを持ってきました - あくまでも、私たちの現在地のスナップショットです - ⽇進⽉歩‧朝令暮改上等でやり⽅を変えています - 前回の発表(6⽉末)から変わった部分のご紹介も持ってきました - プロダクトやチームのフェーズによっても変わるはず - このあと、皆さんのプラクティスを聞けるのがとても楽しみです!

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

© 2024 LayerX Inc. 13 プロダクトバックログを分裂させたくなる誘惑 - 結局、⽚⼿間で進められない⼤きさの課題はプロダクトバックログとの折り 合いをつける必要がある - 20%ルールを敷いてもバッファ扱いされがち(2回⽬) - いっそのことバックログもチームも分裂させてみる? - メインのチームが忙しいとき、本当にサブチームから⼈を都合しようと したくならない? - なるよね🥺 こうなる

Slide 14

Slide 14 text

© 2024 LayerX Inc. 14 スクラムガイドをたずねる プロダクトバックログを分裂させたくなる誘惑 プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必 要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源であ る。 - バックログを複数持つことはガイドでは推奨されていないことが分かる - やるべきは「がんばって同じ尺度で判断可能にすること」?

Slide 15

Slide 15 text

© 2024 LayerX Inc. 15 私たちの現在地 プロダクトバックログを分裂させたくなる誘惑 他の施策と価値基準を揃えて、優先度を検討 - 技術的課題のアウトカム軸をPOとの共通⾔語に翻訳する - 時間軸や進め⽅についての材料があると⽬処が⽴てやすい - ⼩粒なものは定期的に「改善デー」を設けてまとめて倒す 過去の技術的課題を加⼯したもの

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

© 2024 LayerX Inc. 17 ことのはじまり 専任スクラムマスターが置けない問題 - スクラムマスターにまつわる永遠の問い - 「専任スクラムマスターを置くか」=「開発⼈員を削る覚悟があるか」 - とはいえ、開発⼈員の誰かが⽚⼿間でやるのは現実的ではないシーンも… - だからロールが分けられているということでもある - まずは要素を抽出してみよう

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

© 2024 LayerX Inc. 19 私たちの現在地 専任スクラムマスターが置けない問題 - 全員が当事者というスタンスで、⽬的に⽴ち返りながら皆で改善 - 迷ったら最後はPdMとEMが決めると割り切る - ⚠ 「スクラムをうまくやるための改善」にしない。Be Agile!

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

© 2024 LayerX Inc. 21 ことのはじまり 「POがボトルネック」問題 - 「POはディスカバリー担当、エンジニアはデリバリー担当」 - 本当に? - おそらく最短距離は「全部俺」で課題の発⾒から解決までを⾏うこと - ただし1⼈でできることは、多いようで少ない - だからチームがある - 適切な分担ポイントはどこだろう?

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

© 2024 LayerX Inc. 23 先⼈の知恵をたずねる 「POがボトルネック」問題 過度な分業を避け、全員が⾃律的に意思決定‧⾏動できるだけの透明性が必要 出典: 「私考える⼈、あなた作業する⼈」を越えて、 プロダクトマネジメントがあたりまえになるチームを明⽇から実現していく⽅法

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

© 2024 LayerX Inc. 25 私たちの現在地 「POがボトルネック」問題 - エンジニアの⼀番の強みは、あくまでもエンジニアリング - ただし、顧客への価値提供のラストワンマイルを担っているのもエンジニア - 制約を踏まえつつ、ドメインにディープダイブすることを諦めない - POと背中を預け合いながら、さらに⼿を伸ばし合う - POも施策が⽣煮えの段階からエンジニアをどんどん巻き込んでいく - 「使われないものを作らない」

Slide 26

Slide 26 text

© 2024 LayerX Inc. 26 「使われないものを作らない」 「POがボトルネック」問題 出典: 開発速度が速い #とは(LayerX社内資料)

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

© 2024 LayerX Inc. 28 スクラムガイドをたずねる スプリントプランニングに時間かかりすぎ問題 スプリントが 1 か⽉の場合、スプリントプランニングのタイムボックスは最⼤で 8 時間である。スプリントの期間が短ければ、スプリントプランニングの時間も 短くすることが多い。 - 例えば2週間スプリント(10営業⽇)の場合は、最⼤4時間と解釈できる - …⻑すぎない? - 4時間あったら、実装したいよね? - ⻑引くと、議論に積極参加しなくてもいいや→内職のコンボが起きがち - ⼤事なイベントではあるけど、なんとかしたい

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

© 2024 LayerX Inc. 32 私たちの現在地 スプリントプランニングに時間かかりすぎ問題 エンジニアもWhyとWhatを深く理解し、「使われないものを作らない」ための Howを持った上で、スプリントプランニングに臨めるようになった - 場の⽬的や進⾏がシャープになり、ダイエット成功! - スプリントゴールへ意識が向きやすくなり、達成のためのコミュニケー ションが盛んに取られるようにもなった - ⼀⽅で…

Slide 33

Slide 33 text

© 2024 LayerX Inc. 33 私たちの現在地(New!) スプリントプランニングに時間かかりすぎ問題 リファインメント② バックログ仕様レビューについて… - 👦👧 < 全員の合意がないと開発できないの?重すぎない? - バックログがここで滞留し、次のスプリントに載らないリスク - ただし新メンバーとの観点や⼯数感のすり合わせの場にもなっていた - こうなりました - 1. エンジニアがPOと伴⾛してHowの叩きを作る - 2. デイリースクラムに「Howの叩きを磨く時間」を⼊れて、最短で⽇次 の改善サイクルを回す

Slide 34

Slide 34 text

© 2024 LayerX Inc. 34 私たちの現在地(New!) スプリントプランニングに時間かかりすぎ問題 そのさらに後… - 👦👧 < デイリースクラムのトピック多すぎて消化できないね - 👦👧 < 皆ある程度習熟してきたし、合議‧同期でHowを磨く必要ないかも - こうなりました - 1. エンジニアがPOと伴⾛してHowの叩きを作る - 2. 必要に応じて他のメンバーのレビューも⼊れる - 3. Howの磨き込み時間はスプリントバックログ側で吸収する

Slide 35

Slide 35 text

© 2024 LayerX Inc. 35 私たちはこんな感じ! みなさんは? 根底にあるのは「ユーザーに価値を最速最⼤で届けたい。そのために⾼速でイテ レーションを回したい。だけど制約も多いから、スクラムのやり⽅も試⾏錯誤し ていこう」という姿勢 皆さんの「⾝の丈スクラム」のお話も、ぜひ聞かせてください! このあとも引き続き学び合いましょう〜🥳

Slide 36

Slide 36 text

© 2024 LayerX Inc. 36 最後にPR: お隣のチームの試⾏錯誤、公開しています バクラクでは、フェーズの違う各チームがさまざまな取り組みをしています!