はじめに
こんにちは！ものづくり部のビジネス開発グループでプロダクトマネージャーをしているべったけ(@gb_pdm)です。
2ヶ月ほど前から同じチームのスクラムマスターと「スクラムあるある言いたい」という座談会を始めました。
この座談会をきっかけにスクラムの改善が加速してきているので本日はこの話を紹介します。
「スクラムあるある言いたい」とは？
「スクラムあるある言いたい」とはプロダクトマネージャーの自分とスクラムマスターの2人で週に1回、スクラム運営で起きる疑問や悩みについてざっくばらんに対話する場です。
主な目的は、
- スクラムの用語や概念の共通理解を深め、認識のずれを解消すること
- 開発プロセスで直面する具体的な課題を発見し、解決策を検討すること
- スクラムの原則である「検査と適応」のサイクルを促進すること
です。
以前よりスクラムマスターとの1on1ではスクラムに関する話題が多かったのでもっとオープンな場で議論出来ると良いよねというきっかけで始めました。
スクラムにはレトロスペクティブというプロセス改善のイベントも用意されていますが、2人の関心毎で深堀りをしてしまうと時間も足りず他のメンバーを置き去りにしてしまう懸念もあったのでレトロスペクティブとは切り分けて時間を作ることにしました。
継続する上で意識していること
「スクラムあるある言いたい」を継続していく上で意識していることが2点あります。
1.「浅く広く」より 「狭く深く」
1つ目は深堀りすることです。1度にたくさんのテーマを扱うのではなく1-2つのテーマに絞って深堀りをしています。
人数についても少ないほうが自分たちが気になっているテーマについて深く探求できるのでしばらくは少人数で開催できればと考えています。
ただし今後はゲスト会を作ったりトークセッションの開催なども考えていたりします。
2.オープンな場作り
2つ目はオープンな場作りです。
現状は2人での開催ですが、#scrum_waiwaiというslack chも存在しそこでスクラムに興味のあるメンバーが集まって情報共有をしています。
また「スクラムあるある」で議論した内容はGeminiで文字起こし→Cursorでグラフィックレコーディングに変換しslackに投稿しています。
議論した内容が2人だけの知見にならないようにわかりやすい形でシェア・蓄積しています。
Cursorに作成してもらっているグラレコ
実施してみての効果
これまでの「スクラムあるある言いたい」での議論を通して実際に整理が進んだものを2つ紹介します。
1.スクラムに出てくる用語の違いが整理された
スクラムを実施する中で「ユーザーストーリー」「エピック」「スプリントゴール」「プロダクトバックログアイテム(以下PBI)」といった単語が登場していました。
しかし抽象度や役割の違いが曖昧になっておりメンバー同士で共通認識を持てていませんでした。
そこで下記のように定義を明確にし整理しました。
| 用語 |
定義 |
特徴 |
例 |
| プロダクトゴール |
プロダクトが中長期で達成すべき目標 |
- プロダクトバックログ全体の指針
- 1つのゴールに向けて複数スプリントで前進する |
保護者がスマホだけで迷わず写真を探して購入できる体験を提供する |
| ユーザーストーリー |
ユーザーの目的達成のための具体的な行動や操作を表現 |
- ユーザーストーリーマッピング上で、ある程度可視性が担保された粒度で表現する |
保護者として、運動会の写真をまとめて見たい |
| スプリントゴール |
1スプリントで達成したい価値ベースの目的 |
- タイムボックスの概念がある
- 1つのユーザーストーリーの実現、もしくはそれより細かい単位で定義する |
写真をカテゴリで絞り込めるようにする |
| PBI（プロダクトバックログアイテム） |
ユーザーストーリーを開発可能な状態に分解、整理したもの |
- タスクではなく価値単位
- 1つのスプリントゴールの実現、もしくはそれより細かい単位で定義する |
- 写真データにカテゴリ情報を付与できるようにする
- カテゴリによるフィルタ機能を一覧画面に追加する |
| エピック |
大きなユーザーニーズや機能を表す開発テーマ |
- 複数のユーザーストーリーをグループ化したもの
- タイムボックスの概念がない |
写真閲覧体験の改善 |
関係性イメージ
この整理によりゴール達成に必要な価値とそのために何を作るべきなのかがわかりやすくなりました。
2.「リファインメント」と「スプリントプランニング」の区別が明確になった
当時、チームでは週に1時間リファインメントの時間をとっていたのですが、 ストーリーポイントをつけるのに時間がかかっており、次スプリントが始まるまでにReadyにならないPBIが多くありました。
一方でスプリントプラニングはあっさりと終わってしまうこともありました。
議論を進める中で以下のような課題があることがわかってきました
- リファインメントで細かな実装方法を話過ぎている
- リファインメントにおけるPBIの分解とスプリントプランニングでのスプリントバックログアイテム(SBI)への分解の違いが曖昧
- リファインメントで正確な見積もりを行う必要があるというバイアス
これらの課題に対して以下のように区別を明確にしました。
| 課題 |
To-Be |
| リファインメントで細かな実装方法を話過ぎている |
- クラス設計などのどう実装するかの具体的な作業の議論はスプリントプランニングで行う |
| リファインメントで細かな実装方法を話過ぎている |
- リファインメントではストーリーポイントが大きなPBIは価値の単位で複数のPBIに分解する
- スプリントプランニングでは1つのPBIに対して作業項目の単位で複数のSBIに分解する |
| リファインメントで正確な見積もりを行う必要があるというバイアス |
- リファインメント時点では受け入れ条件、不確実性、影響範囲、作業ボリュームについておおよそ開発チームで認識が合っている状態を作れればOKとする
- スプリントプランニングのタイミングで当初のストーリーポイントと乖離があればつけ直し最終的なPBIを選択する |
これらの変更により以前よりリファインメントがスムーズに進むようになり、スプリントプランニングとの棲み分けも整理されました。
おわりに
今回紹介したテーマ以外でも「品質の管理と計測」や「ドキュメントの管理方法」などのテーマでも話していて、少しずつですが確実に開発プロセスの歯車が噛み合ってきているのを感じます。
早期の成果を期待しすぎず、まずはしっかりとコミュニケーションの場を持つこと。その積み重ねが重要だと感じています。
つい後回しにしてしまいがちな「言葉の認識」「コミュニケーションプロセス」が実はプロダクト開発の微妙な歯車のズレを生むことも多いと感じています。
そこのズレを丁寧に取り除いていくことが、プロダクトマネージャーが本来注力すべき意思決定やプロダクト戦略により集中できる状態に繋がっていくのではないかと考えています。
弊社では一緒に幼保業界・写真業界のDXを推進していく仲間を募集しています。
スクラムやプロダクトマネージャーの業務についてもっと詳しく知りたいなどあればご気軽にご連絡ください！
