【メモ】チーム・ジャーニー第8話本読み会
PO代行
開発チームは、 ..(省略).. 当然関心事はどうやってつくるかが中心になる
プロダクトオーナーはその役割上、何をつくるべきが？が最大の関心事だ。
両者のリテラシーの差、両者の関心の差が分断をもたらす
両者の差を吸収する立場が必要となる。それがプロダクトオーナー代行(PO代行)という役割。
スクラムマスターとは敢えて役割を分けるところがポイント。
著者が経験された現場では大抵PO代行が必要だったそうだ。
私の現場では「スクラムマスターが類似の役割を兼ねている」という気づきがあった。PO代行とスクラムマスターで分離してそれぞれの役割を明確化できそうだ。
「これスクラムマスターの仕事ですか？」という疑問が過去に上がっていたことを思い出した。役割を明確化できていないという現状を踏まえると、すぐにでもアクションしたい。負荷も高いし。
質問：「デザイナーがPO代行を担う設定は偶然？」
書籍の設定の話だ。序盤から気になっていたため質問した。
偶然ではない。
デザイナーは開発チーム内でユーザーとの最も距離が近く、もっともユーザーと向き合い、対話を重ねる立場である。
そういった職種の特性からPO代行を担う場合があるそうだ。しかし、エンジニアリングの知識（≒どうつくるか）がある程度ないと、PO（のような立場）が二人になってしまい代行の意図する役割を果たせない。PO代行とも分断が発生してしまうかもしれない。
コメント：プロダクトバックログリファインメント
書籍内でプロダクトバックログが積み上がっていることに関する話題
以下はコメントの引用。
プロダクトバックログが大量に積み上がらない戦略として、
①つくるかどうか分からないものは、決定を遅らせるためにICEBOXに放り込んでおく。
②定期的にプロダクトバックログを整理する
あたりができそうかと思いました。
私の現場では、半年経過したプロダクトバックログアイテムを対象に②を毎月見直ししています。
アイスボックスについては、「正しいものを正しくつくる」の3つの余白戦略の一つ受け入れの余白に記載している。確認しよう！(p.139)
なお、整理には基準が必要。時間軸を基準にするのはありだそうだ。
整理の仕方は「バッサリ捨てる」で「すっきり」がベターそうだった。
私の現場では、削除はせずにプロダクトバックログの外に出しているだけで全て自動的に消すわけではない、外に出した後に「これ必要だよ」と戻ってくることも。
過去にお蔵入りしたプロダクトバックログアイテムが、また出てきた際に「当時はなぜやらないことにしたんだ？」ということが話題になり、トラッキング性を考慮して残している。
明確な理由があった上で、再登場し優先度が上がってくるのだから削除してしまっても良いかもしれないと気づきがあった。過去と今は状況が異なるのだから。
機能一覧≠プロダクトバックログ
プロダクト開発において、プロダクトバックログが積み上がること自体はプロダクトをしっかり見ていることだから問題ない。むしろ増えていかないとよくない。だから整理が必要になる。
減っていくケースとしてありそうなのがSIerさんの業務では機能の一覧を倒していくことが考えられそうだが、機能一覧はプロダクトバックログとは異なることに留意したい。
SIさんの「プロジェクトは終わらせるもの」。「プロダクト開発は終わらせないもの」という文脈がありそうだ。
私はSI未経験のため想像です。