🏝

スクラムフェス沖縄レポート

2024/12/19に公開

はじめに

これは株式会社TimeTree Advent Calendar 2024 の20日目の記事です。

https://qiita.com/advent-calendar/2024/timetree

TimeTreeの共有カレンダー本部でスクラムマスターをしている@susiyakiです!

普段の業務ではWebフロントのリファクタリングをしつつ、共有カレンダー本部のスクラムマスターとして楽しく働かせてもらっています。
最近はダーツやポケモンカードゲーム(紙のほう)にハマっています。

イベント概要

スクラムフェス沖縄はアジャイルコミュニティの祭典です。

・アジャイル開発をこれから始めようという人
・とりあえずやっているけど、これで良いのか悩んでいる人
・より良いソフトウェア開発・運用のやり方を探している人
・チームや組織の人間関係を良くしたいと思っている人
・アジャイル開発に取り組む仲間が欲しい人

立場の異なる様々な人々が集まり、交流を通してアジャイルについての学びや気づきを得られる場です。この2日間を通じ、参加者同士でスクラムやアジャイルプラクティスについての知識やパッションをシェアするだけでなく、ここで出会ったエキスパートに困りごとを相談することもできます。

(公式サイトから引用)

今回はリモートワーク環境下では実施が難しい体験型のワークショップを体験したい、またOST(オープンスペーステクノロジー)を通じて最近感じている疑問や悩みを深く掘り下げたいと考え、参加を決意しました。

https://www.scrumfestokinawa.org/
https://x.com/scrumOkinawa

イベントで体験したこと

イベント先へ移動

Day1は金曜日の17時開始だったため当日に沖縄まで移動しました。

ランチは沖縄そばをいただきました。

肉が4種類も乗っててボリュームがすごかったです。

それにしても天気がよくて12月とは思えない気温でした。ヒートテックを着ていたのでじっとりと汗をかいていました。

Day1 - オープニング

会場には開始時間の15分前ほどに到着しました。

同じ卓に座った方たちと自己紹介やワクワク感を共有しあっていると早速オープニングが開始しました。

スクラムフェス沖縄は他のスクラムフェスと比較して少し規模が小さく、雰囲気もラフで参加者同士の距離が近い場となっているようです。初めての参加にはうってつけですね!

この2日間でより多くの学びや気づきを得られるように頑張るぞと気合いを入れて臨みます!

↓スクラムフェスの目的

Day1 - ピンポンゲームでスクラム体験ワークショップ

ピンポンゲームでスクラム体験ワークショップ - Scrum Fest Okinawa 2024

まだ会場の雰囲気が固まっているなか、Kawaguchiさんによる1つ目のワークショップが開始しました。

このワークショップの目的は、チームが自ら知って望んてやりたくなるような流れを生むADAPTモデルに則り、「トレーニング・コーチング・コミュニティ」のうち「トレーニング」を体験するというものでした。

まず、スクラムフレームワークに関する「役割・イベント・成果物」などの基礎の説明から始まり、スクラムフレームワークがチームの合意をしやすくするための仕組みであることやチームの暗黙知(だれかなにをできるか)を育むのに有効であることをわかりやすく解説していただきました。

その後、ピンポンゲームのルールが説明されました

ルール

ワークショップのルールを簡単にいうと、

  • 参加者を2チームに分ける
  • ピンポン玉を手渡しでなく同じチームの人に渡す
    • 空中にある時間を作る
  • チーム全員に一巡したピンポン玉の個数をスコアにする

です。

これをスクラムのフレームワークに当てはめて、

  1. スプリント計画(1分)
    1. どのような方法で実施するか考え、いくつ運べるかどうか推測する
    2. 初回の個数は勘で、2回目以降は前回の結果を基に推測する
  2. ワーク(2分)
    1. 実際にやってみる
  3. デモ(1分)
    1. ワーク中にいくつ運べたかをステークホルダー(=運営)へ報告する
  4. ふりかえり(2分)
    1. ワークで出た課題を共有して次どうするか改善アクションを考える

を1スプリントとして実施します。

今回は3スプリントの実施でどのような変化があるかを試してみることになりました。

1スプリント目

チームメンバーは15名で、まだあまり打ち解けていないギクシャクした雰囲気で開始しました。

ひとまず目標は安牌を取って10個に設定。(Kawaguchiさん曰く、「社会人だね。学生向けのときはもっと挑戦的な数字が出ることが多いよ。」とのことで面白いなーと感じました。)

1スプリント目の結果は、目標10個に対して44個と予想を大きく上回りました。ふりかえりでは、想定以上の結果に手応えを感じつつ、以下のような改善点が挙がりました:

  • 複数のピンポン玉を同時に回すことで効率化できる可能性
  • 声出しによるカウントは有効だが、運搬に集中するため最後にまとめて集計する案

チームとしての最初の一歩を踏み出せた実りあるスプリントとなりました。

2スプリント目

2スプリント目では、チームの手応えと改善案を踏まえ、1スプリント目の実績44個から大きく引き上げて120個という挑戦的な目標を設定しました。これは3個ずつピンポン玉を回すというアプローチを見込んでおよそ3倍に引き上げたからですね。

実施後のふりかえりでは、目標には届かなかったものの75個と前回から大きく進展しました。ピンポン玉の受け渡し方の工夫や、カウントの仕方など具体的な改善点が明確になり、次のスプリントに向けた建設的な議論ができました。

また、このあたりからチームの一体感も生まれ始め、会場の雰囲気がとても明るくなったことを感じました。

3スプリント目

3スプリント目では、これまでの改善を活かし、目標120個へ再挑戦。過去2スプリントで培った効率的な受け渡し方法と、自然と生まれたチームの一体感により、最終的に目標を大きく上回る149個を達成しました。

この結果は、スプリントを重ねることでの改善の積み重ねと、チームのコミュニケーションから得られた成長だと感じました。過去2回に比べみんなが声を出してうまく連携していることも感じ取れ、これが暗黙知の共有かと実感することもできました。

感想

このワークショップを通じて、スクラムの本質的な価値をとても実感することができました。特に印象に残ったのは以下の3点です:

  • チームの成長が数値として可視化されることで、改善の効果が明確に実感できた点
  • コミュニケーションが活発になるにつれて、自然とパフォーマンスが向上していった点
  • ふりかえりを通じて次のアクションが明確になり、それを実行することで確実な成長につながった点

このような体験型のワークショップは、座学では得られない実践的な学びを提供してくれ、今後の実務にも活かせる貴重な経験となりました。

Day1 - あなたはだぁれ?インタビュー大会

参加者同士でインタビューをしあって交流しあうワークショップでした。


ゲームと言われると勝ちたい気持ちが抑えられず、猛スピードでインタビューをこなしました。(たぶん目的はそうじゃないw)

結果1位タイが15個で4名おり優勝しました🏅

↓アンケート結果。「初恋はいつですか?」の質問はセンスを感じました。

Day1 - 懇親会

お酒とおつまみを片手に様々な方と交流させていただきました。

特に印象に残っているのが「PdMとPOの違いってなんだっけ?(POの責務ってどうだっけ?)」と「スプリントレビューの目的と注意点」についての話です。

PdMとPOの責務の違い

それぞれの主とする目的は、

PdM(プロダクトマネージャー): プロダクトの価値に向き合い、価値を最大化するための企画を進める役割。

PO(プロダクトオーナー): プロダクト開発に責任を持ち、小さく早く安く価値を創造するための道を決める”枝刈り”をする役割。開発チームやPdMのやりたいことを整理して、なぜいまこれをやるのかを納得させる。

です。

PdMとPOの違いを理解した上で、以下の点に気をつけると効果的に開発ができると再認識することができました。

  • プロダクトバックログの管理はPOと開発チームが主導し、ステークホルダーからの直接的な介入は避ける
  • 開発チームの技術的な取り組み(リファクタリングなど)の時間確保には、スプリントレビューでの信頼関係構築が重要
  • 計画されたタスクを確実に完了することで、余剰時間を柔軟に活用できる環境を作る

スプリントレビューの目的と注意点

  • POはレビューを受ける側としての立ち位置にいること
  • スプリントレビューを通じて、ステークホルダーと進捗や課題についてカジュアルに話せる関係性を築いていくことが重要
  • 収益やユーザー数の成果を共有し、次のスプリントを楽しめる環境を作る。
    • 単なる進捗報告では成功しても面白みがなく、遅延してしまったときは否定的な印象だけが残ってしまう

自チームとの比較で気づいた点

  • プロダクトマネージャーとプロダクトオーナーを1人で兼任している場合、スプリントレビューでの立ち位置が難しくなってしまう
    • 場が進捗報告に偏りがちなため、仕組みの見直しの必要性を感じた
  • いまの自分のチームはプロダクトの方向性が明確で大きなブレが生じていないのは良い点。また、チーム全体でプロダクト価値への関心が高く、取捨選択の判断もチームで連携して適切に行えている
    • ただし、大きな施策単位での開発になりがちで、小さな改善の機会を逃している可能性がある
    • 経験豊富なメンバーへの依存度が高く、新メンバーの参入障壁が課題
  • ビジネス面での知見を持つステークホルダーをレビューに招き、新しい視点でのフィードバックを得ることで、より良い改善につながりそう

Day2 - 「もやもや」の可視化 グラフィックを使った対話をしてみよう

グラフィックファシリテーションという「無自覚を自覚」するためのファシリテーション技法を使って「対話」をしながら特定のテーマについて発散するワークを実施しました。

一般社団法人 グラフィックファシリテーション協会

6つのテーマが発案されて、今回は「みんなで話せるようにしたい。発言しないひとがいるともやもやする」について話すことになりました。

テーマの背景は、振り返りでのKPTにおいて、チームメンバーが何か考えを持っているはずなのに意見を出してくれないことへのもやもやした気持ちでした。

対話スタート

to 発案者の形で参加していた約20名の方から質問や意見がたくさん出てきました。

(発案者の返答は太字にします)

1枚目の画像

  • キレ者のメンバーがいい意見を出してもう言うことがないのかも
  • 特定の人だけが話す状態の悪いところって何だっけ?
    • 同じチームだから一緒に考えて決めたい

2枚目の画像

  • ふりかえりの参加人数はどれくらい?
    • 7人くらい
    • →うちのチームでは5人いかないくらいだとやりやすいかも
  • 自分から話を振るのが難しい
  • 話をしていないひとは納得しているのか不安…
    • →自分事にしたいよね
  • Tryを出したら作業が増えるのが嫌なのかも?
  • KPTだと先に書かれると出しにくいかもね
  • リモートだと発言がぶつからないようにするから皆の声を聞くのが難しい
    • 対面は相手の顔が見えるので話しやすい
  • 違うことをやっている人もいそう
    • カメラOFFは怖いよね
      • 話も振りにくくなる
  • ↑のこれまで出た悩みってチームに共有できている?
    • できでないかも

3枚目の画像

  • チームのメンバーの内訳ってどんな感じ?
    • Webアプリの開発をしているチームがあって、半年前からiOSやAndroidのメンバーと合流した
    • →特定のよく話してくれるひとはシニアに固まっていたりする?
    • 人によるけど新しいメンバーの発言は少ないかも

このとき、ファシリテーターが右下に茶色の図(お好み焼きのような形)を描き始めると、参加者の注目が集まりました。

ファシリテーターは「現在の場の状況が、発案者(黒丸)に対して一方的に質問が飛ぶ形になっていませんか?」と投げかけました。

私も含め参加者は納得し、「これは対話というより、単なる対談を聞いているような状態でした」という意見に多くの共感が集まりました。

この気づきをきっかけに、議論は発案者個人の現場状況の聞き取りから、参加者それぞれが抱える「もやもや」を可視化する方向へと変化していきました。

  • 学生時代の合唱コンクールや体育祭など、やってくれないことへの不満といった視点の気持ちってあったりするのかも、みんなはこういうネガティブな感情はない?
  • 特に課題を感じていないという前向きな沈黙なのかも?
    • →それを伝えてくれると安心するよね
  • 役割を持つ人がそのロールに沿って話すことはやりやすい

4枚目の画像

  • 話をまとめて発言するまで時間がかかり、タイミングを逃すようなメンバーの声を聞いたことがある
    • →みんなが話せるようなグラウンドルールを立てるとよかった
  • ひとりでファシリテーションをするのではなくみんなで進めるともっと楽になれそう
    • →うちではファシリテーションのローテをやってみていい感じ

ふりかえり

  • 文字だけより理解度が高かった
  • 解決しようという思考に引っ張られてしまった
  • 絵を書くスピードに合わせて間があり、理解を深めやすかった
  • 絵から思考を広げられた
  • 話しやすい場だった
  • 言葉では伝えにくいメタ的なものを伝えるのに絵は便利だった(お好み焼き)
  • 絵で和んで雰囲気がよかった
  • 自分のイメージと違うグラフィックから新しい着眼点を得られた
  • 描き直しをせず、そのまま置いていくというのが新しかった
  • もやもやを聞いてくれて嬉しかった
  • 自分の中でふりかえりをするタイミングがあり、解決策が見えてきやすかった
  • 場の雰囲気がカタめなものでスタートしたのでふざけにくかった
  • 今回は会場の都合上、椅子に座ってやっていたが立って絵の前を動きながらだともっとやりやすそう

学び

  • 言語化が難しい感覚を視覚情報として整理するアプローチの有効性を実感した
  • 長文や強い表現で場の雰囲気が重くなりがちな内容でも、イラストを活用することで柔らかい雰囲気を保ちながら進行できた
  • 振り返り時に出た意見を見返すと、視覚化によって細かな内容まで記憶に残りやすいことに気づいた
  • 即座に解決策を探るのではなく、対話による発散の場として維持することの大切さを学んだ。また、その軌道修正も自然な形で行えた点がよかった

Day2 - ランチタイム

会社の同僚とイベントで知り合ったPOの方と一緒にタコスを楽しみました。

普段はあまり聞けないPO視点での悩みを伺うことができ、とても勉強になりました。

ビーフ・チキン・ツナのタコスを一つずつ注文したのですが、特にツナは絶妙なソースと皮のカリッとした食感が最高でした。

Day2 - 【地獄のデイリースクラム】アンチパターンぜんぶやってみた

【地獄のデイリースクラム】アンチパターンぜんぶやってみた - speaker Deck

アンチパターンを試すことで普段のふるまいを見直してチームをカイゼンするためのアイデアを得るためのワークショップ。

ルール

1枚ずつ配られた役職のカードの人物像になりきりながら、デイリースクラムを実施する。

普段通りの進行をしつつ、アンチパターンを実行しているひとには適宜注意をして円滑に進められるように場を整える。

実際にやってみて、よかった点・次に活かしたい点をふりかえる。

今回は、

  • スクラムマスター(1人)
  • アンチパターン(2人)
  • 善良な開発者(残り)

という構成で実施しました。

1回目

スクラムマスター役で参加しました。

いつも自分のチームでやっているように順番に進捗確認を進めていきましたが、一人のメンバーがデイリースクラムに集中せず、別のことに夢中になっていました。そこで、その方に積極的に話を振り、議論の輪に戻そうとアプローチしました。

しかし、もう一人のアンチパターン役を見つけられないまま時間切れとなってしまいました。

アンチパターンをやっていた方は、

  • スキマ時間マスター
  • 進捗報告マスター

でした。

ふりかえりでは、以下のような意見が出ました:

  • スキマ時間マスターはよく見かける行動だが対応が難しく、はっきりと指摘すべき
  • スキマ時間マスターとして内職をしてみたが、会話の内容が半分しか理解できず、やはり望ましくないと実感した
  • 進捗報告マスターは、スクラムマスターから話を振られた部分だけに注力していた
  • スクラムマスターは進捗の内容より、参加者の様子に目を向けて場を見ることが重要
  • ファシリテーションを一人で抱え込む必要はない
    • 自分のチームではファシリテーターをローテーションしている

という意見が出ました。

反省点

  • 必要な指摘であっても「場の空気が悪くなるのでは」と過度に遠慮してしまっていた
  • ファシリテーションを1人で抱え込もうとしすぎて、周囲への目配りができていなかった

2回目

アンチパターン「スキマ時間マスター」として参加しました。

1回目の方の指摘通り、議論の内容がほとんど理解できず、予想以上に問題のある行動だと実感しながらロールプレイを行いました。

もう一人の参加者はムードブレイカーの役を演じており、善良な開発者たちがなだめるような形で会議が進行しました。

今回のアンチパターン

  • スキマ時間マスター
  • ムードブレイカー

ふりかえりでは、

  • アンチパターン役を演じることで、チーム全体のアウトプットを意識せず自分の進捗だけに着目することの問題点を実感できた
  • ワークショップでは意図的に誇張した演技をしたが、実際の業務でも知らず知らずのうちにアンチパターンに陥る可能性があるため注意が必要

という意見が出ました。

学び

  • チーム全体の様子により注意を払う
  • 必要な指摘は躊躇せず、タイムリーに行う
  • 自分の作業に没頭しすぎていないか、客観的に振り返る習慣をつける

Day2 - OST: 安定しないベロシティ どう改善する?

背景

ベロシティが安定せず、チームのアウトプットが実際に向上しているのかを定量的に評価することが難しいと感じていました。

また、この問題の要因としてタスクの粒度やスプリントゴールの設定方法が影響している可能性があるかもしれないと考えており、その点についても聞いてみたいです。

という僕からの発案でした。

メモ

  • (アジャイルコーチ曰く)最近はベロシティを教えていない
    • 数値を追ってもクオリティは上がらないため
      • アウトプットの質と量、特に質を向上させながら迅速なデリバリを実現することが重要
    • ベロシティの数値だけを振り返ることは、プロダクトを見ていないのと同じ
  • ベロシティではなく生産性を重視する
    • 生産性とは、コード品質と、いかに早く安く小さく価値を生み出せるかということ
    • 生産性が向上すれば、ステークホルダーがより多くの要望を出してくれるようになる
      • 逆に要望が出ないことは信頼関係が不足している証拠
    • 生産性向上にはコードリトリートが効果的
      • 開発時間の約8割はコードを読む時間。品質が上がれば読む時間が短縮され、不要な機能の削除も容易になる
      • 将来の負債となるコードは残さない
  • 課金ユーザーなど、強い利害関係を持つステークホルダーからのフィードバックが非常に重要
    • スプリントレビューに招待する
  • プロダクトの品質維持をPOやシニアエンジニアの個人に依存している状態は、いずれ破綻するため改善が必要
  • リリース時期だけを追求しても、進捗は早くならず、不要な機能まで含めることになる
    • それでは開発チームも楽しくない
  • ステークホルダーと共にゴールを設定する
  • スプリントゴールがタスクリストになっている状況について
    • チームにこの状況が楽しいか確認してほしい
    • スクラム未経験のチームではよくある状態だが、慣れてきたら次のステップを目指そう
    • 「ステークホルダーにどめきを起こす」「ステークホルダーからツッコミを貰う」などをゴールにすると、成果発表がより楽しくなる
    • どのような価値を生み出すかを考えてゴールを設定する
  • 定期的なオンサイトレビューで、楽しさと適度な緊張感が得られる
    • ステークホルダーとの信頼関係構築にも効果的
    • コーヒーやお菓子があると、リラックスした雰囲気が作れる
  • スプリントレビューは進捗報告ではなく、価値向上を考える場とする
    • ユーザーストーリーを再現するロールプレイ形式で実施すると効果的
      • ex) アプリストアからインストールし、特定の機能を体験してもらい、ファン化して継続利用につなげる
      • ステークホルダーから「必要なシナリオは十分か」「機能を削って早期リリースすべきでは」といった意見が出るよう促す
  • 20個のPBIごとに1つは機能を削減するものを含める
    • 生産性向上には、必要なものだけを作る姿勢が重要
  • KPI未達成状態から脱却する
    • KGIが達成できてもKPIが未達成な状態は、いずれ方向性が外れるリスクが高い
    • 計画立案のスキル向上が必要
  • PBIの価値、シナリオ、中止条件は事前に設定する
    • ステークホルダーと協力して着手前に決める
  • チームに価値提供の成功体験を実感させる
    • 数値やユーザーの声をステークホルダーから共有してもらい、称賛を得ることも大切

学び

  • スプリントを楽しく回せる環境づくりを目指す
  • プロダクト価値の向上と迅速なデリバリーには、ステークホルダーとの強い信頼関係が不可欠
  • マネタイズへの意識を高め、小さく・早く・安くプロダクトを作ることを重視する
  • スプリントレビューを、プロダクト価値とチームのやりがいを高める場として機能させることが自分のミッション


Day2 - クロージング

運営スタッフの皆様のおかげで、非常に有意義な時間を過ごすことができました!

たくさんの学びと今後挑戦したいことを得られましたが、一つ一つ着実に取り組んでいきたいと思います。

Day2 - 懇親会

大人数で入れる店を探すのに苦労しましたが、沖縄料理が充実していると聞いてキャッチの方の案内に従うことにしました。

これまでキャッチの案内で入った店の中で、料理のクオリティと価格のバランスが最高でした!

参加者それぞれの現場での経験や課題について語り合い、お互いの意欲を高め合える刺激的な時間となりました!



カンファレンスを通して得た気づき

スクラムフェス沖縄への参加を通じて、アジャイル開発における「人」と「価値」の重要性を改めて実感しました。特に印象的だったのは、単なる数値や進捗管理にとどまらず、チームの楽しさや成長、そしてプロダクトの価値向上に重点を置くことの大切さです。

ワークショップやOSTでの議論から、以下の重要な気づきを得ました:

  • スクラムマスターとして、チームが楽しみながら価値のあるプロダクトを開発できる環境づくりを最優先すべき
  • ステークホルダーとの信頼関係構築が、プロダクトの成功への鍵となる
  • スプリントレビューは進捗報告の場を超えて、価値を共に考え、成果を分かち合える場とする

この経験を活かし、TimeTreeでのスクラムマスターとしての活動をさらに充実させていきます。特に、チームとステークホルダーの距離を縮め、共にプロダクトの価値を高められる関係性の構築に注力します。

TimeTree Tech Blog

Discussion