RSGT2025参加記録

こんにちは。

BIPROGYで、アジャイルを社内外に広める活動をしている本多です。普段は、スクラムマスターや、社内向けの研修を企画運営しています。どうぞ宜しくお願い致します。

1月に開催された、国内最大級のアジャイルカンファレンスRegional Scrum Gathering 2025（RSGT）に参加しました。RSGTは、他の学習カンファレンスと異なり、独特の熱狂的な雰囲気があります。それを言葉で十分に伝えきるのは難しいですが、本記事では私が得た学びや気づきを中心にレポートします。アジャイルに関わっていて、まだ参加したことのない方は一度参加することをお勧めします。

Day1

基調講演1 James Shore - The Best Product Engineering Org in the World

• 生産性を測定することはできない。Martin FowlerやKent Beckも無理だと言っている
• CEOから生産性の測定を要求された。生産性の測定はできないため、最高の組織に何があるのか1ヵ月考え、6つのカテゴリを定義した。このカテゴリは我々のカテゴリなのでみんなのものとは違う点は注意

1. People
   自分で意思決定できるひと。定義は会社それぞれ。そのような人を育成するために、キャリアラダーを変えた。
2. Internal Quality
   調べたらリソースの15％しか価値提供の作業をしていない。沢山価値提供するために、"無駄"を取り除く。そのためには、Feedbackを早くする、ビルドを早くする（1秒未満がベスト）。リファクタリングはin place（その場）で行うか、変更時に行う。ビックバンやモジュール単位でのリファクタリングは危険。
3. Lovability
   愛されるSW。内部品質が良ければ、余力ができる。MVPは小さいテスト。Eric Evansのメジャーループ「Idea→Build→Code→Measure→Data→Learn→（繰り返し）」を活用する。
   リーダーシップが自分たちで批判できることが大事。
4. Visibility
   約束したものを期限通りに出荷できているのか？プロダクトベースの考えは、プロジェクトベースの考えの人にとっては期限を守らないと捉えられてしまう。なので、日程は伝えずに、期間（2か月～8か月など）で伝える。日付を出さないことは信頼が前提になる。
5. Agility
   技術能力が必要。DesignとCodeを常にクリーンに保つこと。チームトポロジーはチーム編成のやり方だが、サイロ化など問題もある。FASTがおすすめ。FASTは、都度チーム編成を変えるので、サイロ化を防ぐ。
6. Profitability
   事業が続くこと。エンジニアリングとビジネスの成功は相関しない。

Jame Shoreさんの知見をもっと知りたい方は、著書「アート・オブ・アジャイル デベロップメント」をチェックしましょう。

Yasunobu Kawaguchi - 失敗を学びに変えるアジャイルなマインドセット：Linda, Lyssa, Jeff, そしてEmotion Scienceから学ぶ13年間の気づき

• Linda Risingの話
  • MINDSETの話
  • 努力チームは難しい問題を選び、困難なチャレンジを楽しむ。頭脳チームは簡単な問題を選び、困難な課題にはやる気をなくす
  • Fearless Chageの著者でもある
• Lyssa Adkinsの話
  • VUCAに加えて変化が絶え間なく且つ指数関数的に増大している変化の追えない世界になっている
  • WFは安定期のやり方。Agileは変化を受け入れて、私たちは変化できる。安定期のない時代にこそAgile
  • コーチングアジャイルチームスの著者でもある
• Jeff Pattonの話
  • 付箋を書くのがめちゃくちゃ早い！手を動かすのが大事。どんどん書く
  • やらなくて良いことはやらない
  • Day2で基調講演する方
• 任天堂の話
  • 事実と仮説は異なるものだが、混同しがち
• Micael Sahotaの話
  • 感情的なささくれと付き合う
  • ネガティブな感情は断絶を生む。ネガティブな感情は時系列を無視するため、ロジカルに考えられなくなる
  • 新しいアイデアは思考を止めてしまう
  • 考えるときは一晩寝かせる
• Mike Cornの話
  • 「I could be wrong」

Peter Beck / Andreas Schliep - The Project to Product with Scrum Playbook. Bridging the Gap between project and product thinking.

• Scrum Playbookを使って、意思決定を助けることができる
• プロダクトとプロジェクトの違い。プロダクトは作業の結果のこと。プロジェクトは時限のある一時的な取り組み。プロダクト開発の中の一つの活動
• イノベーションゴールを設定する
• 大きな目的をバックログに落とす
• プロジェクトを開始してよいかどうかは、重要な意思決定となる。仕掛が多くなりすぎないようにWIPを検討する
• Return on Enterpriseを考えよう

(所感)Playbookはひとつの方針となりえそう。

Teemu Hyyryläinen - A new innovative way to manage the complexity of a team.

• Entangled（もつれた、ややこしい、絡み合った）をどうマネージするのか？
• 解きほぐしたいが、花に美しく！といっても無駄。組織は複雑
• 3つのステップ
  1. 遠いゴールではなく、今の状況に目を向けて改革する
  2. 大きな変更ではなく、小さく変えていく。ひとつずつパラメータを変えていく
  3. 流れを感じ何が起こるかを察知する（タイミング）
• セオリー
  1. B(振る舞い)=f(P（個性）,E（環境）)環境が振る舞いに影響を与える
  2. 良いことをするエネルギー＞悪いことをするエネルギー　の場合良いことをする。省エネな選択肢を取るのが人間
     • ex 役に立つツール、習慣化、ポリシーにする
  3. 人はコントロールできない。人間の意思決定は権限、コスト、グループアイデンティティ
• 例
  • 現状を理解する
    • 何が含まれている？どんなチーム？構造？所属は？ポリシーは？いつも何している？どんなアイデア？影響を与える人は？　これらをマップにする
  • 何を変えていけるのか？
    • 時間とエネルギーの2軸をとって、現状の要素をプロットする
    • プロットできないものもある。深く知る
  • 計画して実行する
    • 複雑なものは小さく実験する
    • タイミングが重要であり、傾向が決め手となる。因果ではない
    • 反復する

（所感）障害リストの作成や順番決めのプロセスに使えそう

Chris Lucian - Generate Organization-wide Understanding with Cross Discipline Causal Loop Diagramming

• 因果ループ図の話　※図自体についてはこちらを参考にしてください
• 「モデルは正しくないが、役に立つこともある」モデルを作って洞察について話し合う。このことにより気づきが生まれる。自社の事例としては投資の方針が変わった
• 書き方（聞き方）
  • 重要な量は何ですか？
  • その量はどんな影響を及ぼしますか？
  • その量はどんな影響を受けますか？
  • バランスループ、強化ループが見えるか？
  • 遅延はあるか？
  • 線の強さは？
  • システムに影響を与える変数はなにか？
• VSMとの違い
  • VSMではプロセスをリーンにできるが、ループは見えない
• 憶測は書かない。確度の高い事柄を入れる。憶測を書く場合は真実か確認する

（所感）聞き方は有益。使っていきたい。

Day2

基調講演2 Jeff Patton - Maximizing Value Using a Digital Product Mindset

• ほとんどの組織ではプロダクトを理解していない→プロダクトシンキングをしていない
• 価値はどこから生まれるのか？
  • Amazon Fire Phoneの例。作っているひとは売れないことが分かっていたが、Jeffが欲しいから作った。つまり、チームにとっての客はJeffであった。品質は高かったが売れなかった
• 何が価値をもたらすのか？
  • みなさんとユーザーがきめるもの。使い続けてくれて、口コミしてくれるもの
  • 嫌いでも使うケースがある。BtoBでよくある。会社が決めた物。ユーザーの価値と組織の価値と2つある
  • ビジネスニーズが機会を生み、成果物（Output）がユーザー価値（Outcome）を生む、そしてビジネスにImpactを与える
    • この一連がプロダクト。プロジェクトはOutputを作るところだけ
  • ビジネスは客に価値提供をできたのか？
  • ウェイター（注文とって運ぶ(output)）ではなく、ドクター（患者の課題を捉えて結果（outcome）をだす）
• 何がプロダクトか？
  • 全て
  • プロダクトに資金を与える。プロジェクトではない
• 何を測定する？
  • Impact、ビジネスメトリクスは遅行指標
  • ROIではなく、チームKPIやValueを生んでいるのかを見る
  • まずユーザーを気にする
    • 使っているか？使い続けているか？使うまでの期間など
  • 次に、ジャーニーを測る
    • 見つけて、使う判断をする、使ってみる、使い続ける。海賊指標が使える
    • メトリクスはひとつだけ使う。プロダクトの段階でメトリクスを変える

Jeff Pattoneさんの知見をもっと知りたい方は、著書「ユーザーストーリーマッピング」をチェックしましょう。

Angel Diaz-Maroto Alvarez - the LeadershipDancefloor: Mastering Agile Leadership Dynamics

• 椅子は共通の理解を得られるけど、Agile、リーダーシップは、人よって解釈が異なるため、共通フレームを作成した
• 4つの要素がある
  • オペレーション
  • ファイナンス・リーガル
  • マーケットポジション
  • ヒューマンキャピタル
• リーダーシップとはGapに対応する能力
  • 会話に必要なスキル、戦略は？
  • リーダーは誘う。誘われた側が選択する。両社が輝ける空間を作る
  • 4つのスキル
    • 聞く：変化に抵抗するのは情報が不足しているから。彼らの大事なものは？
    • 問う：情報は隠れている
    • 明確にする
    • アンカリング：約束を実行する能力。良い約束をする
  • リレーションシップフレーム
    • 会話（コーチングなど）に先立ち合意をとる。チームの期待・チームへの期待を明確にする。勝手に始めない
  • コンテキスト
    • 何が課題か？で違う回答がでないようにする
    • リーダーはボスにジャンプさせる（※部下への指示ではない）
  • パーパス
    • どんな将来を作りたい？アジャイル導入の目的は？解決することはなに？
  • リーダー
    • 影響を及ぼせる人
    • 道のりに気付く人
    • 説得ではなく、アイデンティティを感じさせるもの
    • リーダで"ある"ことを通じて、選択させ、行動させる
    • マインドセット
      • ジムへトレーニングに行くのは、よりよい結果が生まれる
      • 行かないことでネガティブになることを認識させる
      • 変わらないことのコストを理解させる
      • マインドが変わらないと名前だけが変わる
  • グループ
    • 文化を変えることは解釈を変えること。人はかえられない
    • カオスの状態だと文化が変わる。一時的にカオスにする
• 自分を変えることは難しい

（所感）リーダーシップ理解の解像度を上げられた気がする。
（参考）Angelさんのサイト。研修もやられているそうです。

Michael Ong / Jodie Loi - Cowtopia: Designing Agility Through Playful Innovation

• Cowtopia(カウトピア）というワークショップ
• クネビンフレームワークの混乱を除く4象限それぞれで推奨される行動を実践してみようというもの
• ワークショップのルール
  • 地球を温暖化から守るため牛を火星に送るゲームです
  • 6名のチームに分かれます
  • 1人はキャプテン、1人は牛、1人はハピネス（盛上役）、他はビルダーです
  • チームは牛や、うんち貯蔵庫や、ロボ牛ドクターなど作り火星に送ります
  • 火星に行くためには、ロケットを作り飛び立ちます。その時、うんち棒を光らせます。うんち棒が光っていないと宇宙人につかまり死にます
  • 火星にはお姫様がいます
  • 火星に付くと、歌ったり、踊ったり、事故で死んだりします
  • ルール違反すると死にます（牛なのに喋るなど）
  • 最終的に牛を既定の頭数送り込めれば成功

説明が難しいワークショップで、参加者も分からないまま進みます。

（所感）説明が難しいワークショップで、参加者も分からないまま進みます。今の状況は複雑系？カオス系？などを考え、適切な対応を試みて、結果を受けるという体験ができました。分からない中を何とか理解しながら進むというのがこのゲームの重要なポイントなのでしょう。実際、クネビンフレームワークの理解には有効と感じました。ワークショップとしても面白かったです。
私は牛役だったので、隣チームの牛と「モーモー」言ってました。

公式サイトのようなものを見つけました、興味のあるかたは覗いてみてください。

Day3

Takeshi Kaise / Ryota Saiga - 現場で使える！スプリントプランニング体験ワークショップ

• 講師がプロダクトオーナー役、スクラムマスター役を担い、参加者が6名程度で開発者チームを作り、それぞれスプリントプランニングを進めていくというワークショップ
• 以下学び
  • プロダクトオーナーに聞くことを遠慮しない
  • 明瞭にスプリントゴールをもっていないプロダクトオーナー、プランニングの活動の中でDevとすり合わせながらゴールを決めていく
  • 同じプロダクトオーナーでも、チームが違うと、出来上がるスプリントゴールも、計画もだいぶ変わる
  • 内部品質については最初から高いレベルで作りこむ。そのためにもチームの組成が非常に重要
  • Doneの定義とセットでUndoneの定義もつくる
  • Doneの定義もプランニング中に調整する

Closing Keynote - Hiyoshi Homma ホンダ流「ワイガヤ」のすすめ

• Scrumの源流の1つとされる論文「The New New Product Development Game」by Hirotaka Takeuchi and Ikujiro Nonakaで紹介されているHONDAの事例に携わっていた方の講演
• 源流の源流の話
• CITYの開発物語
  • 1978年、若者ユーザーを取り返す製品を作るという指示が降りてきた
  • スーパーシビックを作ったが、現場ではこんなものに乗らないとよ若手が言っていた
  • 一番若いメンバー（当時28歳の自分）がCITYの企画を提案したが、40~50代の人には理解されなかった
  • 技術者やデザイナーが怒鳴り込んできたが、想いを伝え続けた。ブレてはならないと思った
  • CITYはCMと合わせて大流行した
• ワイガヤとは
  • 集団的な議論を重ね、モノゴトの本質に深くアプローチする為の効果的イノベーション手法で、原点は井戸端会議
    • 上下関係なし。自由になんでも話す。議事録残さない
    • コミュニケーションと「ノリ」
    • 報連相や会議とは別物
    • 異種混合、異論・争論
    • 個人力をアップさせる
    • 想いに昇華させる
    • 知恵の集約→スパイラルアップ
    • わくわく・ドキドキ
    • ワイガヤが変革リーダーシップ（共感型）を育む
• 組織は変わっていく、大きくなると忖度気質になり改善が行われる、良くなっても、また悪くなる。アップダウンの繰り返し
• 分からない人は分からない。ではなく、分からない人でも分かるくらいの超えた発想を作る
• 横にネットワークを拡大して世論を作る。異質と繋がる。トップと繋がる
• 想いと思い込みは違う。自分の考えが想いか思い込みかの判断は、マーケットへ出たときに分かる。自分では判断できない

（所感）Scrumの源流を感じた。ワイガヤはスクラムを組んでいる印象を受ける。異種混合はスクラムで言う、マルチファンクション、マルチラーニングにあたりそう。スパイラルアップはSECIモデルにも関連する。Scrum単純なモノづくりのフレームワークではないことを改めて感じることができた。
スーパーシビックの例は、Jeff Pattonさんの基調講演でのAmazon Fire Phoneと相似している点も面白かった。

全体所感

全体を通じて印象の特に残ったものは、次の2つの前提。

1. B=f(P,E)
   Hyyryläinenさんのセッションで紹介された数式です。B（行動）は、P（個性）E（環境）によって生まれるが、P（個性）を変えることはできないので、E（環境）を変えるというもの。Angelさんの「変わらないことのコスト（Negative Result）を理解させる」にも同様の前提を感じました。
   スクラムマスターの持つべきスキルは、E（環境）をどう整備するというのかという観点に立つと、様々なワークや活動が少し違って見えてきます。
2. 「I could be wrong」
   Kawaguchiさんのセッションで紹介されたフレーズ。間違っているかもしれないという前提に立つというもの。Jamesさんの「リーダーシップが自分たちで批判できることが大事」や、Hommaさんの「想いと思い込みは違う。自分の考えが想いか思い込みかの判断は、マーケットへ出たときに分かる。自分では判断できない」という所にも同じ思想を感じました。

RSGTではありせんが、B=f(P,E)の数式や、「I could be wrong」の話※は、昨年の10月に受講したCertified LeSS Practitioner研修の中で、Craig Larmanさんからも語られていました。
※Craig Larmanさんは「I could be wrong」という表現は使っておらず、より強い表現「We don’t know」や「常に全て私たちが間違っている」で説明していた。

録画を見よう！

ScrumTokyoのYoutubeチャンネルで、数か月後には録画も公開されますので、気になるセッションを視聴してみてください。私がレポートした以外にも沢山のセッションがあります！

We Are Hiring!

BIPROGYでは積極的に採用活動を実施しています。システム開発から企画、スタッフなど募集中です。もちろんアジャイル関連案件もあります。詳細は採用ページをご確認ください。