概要
最近、認定プロダクトオーナー研修（CSPO®）を受講することが出来たので
熱量がキープ出来ているうちに研修を通して学んだことを書き留めておきます。
研修の内容等は都度変わると思われるため、ネタバレ等を記載するものではなく、
受講を検討している方の後押しになる様な内容になればと。
認定プロダクトオーナー研修（CSPO®）って？
認定スクラムトレーナー（CST）によって開催されるScrum Alliance認定のプロダクトオーナー向け研修です。
私が今回受講したのは日本人唯一のCSTである 江端一将（ebacky）氏のもの。
受講対象は現役のプロダクトオーナー、プロダクトオーナーになる予定の方、スクラムの理解を深めたい方になると思います。
研修と銘打っていますが、単なる座学ではなく個人ワークやグループワークを中心としたトレーニングになります。
受けたらどうなる？
生半可な覚悟では務まらないんだという、
プロダクトオーナーの大変さを身をもって体験することが出来ます。
出された課題について考える
↓
課題が解けない…
↓
実際の話も交えて現実のプロダクトオーナーがこれでは話にならないと指摘される
↓
考える（けど解けない）
↓
何が悪いかの解説（答えは言わない）
のループ。
※ 解ける解けないは個人差があります
ちなみに私は研修中と終わってから数日は課題と向き合う夢を見ました。
ROI最大化… ROI最大化… ROI最大化… ROI最大化… ROI最大化…
ここで面白そうだからやってみたい！と感じた人には是非おすすめします。
認定ってなに？
トレーニングを通してCSTに認められ、Scrum Allianceに登録されると認定スクラムプロダクトオーナーとなります。
なったからといって別にプロダクトオーナーが務まるわけではないのですが、
Scrum Allianceの公式サイト上でCSPOしかアクセスできない文献などを読むことが出来るそうです。
認定されるには、前提条件として連続30時間(1日10時間を3日)の学習が必要です。（多忙な方は時期を調整した方が良いです）
そして連続30時間のトレーニングの中でCSTに対して積極的に能力をアピールする必要があります。
ちなみにプロダクトオーナーは天賦の才で務まるものではなく
実践の積み重ねによってのみ成りえるものとのこと。
研修で学んだこと
圧倒的な理論によるROIとは
マーケット課題に対して解決策（プロダクトバックログ）を用いて対処しますが、
プロダクトオーナーはROI（Return On Investment）の最大化に責務を負うので、
投資に対してどれだけ大きなリターンが得られるのか戦略が必要になってきます。
ここでいうROIの対象はプロダクトではなく、
プロダクトを作り上げる開発チームに対しての投資、それによってもたらされるリターンを指します。
そこでROI最大化の観点からマーケット課題を解決できる確率を計算するのですが、
①（今捉えているものが）課題である確率 × ②課題と解決策の論理性 × ③開発チームの実現確率
という式があります。
① そもそも本当にそれが課題であるのか確認できているか
② その解決策で課題が解決出来る可能性について仮説検証したか
③ 開発チームの実現確率が入ってくるため、開発チームのスキルなど、開発チームのことをどれだけ理解しているかが重要
中でも特に需要なのが、①の課題であるかです。
ここが誤っていると以降の解決策もプロダクトに費やす労力も全て無駄になってしまいます。
マーケットの課題が揺るぎないものだと確信出来たら
「リターン ÷ 投資」が最も高い解決策を選択していく必要があります。
ちなみに開発チームの成長に繋がり、将来的に大きなリターンを得る様な投資が出来れば尚良いとされています。
プロダクトオーナーはマーケット課題に対しての解決策、その実現確率について
投資家に説明出来る状態になっている必要があります。
プロダクトバックログの取り扱いについて
プロダクトバックログの優先順位付けは重要な責務ですが、
必ずしもプロダクトバックログをプロダクトオーナーが作成する必要はありません。
プロダクトオーナーのビジョンが開発チームに正しく伝わっているのであれば、
開発チームがプロダクトバックログを作成し、プロダクトオーナーが手直し、共有、優先順位付けをするで構いません。
よく、プロダクトバックログにはWHAT（なにを）のみ書いてHOW（どうやって）を書くべきでないという様な話を聞くこともありますが、これはプロダクトオーナーがやり方も含めて記載してしまうことで開発チームの成長を阻害する可能性があるからの話で、開発チームが上げる分に関してはその限りではありません。
また、ROI最大化の観点から既定路線がボツになる可能性もゼロではないため、
プロダクトバックログには必ず実施する確度の高いもののみを上げるのではなく、
実際に実施するか分からない確度の低いものも上げておく方が良いそうです。
あと、開発チームに無縁のバックログも上げておいて良いとのこと。
これはそれを見た開発チームから何かしらのフィードバックを受けられる可能性もあるためです。
Doneな状態（Undoneを排除する重要性）
スクラムではDoneな状態であればあるほど良いとされています。
Doneな状態とは
サービス提供社（者）としてマーケットにプロダクトを提供しても良い状態。
つまりUndoneを如何に排除できるかが肝になります。
全て当初予定通り完了出来れば問題無いのですが、
予定通り進まなかったとすると…
製品のリリース計画を例に示します。
上の例だと機能の開発は全て完了しているものの、テストが未完了のためリリース出来ない状態になってしまいます。
それに比べて下の例だと機能③はリリース出来ないものの、機能①と機能②についてはリリース可能な状態となっています。
これが市場競争力を問うようなプロダクトであった場合、
MVP（Minimum Viable Product）の観点からもUndoneを排除した方が良い理由が分かるかと思います。
その他の学び
潜在的な課題を見つける方法
マーケットに潜む課題に対して解決策を打つのが基本ですが、
そもそもプロダクトオーナーが意識出来ていない課題に対して打ち手を講じることは出来ません。
ではどうするのか？ですが、
潜在的なステークホルダーが存在しないか投資家に対して確認することが有効です。
ステークホルダーは何かしらの課題を抱えている場合が多いので、新たな課題が見えてくるという訳です。
プロダクトオーナーと開発チームのプロダクトに向き合う力量が釣り合っていない場合
プロダクトオーナーの力量が圧倒的に高い場合
開発チームの成長を見守る。それでも改善の兆しが見えない場合はそのチームでは成し得ない可能性もある。
開発チームに介入してはいけない理由は、前段で述べたとおり、開発チームの自律性など成長を妨げる可能性があるため。
開発チームの力量が圧倒的に高い場合
プロダクトオーナーに対して分かりやすく説明する。（前段で述べた「マーケット課題を解決できる確率」などを用いると良い）
それでもプロダクトオーナーが納得してくれない場合は投資家やステークホルダーを巻き込む。
どうやったら成功するプロダクトを生み出せるのか？
確実に言えることは世の中の失敗したプロダクトには共通点があるということ。
ただし、世の中で成功したプロダクトを模倣したからといって必ずしも上手くいくとは限らない。
なぜなら実行するタイミングが影響するなど、成功を左右する要素が多分にあるため。
まずは、先人の失敗を糧に失敗する確率を少しでも下げる。
最後に
私の学び得たことをかいつまんで書きました。
これだけ見てもあまり参考にならないという方もいらっしゃるかと思いますが、
ここに書けていないだけで他にも学び得ることはたくさんありますし、
何よりアジャイル開発に取り組む意識は確実に変わると思いますので、
改めておすすめしておきます。