参加ログ：LeSS morning #4 〜イニシャルプロダクトバックログリファインメント〜
表題の勉強会「LeSS morning #4 〜イニシャルプロダクトバックログリファインメント〜」に参加してきました。#4 とあるとおり、これまでにも3回開催されていて、うち2回は参加したのですが、こんなかたちで共有はしていませんでした。今回、クリアな学びが得られて「共有したい」と思えたので、記録に残しておこうと思います。
なお、以降は見出しが長くなるので「イニシャルPBLリファインメント」と表記したいと思います。
事前の興味と期待
LeSS morning には昨年秋の立ち上げイベントの初回から参加させてもらっていて、いまいまかなり優先して参加しようとしています。というのも、目下社内で「二度目の LeSS 挑戦」の真っただ中にいるからだったりします。
なのでまぁ、メールで開催通知が届いた時点で参加は即決してたんですw。
なぜイニシャルPBLリファインメント？
とはいえ、今回のテーマに「イニシャルPBLリファインメント」を採り上げられたことに軽く驚きました。LeSS morning でやるということは、複数チームでこのイベントを行う意義が特に何かあるからだろう！と思うものの、自分にはそれをサラッと思いつくことができなかったので、今回どのあたりに注目してテーマ設定したんだろう？と思ってました。
なお、シングルチームのスクラムでイニシャルPBLリファインメントをやる価値は、これまでの実践で十分感じていました（SMとしていろんなチームの活動をみてきたなかでも、CTO室やEM室で毎期初の課題設定をしたあとに自分たちが実践してきたなかでも）。
LeSSに関係なく学べても有り難い
また、もしシングルチームで行うのと同様にユーザーストーリーマッピングなどからバックログアイテムを作成する演習だったとしても、ぜったい面白いだろうと思って会場に向かいました。
他社の開発チームの方と実践する機会なんて、そうそうあるわけでもなく、しかもこういう勉強会に参加するような方々となので！
イニシャルPBLリファインメントとは
イベントの定義
勉強会の始めに説明いただいた内容と（たぶん）近い情報を書き留めます。
Before you start your first Sprint, you need (1) a Product Backlog with some ready items, and (2) a Definition of Done. Scrum doesn’t name the activity for this, but we’ll use the term initial Product Backlog Refinement (initial PBR, IPBR), because it is similar to regular PBR each Sprint.
Typical activities include defining a vision, discovering Product Backlog items, splitting large items, refining items until ready, identifying risks, defining “done”, and estimating.
【私なりの日本語訳】
最初のスプリントを開始する前に、いくつかの着手可能なアイテムがあるプロダクトバックログ（１）、および Doneの定義（２）が必要です。
スクラムはこの活動に名前を付けていませんが、スプリント中に行う通常の PBR（プロダクトバックログリファインメント）に似ているので、私たちはイニシャルプロダクトバックログリファインメント（イニシャルPBR, IPBR）という用語を使うことにします。
典型的な活動は、ビジョンの定義、プロダクトバックログアイテムの発見、大きなアイテムの分割、着手可能レベルまでのアイテムの明確化、リスクの特定、Doneの定義、見積もり、などです。
今回の演習内容
今回の勉強会では、上記活動のなかでも次のあたりを実践する設定でした。
プロダクトバックログアイテムの発見
大きなアイテムの分割
着手可能レベルまでのアイテムの明確化
冒頭の一文でいうと（１）の “いくつかの着手可能なアイテムがあるプロダクトバックログ” を作成する部分に当てはまりそうです。
以下、当日の進め方をざっくり辿ります。
先ず、チーム分けがありました。
今回は、LeSS・スクラムの経験年数の長さが近い人をグルーピングするかたちでした（今回課されたプロダクトゴールに即した意図ある分け方だったと思いますが、実際の開発チーム編成だと違う考え方になりそうですね）。
そして、次のようなワークを行いました。
POからプロダクトゴールの共有（今回は、10月下旬に開催予定となった『LeSS’ YOAKE』最終日の Open Space のコンテンツを企画すること）
チームで企画案＝バックログアイテム候補案の洗い出し（先ずはタイトルと概要説明くらいまで）
ワールドカフェ形式でリファインメント継続（各チーム2人だけホストとして残って、他のメンバーは他チームのテーブルを巡回して詳細化や派生アイテム作成など）
着手可能レベルに達したアイテムの優先順位付け（自チームに戻ってリファインメント経過の共有を受けてから実施）
再びワールドカフェ形式っぽく全チームテーブルを回って優先順位付けの結果を眺めて回る（こんどはメンバーの行き場所をシャッフルして全員が巡回）
このあとは、結果をPOが1本のプロダクトバックログに集約するという設定で、LeSS morning の次回以降に繫がっていくことも想定されます。
👇運営からのレポートが！手順などこちらが正確かと（2024/03/26追記）
イニシャルPBLリファインメントで得られること
さて、今回体験して自分が気づいたり感じたりしたことを書き留めておきたいと思います。
バックログアイテムの理解を深め、かつチーム間の共有知にできる
1チームでリファインメントを進めるのに比べて、さらにポジティブな効果を体感することができました。
自チームで考え出したアイテムは壁打ち的な質疑応答によってどんどん洗練される
他チームのアイテムは客観的に見れ、いい塩梅の「無責任さ」や「面白がり」によって派生アイデアも拡がる
そして、ごく自然に全チームのバックログアイテムの種を、網羅的に把握することができている
LeSSを組んでいる他チームの特性や志向性を（自然に）把握できる
最初のチーム分けは今回のテーマのカンファレンスプログラムを考える上で、経験値ごとに興味関心のあるプログラムを生み出す設定だったと思いますが、他チームのテーブルを回っていくなかで、やはり各チームの特性が色濃く反映されていることを知ることができました。
これは、LeSSを共に組む「チーム同士の相互理解」を高めるうえで、かなり有効な体験になるように思いました。
他チームの良いプラクティスを（自然に）把握できる
そして、さらに面白い副次的効果だと思ったのが、
バックログアイテムの表現方法とか、整理のしかたとかを、他のチームでやってる様子から学べたことです。
なるほど、こういう効果もあるのか！と思った瞬間がありました。
具体的な生かし方として次のようなイメージもできました。
他チームのACの書き方を知ることで、自チームのもより洗練できる
そもそもの課題（issue）に対してアプローチする方向性とか考え方のバリエーションに触れて、自分たちも視野や掘り下げ方を拡げられる
やってみよう（Next Action）
イニシャルPBLリファインメントの価値を共有する【In Progress】
と思ってここに書きました。
・・書いて世に出した点は DONE ですが、新年度に入る＆四半期のスタートになる社内にも少し Push で共有できればと思っています。
サブタスクの進捗状況👇
世の中に自分の言葉で共有する【Done】
社内に共有する【In Progress】
Slackにこのレポートを共有しました（そもそもその目的で書いたw）
LeSS.works の輪読をやるのは？【未リファインメント】
今回あらためて気付いたのが、まだ LeSS.works の日本語訳が多くないことです。もちろん、ブラウザの機能やプラグインなどでその場で日本語化して読むこともできるますが、スクラムやLeSSの文脈は機械翻訳だと腹落ちしづらい部分も多いのではという印象を持っています。そこで、LeSS.works の輪読を有志でやる野良勉強会もありでは？と思いました。
LeSS morning で勉強したことについて事後に読み合わせるとか
LeSS morning と関係なく、興味のあるところを選んで読み進めるとか
去年の9月、コロナ明けで再開された初回の「認定LeSS実践者研修」で、LeSS 本の内容が少し古くなってきていることを知ったのも理由の1つです。（例えば Overall PBL Refinement が必須イベントから外れたとか）
この構想は賛同者の方がいらっしゃれば、チームを組んで「イニシャルPBLリファインメント」に進めるアイテムにできればと思いますw。
まとめ
POにお薦めしたい、相当タイパの高いイベント
シングルチームのスクラムでも「ミーティング（スクラムイベント）に時間を奪われる」というネガティブな意見がよく出てくると思いますが、このイニシャルPBLリファインメントは、おそらく大半の参加者が意義と効果を体感できるように思いました。
そういう意味で、とくにPOの視点に立つととてもタイパが高く感じられるのでは？と思われ・・、「イニシャルPBLリファインメント」はやってみることをかなりお薦めしたいと思います。
期初に限らず、LeSSに限らず、
また、Sprint 0 のような「イニシャル」にとどまらず、同じプロダクトゴールを共有するチーム間で「合同でリファインメントをやる」ことの意義・効能も同様にあるだろうと考えられたことも、書き添えておきたいと思います！
それと、今回は LeSS の勉強会から学んだ「複数チームでやること」の価値にフォーカスしましたが、最初のほうに書いたとおり、“イニシャルPBLリファインメントをやる”ことは、1チームだけでもお薦めします。
「打数」である Velocity を1スプリントだけ少し落としてでも、プロダクトゴールをチーム全体でしっかり向き合っておくことが、「打率」を高めるので、後で複利が効いてくるはず！という考えからです。
以前、開発スピードについて書いたときに下記を引用した話と繫がります。
図5.4：「コードを書くためだけにここにいる」という姿勢は、実際のステークホルダー（の不満）から逃げる素晴らしい方法だ
今日はこのへんで！