Regional Scrum Gathering Tokyo 2024 Day1 参加記録
こんにちはswampです。
今年もRegional Scrum Gathering Tokyo 2024 に参加してきました。アジャイルマインドあふれる空間で色々な方とお話しできてとても楽しかったです。
3部構成で私がRSGT2023に参加した感想と私が聴講した各セッションの簡単なレポートをお届けできればと思います。
- Regional Scrum Gathering Tokyo 2024 Day1 参加記録 (この記事)
- Regional Scrum Gathering Tokyo 2024 Day2, Day3 参加記録 (近日執筆予定)
- Regional Scrum Gathering Tokyo 2024 に参加してきた話 (全体の感想まとめ、近日執筆予定)
今回はDay1で聴講したセッションのまとめや感想をお届けします。
目次
- 目次
- Dynamic Reteaming, The Art and Wisdom of Changing Teams
- Badプラクティスを選んで失敗しながら進めた新規プロダクト開発
- 【あなたにとって】全員正解クイズ〜相手の価値観を引き出す方法〜【スクラムとは？】
- 証券取引所のサービスをアジャイルに開発し続ける上での学びと取り組み〜信頼性とアジリティの両立を目指して〜
- 仮説→実験→検証→学び...プロダクト開発を前に進めるためにMobius Outcome Deliveryを学び、実践していること
- ベロシティ Deep Dive
- エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜
- Day2, Day3に続く...
Dynamic Reteaming, The Art and Wisdom of Changing Teams
ざっくりとしたまとめ
Dynamic Reteamingに関する話でした。
- 時間がたっても同じチームを維持できるのであれば素晴らしい成果が出るかもしれないが、現実Reteamは頻繁に起こる。
- なぜチームが変わる？
- 成長
- 新しい仕事が生まれる
- ナレッジ共有（冗長性があるなど）
- 新しいもの事を学ぶ
- 衝撃的な出来事（Surprise reasons）
- 新しいリーダーを連れてくるなど
- Dynamic Reteamingの5パターン
- One by One（誰かが入社した、退社した）
- オンボーディング、オフボーディングのサポート
- Work in Pairs（２人で作業することで組織への帰属意識をもたらせることができる。１人ではないのだという形、オンボーディングの効果的）
- Market of Skills Activity
- 自分の自己紹介的なもの（Skill、Hobbies、何学ぶなど）を作って関係性を構築しなおす。お互いの違いを認識できる
- Grow and Split（成長して分割する）
- Merging
- 複数のチームが1つになっていく
- Story of our team activity
- これまでの歴史を共有するために何ができるのか。個人個人が順番に並べる。そのチームに参加した日時と時間を書く。
- どんなことを達成したのかをチームで共有する。
- Lsolation（隔離）
- チームの脇に作る。他のチームと違う仕事をする自由を与える。
- 緊急の問題を解決するため、本番でインシデントがあったら隔離されたチームを作る、新しいプロダクトを作るためになど
- 他チームと隔離されていると集中できる。他チームと同じルールを守る必要がない。
- プロセスの自由を与えることが大事。ただし、何をやっているのかを共有することは大事
- サイロ化は必ずしも悪ではない。
- Switching
- One By Oneと似ているが、知識を広げることややりがいを求めるなどで意図的に人をSwitchingする。
- 知識の重複を共有する。
- 別チームを試すことができるようなプログラムもある。
- One by One（誰かが入社した、退社した）
- リーダーは忍耐を持つことが重要、ただ指示することはできることはできるかもしれないけど変化に皆にオーナーシップを持たせることも必要。オープンにリチーミングすることも重要
- チームをまたぐコミュニティを作ることも大事。リチーミングされたときも初対面ではないというのはハードルが低くなる。
- リチーミングは人のレイヤーにフォーカスして実施することが重要
感想
Reteaingが起こった時にどのように、それぞれの種類ごとに、どのようなパターンでどう振舞っていけばよいのかという部分について知れて勉強になりました。
仕方ない時もあれば、戦略的にReteamingすることもあるのかなと思いますが、普段から横のつながりを持って相互理解をして仕事をしていくことがいざReteamingとなったときも重要なのだと感じました。
QAの中でエンジニア側はスクラムのアジャイルの編成が取れているが、ビジネスサイドは中々チーム編成していくべきかという質問があり、回答として、エンジニアが、ビジネスから遠ざかった形で仕事をしている可能性はあり、ビジネスサイドがどのようなプレッシャーを感じているのか、どうやったらビジネスサイドが成功を収められるかを知り、共感を持ち、団結して手柄を作ることが重要と話されており、印象的でした。 自分たちの考え方を押し付けて、勝手に落胆するのではなく、寄り添って共感を持つこと、互いに相互理解をすることは今後、働いていく中で重要にしたいなと思います。
Badプラクティスを選んで失敗しながら進めた新規プロダクト開発
ざっくりとしたまとめ
- 新規開発では分かっていないことがたくさんあり、開発中にも新しい情報がたくさん入ってくる。前もって決めてもうまくいかないから、Readyを待たない、見積りをしないことで、「分かっていないこと」を解決しながら「新しい情報」にも素早く対応
- 役だったのは全体マップ
- 全体像を把握できたことで、初期の段階からMVPを削ることができた
- チーム作り
- 「良いチームが良いプロダクトを作る」を体現するドリームチーム→技術力×顧客価値
- 初期開発では開発コストを抑えることが重要。むやみに人を入れてオンボーディングコスト、日常のコミュニケーションコストなどを増やさない
- スクラムマスターとして
- チームの置かれた状況に応じてチームの動きを変化させていく
- Readyを待たない・見積りをしない
- 分かっていないことが多かったけど、調査しながら並行して実行
- 新しい情報にも対応しつつ一番早い方法で土台構築
- スプリント内でタスクが終わらない
- タスクを1つずつ終わらせることに重きを置く。毎日のデイリースクラムで今日何をやるべきかを毎朝プランニング
- スプリントと言う区切りよりも今日何をすべきかを大事にした。
- 仕掛中のユーザーストーリーがたくさんあった
- バックエンド開発は2回実装した。
- 実現可能性を早い段階でチェック、全体を見ながら本番レベルの実装ができた
- 進める中で一番意識したこと
- 毎週のスプリントレビューで「動くもの」を見せること！
- 毎週チームで全体マップで現在地を確認できた
- 早い段階でステークホルダーにモックを見せることで早い段階で方針転換
- 再計画
- 計画が常に正しいわけではない
- 現状の延長戦でゴールを考える
- スケジュール見直しは大胆に１回で
- スケジュールの見直しは何度もやるもんじゃない。
- 計画づくりに時間がかかる
- ステークホルダーへの説明コスト
- スケジュールの見直しは何度もやるもんじゃない。
- スケジュールの見直しに必要な条件
- やらなければいけないことが全て洗い出せているか。
- チームのベロシティが安定しているか。
- チームの危機感は十分に上がっているか。
- 再計画づくり
- 全体マップを眺めながら、ストーリーの洗い出し・確認
- 三点見積法（楽観値、最頻値、悲観値）により、機能開発の着地点を算出
- リリース準備期間も含めて１か月のバッファを取る
- リリース予定日の肌間のすりあわせ
- ステークホルダーへの説明
感想
今後、新規開発に携わる可能性もあり、興味深く拝聴しました。
プロダクトの全体像を俯瞰してみることができる全体マップはとても有用そうに感じたので、是非取り入れてみたいです。
Badプラクティスと呼ばれている手法を使ったとしても、毎週のスプリントレビューで「動くもの」を見せることができている点が非常に重要な点であると感じました。やはり動くものができればステークホルダーが開発チームに信頼感を持てるポイントではないかと思います。
一方で、経験、技術力、コミュニケーション能力が高い開発者が2人が集まったことが功を奏している部分も感じました。自組織では、自分も含め若いエンジニアが大半なのでこの講演の内容をどう応用していけるかは考えていかないとなと感じました。
【あなたにとって】全員正解クイズ〜相手の価値観を引き出す方法〜【スクラムとは？】
感想
質問する人が「これは全員正解クイズです。何を答えても間違いではないです」と相手にしっかりと伝えましょう。回答者が答えたら「正解！！！」と言うということで価値観を引き出す全員正解クイズの紹介でした。
「あなたにとってスクラムとは？」という一見答えずらい問いについて、必ず「正解！！！」とすることによって心理的負荷を下げた状態での質問は、実際に答えてみて確かに答えやすいなと感じました。
人それぞれの価値観を測るような質問をする場合には使ってみたいです。
証券取引所のサービスをアジャイルに開発し続ける上での学びと取り組み〜信頼性とアジリティの両立を目指して〜
ざっくりとしたまとめ
高い信頼性が必要な機関投資家向けのサービス開発（受託開発）で試行錯誤しながら開発を進めていったケースの講演
未知のユーザへのサービス提供のため適切な要件が分からないという課題感の解決のため、リーンスタットアップアジャイル開発を採用
リーンスタートアップアジャイル開発は、ユーザに対する仮説検証をくりかえしながらアジリティをもってプロダクトを開発し続けるリーンXPをバランスチームの中で実践すること。
これを実現するために、価値探索と価値検証のサイクルを経てニーズが確認できたものから開発するユーザ中心設計や重視すること。受託開発ではあるが、受託元の企業のメンバーも開発チームに入ることで、会社の垣根なくフラットな関係性で頻繁なコラボレーションを行うことを重視されている
以下のような学びがあった
- 信頼性とアジリティの両立
- ユーザにとって意図しない取引が発生することがこのプロダクトで最も防ぎたいこと
- それをチームの共通認識として持ち、品質担保の活動を絶対に守るべき部分に部分的に強化して手厚く実施している
- 部分的な強化をすることでアジリティを確保した品質保証の取り組みを実施している
- 大規模開発への対応
- 大きな機能に集中して長期間新規リリースができなかった経験から、大きな機能と並行して小さな機能をリリースし続けることが重要と認識した。
- そのために、FeatureブランチからFeatureフラグに変更、UX改善につながる小さなストーリーを毎月リリースするなどの工夫をした。
- 小さな機能でもユーザに価値を提供し続けることで営業やリサーチのきっかけにもつながった。
- チームイベントの継続的な改善
- チームメンバーの変化などでチームイベントに対する考え方が変わることでレトロスペクティブなどが形骸化するなどの影響
- 定期的にイベント自体を振り返る活動をすることで、プロダクトやチームを取り巻く環境の変化に適応することができた
感想
受託開発かつ品質や信頼性を強く要求されるプロダクトにおけるアジャイル開発の一例で印象に残りました。そのような状況の中でも信頼性の向上やユーザに価値を提供し続けること、アジャイルやスクラム自体の改善を両立して進めることができるのは強みだと感じました。リサーチを通してユーザ価値検証を実施している点や顧客と同じ空間で協調しながら進められて点は羨ましかったです。品質に関しては自分のプロジェクトでも課題になっているので、発表にあったような品質担保活動は参考にしたいです。
仮説→実験→検証→学び...プロダクト開発を前に進めるためにMobius Outcome Deliveryを学び、実践していること
感想
Mobius Navigator 初めて知りました。
普段やっている開発が、点になってつながっていないのではないか、学びを将来に生かせられていないのではないか、どこがボトルネックになっているのかが特定できていない、やったことがチーム内に閉じていて知見をチーム間で活かせていないのではないかという問いには心当たりも大きかったです。Mobius Navigatorもう少し自分でも学習して取り入れられるところからはじめてみたい。
ただフレームワークを取り入れるだけでなく、「仲間とやること」、「細かく検査と適応すること」、「やってもらうのではなく一緒にやること」を意識されていることは、どんな施策を実施するにしても意識が必要ではないかと強く感じました。
ベロシティ Deep Dive
感想
ベロシティを生産性の指標にしたり、報告したり、評価に使ったりするのは無意味。あくまでスクラムチームのために使うものだということが強く伝わってくる講演でした。
私自身も生産性と言う軸で見ていたり、数字の上下に一喜一憂したり、目標ベロシティを設定して、届いていないことを問題とみなしていたような気もするので反省しなければなと感じました。
そもそも、アジャイルやスクラムが目指すのはプロダクトの生み出す価値（アウトカムやインパクト）であるため、「付加価値生産性」を重視する必要である。ベロシティという物的生産性が高いだけでは意味がないということは、うまく言語化できていない部分だったのでなるほどなと感じました。
ベロシティというプロダクトの価値を生まない数字を作るよりも、プロダクトの価値を最大化することがアジャイル/スクラムの本質ということを意識してうまくベロシティを使ってチーム自身の予測と改善に役立てていきたいです。
エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜
ざっくりとしたまとめ
- お金や資本 VS ヒトやチームを取り上げる
- 「超一流」の研究 (Ecpert on Experts)
- 天賦の才能はない
- 共通していること
- 10000時間以上、夢中で没頭している
- 限界的練習を続けている
- 新しい方式を学ぶ続けフィードバックを受けている
- 一流エンジニア組織に必要な環境を整えることが経営
- 「夢中」の研究（エモさ）
- 長期にわたって活躍できる人は、内発的動機が強くシンプルな人
- 夢中だからエモく没頭する！没頭するから上達する
- 夢中でエモいやつの特徴
- 外発的動機を長期的に凌ぐ
- 圧倒的な没頭力で熟達する
- ココロが健康、幸せ
- 内発的動機同士惹きつけあう
- 報酬の研究
- アンダーマイニング効果
- 報酬で釣りすぎると内発的動機が毀損する。
- 自発的に行っていた行為に報酬を与え続けると、仕事の目的がやりがいから報酬になる
- エンハンシング効果
- 機械的なルーチン作業にきわめて有効。報酬の1回目は有効
- アンダーマイニング効果
- お金や資本で支配した気になっている経営陣が言う「報酬制度」ってエモさを壊しかねない劇薬！「会社は伸びるが現場は不幸」なのが過去のダサい経営
- 夢中な人の最高な報酬はエモい仲間と価値ある仕事。そして自身の成長！
- 成長の研究
- 記憶力と年齢の関係
- 「夢中」を維持すれば何歳でも成長できる！新技術もビジネスもマスターできる
- 勉強方法の研究
- アウトプットすることが最も重要
- フルスイングを技術を社会実装する。ビジネス側に全力で投げ込む
- 外とのつながり「外部」へ発信する。異なる人へのアウトプット+フィードバック
- 良質なアウトプットがエモさを維持する。エモさ最高
- ビジネス側はお金が全てなの？
- ビジネス側とは数字ばかり聞くから、お金の話になってしまう。
- 外発的動機っぽい匂いがする
- ビジネス側にもエモい事を聞こう！
- 何が好きですか、どれだけ好きですか？
- デジタルビジネスの先にエモい「魂」がある
- オタク同士感動できる。ビジネス側ともエモくつながれる。どちらも本気で真剣！！
- 技術屋はビジネスサイドに合わせすぎ。エモさを共有することが必要
- エモいエンジニア組織の経営：カネ中心からヒト中心にシフトする！！！
- 資本市場を意識せず、内発的動機を邪魔させない環境を撤廃、売り上げ目標撤廃、営業組織廃止、顧客満足絶対、エモい仕事のみ受注する…
- ヒトも売り上げ/利益も着実に上がる
- エンジニアこそがビジネス側に飛び込もう！
- スクラムマスター的な人はここのかけわたしをする
- 数字に従属せずに本気にエモく生きよう！
感想
エモい発表で自分も頑張らなきゃなと思う発表でした。
超一流、夢中、報酬、勉強方法、成長のそれぞれの研究結果をもとにエンジニア組織を経営していくための理論を探求されており非常に興味深かったです。
特に印象に残ったのはエビングハウスの忘却曲線が20代と60代で大して変わらないということです。結局は何歳になっても夢中を維持することができれば新しいことに挑戦して成長できるのかと思いました。
最近、ただ漫然と仕事や生活をこなしていて、夢中になって本気で何かをするという機会は少なくなってきている実感があります。ビジネス側の人とも強調して、もっと夢中で本気にプロダクト、プロジェクトに向き合って成長していきたいと感じました。ワクワクして生活、仕事していきたい！
そのためには色々なことに興味をもって勉強することも大事です。それだけではなくまずは、RSGTのブログを書くなど何でもいいからアウトプットして自分のものにしてフィードバックを受けることから始めていきたいです。
