【スクラム事例紹介】スクラムを組織全体に浸透させるための第一歩として、「PBIリファインメントワークショップ」をやっている話
こんにちは。Ubieというヘルステックスタートアップ企業でQAエンジニアをしているakinkです。
Ubieでは、プロダクト開発に限らず、マーケット開発や組織開発、採用といった様々なテーマを扱うチームでスクラムが採用されています。
そのため、メンバーが効率よくスクラムを習得し、爆速で事業(コト)に向かえるよう支援するための「スクラム工場」というチームがあります。
※以下は活動例
■オンボーディングセッションの型化、運用
・スクラム概要+スクラムオンボーディングフローの説明セッションの開催
・プロダクトバックログアイテムリファインメントワークショップの開催
■自己学習コンテンツの整備
・入社必読書の一つとして「スクラムガイド2020」を配布
・スクラム基本知識理解度テスト25問 (答えの解説付き) の作成、布教
・スクラム習熟度別の学習資料まとめの作成
本記事では、昨年の9月より取り組み始めた「プロダクトバックログアイテム (以下PBI) リファインメントワークショップ」について紹介します。
【背景】組織としてスクラムを採用している理由
Ubieでは事業フェーズごとに組織が分かれており、主に0→10フェーズの事業開発を担うUbie Discoveryという組織でスクラムが採用されています。
Ubie Discoveryの特徴として、
①不確実性の高い事業課題に対して仮説検証を小さく行い、アセットを積み上げること
②複数の既存事業を同時並行で開発・育成し、互いの事業に活かすことで指数関数的に全体成果を最大化すること (多拠点同時突破)
を重視しており、これらを効率的に実現する手段としてスクラムを導入しています。
※より詳細な背景は下記のカルチャーガイドを参照
PBIリファインメントワークショップとは何か
1人1人が自分のチームでよりよいPBIをたくさん積める+チームで生まれたPBIのリファインメントを効率的に行なえるようになることを目的としたワークショップです。
参加者4~5名+ファシリテータ1名でmiro(オンライン上のホワイトボード)に集まり、参加者が持ち寄ったPBIについての気づきや改善点、リファインするならどう書く?といったディスカッションを行います。
元々はグローバルチームで試してよかった取り組みを、全社に展開する形で実施しました。現在では新入社員向けのオンボーディングセッションとして毎月開催されています。
背景課題とワークショップの位置づけ
グローバルチームのスクラムマスター曰く、
「メンバーによってPBIの質と量のばらつきが大きすぎてリファインメントのROIが微妙」という課題を解決するために実施したのがはじまりだったとのこと。実践した結果、チーム内で重視するポイントを共通言語化できたおかげで明らかにPBI作成、優先順位付けの生産性があがったという効果を実感したそうです。
Ubie Discoveryが目指す「多拠点同時突破」を短期間で実現するには、1人の優秀なプロダクトオーナーが考えた企画をその他のメンバーが開発するという片方向のスタイルだと時間がかかりすぎる。とはいえ、プロダクトオーナーやスクラムマスターのスキルをで全員がすぐに習得するのは難しい。
少なくとも、皆がPBIを生み出し創発的なコミュニケーションが生まれる状態を目指すことが、多拠点同時突破の実現確度を高めるための第一歩と考え、この取り組みを行っています。
PBIリファインメントワークショップ実施の流れ
実際の進め方は以下の通りです。
【開催1週間前】事前課題のアナウンス
参加対象となる入社1ヶ月目の社員に宿題のアナウンスを行います。
宿題の内容は2つ
「これうまくいかなかったな〜」と思うPBIをワークショップ用のmiroに添付してもらう
自分が作成したPBIが望ましいが、なければチーム内で議論になったPBIを選択
「有効で有用なPBIを作るためのガイド」という社内資料を読んでもらう
【当日】PBIについての基本知識をおさらい後、ディスカッション
①基本知識のおさらい：10分
ファシリテーターが中心となり、下記の基礎知識を説明します。
※事前課題で関連資料を読んでもらっている前提なので要点のみ
■PBIとは何か、大事なこと
・誰にどんな価値を提供するかを書く
・PBIはあくまでコミュニケーションを生むきっかけにすぎない
→どういう内容が盛り込まれていると創発的なコミュニケーションが生まれやすいか?を知ることが大事
■INVEST則について
・Independent（独立している）
・Negotiable （交渉可能である）
・Valuable （価値がある）
・Estimatable （見積もり可能である）
・Small （小さい）
・Testable （テスト可能である）
■よくある落とし穴
■一番大事なこと
・「透明性・検査・適応」がすべて。あまり書き方にこだわりすぎないこと
②持ち寄ったPBIについてのディスカッション：50分 (10分×4~5人)
参加者本人より、PBIの内容/背景/チーム内でのリファイン内容について説明してもらった後、参加者全員でディスカッションを行います。
参加者が気になった点についての質問
本人の気付きや困った点、今思えばこう書いたほうがよかったかもというポイントのシェア
改善ディスカッションから派生した自チームでの取り組みシェア
【後日】動画の格納、共有
ワークショップの様子は録画し、過去分も含め皆がアクセスできるようになっています。
ワークショップで話題になった論点
過去10回開催した中で、話題になった論点についていくつか紹介します。
プロダクトゴール(=UbieではOKR)やスプリントゴールとの関連性
Why Now (今着手すべき理由)はチームで話した?
例)「ユーザーからのお問い合わせコスト削減」などやればやるだけいいテーマこそ、「なぜ今やる必要があるのか?」の議論が抜けがち
惰性で足元のPBIやっちゃってることある?
例) 「透明性、検査、適応」の原則が機能しているチームでは、マーケットの変化に応じてスプリントゴールを見直した結果、「そのPBIは着手しない」と判断することもあるため
INVEST則に沿った深堀り/明瞭化
Negotiable (交渉可能である) か
Acceptance Criteria (受け入れ基準、 以下AC)にHOWを規定しすぎてしまってないか?
💡Outcome(〜な状態)を書くと交渉の余地が生まれてベター
Valuable (価値がある) か
タイトルがTODOになってしまっており価値を判断しづらい場合
💡「whoとwhatとwhy」が明確だとバックログの並び替え (優先順位付け)しやすいよね
やるべきことが明らかで、チーム内の解釈が一意に定まるならこの限りではない
価値の提供先は誰か明確か?
例) 患者側なのか、医療機関側なのか。医療機関側だとしたら医師なのか看護師なのか受付なのか
Estimatable (見積もり可能である) か
メンバー間に知識の偏りがあり見積もれない場合
💡その場で話すことで埋まらない知識ギャップが有る場合、ギャップを埋めるための時間を別途とった後、再度リファインするのも手
Small/Sized Right (小さい/適切なサイズ) か
見積もりが「1スプリントでは収まらないボリューム」になってしまった
このACがMVP (Minimum Viable Product) として必要だった理由/背景はなんだった?
💡PBI分割の余地がありそう。PBI分割方法の考え方はryuzeeさんの記事が参考になるので読んでみてね
Testable (テスト可能である) か
ACの解釈が一意か?
例) 「〇〇を使いやすくする」という記述
何がどういう状態になると使いやすいといえるのか?
リリース後の検証はどうやって行うか、チームで話した?
投資対効果 (Return On Investment) について
Investmentの調整の余地は検討した?
例) VP (Value Proposition /提供価値) を実装なしで検証する方法は検討した?
Investmentだけでなく、Returnも検討した?
Rの種類
ユーザー体験の向上
ブランド価値の向上
データ的価値の獲得
今返済することで今後に効いてくる負債
Rの規模
例) 全ユーザー vs 特定ユーザー
Rの掛け合わせ
単体の価値のみを狙うのか or 将来的な副次的価値も含めたReturnを狙っているのか
例) 現時点では利用ユーザー数が少なくデータ的価値のインパクトは小さいが、直近の広告投資でユーザー数爆増が見込めるので今仕込む価値がある機能
PBIの作り方/チームでのリファインメントの様子について
どれくらいの時間かけて作った?
💡初手で作り込み過ぎている場合→要所を押さえて5〜10分とかでぽんぽんつくって、リファインメントで磨き込むほうがいいかも
チームでのリファインメント時に追加された情報はある?
💡PBIはあくまでコミュニケーションのきっかけにすぎないのでその場で生まれた対話が重要
お悩み相談系
作り込みすぎて見積もりと実績が乖離してしまった。どうしたら防げた?
💡「やらないこと」をACに明記することで、かけるべきInvestmentの認識をあわせる方法をとってるチームもあるよ
新メンバーが入ってメンバー間にドメイン知識の偏りが生まれた場合、PBIは詳細に書いたほうがいい? (透明性の観点で)
💡ドキュメンテーションを充実させるのも一つの手だけど、「ただ話す」ことで情報格差を埋めるHOWも検討するとよさそう
実際にリリースした上での反省シェア
Investの小ささだけで着手が決まったけど、狙っているReturnがあいまいでROIが見積もれてなかったことがあった
いちから機能を作ってしまったけど、既にある資産の使い回しができたと後から気づいた
ワークショップをやってみてよかったこと・改善点
よかったこと
他チームのPBIの書き方を見ることで自チームの書き方を相対化できた点、プラクティスはプラクティスで、結果的には原理原則に立ち戻るのが大事だよねといった共通認識の醸成ができたのは良かった点です。
また、ミーティングは全て録画しているので、自分が参加していない回も見ることで学びを深めることができる点もよいところかなと思います。
1月のワークショップ参加者の感想 (抜粋)
他チームのPBIの書き方/リファインの様子を知ることができた
よく課題になる点、その乗り越え方を実践的に学べた
ディスカッションの中で様々な観点が出てきて参考になった 等
改善点
参加者によって、スクラムに対する理解度や業務での実践度合いにばらつきがある点を考慮した設計になっていないので改善していきたいです。
また、実施回によって話題となるポイントが異なるため、網羅的に学びを共有できているとはいえない状態です。よくある落とし穴やTips情報を形式知として集約し、組織全体にシェアする活動もセットで実施する必要がありそうです。(この記事もその一環)
最後に
スクラムを導入している現場では、「PBI作成がPOに偏りがち」、「リファインメントが機能せず、PBIが生煮え状態でスプリントに投下されベロシティが安定しない」といった課題はあるあるなのかなと思います。(自戒を込めて)
類似の課題を抱えるチームにとって、本記事が少しでも参考になれば幸いです。
Ubieでは事業と同じくらい事業を生み出すための生産基盤への投資を重視しています。今回の例のように、「スクラムを組織に浸透させることで組織全体の生産性を向上する」といったテーマも興味があれば誰でも取り組むことができます。
もちろん、Ubieでもうまくいっているチーム、苦戦しているチームの両方存在します。うまくいっているチームの知見/マインドセットを組織に還元するための仕組みを作っていきたいと考え活動しておりますが、まだまだ道半ばです。このテーマに興味ある、一緒にやりたいよ!という方、絶賛募集中です。
限られたリソースや時間制約の中で、プロダクトの価値を高めるにはどうすればよいかを考えることが好き!という方、Ubieで一緒に働きませんか?
少しでも興味が湧いたという方は、TwitterやFacebookなどでお気軽にご連絡ください!
また、本記事では触れなかったスクラムのオンボーディング設計や実践事例について話を聞いてみたい! Ubieでのスクラムに興味がある!という方はmeetyでお話もできるので気軽にご連絡ください!
オミクロン株の感染拡大もあり不安な日々が続きますが、皆様ご自愛ください。少しでも体調に不安を感じたときは、ユビーAI受診相談を使ってみてもらえると幸いです。完全無料です。