俯瞰と個別の⼆つの視点で紡ぐ スクラムマスターの成⻑と協働 / Dual Views Weaving Scrum Master Growth

Transcript

1. 俯瞰と個別の⼆つの視点で紡ぐ スクラムマスターの成⻑と協働 Scrum Fest Fukuoka 2025 2025.03.08
2. ⾃⼰紹介 Toshinari Cybozu Scrum Master X:@10shinari 2
3. ⾃⼰紹介 2022年9⽉にサイボウズ株式会社に⼊社。 kintone開発チームでスクラムマスターを担当。元QA 今年の抱負：アウトプットの良さを広める、⾃⼰研鑽 とうま X:@toma_cy mixi2:@to_ma 3
4. アジェンダ 1. スクラムマスターの導⼊と初期の動き 2. サイロ化の発⽣と対策 3. スクラムマスターの成⻑ 4. スクラムマスターの協働 5. 協働によるアクションと効果 6.今後の展望や取り組み 4
5. スクラムマスターの導⼊と初期の動き
6. 私たちの背景 • 所属：kintoneという製品の開発チーム • kintoneのサービス歴：14年⽬（2011年11⽉ リリース） • kintone開発メンバー数：100⼈以上 ※2025年現在 6
7. 開発⼿法の変遷 • 初期：ウォーターフォール • 2016年：アジャイル開発（LeSS）に転向 7
8. LeSSによる開発 引用：https://less.works/jp/less/framework 8
9. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム Aチーム PG Bチーム Cチーム Dチーム チーム外 PdM デザイナー QA PG QA PG QA PG QA リファインメント 開発プロセスと組織の概略 ~2022
10. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム Aチーム PG Bチーム Cチーム Dチーム チーム外 PdM デザイナー QA PG QA PG QA PG QA リファインメント 開発プロセスと組織の概略 ~2022
11. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム Aチーム PG Bチーム Cチーム Dチーム チーム外 PdM デザイナー QA PG QA PG QA PG QA リファインメント 開発プロセスと組織の概略 ~2022
12. 2022年に⼤幅な体制変更 • 課題：負債の蓄積による価値創造スピードの低下 • 対応策：「全員が全機能を作る」から「機能ごとにチームで分 担開発」へ 12 「肥⼤化‧モノリス化するプロダクト開発組織を ⾃律的で⼩さなチーム群に変えていく ―kintone開発チームの事例―」より
13. 13 チーム Aチーム PG Bチーム Cチーム Dチーム QA PG QA PG QA PG QA 全員が全機能を作る
14. 14 チーム Aチーム PG Bチーム Cチーム Dチーム QA PG QA PG QA PG QA ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム QA PG QA PG QA PG QA 全員が全機能を作る 機能ごとにチームで分担開発 “アプリの設定” “アプリ“ “ポータル“ ”通知/検索“ “システム管理“ ”レコード読み込み“
15. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM デザイナー QA PG QA PG QA PG QA リファインメント 開発プロセスと組織の概略
16. リチーミングの挑戦 • 新たなチーム編成でのスタート • 形成期（タックマンモデル）からの再出発 形成期 チームが形 成される 混乱期 ぶつかりあう 統一期 共通の規範 が形成される 機能期 チームとして 成果を出す 散会期 チームの終 結 16
17. スクラムマスターの配置 • 機能ごとに分割された各チームにSMを配置 • 2016-2022年：チーム内にSM不在（アジャイルコーチが⽀援） 17
18. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 PdM デザイナー
19. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 QA PG QA PG QA PG QA リファインメント 開発プロセスと組織の概略 PdM デザイナー • 開発メンバーから希望者がチャ レンジ • 初期はプログラマやQAといった 主務と兼務するメンバーがほと んど SM SM SM SM
20. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 PdM デザイナー 引用：https://less.works/jp/less/rules
21. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 PdM デザイナー 1⼈ひとりのSMが担当チーム内に 向けた活動と同時に組織全体にま で⽬を向けて活動をするにはスキ ル的にも時間的にもオーバー
22. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM 全体SM QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 デザイナー 組織全体を俯瞰的に⽀援するSMとして 「全体SM」を配置
23. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM 全体SM QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 デザイナー • 狭く深く活動し単⼀チームを⽀援するチームSM • 広く浅く活動し組織全体を⽀援する全体SM
24. とうま 個別チームへの集中 24
25. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM EM デザイナー QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 とうま
26. SMとしての 経験不⾜ 当時の関⼼事 個別チームに注⼒ 🍮チームに改善点が 沢⼭ありそう 26
27. その他、全チームが関連するイベントの関⼼はややあるぐらい ‧オーバーオールレトロスペクティブ ‧スプリントレビュー とはいえ積極的に貢献できていたかというと疑問 当時の関⼼事 27
28. Toshinari 組織全体を俯瞰した活動に集中 28
29. 次の スプリント 前の スプリント スプリント レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM 全体SM QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 デザイナー スプリントプランニング 一部／二部 スプリント レビュー 変更後の体制に合わせて、 チーム横断のイベントを最適化
30. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM 全体SM QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 デザイナー • デザインチーム↔開発チームの連携改善 • PdMチーム↔開発チームの連携改善 • PdMと開発者の過度な分業改善
31. 改めて今⽇のテーマ 複数⼈のSMが協働できるようになるまでの成⻑のストーリー を、個別と俯瞰のそれぞれのSMの視点から話します。 31
32. サイロ化の発⽣と対策
33. 各々のSMが独⽴して活動 • 全体SMとチームSMがそれぞれの活動に集中していった • それゆえ情報共有や協働が⾏われていない状況が続いてた 33
34. 全体SMの⽴場からの改善活動が困難に • 全体SMとして活動していく中で、次第に改善を進めることが難し くなってきた • 各チームによって成熟度や優先して取り組みたいことが異なる中 で、チーム外からトップダウンで改善を進めている状態に なってしまっていたため 34
35. 35 例：フィーチャーファクトリーの改善 Why/Howを考える • ユーザーストーリー • 詳細過ぎる受け⼊れ条件（≒仕様） Howの通りに実現する • 細かくPdMに相談
36. 36 こういった状態が⻑く続いていた 例：フィーチャーファクトリーの改善 Why/Howを考える • ユーザーストーリー • 詳細過ぎる受け⼊れ条件（≒仕様） 考えられたHowの通りに実現
37. 37 例：フィーチャーファクトリーの改善 Howを開発チームからも考え てもらえるように推進 「⾔われるならやりますけど‧‧‧う〜ん」 「いやいや、うちは今それどころじゃないです」
38. 38 例：フィーチャーファクトリーの改善 Howを開発チームからも考え てもらえるように推進 「⾔われるならやりますけど‧‧‧う〜ん」 「いやいや、うちは今それどころじゃないです」
39. 全体SMの限界 • 全体SMだけで改善を推進するには限界を感じる • 組織全体に対して外発的に改善を推進するだけではなく、個別 チームからの内発的な推進も必要 39 全体の課題（組織全体の課題）を SM達で協⼒し合えるようになりたい
40. 周りを⾒渡して考えたこと 「チーム間で成熟度の差が顕著になってきてるな」 40 「各々のSMが担当チームに閉じきった活動になっているな」 「同じチームにSMが複数⼈いる利点をいかせていないな」 個別の課題（各チームの課題）を SM達で協⼒し合えるようになりたい 「チーム毎にノウハウ溜まってきていそうだな」
41. 各SMが担当チームに閉じず、 協働していけるようになりたい 41 個別の課題 （各チームの課題） 全体の課題 （組織全体の課題）
42. SM同⼠で集まる ⾊々と試⾏錯誤してきました 42 2023 2024 2025 SM誕生 SM達でチームビルディング
43. SM同⼠で集まる ⾊々と試⾏錯誤してきました 43 2023 2024 2025 【定例MTG】 OSTのような参加者駆動形式で インペディメントについて対話 SM誕生 SM達でチームビルディング
44. SM同⼠で集まる ⾊々と試⾏錯誤してきました 44 2023 2024 2025 【定例MTG】 OSTのような参加者駆動形式で インペディメントについて対話 SM誕生 【定例MTG】 組織全体のインペディメントを可視化して、 SM達で取り組んでいく改善の アラインメントを取る SM達でチームビルディング
45. SM同⼠で集まる ⾊々と試⾏錯誤してきました 45 2023 2024 2025 【定例MTG】 OSTのような参加者駆動形式で インペディメントについて対話 SM誕生 【定例MTG】 組織全体のインペディメントを可視化して、 SM達で取り組んでいく改善の アラインメントを取る SM達でチームビルディング 協働に近づいていく効果が得られない状況が続いた…
46. なぜ上⼿くいかなかった？ • チームSMが担当チームの⽀援に⼿⼀杯 • チームSMが担当チームの外側について⾃分ごとになっていない • 全体SMのリーダーシップ不⾜ 46
47. なぜ上⼿くいかなかった？ • チームSMが担当チームの⽀援に⼿⼀杯 • チームSMが担当チームの外側について⾃分ごとになっていない • 全体SMのリーダーシップ不⾜ 47
48. 48 2023 2024 2025 【定例MTG】 OSTのような参加者駆動形式で インペディメントについて対話 SM誕生 【定例MTG】 組織全体のインペディメントを可視化して、 SM達で取り組んでいく改善の アラインメントを取る SM達でチームビルディング 全体SMの廃⽌ 全体SM 廃止
49. • 全体SMという役割が元々不要だったわけではない • 全体SMという組織全体を俯瞰してみることに特化した役割の必 要性が減ってきていると考えた 49 SM主務のメンバー が増えた 各チームが 機能期になった 全体SMの廃⽌
50. • 従来の役割構造を続けていると、 チームSMの⼀⼈⼀⼈が組織全体に対して⾏動していくことへの 障害になりかねないと考えた • チームSMが⾃⾝の成⻑や、担当チームの状態の変化により、担 当チームの外側に対しても徐々に活動を広げていける環境にす る意図 50 全体SMの廃⽌
51. • 個別チームに閉じない改善にチームSMを巻き込んで取り組む • チームSMが個別チームの外側に対しても⽬を向けて改善に取り 組んでいける空気感を作っていく狙い 51 全体SMの廃⽌に加えて
52. 焦りと葛藤 • SM⼀⼈ひとり、置かれている状況が異なるため改善活動への参 加を強要するようなことはしなかった。 • 緩やかに変化していくことを待ちの姿勢で居続けるのか、 それともか攻めの姿勢で他にもっとやれることがあるのではな いかと常に焦りと葛藤に悩まされていた。 52
53. 転機が訪れる SM達の⽴場と⼼情に変化が⽣まれていく • EMという新しい役割の誕⽣ • 協働に対してのSM同⼠の対話 53
54. スクラムマスターの成⻑
55. EMという新しい役割の誕⽣ 55
56. EM新設の背景 56 kintoneはリリースから10年以上経過 製品仕様や 実装が複雑化 戦略を踏まえた計画が立てづらいという声も 組織規模が拡⼤し PdMとの距離感が遠く
57. EM新設の背景 57 事業戦略に沿った開発組織の⽬標‧計画を策定し、 現場メンバーの活動に反映される必要がある ＝ アラインメント アラインメント‧リーダーシップを向上するための試み EMの新設
58. kintone 開発チームのアラインメント‧リーダーシップ向上に向けた取り組み https://blog.cybozu.io/entry/2024-08-17-kintone-team-alignment 58
59. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM EM デザイナー QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 爆誕
60. EMとPdMが連携し、顧客価値に 関わるプロジェクトの⽴ち上げ を⾏い、事業戦略の遂⾏に貢献 事業戦略の遂⾏ チームの課題や要望の意思決定 をEMが⾏うことでスピード感を 持った対応が⾏えるようになっ た チームに関する迅速な意思決定 不確実性の⾼いプロジェクトに 対しても、迅速にチームを組み ゴールを達成する動きが可能に なった 機動的なプロジェクトチームの編成 60 ポジティブな影響
61. EMの負荷‧⼤ チームの安定性低下 61 EMとPdMが連携し、顧客価値に 関わるプロジェクトの⽴ち上げ を⾏い、事業戦略の遂⾏に貢献 事業戦略の遂⾏ チームの課題や要望の意思決定 をEMが⾏うことでスピード感を 持った対応が⾏えるようになっ た チームに関する迅速な意思決定 不確実性の⾼いプロジェクトに 対しても、迅速にチームを組み ゴールを達成する動きが可能に なった 機動的なプロジェクトチームの編成 ネガティブな影響
62. EMの負荷‧⼤ マネージャーと兼務しているEMもいるため EMでやるべき活動がおろそかになる懸念 チーム全体で価値を最⼤化するために、同じ⽅向を向いて 活動するためのアライメントを実現する EMの重要な役割の一つ 62
63. タスク整理を⽀援するために、某EMの タスクを洗い出してみた結果 ⼤量のミーティング！ （なんとかチームに委譲できないか模索中） EMの負荷‧⼤ 63
64. トピック A トピック B チームの安定性低下 64 2チームでトピックA、Bを開発している状態
65. トピック A トピック B トピック C トピック Cが増えたとした場合‧‧‧ アサイン変更により対応 その結果、安定しないチームに チームの安定性低下 65
66. チームを⽀援して良いチーム作りをする 1つのチームを⽀援していても、効果的でない メンバーの⼊れ替えが発⽣ 積み上げてきたものがリセットされる ふりだしに戻る 68
67. １チームだけ⾒ていても 解決できない チーム外にも視野を広げて⽀援する必要性を痛感 69 トピック A トピック B トピック C
68. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🐤チーム 🐰チーム チーム外 PdM EM デザイナー QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 PG QA SM 🍮チーム 今更ながら、視野がめちゃくちゃ 狭くなっているこという内省
69. １つのチームだけに注⼒するのではなく、 複数チームも考慮した⽀援が必要 しかし、⼀⼈では複数チームを⾒るハードルは ⾼いのでSM同⼠の協働が重要 72
70. 他のSMと協働すべきという納得感が醸成 73 SM同⼠の協働を強めて、チーム や組織への貢献を⾼められたら いいよね EM誕⽣前 チームや組織に効果的に貢献す るためには、協⼒が不可⽋！ EM誕⽣後
71. 協働に対してのSM同⼠の対話 74
72. とある⽇のSM定例 とある⽇ 2023 2024 2025 SMの協働を促進するために SM定例を改善しようという流れに SM定例：SM達が集まって、知⾒の共有や課題のディスカッションを⾏う場 75
73. SM定例の⽬的の再認識 ⼀つの製品チームの中に複数のSMがいることを活かすことで SMとしてのチームへの貢献を⾼める 76 SM同⼠が⾊々話せると知⾒も増えていいよね
74. ⾊々アイディアを出してみるも、 ⽅法論に終始している感がぬぐえない 相談事項 ⽬的に合わせたアジェンダ出し 経験内容の共有 もやもや 知⾒の共有 雑談
75. 定例はあくまで⽅法なので、いったん忘れて ⽬的を遂⾏するためにどうすればいいか話そう EMが整備された中、SMの存在価値とは？ 78 ⽬的 ⼀つの製品チームの中に複数のSMがいることを活かすことで SMとしてのチームへの貢献を⾼める
76. EMが整備されたことにより 解消されたチームの課題も少なくない SMとしてやるべきことなくなった？
77. EMが整備されたことにより 解消されたチームの課題も少なくない SMとしてやるべきことなくなった？ 否
78. 視野を広げることで⽀援できる課題もある 「EMの負荷‧⼤」 「チームの安定性低下」 チーム外に⽬を向けるとまだまだ課題は沢⼭ある
79. QA PG 現状は⾒えていなくても複数SMにより 多⾓的な視点と広い視野を持つことで 新たな課題も⾒つかるかもしれない SM SM 🐰チーム 🐤チーム QA ⚙チーム PG QA SM EM EM EM EM 🍮チーム PG PG QA
80. SM定例改善の結果 SM定例による対話を通じた 情報共有で視野を広げていく 視野を広げると明らかな課題が存在する さらに、多⾓的な視点と広い視野で新たな課題が⾒つかる可能性も 83 そのためにはSM同⼠の対話が重要
81. SMとしての役⽬を終えて、 エンジニアに戻るメンバーもいた ⽬的に向き合ってより良い選択をしただけで ネガティブな話ではなく状況に適応した結果 ⼀⽅で‧‧‧ 84
82. ⽬的ベースで考えるのが重要 そして、これを機にSM同⼠の協働が加速 85 SM同⼠が協働することの納得感が増したSM定例改善
83. スクラムマスターの協働
84. 新たな協働の形 87 2023 2024 2025 事業戦略/プロダクト戦略を達成するため 新たな協働の形 SMの誰もが、必要な時に必要なリーダーシップを 発揮していける状態を⽬指した
85. 88 課題A リーダーシップ フォロワーシップ 課題B 課題C 課題に対してリーダーシップを発揮しつつ、 相互のフォロワーシップによって⽀えあっている
86. SMメンバー間で情報共有 • リーダーシップを発揮するに は俯瞰（組織全体）と個別 （各チーム）の両⽅の情報が 必要 • SMメンバー間で次の情報を共 有 • 組織全体の状況 • チーム内の状況 • EMの動向 • など 89
87. インペディメントの共同管理 • アイゼンハワーマトリクス • 追加情報を共有し合い、新 しい状態を保つ • 解消するインペディメント を選択してアクションを計 画して実⾏していく 90
88. 協働できるようになるために必要だった こと • 担当チームの外に⽬を向けていける余裕 • 担当チームの外に⽬を向けていく必要性 • リーダーシップ⼒ • 協働しなければ達成できない課題を⽰し推進 91
89. 協働によるアクションと効果
90. チーム全体に関わる活動 93
91. 次の スプリント 前の スプリント スプリント レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM 全体SM QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略 デザイナー スプリントプランニング 一部／二部 スプリント レビュー オーバーオールレトロスペクティブの改善
92. 課題：オーバーオールレトロスペクティブのファシリテーションの 難しさ（議題の選定、進め⽅、盛り上げ⽅） 対策：オーバーオールレトロスペクティブのふりかえりをSM同⼠で⾏った 98 様々な改善点を出すことが出来 改善し続けることができた 結果 オーバーオールレトロスペクティブの改善
93. ファシリテーター役と参加者役、双⽅の視点が あったからこそ改善を促進できた ふりかえりのふりかえりは重要 オーバーオールレトロスペクティブの改善 99 そして、終了直後に内省することが⼤切
94. ドット投票の⼯夫 全チームへのヒアリングの⼯夫 議題を選ぶためにドット投票を採⽤。さらに熱量を図る ために、積極的に⾔いたいことがあるかどうか、なんと なく気になるかを区別できるようにした。 これにより、同数票であった場合などにどちらを選ぶか の⼀つの判断材料にする。 全チームの状況を聞きたい場合に⼝頭で問いかけても 答えづらい。各チームのテキストで書いてもらう場所 を⽤意するため、あらかじめ付箋を⽤意。 潜在的にあるかもしれない課題を挙げやすくするため の⼯夫。 氷⼭モデルをつかうことで、思考の幅を広げる狙い。 氷⼭のメタファー 100 オーバーオールレトロスペクティブの改善
95. SMとして投げかけたい問いがないか、事前に話す 普段話題に出づらいが話したほうが良いと思われる問いかけ、など 101 オーバーオールレトロスペクティブの改善
96. EMを⽀援する活動 102
97. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM EM デザイナー QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略
98. 課題：EM活動が、現状どんな状況にあるのかわからない 対策：EM陣を集めてふりかえりを実施 104 EM活動のふりかえり 現状の課題感やEM陣が感じていることなどが明らかになった 結果
99. 105 EM活動のふりかえり
100. SM同⼠で相談して、問いかけ⽅法を⼯夫 106 このふりかえりにより、具体的な課題も⾒えてきた
101. 課題：アラインメントを狙った定例だが、時間内におさまらず議題が 消化しきれない 対策：EM定例の⽬的を再整理 107 Mtg時間を短縮することにつながり ⽬的にフォーカスすることができた 結果 EM定例の改善
102. EM定例の改善 EM定例とは 各チームのアライメント を強化する 様々な課題の議論や 情報共有 108 ＋ 別の⽅法で代替 唯⼀の⽬的に設定 アラインメントのおざなりを回避し Mtg時間が短縮できた（1h -> 30m）
103. 特定のチームに関わる活動 109
104. スプリントプランニング 一部／二部 次の スプリント 前の スプリント スプリント スプリント レビュー レトロ スペクティブ オーバーオール レトロスペクティブ 開発プロセス（LeSSベース） チーム ⚙チーム PG 🍮チーム 🐤チーム 🐰チーム チーム外 PdM EM デザイナー QA SM PG QA SM PG QA SM PG QA SM リファインメント 開発プロセスと組織の概略
105. • 🍮チームに関する課題をSM同⼠が協働して⽀援する • 別チームからSMとして移ってきたり • 🍮内の課題に複数SMでディスカッションしたり 111
106. 今後の展望や取り組み
107. etc... 2025年の現在 → SMの⼈数（3名）に対してチームの数が圧倒的に増えた。 SMがカバーしきれていないチームもいる。 113
108. （kintone開発全体のロードマップですが、 絶対⾒せられないので、⼼で感じて下さい） SM達で事業戦略/製品戦略の観点とチームの成熟度の観点を照ら し合わせながら、重点的に⾒るチームと薄く⾒るチームとを再考 し、戦略的に組織全体を⽀援していく 114
109. SM達でインペディメントをシステム思考で分析し始めた。 共通認識を育みながら、レバレッジポイントを⾒つけて効果的に アプローチしていく。 115
110. SMが協働するためのポイント 116 最後に そんな⾃⼰成⻑について Toshinari、とうまから⼀⾔ずつ 「⾃⼰成⻑」