RSGT2026に参加しました
Webプロダクト開発部 Webプロダクト1グループのグループマネージャーをしている伊藤です。
今回初めてRegional Scrum Gathering Tokyo 2026に参加してきました。３日間、多くのセッション、Open Space Technology（OST）、懇親会に現地参加してきました。最も大きな収穫としては、自身のチームにおける複数プロダクト体制を「制約」から「可能性」へとリフレーミングできたことです。参加前のモヤっとした課題感が、セッションや対話を重ねるごとに次々と晴れていく。そんな手応えのある体験ができました。その中での学びや感じたことを共有できればと思います。
参加のきっかけ
私たちのチームは、複数のプロダクトを少数のメンバーで担当しており、各メンバーが異なるプロジェクトに関わりながらも、チーム全体としての一体感を大切にしていきたいと考えていました。 日々の業務サイクルの中で、スクラムの手法の一部も取り入れてはいましたが、不満はないものの、どこか「モヤっと」した感覚が残っていました。
私個人としては、複数プロダクト体制で、チームが離散してしまうのではという心理的不安も正直ありました。目標設定、評価、メンバーのモチベーション維持と向上、チームとしての方向性の立てづらさも感じていました。こうした課題の解決のヒントが、RSGTにあるのではないかという期待を持ちながら、今回の参加を決めました。
心に残ったセッションと気づき
Day1: スクラムマスターの役割についての再認識
スクラムマスターがスクラムチームに入って取り組む5つのこと - 増田 謙太郎
チーム立ち上げ時の方向性は間違っていなかったと再認識ができたセッションでした。このセッションでは、スクラムマスターのロールが「サーバントリーダーシップ」に基づいていることを改めて理解しました。
特に印象に残った「5つの大切なこと」：
- 「助けて！」と叫ぶ - スクラムマスターが真っ先にチームメンバーを頼り、頼り、頼られる関係を作ることの重要性
- 余裕を持つ - 時間・心身ともに余裕を持ち、カレンダーを開けておくことで相談されやすくする
- 偉い人とのコネクションを作る - チームの障害を取り除くために、組織内の重要な情報や関係性を構築する
- 見せられないインペディメントリスト（障害や阻害要因） - 信頼されるスクラムマスターには極秘情報が集まることもあり、それを活用する
- 楽しく仕事する - 楽しそうに仕事をしている姿が、次のスクラムマスターを育てる
Webプロダクトチーム立ち上げ時を振り返ると、入社初日に「入社したてで申し訳ないけど、助けてほしい！」と最初に伝えたことを思い出しました。当時は試行錯誤の連続でしたが、この「真っ先に頼る」という姿勢はチーム内での信頼と相互扶助の関係を築く第一歩になっていたのかもしれないと感じました。一方で「余裕を持つ」ことはまだあまりできていないので個人的な課題だなと感じさせられました。
Day2: 自己管理型チーム時代のマネージャーの課題
自己管理型チームの一員となるためのセルフマネジメント：モチベーション編 - 小田中 育生
このセッションで最も心に刺さったメッセージが、「チームメンバーはいい状態なのに、EM（エンジニアリングマネージャー）のモチベーションが上がらない」という問題提起でした。
セッションの中で語られたのは、自己管理型チームになることは素晴らしいことだが、マネージャー自身も人間だから自己を見失うこともある。その時にどう立ち直るかが大切だということです。重要なのは「マネジメントのスコープに自分も含める」という考え方。
複数プロダクト体制の中では、プロジェクトマネージャーとしての責任、メンバーマネジメントとしての責任、そして自分を含めたキャリアやモチベーション。これらを全て独立した課題として扱っていた部分がありました。しかし、セッションで語られた「ABC理論での内省、メンバーの活躍、信念のリフレーミングで晴れていった」というメッセージに深く共感しました。
また、セッションで印象的だったのは「モチベーションの源泉」の多様性です。セッションでは、モチベーションの源泉を「挑戦」「報酬」「達成・貢献」と分類し、その心の着火点は一人一人異なることが強調されていました。チームメンバーのタイプを「先導（ゴール決定から巻き込むタイプ）」「自走者（ゴール提示でプロセスは任せるタイプ）」「成長株（期待を示すタイプ）」に分け、それぞれに異なるアプローチが必要だという話は、自分たちのチームマネジメントにも直結する気づきでした。
あの夜、私たちは「人間」に戻った。 ── 災害ユートピア、贈与、そしてアジャイルの再構築 - 秋葉 啓充
チームとしての一体感についての根本的な考え方を提示してくれたセッションでした。セッションでは「システムトラブル時の一体感」を平時に再現できないか、という問いが提起されていました。
今のチームも最初のプロダクト開発を乗り越えたからこそ出来上がったチームなのかもしれません。その過程での「火」（セッションでは「集合的沸騰（Collective Effervescence）」と呼ばれていました）が、今のチームの空気感を作っているのだとしたら、その火を持ち続けるために何が必要か。
セッションで特に学んだのが、「贈与の三つの義務」（マルセル・モースの「贈与論」） - 与えること、受け取ること、返すことの連環を、チームに実装するという考え方です。また、朝会でのルール「愚痴も弱音もOK。最後は全員で拍手（拍手に繋がるように話す）」というアイデアと、「制度を回すのではなく、チームに"火"を灯す」というマネジメントの考え方がとても心に響きました。
産業的変化も組織的変化も乗り越えられるチームへの成長 - 笹尾 納勇仁
生成AIの登場による急速な変化に、チーム開発プロセスはまだ対応しきれていないという指摘が心に残りました。セッションでは「生成AIは産業期変化」であり、解像度の高い情報と短いリードタイムが必要になると強調されていました。
特に参考になったのは、生成AIの時代では「エンジニアもPRDに記載する」ことが大切だという話。なぜこの仕様なのかを自分たちが説明できるようになることで、チーム全体の「価値密度」が上がっていくという考え方は、複数プロダクト体制におけるプロジェクトチーム間のコミュニケーション改善に繋がると感じました。
一方で、エンジニアリングマネージャーとして感じるのは、ツールや技術が一気に変わったとしても、チームの基本的な仕組みは案外変わらないのではないか、ということです。むしろ、変化に対応するために必要な「チームメンバーとの向き合い方」の重要性が高まっているのかもしれません。
飲み会での学び - 懇親会の大切さ
Day1&Day2でのセッション後の懇親会では、参加者同士でセッションの振り返りをしつつ、それぞれの現場の「生の声・体験」を共有しながら、多くのアドバイスをもらいました。複数プロダクト体制での自分たちの悩みに対して、「エンジニアリングマネージャー」と「スクラムマスター」という異なるロールの視点の切り替え方についても、初めてアドバイスをもらいました。こうした実践的な対話が、最後のOSTでの気づきを深めることになったのです。
OST（Open Space Technology）での整理
OST（Open Space Technology）とは、参加者自らが議題を提案し、関心のある人同士で対話を進めながら、理解を深めたり具体的なアクションを導き出す手法のことです。
私からは「組織チーム、メンバーは別々のプロジェクト、どうする？」というテーマを出してみました。（ここで「組織チーム」とは、マトリクス型組織において、1つの開発チームが複数部門の複数プロダクトを担当する状況を指しています。）
スクラムマスターとしての役割、エンジニアリングマネージャーとしての役割は別物である。 しかし、同じ人間が両方のロールを持つ場合、それぞれの目線を意識的に切り替える必要があります。前日の懇親会での学びと、OSTでの対話を通じて、この重要性が腑に落ちました。
例えば、スクラムマスター的な視点では「プロジェクトチーム内の心理的安全性」や「コミュニケーション」「インペディメント除去」に加えて、「プロダクトの価値やビジョンをチームメンバーに浸透させる」といったプロダクトマネージャー支援も視野に入れ、一方でエンジニアリングマネージャー的な視点では「メンバーの成長」「目標設定と評価」「モチベーション維持向上」「自分自身のマネジメント」に目を向ける。両者とも同じくらい大切ですが、どのレンズで課題を見つめるのかを意識することで、判断の根拠が明確になり、より適切なアクションが取れるようになるという気づきをえました。
またOSTの中で学んだもう一つの重要な概念が「サーバントリーダー志向」でした。これは単なる奉仕の精神ではなく、メンバーの「行動設計」を後押しし、内省を促すというアプローチの重要性でした。
振り返ってみると、これまでの自分の思い込みは、「チーム一丸」という理想的なスタイルで考えようとしすぎていたことが大きな要因だと気づきました。自分自身も担当プロジェクトの一メンバーであり、その中での振る舞いと、組織チームのリーダーとしての役割は分けた方がいいのではないか。この考え方がOSTの中で形になりました。 また議論の中で参加者の一人から「現在のチーム状況は決して悪い状態ではなく、とても好感が持てるチーム」との声をいただけたのはとても嬉しかったです。無意識のうちに両方の役割を少しは実践できていたのかもしれません。
AI時代のアジャイルチーム - スクラムというコンフォートゾーンからの脱却
AI時代のアジャイルチームを目指して - 及部 敬雄
このセッションで深く考えさせられたのは、「作業レベルでのAI開発は進む一方、チーム開発プロセスはあまり変化できていない」という指摘です。AIは「支援 > 伴奏 > 委託」へと進化しており、個人レベルでは効果が高いが、組織レベルでは高くないという現実が興味深かったです。
セッションで紹介されていた「よくある現実スクラム」：
- プロダクトオーナーとの対話が少ない
- エンジニアの誰かがスクラムマスターをやっている（兼務）
- デザイナー、テストエンジニアが複数プロジェクト横断になりがち
- タスクが個人にアサインされている
- スクラムイベントがスケジュール中心になっている
これらを聞いていて、自分たちのチームとも一部重なる部分があると感じました。また「スクラムがコンフォートゾーン化することが悪いわけではない」とも述べられており、むしろ重要なのは「スクラムガイド以上のスピードで開発プロセスを更新していく必要がある」という点でした。
セッションで強調されていたAI時代のアジャイルチームに必要な要素：
- 意思決定の範囲を広げ、質を高める
- チームで扱う変数を増やす（変える）
- 学習する仕組みが備わっている
- ロールを動的にする（ロールが固定であることが変化を阻害する）
特に「ロールを動的にする」という概念は、複数プロダクト体制で異なるロールを求められる自分たちのチームにとって、非常に参考になるものでした。また「自分のハンドルは自分で握れ！」というメッセージや、「モブプログラミングの再評価」という話も、チーム全体で大切にしていきたいと改めて感じさせられました。
これからの方向性
RSGTを通じて改めて感じたのは、「仕組みや手法も重要だが、何より人との関わり方が最も大切である」ということです。 複数プロダクト体制の少数チームを率いていく上で、重要なのは以下の3つだと気づきました。
メンバー一人一人と向き合い続けること - メンバーの「心の着火点」を理解し、メンバーそれぞれに火が灯り、チーム全体が明るくなるような人間関係と相談しやすい環境を構築すること
エンジニアマネージャーとスクラムマスターの視点を意識的に切り替えること - エンジニアマネージャー視点では「メンバーの成長」「目標設定」を、スクラムマスター視点では「心理的安全性」「インペディメント除去」を重視する。課題に応じて意識的に視点を切り替えること
マネージャー自身もマネジメント対象であること - 自分のモチベーション、キャリア、葛藤も統合して考えること
スクラムやアジャイルというフレームワークは確かに有効な道具ですが、最も大切なのはメンバーの自発性や内省を後押しできる環境と「人間関係」をどう構築するか。これまでも、そして、これからもチームマネジメントの鍵になると再認識できました。
「変化に飛び込んで楽しむ」というメッセージは、チームメンバーへの向き合い方の姿勢としても応用できると感じています。 RSGTでの学びを、チーム内での対話や実装を通じて、少しずつ形にしていきたいと思います。
最後に
RSGT2026に参加して改めて気づいたのは、「スクラムやアジャイルというフレームワークや手段以上に、人間関係とコミュニケーションが大切である」という当たり前のことを、改めて確信に変えることができたことです。アジャイルソフトウェア開発宣言で「プロセスやツールよりも個人と対話を」と示されているように、チームメンバーと向き合い、メンバーのモチベーションの源泉を理解し、自分自身もマネジメント対象として観察を続けること。これらの実践を通じて、メンバーの自発性や内省を後押しできる環境と「人間関係」をどう構築するか。それこそが、チームマネジメントの本質だと再認識できました。
また複数プロダクト体制という制約の中で「チームとしての一体感」と「メンバー配置」の両立について悩んでいましたが、「複数プロダクト体制」が「制約」から「可能性」にリフレーミングできたことがRSGTに参加した最大の学びとなりました。メンバーがそれぞれのプロジェクトと向き合いながらも、複数プロダクト体制という環境をチームの力を最大化する機会として捉え、チームの一員として互いに越境し支え合う関係を意識的に構築・維持していく。そうすることで、今の体制だからこそお互いに成長できるチームを目指していきたいと思います。
参考： Webプロダクト開発部の立ち上げについて詳しく知りたい方は、以下の記事もご覧ください。 Webで移動にまつわる課題を解決へと導く。Webプロダクト開発チーム立ち上げの全貌 | GO-on
