Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

yuk4w4
June 22, 2024

スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team

2024/06/22にScrum Fest Osaka 2024 品川&葛飾トラックで発表させていただいた資料です。

Scrum Fest Osaka
https://www.scrumosaka.org/
プロポーザル
https://confengine.com/conferences/scrum-fest-osaka-2024/proposal/20146

yuk4w4

June 22, 2024
Tweet

More Decks by yuk4w4

Other Decks in Programming

Transcript

  1. ⾃⼰紹介 湯川 正洋 @yuk4w4 (ゆかわ) Webエンジニア: 2010〜 アジャイル/スクラム: 2016〜 (Dev)

    SaaS開発: 2019〜 (SM, PO, etc...) DevLOVE関⻄ - 個⼈からチームへの越境、チームから組織への越境 発表 レビュアー参加 - スクラムの拡張による組織づくり Scrum Fest Osaka 2024並びに 品川&葛飾トラックの皆様に格別の感謝 ココにいます
  2. 会社 & プロダクト紹介 “だれでもできる”SEOツール スクラム 1週間スプリント 266スプリント 2024年6⽉22⽇現在 インフルエンサーマーケティングプラットフォーム スクラム

    1週間スプリント 243スプリント 2024年6⽉22⽇現在 デジタルマーケティング領域の複数のBtoB SaaSを開発・提供 エンジニア新卒採⽤継続中
  3. 新卒・ジュニアをふつーにこのスクラムに⼊れるのは厳しすぎた • プロダクトバックログ(PBL)は基本的には価値が⾼いと思われる順に並んでいる • スクラム“チーム”の能⼒は考慮するが、 新卒・ジュニアの能⼒を考慮してPBLの順番を変えることはない (スプリントバックログにピックアップすることはある) • フルサイクルチームでは開発以外のプロダクトに関連するタスクが 予定/割り込み問わず⼀定あり、キャパシティのいくらかを割り当てている

    ↓つまり… • 適切な難度・責任の開発タスクが⾃然とやってくることはほとんどない • 適切な開発タスクがないからと⾔って、 定型作業や雑務だけでは開発に関する技術⼒・仕事⼒はほとんど向上しない • 先輩が(相対的に)簡単・⼩さなタスクを息をするように完了させていることもしばしば ↓そして… • 何とかできそうなことを探して、開発タスクを無理やり切り出すことが始まる • 付加価値をうまない仕事が増える • もしスプリントゴールから切り出され、依存していると達成が危うくなる ・・・ プロダクトバックログの例 PBIの粒度ではなくリリース単位での 難易度や規模のイメージ
  4. こうありたい • フルサイクルのスクラムチームとして • スプリントゴールのために開発者が⾃⽴⾃⾛し協⼒しあっている • ある⼯程やある領域にこだわらずプロダクトに向き合える • 個⼈として •

    仕事の価値と責任を感じられる • うまくいってもうまくいかなくても健全に⾃分のせいと感じられる • 仕事が⼤きくなっていくことで成⻑を感じられる
  5. 開発者を5つのステージに分ける ステージ 4 ステージ 3 ステージ 2 ステージ 5 スクラムにおける良きフルサイクル開発者

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

    情報/設計の流れ 5 4 3 2 1 上のステージは下のステージの範囲も全て含む (移動ではなく拡⼤するイメージ)
  7. ステージごとに週次で結果を評価・フィードバックする • 毎週、そのステージごとに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は取れない どんなステージ・仕事でも⾃分から提案・改善する所作を⾝につける
  8. (後から知った)組織パターンに照らし合わせると 託児所 • 1⼈2⼈の先⽣と、⽣徒たちのチーム を分離する • 違い • 託児所ほど先⽣を切り離してはいない •

    2軍兼ユースチームのイメージ • プロダクトのPBI/開発タスクを使って フィードバックサイクルを回す https://www.shoeisha.co.jp/book/detail/9784798128443