まずプロダクトオーナーって何かおさらい
スクラムガイド（2017）には以下の通り定義されています。
プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。 (中略) プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。
プロダクトオーナーは1人が基本であり、プロダクトオーナーにはプロダクトの価値を最大化する責任がある。優先順位についてもプロダクトオーナーの判断が全て。
ということになります。
1つのプロダクトの価値を、外部環境・内部環境から総合的に判断できる知識と経験。仮説検証し、やらないものはやらないと言える決断力。これらが求められるのがプロダクトオーナーの厳しさだと思います。
では、開発現場でよく困ることってなんでしょう？
プロダクトオーナーが複数人立ってしまう
これは現場が非常に困る要素の１つです。判断を仰ぐべき人間が複数いるということはそれだけでスピードが落ちますし、場合によっては何度も行き来するなんていう最悪のことさえ起こりえます。
一人にしてもらうことが必要ですが、その組織において一人にできない原因をちゃんと考えて対策を講じる事のほうがより重要だと思います。
プロダクトオーナーがつかまらない
プロダクトオーナーがこの業務に集中できない状態にあると、まったく捕まえることができなくなって開発スピードが落ちてしまいます。
プロダクトオーナーになる以上、プロダクトオーナーという責任とその難しさをしっかりと認識してもらい、その時間が確保できる状態にすることが重要です。
プロダクトオーナーという言葉だけが先立っていないか？ちゃんと説明されているか？はとても重要なファクターになると思います。
何を作るべきなのかなかなか決まらない
プロダクトオーナーの判断がスムーズにいかないと、当然何を作るべきなのかが決まらず、本来のアジャイルのスピードが損なわれてしまいます。決まらない要因は、時間がなかったり、判断する情報や経験が足りなかったり、様々なんだと思います。
これらの状態が生まれると、プロダクトオーナー自体がボトルネックになる危険性が出てきます。しかし、プロダクトオーナーになれる人間はそうそう替わりのいない人ばかりです。
では、なにかチームで補っていく方法はないでしょうか？
プロダクトオーナーをチームで補完するには
ちょうど参考になるドキュメントがあったのでこちらを参考にさせていただきます。
＜スライド＞正しいものを正しくつくる / Do the Right things Right（市谷 聡啓さん）
＜amazon＞正しいものを正しくつくる（著：市谷 聡啓さん）
この中で語られているのは「プロダクトオーナーの民主化」という話になってます。
以降、書籍とスライドの内容から抜粋してお話しますので、詳細はぜひ書籍をご覧ください。
なぜプロダクト開発は今だに苦労するのか
なぜアジャイルという開発手法が取り入れられて尚、開発現場は今も苦しんでいるのか？
それは、プロダクト開発とは、「誰も正解を持っていないものを、それでも形にする」ことにあり、その不確実性に対して立ち向かわなければいけない。ということです。
「不確実性」は「多様性」から生まれている
「多様性」とは、「プロダクト自体」と「とりまく人間（いわば、ステークホルダーですかね）」に分かれる。
「プロダクト自体」の多様性とは、「SoR（System of Record）」と「SoE（System of Engagement）」と「技術」があり、
「SoR（System of Record）」は、例えば、入出金のような情報を記録・管理するシステムを指し、それには「信頼性（堅実性）」が求められる。
「SoE（System of Engagement）」は、例えば、SNSのようなユーザーとの関係性（操作感や達成感など）が求められるシステムを指し、それには市場投入するスピードと検証と改善を繰り返す柔軟性が求められる。
そのため、この２つは、トレードオフの関係性で、両立ができない。
そして「技術」は、開発言語から環境まで日進月歩に進んでいて状況はどんどん変わっていく。
これらが、「プロダクト自体」の多様性が生む「不確実性」です。
そして、「とりまく人間」は、「作り手」「役割」「経験」「働き方」など、個人の状態の多様性が生む「不確実性」です。
おわかりの通り、これらの「不確実性」から逃れるすべはない。ということですね。
では、この「不確実性」とどう戦うか？ということになります。
「不確実性」への戦い
「不確実性」と戦う術として提示されているのが「仮説検証」です。
「仮説検証」は、「プロダクトとして何が正しいか」は誰にもわからないのだから、それを見立てて、チームの共通理解にする活動。と定義されています。
そして、この「わからないもの」を「わかるようにする」んじゃなく、
「わからないものを増やそう」＝「新たな理解の獲得」に向けたチーム全体の越境が必要だと。
すると、もう、一人の手に負えるようなものではなくなるので、
「不確実性」には「チームの多様性」で立ち向かっていこう。
そして、チーム全体が越境するようになると、もはやそのチームは「一人に人間のようになる」
これが「共創」であり「プロダクトオーナーの民主化」だと、説かれています。
ここまでが書籍にある概略となります。
非常に現場観としても腑に落ちる内容でした。
では実際、どうプロダクトオーナーを補完していけるんでしょうか？
プロダクトオーナーをチームで補完するためには
① プロダクトマネージャーによる補完（ビジネスモデルを補う）
ビジネスモデルに弱い部分をプロダクトマネージャが補うフォーメーションですね。
例えば、営業戦略を担う方や、サービスの方向性を決定づけられる方が適任になります。
② UIデザイナーによる補完（ユーザビリティを補う）
ユーザビリティに弱い部分をUIデザイナーが補うフォーメーションですね。
UXチームが存在しない場合は、より顧客目線に近い方が担うことになります。
が、何れにしても代行するには条件があります。
なぜプロダクトオーナーが代行できるのか？それは、
前述の全体像でも説かれていたとおり、これに尽きるということですね。
下記のページにも書かれていますが、
そもそもプロダクトオーナーも正解を持っているわけではない。
仮説検証を実施し、そこで得られた学びをチームで分かち合う。
実質的にはPO代行≒POに他ならない
この通りで、どれだけチーム全体で足りない所を補い合って、その集合知をプロダクトに活かせるか。ということだと思います。
そして、最終的にはプロダクトオーナーが１人になっていくように進んでいくべきなんでしょう。
それが、プロダクトオーナーの民主化。という論点になっています。
弊社でも決して上手く行っているわけではなく、こうなっていかないといけないのかな。という課題感を持って書かせてもらっています。
正しいものを正しくつくれるようになりたいですね。