価値提供のリードタイムを短くするための戦術としてのチーム替え「流動チーム体制」に取り組んでいたら実はLeSSでのモブだったお話 / Our way of Dynamic Reteaming was just a "mob" of LeSS

RSGT2024での登壇資料です。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19113/less

Transcript

1. ˜
   -:
   $PSQPSBUJPO 価値提供のリードタイムを短くするための 戦術としてのチーム替え 「流動チーム体制」 に取り組んでいたら 実はLeSSでのモブプロだったお話 LINEヤフー株式会社 中井菜⼦ 新⽥了仁 @RSGT2024
2. ˜
   -:
   $PSQPSBUJPO 価値提供のリードタイムを短くするための 戦術としてのチーム替え 「流動チーム体制」 に取り組んでいたら 実はLeSSでのモブプロだったお話 LINEヤフー株式会社 中井菜⼦ 新⽥了仁 @RSGT2024
3. ˜
   -:
   $PSQPSBUJPO ⾃⼰紹介 中井 菜⼦ / Saiko Nakai（@nako418） LINEヤフー株式会社 2018年4⽉〜 プロダクトオーナーとしてスクラムに関わりはじめる 2020年7⽉〜 とある社内プロダクトたちのプロダクトオーナー 新⽥ 了仁 / Akinori Nitta LINEヤフー株式会社 2018年4⽉〜 新卒⼊社 2018年10⽉〜 とある社内プロダクトチームに開発者として参加
4. ˜
   -:
   $PSQPSBUJPO • わたしたちのチームの状況と、その課題を解決するための戦術「流動チーム体制」 • 「流動チーム体制」誕⽣の背景となった取り組み • 戦術を編み出して実現するまでと、実際に試してみた結果 • プロダクトオーナーと開発者それぞれの⽴場で考えていたこと • 取り組みや、プロダクト、チームの状況をそれぞれどう捉えていたのか • わたしたち流の Dynamic Reteaming がうまくいったワケ  今⽇のおはなし
5. ˜
   -:
   $PSQPSBUJPO • Reteamingは良いぞというお話 • あくまでも⼀つの⼿段と捉えているので、これを推奨したいというお話ではない • 昨年のRSGTでお話した運⽤とスクラムの続き • 運⽤⾃体はなくならないので、昨年のお話はそのまま今回のお話の仕組みの中でも⽣き続けています  今⽇おはなししないこと
6. ˜
   -:
   $PSQPSBUJPO • エピック • プロダクトとして解決したい課題のうち、単体のバックログアイテムでは解決できない粒度のもの • 複数のバックログアイテムによって構成される価値提供の単位  ⾔葉の説明 バックログアイテム 価値提供の単位 = エピック 価値提供の単位 = エピック
7. ˜
   -:
   $PSQPSBUJPO 1. はじめに 2. 成⻑したLeSSチームが抱えていた課題 3. 「流動チーム体制」 4. 「流動チーム体制」をふりかえる 5. まとめ  もくじ
8. ˜
   -:
   $PSQPSBUJPO 1. はじめに わたしたちのチームとプロダクトの状況 
9. ˜
   -:
   $PSQPSBUJPO • LeSSチームとして3年間プロダクト開発 • プロダクトオーナー1⼈、スクラムマスター1⼈、3つの開発チームで構成 • 新旧２つのプロダクトを担当  わたしたちのチームとプロダクト 新プロダクト 旧プロダクト 移⾏中 衰退期の後半 利⽤者はまだまだ多いので 保守運⽤はサボれない 成⻑期真っ只中 旧プロダクトからの移⾏が 進み利⽤者は急増中
10. ˜
    -:
    $PSQPSBUJPO • プロダクトの課題が増え続ける • 旧プロダクトから新プロダクトへの移⾏のために必要な開発 • ステークホルダーからの要求の増加 • ⽇々の運⽤業務の増加 • 技術的負債の返済 • ⼀つのエピックが完了するのに時間がかかる • ⼤きなエピックを複数の開発チームで順に開発すると⼿戻りが発⽣しやすい • 複数の課題に同時に取り組んでしまい、インクリメントを作るリードタイムが⼤きくなる • どの課題もなかなか解決できず、期末に駆け込む  わたしたちのチームで起きていたこと
11. ˜
    -:
    $PSQPSBUJPO  わたしたちのチームで起きていたこと エピックがなかなか終わらない。もっと細か くプロダクトの価値提供がしたいけどできて いない。難産な案件が多くてつらい。 来期の後半には⼤きな案件があるし、 もっと⼤変になることわかっているのに どうしたらいいの・・︕︖ っていうか期末に駆け込んでいる 状況ってアジャイルじゃないし︕ 開発チームをまたいでアイテムを 引き継ぐの⼤変だな。 連携するのに複雑になっているな。 折⾓、優秀なメンバーが集まっているのに、 うまく価値提供につながらないの勿体無いな。
12. ˜
    -:
    $PSQPSBUJPO  もっと継続的に価値提供をし続けたい 写真︓Rowen Smith on Unsplash
13. ˜
    -:
    $PSQPSBUJPO  「流動チーム体制」の導⼊により解決を狙った 写真︓Riccardo Annandale on Unsplash
14. ˜
    -:
    $PSQPSBUJPO  「流動チーム体制」という⼤胆な施策を選択する上で、 そもそも「流動チーム体制」が どういう経緯で⽣まれ、どんなことをやったのか。 そのきっかけとなった施策を⾏った約1年前に遡る
15. ˜
    -:
    $PSQPSBUJPO 2. 成⻑したLeSSチームが 抱えていた課題 「流動チーム体制」の前⾝の取り組み 
16. ˜
    -:
    $PSQPSBUJPO • 開発メンバーのLeSSの熟練度 • 守破離で例えると「破」 • 開発メンバー同⼠の関係性 • 協⼒と相互のサポートが重要性を経験から体感している • 楽しく価値のある仕事をしたい • ユーザへプロダクトが提供する価値を⾼めたい • メンバー個⼈としてもスキルアップもしたい • 結果にもこだわりたい • 余裕のあるチームでありたい  開発メンバーが考えていること 開発メンバー
17. ˜
    -:
    $PSQPSBUJPO  開発メンバー 写真︓Raphael Rychetsky on Unsplash 2022年9⽉ ビッグイシューを解決したい 旧プロダクトの規模、LeSSチームの規模も⼤きくなったな 今期はチームのさらなる成⻑と結果のためにも、 ビッグイシューを解決したいな 旧プロダクトで保守運⽤コストが増加している。 解消するには、抜本的な改修が必要そう。 今期のビッグイシューはこれになりそうだ。
18. ˜
    -:
    $PSQPSBUJPO  開発メンバー 写真︓Raphael Rychetsky on Unsplash 2022年9⽉ ビッグイシューを解決したい 旧プロダクトで保守運⽤コストが増加している。 解消するには、抜本的な改修が必要そう。 今期のビッグイシューはこれになりそうだ。 今期はチームのさらなる成⻑と結果のためにも、 ビッグイシューを解決したいな 旧プロダクトの規模、LeSSチームの規模も⼤きくなったな
19. ˜
    -:
    $PSQPSBUJPO 「イシューからはじめよ」より、イシューとは。 A. 2つ以上の集団の間で決着のついていない問題 B. 根本に関わる、もしくは⽩⿊がはっきりしない問題  イシューとは
20. ˜
    -:
    $PSQPSBUJPO 価値のある仕事は、「イシュー度」と「解の質」の 両⽅が⾼い必要がある。 - 「イシュー度」 - ⾃分の置かれた局⾯でこの問題に答えを出す必要の⾼さ - 「解の質」 - そのイシューに対して、どこまで明確に答えを出せてい るか  価値のある仕事とは イシュー度 解 の 質 ⾼ ⾼ 低 低 価値のある仕事 イシューの⾒極め 解 の 磨 き 込 み
21. ˜
    -:
    $PSQPSBUJPO 「ビッグイシュー」: 「イシュー度」が⾼く、解の質次第で⼤きく価値のあ る仕事になる問題。 メリット︓ - 問題の答えを出すことで、抜本的な解決が狙える - 周辺の⽐較的に⼩さい課題もまとめて解決できる デメリット︓ - 今まで解いていないイシューのため、実現難易度は ⾼いことが多い（技術⾯・作業コスト⾯が⾼い）  ビッグイシューとは イシュー度 解 の 質 ⾼ ⾼ 低 低 価値のある仕事 ビッグ イシュー イシューの⾒極め
22. ˜
    -:
    $PSQPSBUJPO 「ビッグイシュー」: 「イシュー度」が⾼く、解の質次第で⼤きく価値のあ る仕事になる問題。 メリット︓ - 問題の答えを出すことで、抜本的な解決が狙える - 周辺の⽐較的に⼩さい課題もまとめて解決できる デメリット︓ - 今まで解いていないイシューのため、実現難易度は ⾼いことが多い（技術⾯・作業コスト⾯が⾼い）  ビッグイシューとは イシュー度 解 の 質 ⾼ ⾼ 低 低 価値のある仕事 ビッグ イシュー イシューの⾒極め ビッグイシューを解決する過程で、 チームの⼠気やスキルも上がる。 ⼤きな認識ずれも起きにくくなる。
23. ˜
    -:
    $PSQPSBUJPO  LeSSチーム 開発メンバー 写真︓Huzeyfe Turan on Unsplash チームメンバーが⽴て続けに3⼈卒業 2022年11⽉
24. ˜
    -:
    $PSQPSBUJPO  LeSSチーム 開発メンバー 写真︓Huzeyfe Turan on Unsplash チームメンバーが⽴て続けに3⼈卒業 2022年11⽉ このままでは、ビッグイシューに コミットできない︖
25. ˜
    -:
    $PSQPSBUJPO • メンバー卒業により起こったこと • 旧プロダクトの知⾒を持っているメンバーが減ってし まった • メンバー卒業による懸念点 • 着⼿できるメンバーが減ることで開発チームをまたいで 品質を担保する必要が出てきた。 • アイテムの優先度が⾼い状態でも、各開発チームでは完 了できないため、着⼿できない。  ビッグイシューにコミットできない このままでは、ビッグイシューに コミットできない︖
26. ˜
    -:
    $PSQPSBUJPO 旧プロダクトのスキルセットを持っているメンバー  旧プロダクトの知⾒を持っているメンバーが減ってしまった メンバー卒業により起こったこと 旧プロダクトの知⾒を持っているメンバーが減ってしまった 3⼈ 3⼈ 2⼈
27. ˜
    -:
    $PSQPSBUJPO  開発チームまたぎで品質を担保する必要が出てきた 着⼿可能 ビッグイシュー ビッグイシュー メンバー卒業による懸念点１ ビッグイシューは技術⾯・作業コスト⾯が⾼いが、各開発チームで着⼿できる予定だった。
28. ˜
    -:
    $PSQPSBUJPO  開発チームまたぎで品質を担保する必要が出てきた メンバー卒業による懸念点１ ビッグイシューは技術⾯・作業コスト⾯が⾼いが、各開発チームで着⼿できる予定だった。 着⼿できるメンバーが減ることで、開発チームをまたいで品質を担保する必要が出てきた。 レビューするチームはプランニングに参加していないので、 レビューコストが予測不能。 ビッグイシュー ビッグイシュー 情報量が多すぎて、レビューが⼤変 考慮もれがあるから、ちゃぶ台返し レビュー お願いします 着⼿可能だけど、 品質に⾃信がないから別チームにも レビューを貰おう 予期しないコストで、着⼿アイテムが未完に
29. ˜
    -:
    $PSQPSBUJPO  アイテムの優先度が⾼い状態でも着⼿できない メンバー卒業による懸念点２ 各開発チームで⾃分たちのチームが、 ⾃分たちのスプリントのバックログアイテムを完了させることにコミットしていた。 ビッグイシューは技術⾯・作業コスト⾯が⾼いため、着⼿できるメンバーが減ることで、 アイテムの優先度が⾼い状態でも着⼿できない。 着⼿不可 ビッグイシュー 着⼿不可 着⼿不可
30. ˜
    -:
    $PSQPSBUJPO  ビッグイシューにコミットできるような仕組みを追加 この状態は、LeSSチームとして ビッグイシューに コミットできていないのでは︖ 着⼿不可 ビッグイシュー 着⼿不可 着⼿不可
31. ˜
    -:
    $PSQPSBUJPO  ビッグイシューにコミットできるような仕組みを追加 着⼿不可 ビッグイシュー 着⼿不可 着⼿不可 この状態は、LeSSチームとして ビッグイシューに コミットできていないのでは︖ LeSSチームとしてビッグイシューに コミットできる状態になるように、 チームメンバーの配置を変えれば、 コミットできる良いのでは ビッグイシュー ビックイシュー 着⼿可能︕
32. ˜
    -:
    $PSQPSBUJPO  LeSSチームとしてビッグイシューにコミットしたい START やったこと 「スプリント中に次のスプリントの作戦会議を⾏う」
33. ˜
    -:
    $PSQPSBUJPO  LeSSチームとしてビッグイシューにコミットしたい START やったこと 「スプリント中に次のスプリントの作戦会議を⾏う」 具体的には • 現在のスプリントの状況を共有 現在のスプリントの進捗 Goal 現在のスプリントの進捗
34. ˜
    -:
    $PSQPSBUJPO 次のスプリントに何をするのか認識合わせ  LeSSチームとしてビッグイシューにコミットしたい Goal 次のスプリントの⽬標 やったこと 「スプリント中に次のスプリントの作戦会議を⾏う」 具体的には • 現在のスプリントの状況を共有 • 次のスプリントでどのようなことを実施するのか確認
35. ˜
    -:
    $PSQPSBUJPO 最終的な結果  LeSSチームとしてビッグイシューにコミットしたい Xの技術に詳しいメンバーが、 あと⼀⼈いればコミットできる Xの技術わかるので、 ヘルプ⼊るよ 次のスプリント これなら、コミットできる やったこと 「スプリント中に次のスプリントの作戦会議を⾏う」 具体的には • 現在のスプリントの状況を共有 • 次のスプリントでどのようなことを実施するのか確認 • 着⼿する開発チームを決めて、対象の開発チームが、 コミットできるような状態になるために話し合い、 移動するメンバーを決める Goal 次のスプリントの⽬標
36. ˜
    -:
    $PSQPSBUJPO 36 写真︓NASA on Unsplash 取り組みの結果
37. ˜
    -:
    $PSQPSBUJPO (poem)かっこいい写真のうえに、「皆の尽⼒でビッグイシューを解決」を配置したい  皆の尽⼒でビッグイシューを解決 写真︓NASA on Unsplash メンバーの尽⼒で ビッグイシューを解決
38. ˜
    -:
    $PSQPSBUJPO ポジティブ • 毎スプリント、チームメンバー全員で作戦会議をするため、共通認識を持ちやすくなった。 • どのようにしてビッグイシューを解決するのか • 現在の状況はどうなっているのか • 次のスプリントはどのようにすれば、 LeSSチームとしてコミットできるのか • バックログアイテムを完了させることよりも、いかに価値を出すために前進させるかの議論ができた • 必要なスキルセットを持つメンバーでプランニングに臨むため、考慮漏れが起きにくくなった • 必要なスキルセットを持つメンバーで1スプリントをこなすため、1チーム内でレビューが収まりやす くなった ネガティブ • 会議体が増えた • 次スプリントの予定を事前にまとめるなどの、事前準備によってやることが増えた  取り組みの効果
39. ˜
    -:
    $PSQPSBUJPO  前⾝の取り組みを図⽰ ⽬指したい状態 制約条件 戦術 ⼈ プロダクト イシュー 環境 チーム 何をどう変えると⽬指したい状態に できるかを考える ビッグイシュー 3⼈卒業 ビッグイシューに コミットしたい チームメンバーが 3⼈卒業 LeSSチームとして コミットできるように ⼈を移動させる
40. ˜
    -:
    $PSQPSBUJPO  パターン化 ⽬指したい状態 制約条件 戦術 何をどう変えると⽬指したい状態に できるかを考える XXX YYY XXX ? YYY ⼈ プロダクト イシュー 環境 チーム
41. ˜
    -:
    $PSQPSBUJPO • プロダクトが置かれる状況 • 期の後半にビッグイシューが控えている • 旧プロダクトから新プロダクトへの移⾏が本格化し、発⽣する課題への対応バックログが増える  このさき訪れるプロダクトとチームの状況 ビッグイシュー ビッグイシュー ︙ ︙ 期の後半 期のはじめ ビッグイシューに 着⼿可能になる 移⾏が本格化 課題 課題
42. ˜
    -:
    $PSQPSBUJPO • プロダクトが置かれる状況 • 期の後半にビッグイシューが控えている • 旧プロダクトから新プロダクトへの移⾏が本格化し、発⽣する課題への対応バックログが増える • チームが置かれる状況 • 期の後半には新卒やインターンが来て育成コストがかかる  このさき訪れるプロダクトとチームの状況 ビッグイシュー ビッグイシュー ︙ ︙ 期の後半 期のはじめ ビッグイシューに 着⼿可能になる 移⾏が本格化 課題 課題
43. ˜
    -:
    $PSQPSBUJPO • プロダクトが置かれる状況 • 期の後半にビッグイシューが控えている • 旧プロダクトから新プロダクトへの移⾏が本格化し、発⽣する課題への対応バックログが増える • チームが置かれる状況 • 期の後半には新卒やインターンが来て育成コストがかかる  このさき訪れるプロダクトとチームの状況 ビッグイシュー ビッグイシュー ︙ ︙ 期の後半 期のはじめ ビッグイシューに 着⼿可能になる 移⾏が本格化 課題 課題 このままでは期の後半に不安がある いまが⼀番スピード出せる
44. ˜
    -:
    $PSQPSBUJPO  パターンにあてはめる ⽬指したい状態 制約条件 戦術 何をどう変えると⽬指したい状態に できるかを考える プロダクトの価値提供 をし続けたい 後半にビッグイシュー がある ⼈の増減により 育成コストが増える 継続的な価値提供 ビッグイシュー 育成コスト ? ⼈ プロダクト イシュー 環境 チーム
45. ˜
    -:
    $PSQPSBUJPO  パターンにあてはめる ⽬指したい状態 制約条件 戦術 何をどう変えると⽬指したい状態に できるかを考える プロダクトの価値提供 をし続けたい 後半にビッグイシュー がある ⼈の増減により 育成コストが増える 継続的な価値提供 ビッグイシュー 育成コスト 流動チーム体制 ⼈ プロダクト イシュー 環境 チーム
46. ˜
    -:
    $PSQPSBUJPO 3.「流動チーム体制」 導⼊によって得られたこと 
47. ˜
    -:
    $PSQPSBUJPO 「流動チーム体制」とは 
48. ˜
    -:
    $PSQPSBUJPO  価値提供のリードタイムを短くするための戦術 写真︓JESHOOTS.COM on Unsplash
49. ˜
    -:
    $PSQPSBUJPO • LeSSチーム • プロダクトオーナー、スクラムマスター、複数の開発チーム • 流動チーム体制 • LeSSの構成はそのままに、開発チームのメンバーを毎スプリント⼊れ替える  「流動チーム体制」とは スプリントN スプリントN+1
50. ˜
    -:
    $PSQPSBUJPO • 3種類のチームをつくる • 注⼒チーム • 注⼒対象のエピックに取り組み、その課題を解決することに注⼒するチーム • Opsチーム • 運⽤業務全般を請け負いながら、チームの運⽤の質を上げていくチーム • PBIチーム • 注⼒対象のエピック以外のバックログアイテムを進めるチーム  「流動チーム体制」とは 注⼒対象のエピックに関するアイテム （注⼒対象になったタイミングで注⼒チームが着⼿する） 注⼒対象のエピック以外のアイテム（PBIチームが着⼿する） エピック1 エピック2 エピック3 バックログ全体
51. ˜
    -:
    $PSQPSBUJPO • 3種類のチームをつくる • 注⼒チーム • 注⼒対象のエピックに取り組み、その課題を解決することに注⼒するチーム • Opsチーム • 運⽤業務全般を請け負いながら、チームの運⽤の質を上げていくチーム • PBIチーム • 注⼒対象のエピック以外のバックログアイテムを進めるチーム  「流動チーム体制」とは 注⼒対象のエピックに関するアイテム （注⼒対象になったタイミングで注⼒チームが着⼿する） 注⼒対象のエピック以外のアイテム（PBIチームが着⼿する） エピック1 エピック2 エピック3 バックログ全体 注⼒チーム以外のチームは、注⼒チーム が注⼒できるように⽀援する
52. ˜
    -:
    $PSQPSBUJPO • 注⼒対象のエピックに関するアイテムは優先順が⼀番⾼い位置に配置 • 将来的には注⼒対象のエピックとして取り組むエピックに関するアイテムは優先順を低くする • いまは着⼿しない判断をしているため、優先順が低い • 注⼒対象のエピック以外のアイテムや運⽤保守関連のアイテムは優先順に配置  バックログの扱い⽅ 注⼒対象のエピックに関するアイテム それぞれの注⼒チームのスプリントバックログに⼊る 注⼒対象のエピック以外のアイテムや保守運⽤関連のアイテム 主にPBIチームのスプリントバックログに⼊る 将来的に注⼒対象のエピックとして取り組むアイテム 優先順は低いので着⼿されない 注⼒対象エピック1のアイテム 注⼒対象エピック2のアイテム 注⼒対象エピック2のアイテム 注⼒対象エピック1のアイテム 注⼒対象エピック1のアイテム バックログ 注⼒対象エピック3のアイテム 注⼒対象エピック3のアイテム ︙
53. ˜
    -:
    $PSQPSBUJPO • 注⼒対象のエピックに関するアイテムは優先順が⼀番⾼い位置に配置 • 将来的には注⼒対象のエピックとして取り組むエピックに関するアイテムは優先順を低くする • いまは着⼿しない判断をしているため、優先順が低い • 注⼒対象のエピック以外のアイテムや運⽤保守関連のアイテムは優先順に配置  バックログの扱い⽅ 注⼒対象エピック1のアイテム 注⼒対象エピック2のアイテム 注⼒対象エピック2のアイテム 注⼒対象エピック1のアイテム 注⼒対象エピック1のアイテム バックログ 注⼒対象エピック3のアイテム 注⼒対象エピック3のアイテム ︙ 注⼒対象エピック1のアイテム 注⼒対象エピック2のアイテム 注⼒対象エピック2のアイテム 注⼒対象エピック1のアイテム 注⼒対象エピック1のアイテム 注⼒1チーム 注⼒2チーム PBIチーム スプリント
54. ˜
    -:
    $PSQPSBUJPO  1週間（1スプリント）のスケジュール セレモニーデー （⽔曜⽇） 1⽇⽬ （⽊曜⽇） 2⽇⽬ （⾦曜⽇） 3⽇⽬ （⽉曜⽇） 4⽇⽬ （⽕曜⽇） セレモニーデー （⽔曜⽇） スプリント プランニング リファインメント リファインメント スプリント レビュー チーム レトロスペクティブ 全体 レトロスペクティブ
55. ˜
    -:
    $PSQPSBUJPO  1週間（1スプリント）のスケジュール セレモニーデー （⽔曜⽇） 1⽇⽬ （⽊曜⽇） 2⽇⽬ （⾦曜⽇） 3⽇⽬ （⽉曜⽇） 4⽇⽬ （⽕曜⽇） セレモニーデー （⽔曜⽇） スプリント プランニング リファインメント リファインメント スプリント レビュー チーム レトロスペクティブ 全体 レトロスペクティブ 「流動チーム体制」を実施するにあたって 内容変更があったイベント
56. ˜
    -:
    $PSQPSBUJPO  1週間（1スプリント）のスケジュール エピック リファインメント セレモニーデー （⽔曜⽇） 1⽇⽬ （⽊曜⽇） 2⽇⽬ （⾦曜⽇） 3⽇⽬ （⽉曜⽇） 4⽇⽬ （⽕曜⽇） セレモニーデー （⽔曜⽇） リファインメント リファインメント スプリント レビュー チーム レトロスペクティブ 全体 レトロスペクティブ エピック リファインメント準備 チーム編成 「流動チーム体制」を実施するにあたって 増えたイベント スプリント プランニング
57. ˜
    -:
    $PSQPSBUJPO • 注⼒対象にするエピックはリファインメントの中で、チームメンバー全員で決める • 新しいエピックに注⼒しはじめる頃のリファインメントで次の注⼒対象を決める • エピックはたくさんあるが、優先順をつけて今注⼒するべきエピックを選択する  リファインメントで注⼒対象のエピックを決める 価値 コ ス ト ⾼ ⾼ 低 低
58. ˜
    -:
    $PSQPSBUJPO • 注⼒対象にするエピックはリファインメントの中で、チームメンバー全員で決める • 新しいエピックに注⼒しはじめる頃のリファインメントで次の注⼒対象を決める • エピックはたくさんあるが、優先順をつけて今注⼒するべきエピックを選択する  リファインメントで注⼒対象のエピックを決める 価値 コ ス ト ⾼ ⾼ 低 低 エピックを完了させることによって提供できる価値 とそれにかかる⼤まかなコストを元にプロットしな がら優先順をつけた 優先して注⼒ 対象にしたい エピック
59. ˜
    -:
    $PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめた  エピックリファインメントの準備
60. ˜
    -:
    $PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめた  エピックリファインメントの準備 このときの作戦会議と同じことを実施している
61. ˜
    -:
    $PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめた  エピックリファインメントの準備 ・はじめは開発メンバーのみんな、エピックリファインメントは⼿探り状態。 ・注⼒チームのメンバーは解像度が⾼く、他のチームメンバーの解像度のズレが課題に。 ・スプリントを重ねる間に、引き継ぐための型が⽣まれたりと、意図や経験値の共有を 意識して動けるようになった。
62. ˜
    -:
    $PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめた  エピックリファインメントの準備 スクラムガイド記載のこれらをPOから開発チームに委譲できてありがたい ・プロダクトバックログアイテムを作成し、明確に伝える。 ・プロダクトバックログアイテムを並び替える。 ・プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
63. ˜
    -:
    $PSQPSBUJPO • 注⼒対象のエピックを対象としたリファインメント • 注⼒チームが次のスプリントでエピックのゴールに近づくための⼤まかな計画を⽴てる • そのためにどれくらいの⼈数/スキルセットが必要かを確認 • 開発メンバー全員が参加する • チームの知⾒を結集することで、⾒落としなどを防ぐ • 全員が情報をキャッチアップできるので、スプリント中に⽀援しやすくなる  エピックリファインメント
64. ˜
    -:
    $PSQPSBUJPO • 次のスプリントにチームでコミットするための体制を決める • チームの枠組みと実施内容、スキルセットなどを⾒ながらメンバー編成 • 個々に⾃分がどのチームに参加したいかを検討して宣⾔ • スキルセットや引き継ぎの観点で全体のバランスを⾒て、⼀部⼊れ替えなどの調整  「流動チーム体制」チーム編成 実際のチーム編成ボード
65. ˜
    -:
    $PSQPSBUJPO • 編成開始前  「流動チーム体制」チーム編成 Opsチーム PBIチーム 注⼒チーム1 注⼒チーム2 まだチームが決まっていない⼈ スプリントN 2-3⼈ 2-3⼈ Xの技術スキル
66. ˜
    -:
    $PSQPSBUJPO • 編成開始前 • 各メンバーはおやすみなどを宣⾔ • ⼀部メンバーはチームが決まっている • 特定のスキルセットが必要な場合は明⽰  「流動チーム体制」チーム編成 Opsチーム PBIチーム 注⼒チーム1 注⼒チーム2 Opsチームはローテーションで あらかじめメンバーが決まって いる（交換可能） 引き継ぎコスト等を考慮し、 注⼒チームは誰かが残留す るケースが多い まだチームが決まっていない⼈ ⽉曜休み スプリントN 2-3⼈ 2-3⼈ 注⼒チームは⼈数の⽬安がある エピックを確実に進めるため に必要なスキルセットがある 場合はあらかじめ提⽰する Xの技術スキル
67. ˜
    -:
    $PSQPSBUJPO • 編成開始前 • 各メンバーはおやすみなどを宣⾔ • ⼀部メンバーはチームが決まっている • 特定のスキルセットが必要な場合は明⽰  「流動チーム体制」チーム編成 Opsチーム PBIチーム 注⼒チーム1 注⼒チーム2 Opsチームはローテーションで あらかじめメンバーが決まって いる（交換可能） 引き継ぎコスト等を考慮し、 注⼒チームは誰かが残留す るケースが多い まだチームが決まっていない⼈ スプリントN 2-3⼈ 2-3⼈ 注⼒チームは⼈数の⽬安がある エピックを確実に進めるため に必要なスキルセットがある 場合はあらかじめ提⽰する ⽉曜休み Xの技術スキル
68. ˜
    -:
    $PSQPSBUJPO • メンバーみんな新しい取り組みに前向き • Slackのリアクションもつくられた  「流動チーム体制」スタート 前向きにチャレンジできてよかったし、 それができるのはいいチームだなぁー プロダクトの価値提供にも期待︕ 取り組むと決まったからには、 結果につなげたい︕
69. ˜
    -:
    $PSQPSBUJPO 「流動チーム体制」がもたらしたもの 
70. ˜
    -:
    $PSQPSBUJPO  成果とチームの変化
71. ˜
    -:
    $PSQPSBUJPO • 注⼒したエピックを確実に進められた • 1エピックを完成させるまでにアイテムに着⼿していないスプリント数︓6.4 → 1.4スプリント  「流動チーム体制」によって得られた成果 スプリント 1エピックを完成させるまでにアイテムに着⼿していないスプリント
72. ˜
    -:
    $PSQPSBUJPO • 注⼒したエピックを確実に進められた • 1エピックを完成させるまでにアイテムに着⼿していないスプリント数︓6.4 → 1.4スプリント • より短い期間でエピックを完了できた • 1エピックを完了させるまでにかかったスプリント数︓12.9スプリント → 8.6スプリント  「流動チーム体制」によって得られた成果 スプリント 1エピックを完了させるまでにかかったスプリント
73. ˜
    -:
    $PSQPSBUJPO • 注⼒したエピックを確実に進められた • 1エピックを完成させるまでにアイテムに着⼿していないスプリント数︓6.4 → 1.4 • より短い期間でエピックを完了できた • 1エピックを完了させるまでにかかったスプリント数︓12.9スプリント → 8.6スプリント  「流動チーム体制」によって得られた成果 成果につながってよかった︕
74. ˜
    -:
    $PSQPSBUJPO • LeSSチームとしてのまとまりが出た（ポジティブ） • 注⼒チームが注⼒できるようにみんなでサポート • エピック全体に⽬を向けられるようになった • スプリント間の引き継ぎがスムーズになった • 最新の情報がキャッチアップしやすくなった • 開発メンバー同⼠のコミュニケーションが増えた • 単体の開発チームや個⼈の観点では課題もあった（ネガティブ） • チームレトロスペクティブの活⽤が難しくなった • 個⼈の成⻑の観点での課題が⾒えてきた  「流動チーム体制」によってチームにおきた変化
75. ˜
    -:
    $PSQPSBUJPO • これまで • LeSSの各開発チーム内で取り組むバックログアイテムに集中しがち • ほかの開発チームからのレビュー依頼への対応が後回しになる • 障害が発⽣するとみんなで対処する  注⼒チームが注⼒できるようにみんなでサポート レビューお願いします ⼀緒に確認します︕ 障害 ⻘チーム あれっ、障害︖ ⿊チーム 緑チーム レビューの前に⾃分のチームの バックログアイテム進めないと…
76. ˜
    -:
    $PSQPSBUJPO • 変化後 • 注⼒チームのレビューは他レビューに⽐べて優先度⾼く⾒るようになった • 障害などが発⽣しても、Opsチームが担当してくれるので注⼒チームは変わらず注⼒できる  注⼒チームが注⼒できるようにみんなでサポート 障害 障害発⽣したので対処 しておきます︕ レビューお願いします はい喜んで︕ 注⼒チームは注⼒対象のエピックに注⼒できる PBIチーム 注⼒チーム Opsチーム
77. ˜
    -:
    $PSQPSBUJPO • これまで • バックログアイテム単体に⽬が⾏きがち • ACは達成できているけれど、エピックのゴールに達するには次スプリントでのカバーが必要  エピックの全体像に⽬を向けられるようになった
78. ˜
    -:
    $PSQPSBUJPO • 変化後 • バックログアイテムではなく、エピックに注⼒するため、エピックの全体像に⽬を向けられる • スプリント中に新たな事実が判明したら適宜やることを変更 • スプリントゴールやエピックのゴールを達成するための「最短経路」を探し続けられる  エピックの全体像に⽬を向けられるようになった
79. ˜
    -:
    $PSQPSBUJPO • これまで • 特定のエピックのバックログアイテムを複数チームが順に担当することで、スキルの継承や知⾒の共 有に課題あり  スプリント間の引き継ぎがスムーズになった エピックAのアイテム エピックAのアイテム 次スプリントでは 別のチームが担当 エピックAのアイテム エピックAのアイテム スプリントN スプリントN+1
80. ˜
    -:
    $PSQPSBUJPO • これまで • 特定のエピックのバックログアイテムを複数チームが順に担当することで、スキルの継承や知⾒の共 有に課題あり • 必要なスキルを⾝につけるためにスプリントの前半を利⽤するなどが発⽣  スプリント間の引き継ぎがスムーズになった 次スプリントでは 別のチームが担当 特定のエピックに紐づくバックログアイテムを別 チームが担当すると、引き継ぎがうまくいかずスプ リントのはじめに調査が必要なケースも エピックAのアイテム エピックAのアイテム エピックAのアイテム エピックAのアイテム スプリントN スプリントN+1
81. ˜
    -:
    $PSQPSBUJPO • 変化後 • 全員でエピックリファインメントを⾏うことで、チーム全体で知識を共有 • 必要なスキルセットを持つメンバーを注⼒チームにアサイン • ⼀⼈は残留することで前スプリントの経緯を継承  スプリント間の引き継ぎがスムーズになった 次スプリントのメ ンバーはチーム替 えで決まる スキルあり 残留 エピックAのアイテム エピックAのアイテム エピックAのアイテム エピックAのアイテム スプリントN スプリントN+1
82. ˜
    -:
    $PSQPSBUJPO • 変化後 • 全員でエピックリファインメントを⾏うことで、チーム全体で知識を共有 • 必要なスキルセットを持つメンバーを注⼒チームにアサイン • ⼀⼈は残留することで前スプリントの経緯を継承  スプリント間の引き継ぎがスムーズになった スプリントN スプリントN+1 次スプリントのメ ンバーはチーム替 えで決まる メンバー残留や必要スキルセットの明確化に より引き継ぎがスムーズに エピックAのアイテム エピックAのアイテム エピックAのアイテム エピックAのアイテム スキルあり 残留
83. ˜
    -:
    $PSQPSBUJPO • これまで • 情報を取得できていたバックログアイテムが限られていた • ⾃分が参加したリファインメントで扱ったもの、⾃分のチームが着⼿したもの • 情報取得が⼗分ではないバックログアイテムに関するレビューのコストが⾼い  最新の情報がキャッチアップしやすくなった レビューに対応するために、バックログアイテム に関する情報収集から⾏う必要があった レビュー依頼 なんのために⾏う変更だっけ︖ バックログアイテム
84. ˜
    -:
    $PSQPSBUJPO • 変化後 • エピックリファインメントは全員参加のため、そこで全員が同じ情報を摂取できる • 注⼒チームに所属していなくても、状況が把握できる 最新の情報がキャッチアップしやすくなった 注⼒チームのバックログアイテムは全員が情報を 共有しているためスムーズにレビューできる レビュー依頼 エピックリファインメントでお話していた件だね 優先的にレビューします︕ 注⼒対象エピックのアイテム 注⼒対象エピックのアイテム バックログアイテム
85. ˜
    -:
    $PSQPSBUJPO • これまで • 同じ開発チームのメンバーとのコミュニケーションは多い • 違う開発チームのメンバーとのコミュニケーションは少ない  開発メンバー同⼠のコミュニケーションが増えた ずっと同じメンバー
86. ˜
    -:
    $PSQPSBUJPO • 変化後 • 毎スプリント違うメンバー構成なのでスプリントごとに違うメンバーとコミュニケーションができる • 結果的に、チーム全体でのコミュニケーションが増えた  開発メンバー同⼠のコミュニケーションが増えた メンバー間のコミュニケーションの偏りが 減り、コミュニケーション量も増えた ずっと同じメンバー 毎スプリント メンバーが⼊れ替わる
87. ˜
    -:
    $PSQPSBUJPO • これまで • 同じメンバーでチームレトロスペクティブを実施 • チームの働き⽅のカイゼンを、スプリントごとに積み重ねていた  チームレトロスペクティブの活⽤が難しくなった 毎スプリント同じメンバーで カイゼンを積み重ねていく 同じメンバーのチーム ・・・
88. ˜
    -:
    $PSQPSBUJPO • 変化後 • チームの働き⽅のカイゼン案を考えても、次スプリントはメンバーが⼊れ替わるため適⽤しにくい • 直接課題を感じたメンバーではないメンバーがカイゼン策だけ実施するよくわからない構図 • 個々で気をつけようになりがち  チームレトロスペクティブの活⽤が難しくなった 毎スプリントメンバーが⼊れ替わるチーム ・・・ このカイゼン策効果あるのかな 個々⼈で気をつけられるといいね 前のスプリントとチームのメンバー構成が 変わるのでカイゼンの積み重ねができない
89. ˜
    -:
    $PSQPSBUJPO • これまで • 開発チーム内の各メンバーの⽴ち位置は⼤きく変わらない • EMと相談しながら個⼈の成⻑を⾒据えた活動をしていた  個⼈の成⻑の観点での課題が⾒えてきた 同じメンバーのチーム ・・・ 中堅 中堅 中堅 中堅 チーム内での役割が⼀定なのでその中で 成⻑の軸を⾒つけられた
90. ˜
    -:
    $PSQPSBUJPO • 変化後 • 毎スプリントチーム編成が変わるので⽴ち位置も変わるため、⼀定の環境下での挑戦がしにくくなっ た  個⼈の成⻑の観点での課題が⾒えてきた 毎スプリントメンバーが⼊れ替わるチーム ・・・ チームのメンバー構成が変わると 求められる役割も変わる 中堅 若⼿ シニア 中堅
91. ˜
    -:
    $PSQPSBUJPO 4.「流動チーム体制」を ふりかえる うまくいったワケ 
92. ˜
    -:
    $PSQPSBUJPO なぜ「流動チーム体制」は うまくいったのか 
93. ˜
    -:
    $PSQPSBUJPO  チーム全員で選択した挑戦だったから 写真︓Duy Pham on Unsplash
94. ˜
    -:
    $PSQPSBUJPO • ⼟台が整っていた • LeSSチームとして成熟していた • チーム全員で選択した挑戦だった • 先⾏事例があった • プロダクトとチームの状況を理解したうえで選択した • 挑戦できるチームだった • ダメだったらやめることを決めていた • 全員が施策のオーナーシップをもてた • スタートダッシュが決まった • あたりまえのようにカイゼンができた  なぜ「流動チーム体制」がうまくいったのか
95. ˜
    -:
    $PSQPSBUJPO • LeSSチームとして3年間プロダクト開発をしてきた • プロダクトオーナー、スクラムマスターは変わらず • スクラムやLeSSに対しての共通認識があった • メンバーの⼊れ替わりはあるが、常にフィーチャーチームでの開発をしていた • 扱うプロダクトに関する共通の基礎知識があった • 半年ごとにLeSSの開発チームのシャッフルをしていた • 開発チームごとの独⽴した最適化ではなく、LeSSチームとして最適化されていた • メンバーが⼊れ替わっても、チームビルディングまでに時間がかからない状態になっていた  ⼟台が整っていた
96. ˜
    -:
    $PSQPSBUJPO  「流動チーム体制」誕⽣の流れ ⽬指したい状態 制約条件 戦術 何をどう変えると⽬指したい状態に できるかを考える プロダクトの価値提供 をし続けたい 後半にビッグイシュー がある ⼈の増減により 育成コストが増える 継続的な価値提供 ビッグイシュー 育成コスト 流動チーム体制 2023年3⽉ ⼈ プロダクト イシュー 環境 チーム
97. ˜
    -:
    $PSQPSBUJPO • プロダクトオーナーからスクラムマスターに課題提議 • 次の半期に⾃分たちのチームが置かれる状況を踏まえてどういうチーム体制にするのが良さそうか • スクラムマスターを中⼼にエンジニアリングマネージャーと相談  チーム全員で選択した挑戦 このままだと来期プロダクトとしてやりたいことができないかも たしかに、全体の⼈数も減ったし、チームを変える にしても育成とかのバランス取るのも⼤変そう あとやっぱりPO的にはエピックがなかなかおわらないのが気になっている。 そもそも単位が⼤きくなってしまっているというのもあるし、⼿戻りが発⽣ することが多いのもある。来期の後半にはビッグイシューのエピックが控え ている上、新卒などの育成コストがだいぶ取られちゃうと思うので、いまの ままだと何も価値提供できなくなってしまうかも それはそう。今期の旧プロダクトで⾏っていた取り組みは割と良 かったと思うけれど、それを参考にしてみるのはどうだろう︖ PO / EM SM / EM
98. ˜
    -:
    $PSQPSBUJPO • プロダクトオーナーからスクラムマスターに課題提議 • 次の半期に⾃分たちのチームが置かれる状況を踏まえてどういうチーム体制にするのが良さそうか • スクラムマスターを中⼼にエンジニアリングマネージャーと相談  チーム全員で選択した挑戦 PO / EM SM / EM よさそう。あれは確実にエピックを終わらせることに注⼒できて いたし、実際にゴールが⾒える状態まで進められていた ベースのチームだけ作っておいて、注⼒するエピック に取り組む⼈だけ選出するような形式はどうだろう プロダクトの現状、チームの状況を踏まえて、来期の体制どうするか、チームメン バーに相談してみましょう。みんなの意⾒を聞いたうえで、どうするか決めよう やってみるのはありかもしれない。ただ、EM的には、旧プロダクトの取り組 みは結果は出ているが、結構⼤変だったというお話を1on1でも聞いている。 実際に仕組みを変えたとして、それを実際にやるのは開発メンバーなので、 みんなの意⾒は聞きたいですね
99. ˜
    -:
    $PSQPSBUJPO  プロダクトとチームの状況を理解したうえで選択した
100. ˜
     -:
     $PSQPSBUJPO • チームに相談 • 次の半期にプロダクトや⾃分たちのチームが置かれる状況を説明 • スクラムマスターを中⼼にエンジニアリングマネージャーと相談して出した案を提案  チーム全員で選択した挑戦 今後のプロダクトとチームが置かれる状況を踏まえて、いまのままの体制でプロダ クトの価値を届け続けられるんだっけ︖ということをSM / PO / EM で考えた。 旧プロダクトで⾏っていた取り組みを参考に考えた、新しい体制を提案したい。 PO / EM SM / EM プロダクト
101. ˜
     -:
     $PSQPSBUJPO • チームに相談 • 次の半期にプロダクトや⾃分たちのチームが置かれる状況を説明 • スクラムマスターを中⼼にエンジニアリングマネージャーと相談して出した案を提案  チーム全員で選択した挑戦 これをやりますという宣⾔ではなくて、案を聞いてどう思うかの意⾒が聞きたい。 もしくは、別の案があればぜひ提案してほしい。実際にこの体制で動くのはみんな なので、どんな感じになりそうかイメージしてみてほしい。 中途半端に⼀部メンバーだけを都度移動するよりも、 もっと⾃由度⾼く全部流動にしてしまえば良いのでは︖ 試してみても良さそう PO / EM SM / EM アグレッシブな案だけれど、他のメンバー的にはどうですか︖ ちょっと不安もあるかな おもしろそう 新しい取り組みに前向きに挑戦できるチーム 挑戦を楽しめるチーム
102. ˜
     -:
     $PSQPSBUJPO  チーム全員で選択した挑戦 ちょっと極端で変化も⼤きいからと いう理由で提案をやめた案がでてき たぞ・・・やれるかな・・・ 元々の取り組みも開発メンバー発案 だし、こういう提案が出てくるのは ありがたいし、うちのチームの良い ところだよなぁ チームの各開発メンバーが、 ⽬的の達成を、主体性を持ちやすい形で、 まとまりそうで良かったな。
103. ˜
     -:
     $PSQPSBUJPO • スクラムマスターとエンジニアリングマネージャーで相談 • メンバーからのアグレッシブな提案を採⽤しつつも、チャレンジしやすく  チーム全員で選択した挑戦 アグレッシブなの来ましたねｗ どうしましょう︖ せっかくメンバーから出てきた案だし、やってみるのもいいと思う。 変化を受け⼊れられる、適応していけるチームだからできそう。 たしかに。でもやるなら退路は⽤意しておきたいですね。うまくいくように仕組 みのカイゼンはしてほしいけれど、失敗しても良いんだよっていうメッセージも セットにしたほうがチャレンジのハードルは下がりそう PO / EM SM / EM ですね。1ヶ⽉くらい経ったらでふりかえりをして、継続するか⽌めるかを決めよう
104. ˜
     -:
     $PSQPSBUJPO • はじめての挑戦なので逃げ道を⽤意 • いきなりうまくいくわけない • カイゼンして仕組みを良くしていく活動はやる • それでもうまくいかなければ⽌める選択肢をはじめから提⽰ • 1ヶ⽉後くらいにチーム内でふりかえりをすることをあらかじめ決めた  ダメだったらやめよう ⽴ち⽌まって ふりかえり 「流動チーム体制」継続 固定の開発チームに戻す ふりかえり・カイゼン
105. ˜
     -:
     $PSQPSBUJPO ふりかえり・カイゼン • はじめての挑戦なので逃げ道を⽤意 • いきなりうまくいくわけない • カイゼンして仕組みを良くしていく活動はやる • それでもうまくいかなければ⽌める選択肢をはじめから提⽰ • 1ヶ⽉後くらいにチーム内でふりかえりをすることをあらかじめ決めた  ダメだったらやめよう ⽴ち⽌まって ふりかえり 「流動チーム体制」継続 固定の開発チームに戻す うまくいかなかったら、今まで通りのやり⽅に戻せばよい という道を⽤意することで挑戦しやすくした
106. ˜
     -:
     $PSQPSBUJPO • スクラムマスターとエンジニアリングマネージャーで相談 • メンバーからのアグレッシブな提案を採⽤しつつも、チャレンジしやすく • それに伴い変えないといけない仕組みを検討  チーム全員で選択した挑戦 PO / EM SM / EM この⽅針で進めるってことは、エピックに焦点を当ててお話する場がほしいのと、それと チーム編成をいつ⾏うのかっていうのを決めないといけない。いままで固定の開発チーム という前提で成り⽴っていたものを全部⾒直さないといけないですね・・・ そうだった・・・・やりますか︕ キックオフまであと2⽇しかないけど・・・やるしかないですね。やりましょう︕
107. ˜
     -:
     $PSQPSBUJPO  「流動チーム体制」誕⽣ ⽬指したい状態 制約条件 戦術 何をどう変えると⽬指したい状態に できるかを考える プロダクトの価値提供 をし続けたい 後半にビッグイシュー がある ⼈の増減により 育成コストが増える 継続的な価値提供 ビッグイシュー 育成コスト 流動チーム体制 2023年4⽉ ⼈ プロダクト イシュー 環境 チーム
108. ˜
     -:
     $PSQPSBUJPO • プロダクトやチームの状況を理解したうえで、「流動チーム体制」に前向きに取り組めた • スタートダッシュを決めることができた • プロダクトにとって⼤事な要素であり、チームにとっての成功体験としても⼤事な要素になった  全員が施策のオーナーシップをもてた 3つのエピックが完了 チームとして⼿応えを感じられた はじめの6スプリント
109. ˜
     -:
     $PSQPSBUJPO • プロダクトやチームの状況を理解したうえで、「流動チーム体制」に前向きに取り組めた • スタートダッシュを決めることができた • プロダクトにとって⼤事な要素であり、チームにとっての成功体験としても⼤事な要素になった • 「流動チーム体制」⾃体のカイゼンに取り組めた • 「流動チーム体制」内の各チームに対する期待値、⽬指す状態、ありたい姿のすり合わせ • 現在地の確認と、⽬指す状態やありたい姿に近づくには何をすればよいかの検討  全員が施策のオーナーシップをもてた ふりかえり・カイゼン ありたい姿 ありたい姿が⾒えることで、 より⾏動につながった
110. ˜
     -:
     $PSQPSBUJPO 「流動チーム体制」とはなんだったのか 
111. ˜
     -:
     $PSQPSBUJPO  「流動チーム体制」とは
112. ˜
     -:
     $PSQPSBUJPO  価値提供のリードタイムを短くするための戦術 写真︓JESHOOTS.COM on Unsplash
113. ˜
     -:
     $PSQPSBUJPO • 「流動チーム体制」でやっていること • 注⼒対象のエピックで扱う課題の解決にチーム全体で注⼒  「流動チーム体制」も1つの⼿段 εΫϥϜνʔϜ͸ɺΰʔϧʹ޲͚ͯՄೳͳݶΓਐḿͰ͖ΔΑ͏ʹɺεϓϦϯτͷ࡞ۀʹूத͢Δɻ 「スクラムガイド2020年度版」 Ken Schwaber＆Jeff Sutherland著 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スクラムの価値基準の⼀つである「集中（Focus）」をチーム全体で体現するための仕組み
114. ˜
     -:
     $PSQPSBUJPO • エピックという⼀つの課題に、メンバーが⼊れ替わりながら取り組んでいる • 課題は全員で共有されている • エピックは注⼒チームに紐づき、その課題を解決するために必要な⽬安の⼈数が明⽰されている  「流動チーム体制」も1つの⼿段 LeSSにおけるMobの形の⼀つと⾔えるかもしれない
115. ˜
     -:
     $PSQPSBUJPO 5. まとめ 「流動チーム体制」を通して得られたこと 
116. ˜
     -:
     $PSQPSBUJPO • 価値提供のリードタイムを短くすると、プロダクトのインクリメントを作り続けられる • 注⼒対象を決めて、チーム全体でそこに集中しコミットできる体制を作ることが⼤切 • 前⾝の取り組みでは、LeSS内の開発チームの⼈の配置を⼀部調整してコミットできるようにした • 「流動チーム体制」では、仕組みで毎スプリントコミットできる体制を作った  プロダクトのインクリメントを確実に作り続けるために
117. ˜
     -:
     $PSQPSBUJPO • プロダクトに関する共通知識とLeSSチームの基盤があれば、⼈の⼊れ替えも変数にできる • これはLeSSにおける⼀つのプラクティスと⾔えそう  ⼈を流動的に動かすのはLeSSの⼀つの選択肢
118. ˜
     -:
     $PSQPSBUJPO • プロダクトに関する共通知識とLeSSチームの基盤があれば、⼈の⼊れ替えも変数にできる • これはLeSSにおける⼀つのプラクティスと⾔えそう  ⼈を流動的に動かすのはLeSSの⼀つの選択肢
119. ˜
     -:
     $PSQPSBUJPO • みんなで話して、みんなの意⾒を聞いて決めて、みんながオーナーシップを持つようにする • チームとしてのありたい姿をみんなでイメージしながら、そこにどうたどり着くかを考える  チーム全体でなにかにチャレンジするときのコツ 対話 オーナーシップ ありたい姿 アクション 現在地
120. ˜
     -:
     $PSQPSBUJPO • 「流動チーム体制」は価値提供のリードタイムを短くするためのLeSSチーム内の取り組み • 「流動チーム体制」はDynamic Reteamingの⼀つの事例になり得る • Reteamingをおこなうことになった経緯や⽬的は異なるが、⼤事にしている要素は同じだった  RSGT2024 Keynote “Dynamic Reteaming” を聞いて ⽬的の明確化 みんなで決める オーナーシップを持つ RSGT2024 Keynote︓ https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19401/dynamic-reteaming-the-art-and-wisdom-of-changing-teams
121. ˜
     -:
     $PSQPSBUJPO • スクラムの検査と適応を、プロダクトだけでなく仕組みに対しても実践していくことで、 アップデートしていける • 体制や働き⽅をアップデートするときには、チーム全体でありたい姿を具体的にしていくこ とで、より効果的に取り組める  さいごに
122. ˜
     -:
     $PSQPSBUJPO  Special Thanks Hiroki Fukasawa Keita Terada Shinichi Yanagido Taiki Yoshikawa Takumi Kataoka Tomonori Kawai Yoichi Nagamoto Yusuke Kondou Hiroshi Hayakawa Mayuki Ishikawa Shu Kutsuzawa Takayuki Ootani Tetsushi Kuma Tomoyuki Nakamura Yudai Moriya Yuya Miki And more...
123. ˜
     -:
     $PSQPSBUJPO ありがとうございました