これはNE Advent Calenderの24日目の記事です！毎年会社のアドカレに参加していますが、書く記事を2021年から+2ずつ増やしていき、2023年、ついに7日分の記事を書くことになりました。7日間あすみアドベントカレンダー的には6日目の記事です📚

「この1年、スクラムマスターとして活動していた自分の間違っていたことをふりかえっていくぞ〜〜！！」＆「あの頃読んで好きだった本のOSUSUME〜〜！！」を7日間通してやっています💪

ついに！！！！遅刻しました！！！！！！！3日目まで(n-1)日目に書いていたのですが、4日目から当日に書くようになり...このような結果に！！

オケツに間に合えば良いだろ精神で、ドーンと構えていこうと思います！

ちなみに、遅れたのはSchool Days一挙放送を見ていたことが原因になります。横目で見ながらアドカレを書こうと思っていたのですが、久しぶりに観たら思ったよりもめちゃくちゃ面白くて筆を進めることができませんでした・・・。この事象から「やはり神アニメ」ということが証明されたからそれはそれでいいか（？）

では、やっていこう〜〜🍥

PO委員会

どんな罪か

スクラム始めたての頃は、実はステークホルダーだった2人をプロダクトオーナーとして見立ててスクラムを回していました。

なぜそのような方法をとったかというと、「なんかちょっと巻き込んでるうちに沼らせていく」理論（day.2記事参照）が自分の中にあったため、最初からプロダクトオーナーを任していなかったという背景があります。

それにしてもスクラムガイドでも良くないと言われている"プロダクトオーナー委員会"の形だったのと、それ以上に色々うまくいかないところがでてきたため、チームで正しい方向に進むために行った"むきなおり"の機会でどうするかを話し合いました。

スクラムガイドのプロダクトオーナーの記述等を改めてじっくり読んだ上で、以下の話し合いをしました。

プロダクトオーナーの基礎的な部分は"委員会"でもやれそう
- プロダクトの価値を最大化
- プロダクトバックログ管理への責任
- 「他の人に委任することもできる」とある通り、プロダクトオーナー個体が全てをやるという訳ではなく、あくまでWhyを持っている人格として存在していれば良さそう
営業と顧客対応の2人の意見に優劣をつけることはしたくない
- どちらか1人を選ぶと営業視点・顧客対応視点どちらかが軽視される、の様な見え方をしそう
不慣れではあるので、このまま共同で進めた方が間違いが少なさそう
- それなりに「負担の分散」みたいな部分も少なからずあったとは思う

チームで上記のことを話し合い結果的には「このまま進めよう」という結論に至りました。各イベントの出席は以下の様に定め、その後PJが終わるまでそのままで進みました。

プロダクトバックログリファインメントはどちらも出席する
スプリントプランニングはどちらも出席する
- スプリントバックログの分解の部分はどちらも離脱
デイリースクラムはどちらも欠席
- ただし、必要なタイミングでどちらかが呼ばれるということは発生していた
スプリントレビューのファシリテーターはスプリント毎に交互に行う
レトロスペクティブはどちらも出席する

チームで話し合って決めたことなのでそれは尊重したいと思いつつ、やってみて「やっぱりうまくいかなかい部分はあったな」という感覚があります。今日はあの時の大罪についてひとりふりかえりをしてみたいと思います。

ふりかえり、反省する

反省ポイント

単純にコストがかかる（あたりまえ体操）

シンプルに1人分を2人がやるというのもありつつ「決定権」が結局どちらにあるのだろう、という感じになる
迷いが発生した時には話し合いで解決していたが、POたちが相談しあうという作業が発生する
どちらか1人が決断すると、それはそれでパワーバランスみたいなのが生まれる感じになりそう

「責任」みたいなのがゆるくなる

そもそもプロダクトオーナーという「プロダクトに責任を持つ人」が曖昧になると、その後の決定みたいなところも若干曖昧になる
今振り返ってみれば、ステークホルダーとプロダクトオーナーの中間くらいの立場な感じがする

逆によかったこと

営業・顧客対応どちらも尊重できた

目論見通り両方の意見を同等に扱えた
特に大きく恩恵だったな〜と思うのはプロダクトバックログリファインメントの部分
- 必ず参加してくれる、というところで、営業目線・顧客対応目線での視点が余す事なく存分に言ってもらえるのは良いことだった
  - これがステークホルダーという立ち位置だと、毎回誘うのもな...（それもありなのか？わからない）となりそうだった

PJ内の中核に他ロールの人を入れるという体験ができて良かった

なぜ茨の道をいったかというと、やはりこれに挑戦してみたかったというのが大きい
スクラムチームとステークホルダーの関係性ではなく、同じスクラムチームに入ってプロダクトを作りたかった
- 今までは考える段階（リファインメントの様な部分）からがっつり入ってる、ということが少なかった
やった結果、エンジニア「他ロールの意見なくして良いものは作れない」という価値観に変わった
- インタビュアー（エンジニア）とインタビュイー（他ロール）の関係ではなく、対話する・一緒に何を作るか決める、という関係性に変わった
- これ無くして今後作れるか？？作れないよな？？？という感覚
他ロールも、エンジニアに対する見方が変わった面があると思う
- それなりに「開発の話している言語（というかワードとか、専門用語とか...）」を理解できるようになっていった
  - こちらも深いところまで喋って良い安心感があるし...
- 「何をやっているかわからない部隊」から、「何を書いてるかはわからないけどやっていることはわかる」になってくれていた

「おすすめしない方法」を敢えてとることでどの様なことが起きるか、うまくいかないか、みたいなところが経験として積めたのは良かったなっておもいます。

次はどうするか

とはいえやっぱり、もう「プロダクトオーナー委員会」の体制をする事はないと思います。 目論見は達成できたとは言え、他の方法でもきっと達成できるはずです。

当時はその発想が無かったのですが、「どちらの声も聞けたのが良かった」に関しては、↑の図に書いた通り、営業でも顧客対応でもない人がプロダクトオーナーとして立つことで達成できる面もありそうです。

また以前の環境だと、他ロールと共同でPJをする事で自分ごと化してもらう（沼ってもらう...）を敢えてする必要がありましたが、この1年で自分たちが築き上げてきた関係性・周りの人にアピールした事で伝わったものなどがあり、そこまでグッと気合い入れずともやりたいことが叶えられる雰囲気があります。

プロダクトオーナー委員会を支えてきた私ですが、正直今でも正しいプロダクトオーナーがどうあるべきか、みたいなのって結構マジでわからんくて頭を悩ませているので、インプットと経験を積んでいきたい...！

まとめ

はい、遅刻しましたが、24日の記事でした！！メリークリスマスイブ！！！

というか実はこれ、急遽生やした大罪なのですが（day.3記事で2つ予定のものを1つにした）、大罪って全然急遽で生やせるんですね。失敗ばっかのせていて恥ずかしい日々ですがどれも大事な経験と思ってます！失敗して学ぶ！！誇っていく！

Today's Osusume Books

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

急遽生やしたことにより、"それっぽい本"が思い浮かばず、今日はお話とあんまり関係ない部分の本を持ってきました！！この本はわりと分厚く（私が読んだ本調べ）分量もあるので、ちょっと時間かけて読んだ気がします。

スクラムの話ではなくあくまで"アジャイルな"見積もりと計画づくりの話なのですが、読んでいきながら「スクラムでいうあの部分のことっぽいな〜」となりながら読み進めていけました。

完全に一致するような事象でない限り、"正確な見積もり"ってマジで存在しないのでそこに真を求めるのはへんてこな話、だが見積もりの行為自体（見直す事）に意味があるんだな、という気持ちになりました。

あとは、最後の章が、"ケーススタディ"として、今までのを総括できる「物語」がついています！これがめちゃくちゃ良い。ぶわーっと今までのが復習できます。最初にこっち読んでどんな話が書いてあるか予想して中身を読んでいくとめちゃくちゃ楽しそう！！

他に印象的だった話を書いていきます。

不確実性コーン

やっぱり何といってもここ...読んでしょっぱな脳天を撃ち抜かれる衝撃あります。（？）見積もりに対して、「これを信じて頑張ろう」とか思わなくなる、それが1番最初に書かれています。特に最初にガーッとやった見積もりなんて、マジで意味なさそう、という気持ちになりました。

どのやり方にも、それを使うのがふさわしい局面がある。しかし、いずれのやり方を採用するにせよ、ベロシティの見積り結果は幅で表現するべきだ。たとえば、あるチームのベロシティをイテレーションあたり20ポイントと見積もったとしよう。この見積りが正確である可能性はとても低い。実際のベロシティは21ポイントかもしれないし、 19ポイントかもしれない。 20,0001 ポイントになるかもしれない。したがってベロシティの見積りは「20ポイントです」と断言するのではなく、幅で表現しよう。「15ポイントから24ポイントです」と言うのだ。

（16章ベロシティの見積もり）

ベロシティの話でも不確実性コーンについて言及されていました。なるほどな〜〜確かに、といった感じ。 "ベロシティが安定していくと良い"とは言われますが、その安定もきっちり同じポイント、ではなくだいたいこの幅で自分たちができる、とみていくのが良さそうに思いました。

不確実性に備えるバッファの計画

アジャイルな計画づくりについて私がよく耳にするのは、「場合によってはうまくいかないのではないか」というものだ。（中略）こうしたリスクの備えとしては、スケジュールにバッファを組み込むのが有効である。バッファとは、見積もり誤差を吸収するための余裕である。不確実性が高かったり、誤りの代償が高くつく場合、バッファを組み込むのは賢い選択だ。バッファはプロジェクトを不確実性の影響から守ってくれる。

（17章不確実に備えるバッファの計画）

フィーチャーバッファ
- 要求の優先順位とすべての提供を確約しない場合の用意バッファ
- 例えばスプリントの30%はオプション的な立ち位置のフィーチャにする、など
スケジュールバッファ
- 50%の見積もりと90%の見積もりの差の平方を求め、その値の合計の平方根を算出する方法

本の中では上記の2つが紹介されていました。また、組み合わせるのが良いともされていました。

"フィーチャーバッファ"に似た様な話として、自分たちのチームではプロダクトバックログ自体に「松竹梅」を出して相談を進めていくことが多いです。プロダクトオーナーとの機能と工数のすり合わせ、みたいなことによく使っています。梅でもいいからスプリント内に全部終わるのがいいのか、特定のバックログに関しては竹までいかなきゃだめそう、とか、そういう場面で目線のすり合わせに使えます。

"スケジュールバッファ"...とはちょっと違う話ですが、自分たちのチームでは"リファクタリングタイム"を毎スプリント必ず設けることにしていました。（エンジニアがレトロスペクティブで提案してOKとなった）スプリント内に明確に隙間を残す（それが上記の様なスケジュールバッファであったり、単にリファクタリングの時間だったり）ことは自然な選択としてしてそうな感じがあります。

そもそも、"バッファ"みたいなものを用意しておこう、の様な明確な記述はここが初めてだったので（多分）、公式にそれを採用して良いんだ、という気持ちになりました。とはいえよく考えたら自分たちでいうと、似た様なことしてるなぁとなったので、不確実なことに挑戦している以上、それこそ"幅"を持たせることは自然な行為な様な気もします。

あとは狩野モデルの話もめちゃくちゃ良かったし......、第6部の「なぜアジャイルな計画づくりがうまくいくのか」の部分がぶっちゃけめちゃくちゃ本質だったりするし......色々感想があった気がするんですが、なんと読書メモを紛失してしまったと、感想文書くのも思い出しに時間かかったのでだいぶ理解が浅かったりしながら進めたところもありそうです。来年もタイミング見計らって読みます...........(•̀ᴗ•́)و ̑̑