RSGT2024に参加してきた
今年も参加してきました。RSGT2024(Regional Scrum Gathering Tokyo 2024)
RSGTも今年で4年連続参加。
過去の参加エントリーはこちら
（あれ、RSGT2023書いてなかったっけ..）
気持ちが新鮮なうちに。ということで、考えたいことは色々あるが、
とりあえず、Day2までの視聴したセッションと全体の所感を書きとどめておく。
Dynamic Reteaming, The Art and Wisdom of Changing Teams
チームのエコサイクルに応じて、「Dynamic Reteaming」で紹介されている5つのパターンを適用していく。
新メンバーがジョインしたり、メンバーが離れたりするタイミングが、関係性を再構築するチャンス。
チームや組織が大規模になってくると、意思決定までに時間がかかり、ものごとの進みが遅くなる（rigidity trap）は、思い当たる部分があった。
大事なのは、単にパターンを押し付けるのではなく、組織やチームも人から構成されているので、彼らへの尊敬を忘れてはいけないということ。
Mitsuyuki Shiiba - Badプラクティスを選んで失敗しながら進めた新規プロダクト開発
新規プロダクト開発をやってきた身として、分かることばかりだった。
必ずしも、こうであるべき・こうしなきゃいけない みたいなものではなくて、事業やチームの状況に応じて、”全体マップ” （ユーザーストーリーマッピング）のような仕組みにしていくことが重要だなと。
そして、作るだけじゃなくて、それを運用し続けることも。
Outcomeに向き合う中で出会っている出来事とその解決案
Outcomeは、定量的に評価できないし、直接コントロールできないよなあと昨年のふりかえりで話していたところだった。
よりユーザーに関心をもって知ろうという気持ちと、リリースした後のユーザーに価値を提供できたのか・価値を感じてもらえたのかを意識しようと思えるセッションだった。
証券取引所のサービスをアジャイルに開発し続ける上での学びと取り組み〜信頼性とアジリティの両立を目指して〜
やりたいことだけではなく、どんな事象だけは避けたいのかを意識しながら進めリスク回避重視したのは、証券取引という業界や組織に合わせたいいアプローチだなあと。
一方、プロダクトとしてやりたいこと（外部システム連携など）と並行して、ユーザ獲得のための要件を進める塩梅がやはり難しい。
よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること
コミュニケーションの量と質
”なにかにつけて感想戦” は、商談同席した後とかに、さくっとやったりする。商談同席に限らず、いろんなシーンで使えそう。
チーム間でモブプログラミングを行き来するのは、お互いの思想や文化を理解する上でもやってみようと思えた。
ベロシティ Deep Dive
”生産性” という言葉の胡散臭さは、まさに自分も感じているところだった。 Outputだけ生み出しても、Outcomeに繋がらなければ、それはユーザに使われなかったり、価値だと感じてもらえないものを作り出しているだけ。
「よく計画どおりにいかなかったので、次はもっと正確に..」と陥りがちだが、 正確にやる時間があるなら、プロダクトコードを書いた方がよい。
経験主義なのだから、うまくいかなかったら、次どうしていこうか？を話した方がよい。
"数字あそびしてるんじゃない" いい言葉だ。
Solving The Value Equation
”価値” という言葉がひとり歩きしだすと、人によってイメージが異なる場合があるので、 言葉にふりまわされずに、自分たちの組織やチームに合わせて、自分たちの言葉で定義していく必要があるなと。
Ryuzeeさんのセッションにも登場した、Effort → Output → Outcome → Impact の話。 計測そのものが目標となってしまう（goodhart's law）
一例だが、コードを書いた量（Output）より、顧客に価値を感じてもらえたかどうか（Outcome）で評価していくとよい。
ただ、Outcomeは定量的に評価がしづらく、一概にコレというのはないので、こちらも "価値" の定義同様、自身が属する組織やチームに合わせて、設定するのがいいんじゃないか というのが今のところの個人的な考え。
「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」カオスなプロダクト開発を効率化したら硬くて息苦しい官僚組織になっちゃった! 大企業病の罠を乗り越え若々しいチームを実現するぞ
新規プロダクトをリリースして、ありがたいことに顧客がついてくると、様々な要望があがってタスクが大量発生する。 すべてのタスクが “緊急” になってしまうのは、よく聞く話なので、客観的に評価できる指標があるといいのだろうなあ。
個人的には、何かやりたいことがあるのであれば、 "その人自身が推し進めていけばよい" スタンスではあるが、専門的な意見を取り入れたいのであれば、周囲はそれに協力的であるといいな。
役割にはとらわれずに、領域侵犯していくのも1つの戦略だったりするのかな。
QAエンジニアってスクラムで何をすればいいの？
弊社でQAエンジニアという職種がないのは、開発エンジニアがテストケースの洗い出しなどまでやっているからかなと思えた。
現場でコードを書いている人が最もプロダクトの解像度が高いと思っているので、漏れているケースや要件に気づくのも含めて、引き続き開発エンジニアがやっていくとよいのだろうなあ。
ハイコンテクストで、ドメイン知識を要することもありそうなので..
誰のためのスクラム？ - 開発チームに閉じず、全ステークホルダーを巻き込んだスクラム開発 -
内部ステークホルダー（セールス・CS）と、フィードバックしあえる場を用意したという話。 発表の文脈的には、現「（現在）今ってこれできる？」とか、「（将来）どう進めていくとよいだろう？」がなされているようだった。
社内で、フィードバックしあえる場でいうと、弊社でも、DemoDayでやっていたりはするが、もう少し軽めに、相談ごとベースでできるといいのだろうな。
外部ステークホルダーとこういった取り組みをやるとしたら、どうやろうかと考えさせられた。
スクラムとデッドライン、壊れゆくチームをつなぎとめるもの
終始、笑えました。
デッドラインとどう付き合うか。 悪だとばかり思っていたが、デッドラインがもたらす効能についての切り口は、納得だった。（優先順位の判断がしやすいなど）
正論ではなく（それはそうなんだけど）、デッドラインに間に合わない場合の機会損失など深ぼる対話、お互いの歩み寄りが必要なんだなと。 よくよく話してみると、デッドラインなんてものはなかったり、スコープから外せたりする。
大事だと思ったのは、”リリース後の借金返済計画” 。 いろいろメンバーは思うところがありながらも、デッドラインに間に合わせて動いてくれるので、間に合って終わりではないということ。
プロダクトをあきらめるとき
新規プロダクト開発のセッションはあるが、あきらめるときのセッションはあまり聴いたことがなかった。
事業でもプロダクトでも、撤退に必要なこと・やらなければならないことを事前に詳細に準備しておくこと。
PoCで「ダメだったねー、じゃあやめようか」となったときに、撤退しやすいように、 普段から捨てやすい（Disposable）アーキテクチャやコードにしておくとよいのだろうな。（ビジネス的な座組はそうはいかないかもしれないが）
あきらめる判断・意思決定について（やらない判断に通ずる）は、個人的にも考えたい。
全体の所感
今年の参加のモチベーションは、事例・プラクティスうんぬんというよりかは、いろんな人の組織・チームに対する思想・行動原理を知りたかったから。
視聴したセッションの中で3つで登場した、Effort → Output → Outcome → Impact / 開発者の生産性の話 が印象的だった。
私自身の目標設定も、Output（例：機能したリリース数）を追うのではなく、Outcome（例：顧客にどう価値を感じてもらえたのか？）を追うようにしている。
RSGT2024後、さっそく、上長（CEO）と2024年上半期の目標設定で、この話ができて、「Outcomeを定量的に評価するのは難しいし、直接コントロールできない。」「けど、間接的にでもよいから、近い指標ってどんなものがあるんだろうね？」みたいな話ができたのは、良かった。
私の普段のはたらきからしても、そのあたりに責任をもってコミットしていく方が、組織・チームにとっていい方向に進むはず。
この話に限らず、今年も収穫が多かったので、自分たちの組織・チームの言葉だったりやり方に変換して、還元していくぞ !
この記事が気に入ったらサポートをしてみませんか？