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

Scrum Fest Fukuoka 2025の登壇資料です。
https://confengine.com/conferences/scrum-fest-fukuoka-2025/proposal/21388

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、とうまから一言ずつ 「自己成長」