スクラムチームに ⼊れないという選択 フルサイクルチームにおける開発者のステップアップ Scrum Fest Osaka 2024 品川&葛飾トラック

⾃⼰紹介 湯川 正洋 @yuk4w4 (ゆかわ) Webエンジニア: 2010〜 アジャイル/スクラム: 2016〜 (Dev) SaaS開発: 2019〜 (SM, PO, etc...) DevLOVE関⻄ - 個⼈からチームへの越境、チームから組織への越境 発表 レビュアー参加 - スクラムの拡張による組織づくり Scrum Fest Osaka 2024並びに 品川&葛飾トラックの皆様に格別の感謝 ココにいます

こんなこと ありませんか？

No content

ペアプログラミング

No content

ふりかえり

No content

プランニング

No content

スプリントレビュー前⽇に コードを全て書き直した

⼤前提 •プロダクトを継続的に開発・提供する •プロダクト開発者を育てる プロダクトの成功には「両⽅」やらなくっちゃあならない でも実際に同時に実践するのは難しい…

本セッションの話 スクラムチームに新卒やジュニアレベルの開発者を⼊れない という選択を昨年しました なぜそうしたのか? どんな設計にしたのか? を話します いつか来た道いつか⾏く道と思って聞いてください

会社 & プロダクト紹介 “だれでもできる”SEOツール スクラム 1週間スプリント 266スプリント 2024年6⽉22⽇現在 インフルエンサーマーケティングプラットフォーム スクラム 1週間スプリント 243スプリント 2024年6⽉22⽇現在 デジタルマーケティング領域の複数のBtoB SaaSを開発・提供 エンジニア新卒採⽤継続中

プロダクトとスクラムチーム 技術 ⽀援 UX UI PdM 開発者 PdM 開発者 開発者 SMG

フルサイクルのスクラムチーム (注) フルサイクルはチームで担保しつつも、個⼈の範囲を拡げて重なりを増やす PLAN-B 2024エンジニア採⽤資料より

何があったか • スクラムチーム × 徒弟制度 • 増える新メンバー • 増えるムラ • 増えるムリ • 減るベロシティ

新卒・ジュニアをふつーにこのスクラムに⼊れるのは厳しすぎた • プロダクトバックログ(PBL)は基本的には価値が⾼いと思われる順に並んでいる • スクラム“チーム”の能⼒は考慮するが、 新卒・ジュニアの能⼒を考慮してPBLの順番を変えることはない (スプリントバックログにピックアップすることはある) • フルサイクルチームでは開発以外のプロダクトに関連するタスクが 予定/割り込み問わず⼀定あり、キャパシティのいくらかを割り当てている ↓つまり… • 適切な難度・責任の開発タスクが⾃然とやってくることはほとんどない • 適切な開発タスクがないからと⾔って、 定型作業や雑務だけでは開発に関する技術⼒・仕事⼒はほとんど向上しない • 先輩が(相対的に)簡単・⼩さなタスクを息をするように完了させていることもしばしば ↓そして… • 何とかできそうなことを探して、開発タスクを無理やり切り出すことが始まる • 付加価値をうまない仕事が増える • もしスプリントゴールから切り出され、依存していると達成が危うくなる ･･･ プロダクトバックログの例 PBIの粒度ではなくリリース単位での 難易度や規模のイメージ

新⼈視点では安全性が低い環境 • 難度が⾼すぎる×⾔われたことをする ＝できそう・できたとは思えない • ⾃⼰効⼒感が低い状態でのフィードバックは 受け⽌めにくい = 無理ゲーをさせられていると感じている • 何ができるようになったかわからない • スプリントゴールを危うくさせてしまった感

よくよく考えたらトータルで遅い ･･･ 新卒・ジュニアを⼊れて 5スプリント 新卒・ジュニアを⼊れて 2スプリント プロダクトバックログの例 PBIの粒度ではなくリリース単位での 難易度や規模のイメージ トータルで7スプリント

よくよく考えたらトータルで遅い ･･･ 新卒・ジュニアを⼊れて 5スプリント 新卒・ジュニアを⼊れて 2スプリント プロダクトバックログの例 PBIの粒度ではなくリリース単位での 難易度や規模のイメージ 新卒・ジュニアを⼊れずに 4スプリント 新卒・ジュニアを⼊れずに 1スプリント トータルで7スプリント トータルで5スプリント

なぜ我々はスクラムチームに⼊れていたのか?

なぜ我々はスクラムチームに⼊れていたのか? 積極的な理由がないことに気づいた 消極的にそうなっていただけ • プロダクトに配属されたから? • ⼊れてないより⼊れている⽅がプロダクトの役に⽴つと思った? • 新卒が⼊っている(他社の)チームがあるから? もし積極的な理由があるなら、スクラムチームに⼊れるという選択は⼗分ある

重要なことはなにか? プロダクトゴールの達成 プロダクトとして スプリントゴールの達成 スクラムチームとして プロダクトゴール達成のため プロダクトの デリバリー

重要なことはなにか? プロダクトゴールの達成 プロダクトとして スプリントゴールの達成 スクラムチームとして プロダクト開発者の育成 組織として プロダクトゴール達成のため スプリントゴールの達成及び 継続的な開発・成⻑のため プロダクトの デリバリー

重要なことはなにか? プロダクトゴールの達成 プロダクトとして スプリントゴールの達成 スクラムチームとして プロダクト開発者の育成 組織として プロダクトゴール達成のため スプリントゴールの達成及び 継続的な開発・成⻑のため プロダクトの デリバリー プロダクト開発者の デリバリー

こうありたい • フルサイクルのスクラムチームとして • スプリントゴールのために開発者が⾃⽴⾃⾛し協⼒しあっている • ある⼯程やある領域にこだわらずプロダクトに向き合える • 個⼈として • 仕事の価値と責任を感じられる • うまくいってもうまくいかなくても健全に⾃分のせいと感じられる • 仕事が⼤きくなっていくことで成⻑を感じられる

4つの取り組み 1. スクラムチームに⼊れない 2. 開発者を5つのステージに 分ける 3. ステージごとに週次で結果を 評価・フィードバックする 4. 機会を作る

スクラムチームに⼊れない ≒ スプリントゴールからの分離 • 新⼈・ジュニアの開発者をカンバンチームに分離する PdM スクラムチーム 開発者 カンバン チーム 開発者 チーム横断 育成チーム

開発者を5つのステージに分ける ステージ 4 ステージ 3 ステージ 2 ステージ 5 スクラムにおける良きフルサイクル開発者 スクラムでの協働、プロダクトに関わる企画・開発・運⽤・検証などに挑戦しチーム能⼒をあげる スプリントゴールを達成する、プロダクトの信頼性を担保する ⼩さなPBI(INVEST※)のリード開発者 ⼩規模チームを率いて、⼩規模PBIの作成からリファインメント、開発、受け⼊れ、リリースなど全てに責任 カンバンチームのプロダクトバックログのメンテナンスも⾏う ※ I=独⽴している N=交渉可能である V=価値がある E=⾒積もり可能である S=⼩さい T=テスト可能である ⼩さなPBI/開発タスクの開発者 ⼩規模な開発タスクにおいて主に開発・テストや運⽤改善を⾏う プロダクトゴールと組織⽬標の達成者 プロダクト開発をリードし、より中⻑期的な視点でプロダクトと組織の改善・成功に取り組む ステージ 1 タスクの実⾏者 開発に限らず、運⽤や組織のタスクなど、依頼者がいる仕事を仕事として完了させる スクラムに⼊れない壁 新卒の場合はこの壁を 半年〜1年で突破を⽬指す 1⼈が1-3⽇程度で 完了するサイズ感

ステージごとの範囲イメージ Dev Task PBI ここから スタートも多い Feature Epic Task モノ/実装の流れ 情報/設計の流れ

ステージごとの範囲イメージ Dev Task PBI ここから スタートも多い Feature Epic Task モノ/実装の流れ 情報/設計の流れ 5 4 3 2 1 上のステージは下のステージの範囲も全て含む (移動ではなく拡⼤するイメージ)

ステージごとに週次で結果を評価・フィードバックする • 毎週、そのステージごとに0-10で評価・フィードバック • 9-10を連打(再現性)できるようになると次ステージのチャンス 0 1 2 3 4 5 6 7 8 9 10 ステージごとの基準で100%近くの結果を出すと7-8 ※5未満の場合は伴⾛よりもティーチング重視にする 7-8に加え、期待を超えた提案・改善・動き⽅などがあると9-10 指⽰されたことだけをうまくやっても9-10は取れない どんなステージ・仕事でも⾃分から提案・改善する所作を⾝につける

ステージごとに週次で結果を評価・フィードバックする EBM(Evidence Based Management)を参考に時系列で⽬標を追った 薄い実践: 理想線、薄い破線: テコ⼊れ線、濃い実践と丸: 実績、星: ⽬標 9 7 5 2024/06/22 スコア

機会を作る 特にステージ2〜3 ステージに⾒合った経験・責任に繋がるPBIを作る → 適切な難度・規模のPBIを⽣む・作るフローを整える 副次的に、PBIを⽣む・作る経験をスクラムチームに増やせる • 現在及び未来のスプリントゴールとは完全に分離する • 基本的には、プロダクトに関連し何らかの価値を⽣むものにする • ステージ3(スクラムチームの1つ前) では⾃分でもPBIを作る • 運⽤改善、リスク対応、データ可視化、技術的負債返済などなど • 練習と割り切る時(スコア5未満)は、過去のPBIを再発明する

(後から知った)組織パターンに照らし合わせると 託児所 • 1⼈2⼈の先⽣と、⽣徒たちのチーム を分離する • 違い • 託児所ほど先⽣を切り離してはいない • 2軍兼ユースチームのイメージ • プロダクトのPBI/開発タスクを使って フィードバックサイクルを回す https://www.shoeisha.co.jp/book/detail/9784798128443

そしてもうすぐ1年

1年弱運⽤した結果、良いことが多い • スプリントゴールが危うくなる構図が減った • 先輩からのフィードバックの質が向上した • スクラムチームに⼊ること⾃体が明確な⽬標になった • いつ頃スクラムチームに⼊れるようになるか ⾒込みが⽴つようになった

学び • ステージとスコアの明確化、⽬標設定、フィードバックのサイクル • 透明性・検査・適応で⽬標に着実に近づく • 経験をデザインし機会を作ることの⼤事さ • 分離したチームで、ステージに合った責任を持って 取り組める環境(Learning Zone)を作る • 仕組みも⼤事だが運⽤はもっと⼤事 運⽤編だけで30分話したい • 仏造って魂⼊れずにしない

クロージング みなさまの現場や組織ではどう取り組まれているでしょうか? お話できれば嬉しいです! 今はまだスクラムチームに⼊れないメンバーが プロダクトをリードする存在になれるよう、より改善・改⾰を重ねます もしご興味を持っていただいた⽅はこちら…→ PLAN-B テックブログ PLAN-B 採⽤

スクラムチームに ⼊れないという選択 フルサイクルチームにおける開発者のステップアップ