Regional Scrum Gathering℠ Tokyo 2023に初参加した話
こんにちは。swampです。（このブログもずいぶん放置していました。）
記事を書くのが随分遅くなってしまいましたが、2023年1月11日～13日に開催された『Regional Scrum Gathering℠ Tokyo 2023』（以下RSGT2023）に初参加しました。アジャイルマインドあふれた空間でとても楽しかったです。
この記事では、私がRSGT2023に参加した感想と私が聴講した各セッションの簡単なレポートをお届けできればと思います。
目次
- 目次
- 全体的な感想
- Five Practices for Building Software with Scrum
- 三歩進んで二歩下がるスクラム〜一歩ずつ変化する開発組織〜
- Effective Retrospective++～楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ～
- スプリントレビュー Deep Live
- どうすれば新しいアイデアが生まれるのか
- The Agilists’ Emerging Superpower and Our Planetary Challenge
- ログの書き方がチームの生産性を爆上げする話
- 自治体DXにアジャイルなマインドとスキルはどれほど役立つのか
- 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法
- The Stable Team - 機能する安定したチームをつくる -
- なぜ変化を起こすのが難しいのか？ - 数年以上に渡って難しさに向き合い考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
- 最後に
全体的な感想
各セッションのレポートはとても長くなりそうなので、先に全体的な感想を書いておきます。 今回初めてRSGT2023に初参加させていただきました。オフラインで数百人超の大型カンファレンスに参加するのも久しぶりで前日から非常にワクワクしていました。どのセッションも大変勉強になるものばかりで、明日から業務に生かしたいと思えるものも複数ありました。また、普段社外でスクラム開発を実践している方とお話する機会はないので、色々な方とコミュニケーションをとれて楽しく学びになりました。
初参加なので知り合いがいるわけでもなく、楽しめるかなと少し不安でしたが、オープニングでPACMAN Ruleが紹介されるなど初めての人にもウェルカムな雰囲気を感じました。 実際に1日目のランチを一人で食べていたときに話しかけてくださった方がいらっしゃり楽しく様々なお話をすることができました。 また、スポンサーブースの方々とも普段それぞれの企業でどうやってスクラム開発を進めているのかといったお話などざっくばらんに様々なお話ができて楽しかったです。 いくつかのセッションで周りの人と話して感想や思っていることを共有してみるという機会もあり、強制的に周りの人とコミュニケーションを取る機会があったのも、あまり積極的な方ではない私にとってはありがたかったです。 ここまでコミュニケーションが取りやすいなと感じたカンファレンスは初めてでした。
RSGT2023を通して、様々な業種、観点からお話をお聞きすることができたのが普段できない経験でした。普段知りえないこともプラクティスを多く知ることができました。また、皆さん強いアジャイルマインドを持っていて共感することばかりでした。
顧客に価値のあるプロダクトをどう考えていくのか。プロダクトを自分事としてとらえて、どうやったら価値のあるプロダクトを自分自身も楽しくパワーを持って生み出せるのか。価値あるプロダクトを作るチームにするにはどうすればいいのか、そういったことを考えさせられる3日でした。
セッションで話されたことだけが正解ではないと思いますが、セッションを聞いたことによって実際に議論したり実践したりする良いきっかけになったと思います。
そして、終わった後、むっちゃワクワクしていて、すぐに色々なことを実践してみたいなと学んだことを感じました。 誰も知り合いもおらず、RSGTに参加するのも少し怖かったですが、勇気を出してコンフォートゾーンを飛び出したからこそ得られた学びや楽しさだったかなと思います。
ここで学んだことを少しずつでも私の周りにも広げていきたいです！
次の章からは私が実際に聴講したセッションについて簡単にレポートしてみたいと思います。
Five Practices for Building Software with Scrum
Five Practices for Building Software with Scrum（スクラムでソフトウェアを構築するための5つのプラクティス）という題目でTo Be AgaileのDavid Bernsteinさんよりお話いただきました。
ソフトウェア開発のプロジェクトの中で成功するのは3つに1つで更に作った機能のうち43％は使われない。更にスクラムを成功させているプロジェクトチームはとても少ないという頭出しからスタートしました。
そんな中でスクラムでソフトウェアを構築するために必要な、5つのプラクティス（継続的な統合、コラボレーション、CLEANなコードを書くこと、TEST First、レガシーコードのリファクタリング）を紹介いただきました。
継続的な統合という面では、CI Serverが常に稼働状態であることは非常に重要ということでした。「アジャイルで最も重要なのはCIサーバからのフィードバック」という言葉は印象的でした。 また、Doneの定義には以下の3種類があるという概念も初めて知り勉強になりました。
- 機能が開発者のコンピュータ上で動く＝Done
- 機能がBuildに統合されている＝Done-Done
- 開発者のマシンで機能、ビルドに統合、保守できる＝Done-Done-Done
自分が関わっているプロジェクトではDoneの定義すら怪しいですが、Done-Done-Doneといった状態になるようにしていきたいです。
コラボレーションという面ではXP（エクストリームプログラミング）やペアプログラミング、バディプログラミング（初めて知った）、モブプログラミングが紹介されました。チームメンバーが機能横断的であるべきであり、ペアリングやモブはチーム全体に学びを増やすことにつながります。一番良い学びは他の人に教えることです。「常にだれかをメンタリングし誰かのメンタリングを受けなさい。」という言葉は印象に残りました。
CLEANなコードを書くという面では、以下の5つのポイントが重要で良いコードの核となるということでした。意識できていない項目も多いので気を付けなければと感じました。
- Cohesive (凝集性が高い)
- 1つのコードは1つのことしかしない
- Loosely Coupled（疎結合）
- Encapsulated（カプセル化）
- 隠すことができればできるほど後で壊さずにできる。
- どのようにやるのかを隠したい。見せるのは何をやるのか。
- Assertive（断定的）
- オブジェクトの状態は自分自身で管理すべき
- Non-Redundant（冗長ではない）
- Dupulicationが最も顕著
- コードが同じでなくても冗長は冗長
- 同じことを別の場所でやろうとすると冗長
- Dupulicationが最も顕著
まずはテストを書くという面では、TDD（テスト駆動開発）の重要性について再認識できました。TDDのポイントはその機能の「ふるまい」を作っていくことで、テストコードを書くことによってどのようなふるまいをさせたいのかということを意識して書くことがポイントで、それによりドキュメントの数も減るということでした。良いテストを書くことがアジャイルの本質という言葉にも合った通りTDDは非常に重要だと感じました。自チームもテストに感染していけるように改善していきたいなと感じました。
レガシーコードのリファクタリングという面ではリファクタリングの重要性やそのテクニック（テストの固定化、システムのストラングリング、ブランチの抽象化）をご紹介くださいました。一度作ったら終わりではなく、継続的に改修していかなければいけません。技術的負債をなるべく「リボ払い」しないようにプロジェクトを進めたいとかんじました。
真のアジャイル精神はアジャイルマニュフェストの第1原則にあるとおり「顧客満足を最優先にして価値のあるソフトウェアを早く継続的に提供する。」ことです。このセッションでご紹介いただいたプラクティスをうまくチームに適応できるように施策を進めていきたいなと思いました。
三歩進んで二歩下がるスクラム〜一歩ずつ変化する開発組織〜
株式会社カオナビさんのスポンサーセッションでした。 カオナビでのスクラム開発の紆余曲折をお聞きすることができました。文字通り三歩進んで二歩下がりながらも一歩ずつ変化していく様子をお聞きできて参考になりました。 「スクラムのWhy」に関心が生まれないチームになっていたという点では、アウトプットのティーチングばかりしていた。学びの過程にある気づきを還元できていなかったというお話がありました。私も自チームのスクラムを振り返った時にスクラムマスターとして学びの過程にある気づきをチームに還元できているのかと言われると自信がないのでこれは意識していかなければと思いました。 機械化されたスクラムという点ではマニュアルを量産して機械化してしまったという部分も印象的でした。 私もクロスファンクショナルなチームを目指して少しずつでも開発組織を変えていけたらなと思いました。 セッションの後、スポンサーブースで色々と情報交換できたのも楽しかったです。ありがとうございました！
Effective Retrospective++～楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ～
NRI 森さんによるふりかえりに関するセッションでした。いつも「ふりかえりカタログ」や「ふりかえりガイドブック」を普段から活用させていただいており、森さんのお話を直接聞けるということで非常に楽しみなセッションの一つでした。
ふりかえりの目的という部分が印象的でした。様々な書籍を引用し、一口にふりかえりといってもそれぞれの書籍ごとに色が違うことに驚きました。 特に『エッセンシャルスクラム』にあるクマのプーさんからの引用が、私の胸に刺さりました。
そうら、クマくんが、二階からおりてきますよ。バタン・バタン・バタン・バタン 頭を階段にぶつけながら、クリストファー・ロビンのあとについてね。 二階からおりてくるのに、クマくんは、こんなおりかたっきり知らないのです。 もっとも、ときには、かんがえることもあるのです。このバタン・バタンをちょっとやめて、かんがえてみさえしたら、ほんとは、またべつなおりかたがあるんじゃないかな・・・とね。それから、いややっぱり、そんなおりかた、ないのかな、とも思ってしまうのです。 ー－『クマのプーさん』（岩波少年文庫、石井桃子訳） スプリントレトロスペクティブはスクラムチームにしばらく「バタン・バタン」とするのをやめて、考える機会を与えるものである。
クマのプーさんができなかった「一度立ち止まって考える機会を作ること」をスプリントレトロスペクティブで大事だということがすっと頭の中に入ってきました。 早速、RSGT後のレトロスペクティブのチェックインでこの話を紹介してみました。非常に受けもよく、チームで「一度立ち止まって考える機会を作ること」の意義を再確認でき、これからクマのプーさんのようにならないためにはどうすればいいか考えることができたのは非常に良かったなと思いました。
それ以外にも様々な観点で目的をとらえることができよい機会となりました。 まずは「立ち止まる」ことから始めていければよいなと思いました。
ふりかえりの7ステップについてもご紹介いただきました。このステップが全てではないことはわかっていますが、自チームのレトロスペクティブはあまりこの型にはめられていないという面もあるので1回このステップを忠実に守って実施してもいいのではないかとは感じました。特にStep6 ふりかえりをカイゼンする。Step 7 アクションを実行するというのはできていないことが多いので実施しなければと思いました。アクションを作ったら即時実行。後回しにせずにチームのパフォーマンス向上につなげようという言葉はチーム全体で共有して肝に銘じたいです。
ふりかえりの成長段階とよくある悩みについても取り上げられ、QAを読むだけでも非常に参考になるものばかりでした。特にアクションがだせないことがあり不安という問いに対して、話が盛り上がりすぎてアクションが出なかったは大丈夫であり、共通の話題・問題について話し合いをしたという行為がチームに新たな行動をもたらすという部分は印象的でした。
私は、レトロスペクティブでは必ず次につながるアクションを出さなければいけない（上長からも強く求められている）と思っていたので、必ずしも継続的にチームのパフォーマンスを向上させる場として、ふりかえりを最大限活用してよい。チームビルディングする時間がないのであればふりかえりのなかでやってもよいという話を聞いて、チームをよくするために自分なりに工夫してレトロスペクティブを進めていきたいなと思いました。
スプリントレビュー Deep Live
スプリントレビューを深堀りしたセッションでした。私自身も顧客と協調した意味のあるスプリントレビューをしたいなと常日頃から思っているのですがただの成果物披露になってしまっているという悩みがありました。このセッションでスプリントレビューについて深堀りしていくにつれて、できていない部分がまだまだ多いなと感じ、見つめなおしていかなければと思いました。
ステークホルダーには影響度合いや関心度合いに違いがあるので、スプリントレビューに呼ぶ頻度や時期、参加の必要性も異なることやプランニングでスプリントゴールが決まった段階で誰を呼ぶか決めるという点、プロダクトオーナーがスプリントレビューをリードすべき（POはレビュワーではない）、スプリントでやったことではなく達成したことをレビューする、デモに使うデータは中途半端ではならない、ステークホルダーへの質問を事前に用意しておくなどが特に印象に残りました。
スプリントレビューはスクラムチームとステークホルダーのワーキングセッションでです。顧客の価値を最大化できる一方的でないスプリントレビューを目指していきたいなと思いました。
どうすれば新しいアイデアが生まれるのか
「どうすれば新しいアイデアが生まれるのか」ということでおもちゃクリエイターの高橋さんからのセッションでした。RSGTでおもちゃクリエイターのお話を伺うことができるとは思っていなかったので楽しみにしていたセッションの一つでした。
新しいアイデアは、現時点で満たされていない人の欲求を満たすアイデアであり、新しいもの、ここにしかないものは実行者や顧客を行動させます。そしてものづくり、製品開発においてはまず「自分」あるいは「身近な大切な人」がユーザーとして欲しいプロダクト、サービスを生み出すことが重要です。自分事としたときには、なんとしても実現してやろうという行動力が違うというのはなるほどと思いました。
日々のプロダクト開発でもいかに「顧客に価値のあるプロダクト」を生み出すかというところを意識して日々スクラム開発を回していますが、もし自分が使うのだったらどう思うだろうという観点は非常に重要だと思いました。色々な業態のプロダクト開発があるので、中々難しいなと思いつつも、自分事にするというのはチームにも伝搬させていきたいなと思いました。
アイデア発想法の一つとして「お題の拡大解釈できないが一度考えてみる。（ある事象の的を大きくしてみること）」ということをご紹介くださいました。スプリントレトロスペクティブでもスクラムのカイゼンのためのアイデアを出しますが、ある問題だけに注目して議論していることも多々あったなと感じました。的を広げてみるというのも実践してみたいと感じました。
高橋さんは、アイデアを実現する行動力を出すために、「遊びにすること」ということを挙げていらっしゃいました。ゆとりをもって楽しんで仕事をすることで良いプロダクトを生み出せるのかなと感じたので楽しくわくわくして仕事ができるチームを作りたいなと思いました。
The Agilists’ Emerging Superpower and Our Planetary Challenge
組織が機械のようであった時代から今は熱帯雨林にとらえられるようになったという頭出しから全体通して非常にエモーショナルなセッションでした。
印象的だった言葉をいくつかご紹介します。
- アジャイルはVUCA時代に対応していくものである。
- Volatility（変動性）・Uncertainty（不確実性）・Complexity（複雑性）・Ambiguity（曖昧性）のことを指しています。一言で言えば、先行きが不透明で将来が見通せないということらしいです。
- アジャイルは変化を代謝する。変化を受け入れる、歓迎する、楽しむことで、私たちのスキルで栄養に変えていく。
- 変化を代謝して私たちのスキルで栄養に変えていくというのはなるほどなと思いました。
- これまではマネージャーが意思決定していたが、これからはチームが意思決定しなければならない。素早く失敗して学んでいく
- チームが意思決定しなければならないという考え方は重要だと感じました。
- Change Edge
- edge theory modelをご紹介いただきました。現在から変化を起こすためには、三角形の頂点であるEdgeを越えなければならない。
- 我々がEdgeを超えるためには会話が重要。会話から何を生み出したいのか、意図や目的を明確にし（Innner work）、それから実際に話す練習をしてみること (Outer Work)を実施し会話に対してしっかりとした準備をすることで会話のスキルを上げていくことが重要
- 私も思いついたことを思いついたまま話し相手に意図が伝わらないことが多々あるので、会話の結果、相手にどうしてほしいのか、自分は何を成し遂げたいのかといったところを準備して望まないとなと思いました。それはアジャイルチームをChange Edgeさせるためにも重要だと感じました。
英語のセッションを日本語同時翻訳でお聞きしたのですが、やっぱり英語で聞けるようになりたいなと思いました。感情に語り掛けるような内容が多かったので、抑揚などが全く分からなくなって意味が取れないみたいなことや、日本語には訳しにくいような概念も理解できるようになりたいなと思いました。正直完全に意図を咀嚼できている気がしないので、英語できるようになりたいと強く感じました。
ログの書き方がチームの生産性を爆上げする話
www.slideshare.net
マイクロソフトの牛尾さんによるログの重要性に関するセッションでした。
ログは、開発環境・本番環境の問題解決、システムの振る舞いの観察・理解、ログを活用して生産性を爆上げするために重要とのことでした。ログは第三者がログを使う場面と目的を想定し、対象者が目的を達成できるような情報を提供することが重要です。 特に自動化を前提にログを書くという言葉は意識しなければなと思いました。自動化を前提に書いておけば自動的な復旧もログを活用することで実行できます。
今関わっているシステムでも、ログが分かりにくくなってインシデント調査が難航するなんてことも頻発しているのでご紹介いただいたベストプラクティスも参考にしながらログをより良いものにしていきたいと感じました。まずは、トレースIDを付与するところから始めたい。
自治体DXにアジャイルなマインドとスキルはどれほど役立つのか
福井県CDO補佐官の岡島さんから、自治体のDX支援の経験がアジャイル実務や培った経験がどう役立っているかについてお話いただきました。
特にPOの経験や学びから生きている「ツボ探求力」では、システムのレバレッジポイント（介入点）をつかむ力が重要で、まずは「情報の流れ」に注目し、情報の流れをよくする施策をとって自己組織化を進めようとしていました。フェーズによってフォーカスするポイントを変えていくということも重要だということでした。その他にも右腕力や民間活力が自治体DXの活用では重要で、どれもこれまでのアジャイル開発の経験を応用して取り込んでいけているということで興味深い話でした。
最後にお話しされた、組織の中から「変革遺伝子」を浸透させようという話も印象的でした。私たちは、生体内のミトコンドリアのように、組織の成長のために形骸化した習慣を打破し、自分らしさを保ちつつワンチームで事に当たることを意識して日々のプロダクト開発もできたらよいなと思いました。
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法
プロダクト開発が進んでいけば、どうしても考える人と作る人が別になってしまい分業や経験のギャップが生まれ、プロダクトマネージャーと開発者が分断していきます。そちらの方が効率がよく心地よいですが、スケールしていったときにコミュニケーションがとれなくなるなど、ソフトウェア開発は上達したがプロダクト開発に失敗した状態になっています。それを防ぐためにプロダクトマネジメントが当たり前になるチームを作ろうというお話でした。
プロダクトは「より価値の高い問題」（What）を解消し、その「解決の質の高さ」（How）を高めていく必要があります。この順番が逆であれば、いくら質のよいものを作っても問題解決にはなっていないので品質の高い売れ残りになってしまいます。私もカッコよさから見た目を重視したいなと思うこともあるのですが、やはり顧客の目線にたつといかに顧客の問題を解決するかが一番重要だと再認識できました。そのうえで「はやい・やすい・うまい」を目指していかなければなと思いました。
プロダクトの成長を加速させるためにもプロダクトマネージャーがボトルネックになってはいけません。特定の個人に依存すると問題の解決に間に合いません。しかし、安易に分業して手抜きでプロダクトバックログを量産してしまうとチームがくずされ「私考える人、あなた作業する人」になってしまいます。そうならないためにプロダクトマネジメントが当たり前になるチームを目指していく必要があります。そのためには経験が必要です。説明責任の機会、育成と人脈の機会、意思決定の機会が必要です。特に説明責任の機会（顧客と直接話す、役員にプロダクトの話をしている、他の部署の人たちと自分から話す）という部分はできていないなと感じています。顧客と話すことをチームに移譲せず、私や上長ばかりが話している気がします。別の講演を聞いていても感じましたが、顧客に話す機会を作ることでチームメンバーにプロダクトを自分事としてとらえてもらえるのではないかなと感じました。
具体的な施策としてモブプロダクトマネジメントやプロダクトさんぽ、ウィークリープロダクト道場をご紹介いただきました。そういった機会を増やしていったときに「ぼくは本当にプロダクトを作りたいのだろうか」という問いにたどり着きます。そこからがプロダクト開発チームのはじまりということなので、まずはここを目指せるようなチームにしていかなければなと感じました。
The Stable Team - 機能する安定したチームをつくる -
一口に機能する安定したチームと言いますが、安定したチームとは何なのかということから、ただ実際には流動的なチームが必要になるという現状があります。そんな制限のある中機能する安定したチームを実装していくためにはどうすればよいのかという話でした。
チームが高いパフォーマンスを維持していくには様々な分野における経験値を積むことや安定性が重要です。しかしながら、様々な環境要因や組織的な判断から完全にメンバーを固定化することは難しいため流動的なチームとなることもあります。ただし、Dynamic Reteamingという考え方などのようにあえて流動的なチームに挑戦するという事例もあるようです。流動的なチームは、安定したチームを否定するものなのかと今まで考えていたので勉強になりました。ただし安定したチームが高いパフォーマンスを発揮できない組織では流動的なチームで成功する可能性はほぼないということでした。
人の移動を減らすだけで安定したチームを作れるのであれば簡単ですが、機能する安定したチームはそれだけでは実現しません。（事実3年を超えたチームはパフォーマンスが悪くなるという結果も出ている。）
機能する安定したチームとは、チームに起こる逃れることのできない様々な変化が起きてもパフォーマンスが発揮できる状態にすぐに回復できるレジリエンスがチームに備わっていること重要です。この動的平衡なチームが機能する安定したチームと言えるとのことでした。
そんなチームのレジリエンス力を高めるためにモブプログラミングでSECIモデルを回したり、YOW（やったこと、起きたこと、わかったこと）を考えていくことが重要です。モブプロで同じ体験をする時間を増やし、個人個人が同じ体験からなにを感じ取り、どのようなアクションをしてそこからなにを学んだのかをチームで共有するそうすることで、表出化（暗黙知⇒形式知）につながります。
最近モブプログラミングする機会が少なくなっているのでやっぱりSECIモデルを回して機能する安定したチームを目指すためにもそういった機会はスクラムマスターとして増やさなければなと思いました。
なぜ変化を起こすのが難しいのか？ - 数年以上に渡って難しさに向き合い考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
NTTコミュニケーションズの岩瀬さんより、組織内での変化を起こすための考え方やプラクティスについて、そして岩瀬さん自身が組織を変えるために実践してきたことをご紹介いただきました。
組織には技術負債と同様に組織的負債があり、それを返済していく＝組織を変化させることには非常に時間がかかります。そんな中で変化を起こすためのプラクティスとして、システム思考、プロダクトマネジメント、目標設定とメトリクス、人を巻き込む方法をご紹介くださいました。
システム思考はレバレッジポイントを意識してシステム系のどこを変えていけばいいのか探ることが重要です。プロダクトマネジメントは、「誰の」「何を」解決するのか？を意識すること。下手に多くの人を狙うのではなくターゲットは絞ることが重要ということは学びになりました。
目標設定とメトリクスでは「たどり着きたい目標の状態」、「現在のベースライン」、「現在のトレンド（現在のベロシティを表している）」、「時間の区切り」を組み合わせたものにすることでできるだけ定量的に決めることが重要です。また、ベースラインのメトリクスを含めた相殺目標を設定することより、解決策を絞り込んだ目標を設定することができるということでした。 よくレトロスペクティブなどでもSMARTな目標をたてることが重要と言いますが、上記のようなポイントをもって長期的でも短期的でも目標を立てられるとよいなと思いました。自分自身の目標やチーム目標、次のスプリントのゴールなど様々な部分で応用できたら良いなと感じました。
また、KPIの定量値はハックできる前提で自分たちのために使おうというのは印象的でした。
それらを人に巻き込み広げていく方法として、アイデアを組織に広めるための48のパターンの内容や説得戦略の6モードを知っておくことを紹介いただきました。特に相手を説得するときは相手に対してもメリットを提示しないと上手くいかないよというお話はその通りだなと思いました。
また、岩瀬さん自身の経験も大変興味深いものでした。と同時に私はまだまだ組織を変革していくために行動できていないなと感じました。より良い形でアジャイルマインドを組織に広げていくためにも、コンフォートゾーンを出るとか迷ったらつらい方を選ぶという考え方は大切にしていかなければなと思いました。一歩踏み出して色々な人を巻き込んでいきたい！
最後に
全編通して、普段味わうことができないアジャイルマインドがあふれた雰囲気で非常に楽しいひと時を過ごすことができました。 スポンサー、運営など関わってくださった方々ありがとうございました！来年も是非参加させていただきたいです！
