はじめに

どうも。ものづくり部のビジネス開発グループでプロダクトマネージャーをしているべったけ(@gb_pdm)です。

少し時間が経ってしまいましたが、2025/1/7-1/10で開催されたRSGT（Regional Scrum Gathering℠ Tokyo）2025に初参加してきたので、本日はその時の様子を紹介したいと思います！

RSGTとは

2025.scrumgatheringtokyo.org

RSGTはアジャイル開発やスクラム開発に関連する国内最大級のカンファレンスです。

オンライン、オフラインでの参加が可能で海外の著名な方を招いての基調講演をはじめ国内のアジャイル開発に関する様々なセッションが3日間開催されます。
(通訳はもちろん、リアルタイムでの文字起こし翻訳や手話なども整備されていてアクセシビリティが素晴らしいな感じました)

またセッションだけでなく体験ワークショップやOST(オープンスペーステクノロジー)といわれる参加者同士でディスカッションを行うコンテンツもあり、交流をすることで学びを深めながら社外の人とも繋がりを作ることができる場になっています。

会場の様子

スポンサー

ネームプレート

バッジ

保有しているスクラムの資格やどの地域から参加しているかを表すバッジをつけることでどこから来たのか、どういった人なのかがすぐにわかるような工夫がされていました。
「初参加」バッジもあり、初参加の方との会話のきっかけにもなったのでとてもありがたかったです。

ビンゴカード

より交流を深めるためのミッションがビンゴになっていて、勇気を持って行動するための最初の1歩を後押してくれます

アジャイル開発関連の書籍

Day1

セッション : スプリントレトロスペクティブ Deep Dive

slide.meguro.ryuzee.com 大好きな吉羽さんのDeep Diveシリーズの最新作。今回も学びの多い内容でした。

学び

スプリントレトロスペクティブはスクラムチームに関わる全ての「品質」と「効果」を高めるためのもの
「品質」「効果」を高めていくための要素として「楽しさ」「幸福感」も重要
スプリントレトロスペクティブで改善策を選ぶ際は
- 最も役に立つものを選ぶ
- スクラムチームで実行可能なものを選ぶ
- 次のスプリントで改善を検査できる程度のサイズにする
「最も役立つ改善」 >「効果は大きくないが直ぐにできる改善」が基本原則

セッション : IMPACT !!　ゴールとアウトカムからはじめる経験的アプローチ

www.docswell.com こちらのセッションはゴールをどう設定し、そのゴールに対してどう検査・適応していくべきかという内容でした。

学び

計画主導(線形)ではなくゴール主導(非線形)で成功に向かっていく
ゴールは大きく3段階の抽象度で設定する
- 山頂のゴール　(責任者で決める)
- 山頂の中間のゴール　(全員で決める)
- 直近のゴール　(チームで決める)
ゴールを分解し作るべき成果物を決める
- ユーザー : 「誰に」提供すべきか
- 価値、体験 : そのユーザーに「どんな体験、価値」を提供すべきか
- 行動変容 : 体験、価値提供するために「どんな行動変容」をしてもらうべきか
- 成果物 : 行動変容しえもらうために「どんな成果物」が必要か

セッション : エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢について

speakerdeck.com チーム間でのサイロ化が進みコラボレーションコストが増加してきたことで、スクラム→FASTに移行したというセッション内容でした。弊社も1プロダクト内に複数チームがあり共感できる課題も多かったので非常に興味深いセッションでした。

学び(というか共感ポイント)

ユーザージャーニーを輪切りにしてチームを作っていたのでサイロ化が進んだ
必要となる技術やチームルールや文化もチーム毎にかなり違っていた
各チーム内ではスクラムが進化したがチーム間連携が必要になったタイミングで問題がでてくる
トータルでのプロダクトの価値が捉えにくい状態になっていた
FAST導入によりスコープが広がったため開発者の認知負荷は上がった(トレードオフ)
自律性を重視したボトムアップで進めていくこの重要性
マネージャーが決めた「自律性のあるFAST導入」って自律的といえるのか？
スクラムではチームは安定的であることが前提 / FASTではチームが流動的であることが前提

Coaches-Clinic（コーチーズクリニック）

コーチーズクリニックはプロのアジャイルコーチの方に無料で相談出来るコンテンツです。
現在進行形で悩んでいることを直接相談できとても有意義な時間でした。

学び

良いプロダクト、良いチームになるなら手法にはこだわらない。いきなり形式ばってチームが壊れてしまうならそうならないように進めていく
- とはいえスクラムガイドで定義されているイベントの反復リズムは守ったほうが良い
- どこまで守ってどこまで崩すかのさじ加減は難しくスクラムマスターの腕の見せどころ
スクラムマスターが開発チームと1on1で対話していくのは注意が必要
- クローズドな場所で話すとスクラムマスターだけが情報を持ち開発チーム全員でのナレッジが進まない構造になってしまう。なるべくチーム内でオープンな場で議論されていくことを目指していく
- いきなりその状態に持っていくのは難しいので最初は言いづらいことを1on1で引き出して徐々にオープンな場で発言できるように促していく

飲み会

廊下で飲み会参加者が募集されていたのでこちらにも参加してきました。

他社の事例が聞けたり、「ぶっちゃけどうですか？」みたいな話も色々聞けて良かったです。

開発手法としての「アジャイル」「ウォーターフォール」は作るものによって是々非々があるけど組織やチームはどちらかに最適化されていることが多いから作るものによって変えるの難しいよねという話をしました。

Day2

Day2は業務都合もありオンラインで参加しました。

基調講演 : Maximizing Value Using a Digital Product Mindset

『ユーザーストーリーマッピング』の著者Jeff Pattonの講演で、リアルタイムに手書きスライドを作りながらの講演でとてもライブ感がありました。

学び

「アウトカム」と「インパクト」を区別する
- 「アウトカム」とはユーザーがプロダクトを利用することで課題を解決し便益を得ること
- 「インパクト」とはユーザーがプロダクトを利用することで得られる事業成果
「Chooser」と「User」を区別する
- 「Chooser」とはそのプロダクトの導入の意思決定を行う人
  - どうやって選んでもらうかを考える
- 「User」とは実際にプロダクトを利用する人
  - どうやって使ってもらうかを考える

セッション : 実践！ソフトウェアエンジニアリングの価値の計測 ── Effort、Output、Outcome、Impact

speakerdeck.com

Effort、Output、Outcome、Impactを区別しそれぞれを関連付けて計測していくための方法が体系的に整理されていて勉強になりました。

学び

紹介されていた『スプリントゴールで価値を駆動しよう』予約しました！
Effort、Output、Outcome、Impact関連付けを自分のチームでも整理して表現しておきたい

セッション : プロダクトマネージャーこそがリーダーだった！？リーダーシップ論から見るPdMとスクラムのいびつな関係

speakerdeck.com スクラムチームとPdMの関係性に関するセッションでとても興味深かったです。
自分の解釈ではこのセッションで登場するPdMはいわいる事業責任者のようなポジションが近いと思い脳内変換しながら拝聴しました。
POのほうが開発チームに近くPdMは事業全体を見る立場で権限を持っているような関係性です。

学び

PdMとスクラムチームの価値観がどれだけ一致しているかが重要
もし実質的な権限を持つPdMがスクラムチームから遠い場合、間にPOを置き適切に権限を移譲する
PdMは開発チームとばかり向き合っているようであれば不十分で事業全体を見て適切に意思決定し権限を持っている必要があるということでもある

Day3

現場で使える！スプリントプランニング体験ワークショップ

最終日のDay3では「現場で使える！スプリントプランニング体験ワークショップ」に参加してきました。

同時間帯で大規模OSTも開催されていて、どちらに参加しようか悩んだのですが、Day1の飲み会でワークショップの主催である合同会社makigaiの雑賀さんとお話させていただく機会がありこちらに参加しました。

講師2人がプロダクトオーナー、スクラムマスターとなり、ワークショップ参加者は4-5人1チームの開発チームとして実際にスプリントプランニングを体験してみるというワークショップでした。

学び

完了の定義におけるDone / UnDoneの区別と管理
- 本来サービスインまでにはやる必要があるがPBIの完了の定義(DoD)として定義できないものはUnDoneとして管理する
  - ドキュメント、脆弱性診断、ログ出力、CI/CD環境など
- UnDoneはスプリントを回していく中でDoneとして扱えるようにチームで改善活動を行っていく
- UnDoneをDoneとして扱うための作業はテクニカルバックログアイテムとしてプロダクトバックログで管理していく
テクニカルバックログアイテムを消化するタイミング
- 実際問題日々の業務の中でテクニカルバックログアイテムの優先度を上げていくのは難しい
- 監視、CI/CD環境などはできればスクラムチームが組成されるタイミング(Sprint0)で消化しておくのが理想
- またPOが次の開発要件をまとめるディスカバリー期間があることも多いのでそのタイミングでテクニカルバックログアイテムを消化していく
スプリントレビュー
- スプリントレビューの参加者はスプリントゴールに最も関わりの深いステークホルダーを招集すべきで毎回変更しても問題ない
- テクニカルバックログアイテムを消化する場合、スプリントゴールが「CI/CD環境の構築」になるようなケースも有り得るのでそういったケースではSREチームやQAチームがステークホルダーになる場合もある

最後に

今回RSGT2025に参加するにあたり、RSGTのスタッフとして参加されていた弊社エンジニアのミッチーさんの奥様に多大なご協力を頂きました。

自分が1人で初参加だったこともあり、開催前に「RSGTの歩き方」としてRSGTを楽しむためのコツをオンラインレクチャーしていただいたり、Day1では知り合いの方を見つけて一緒にランチに誘っていただきました。

おかけ様で色んな方と名刺交換やXでもつながることができ孤立することなくRSGTを楽しめました。

この場をお借りして改めて感謝の気持ちを申し上げたいと思います。本当にありがとうございました。

初めてカンファレンスに参加するときは誰でも緊張するし中々話しかけられない人もいると思うので、自分もそういった方達を見つけたときに優しく声をかけてみんなが来てよかったと思える世界を作れるように微力ながら協力できればと思いました。

以上になります。
最後まで読んでいただきありがとうございました！