『プロフェッショナル プロダクトオーナー』を読んで印象に残った9つのこと
2024年7月に発刊された日本初のプロダクトオーナーの本を読み終えたので、印象に残った9つのことを残しておきたいと思う
どんな本か
まずどんな本かざっくりいうと、プロダクト開発を成功させるには会社のビジョンから開発者の日々の計画までに繋がりが必要になるけれど、組織的目標と開発チームの作業の間には往々に「プロダクトマネジメントのすきま」があることが多いので、その「すきま」を埋めるための戦略と戦術についてPOの手助けになるようなことが書かれている本になる。
印象に残った9つのこと
①プロジェクトマインドセットとプロダクトマインドセットの違い
プロジェクトマインドセットにおける成功は、期間や予算、スコープなどのタスク管理や初期計画がどれだけ忠実に遂行されたかを内側から計測する「インサイドアウト」の定義。
それに対しプロダクトマインドセットにおける成功は、プロダクトを通じて価値（ユーザの獲得/維持、収益、コスト節約など）を外側から計測する「アウトサイドイン」のアプローチであるというもの。
プロジェクトマインドセットだと、ビジネスの価値が弱まり、タスクの管理が強まることになるが、プロダクトマインドセットであれば、無駄が減り、創造性が高まり、リリースが増えるということになる。
②3つのV
プロダクトを開発するにあたっては以下の7つの計画のレイヤーが存在する
会社のビジョン
ビジネス戦略
プロダクトビジョン
プロダクト戦略
リリース計画
スプリント計画
日々の計画
上記の1、2は経営陣やCEOが掲げる組織的目標、6、7は開発チームのものになるが、その中間に「プロダクトマネジメントのすきま」（3、4、5）がある。
会社のパーパスと日々の作業の繋がりのようなものになるかと思うが、そのすきまを埋めるのが下記の3つのVと呼ばれるものになる。
Vision（ビジョン）：3のプロダクトビジョンを埋めるもの
Value（価値） ：4のプロダクト戦略を埋めるもの
Validation（検証）：5のリリース計画を埋めるもの
③ビジョン（Vision）
Zingerman’sの共同創業者であるAri Weinzweigによると、ビジョンとは、将来のある時点におけるプロジェクトの成功イメージで、「北極星」のようなものと考えているというもの。生涯をかけて追い求める終わりのない作品であり目的地ということで、アジャイルの掲げているものと通ずるものがあると感じた。
また優れたビジョンは、自分が何をすれば良いかを聞き手が想像できる（実行できる）ときや、心の琴線に触れる（心に響く）ときに、より記憶に残るものになるので、プロダクトにおけるビジョンをつくった際には、この4象限の右上に当てはまるか確認してみようと思う。
④価値（Value）
プロダクトを開発しているとどうしてもあれもこれも欲しいといった話になってしまうが、その際には「もし、たった1つしか持てないとしたら、それは何ですか？」という質問をしてみると良い切り口になるというもので、以下の言葉はとても印象的。
すべてのものが大事だったら、何も大事じゃないのと同じです
価値の測り方の手法のひとつとして、根拠に基づくマネージメントの方法であるエビデンスベースドマネジメント（EBM）というものがあり、プロダクトが生み出す価値の事実として機能するEBM指標がエビデンスベースドマネジメントガイドに記載されているというもの。
EBMについてはまだまだ勉強が必要そうだけど、先行指標と遅行指標を区別することが重要で、例としてあったダイエットをするという最終目標に対する「遅行指標」が体重であり、「先行指標」になるのが食事量や運動量という例えは非常によく分かりやすかった。
また、プロダクトがどれだけイノベーションを生み出しているか計測するイノベーション率の測定方法があり、測定方法としてはブロダクトバックログアイテムのうち、新しいフィーチャーのアイテムの数と、技術的負債、バグ、メンテナンスのアイテムの数を比べるだけでできるということなので、スプリントごとに計測していってみようかと思う。
ただ、指標については良い目標となる一方で悪用される可能性もあるので注意が必要ということを表しているのが「グッドハートの法則」というもの
尺度が目標になったとき、それは良い尺度ではなくなる
インドの英国直民統治時代の逸話で、政府がコブラの数を減らそうと死体1匹につき報奨金を出したところ、収入の足しにするためにコブラを繁殖させようとする輩が現れてしまい、結果として野生のコブラが増えてしまったという話は印象的であった。
⑤検証（Validation）
計画は決められた進路が価値につながるという仮説にすぎないというもので、以下の言葉が印象的で本当にその通りだと感じた。
計画は役に立たないが、計画づくりは不可欠である
まさにこれは上記①のプロジェクトマインドセットのことになると思うので、プロジェクトに関わるメンバ全員がプロダクトマインドセットを持つことが重要になると思う。
⑥プロダクトバックログの並べ方
スクラム開発をしていると間違いなくPOを悩ませることになるバッグログの並べ方の方法について。
ステップ1：リスクの重み付けをする
まずは発生確率と影響度について、それぞれ高、中、低の重み付け（例：高＝10、中=5、低=1）をして、それをトータルでのリスクとする
全体のリスク＝発生確率 × 影響度
ステップ2：プロダクトバックログの並び順を決める
以下の計算式に、ビジネスとしての収益、インパクトであるビジネス価値を。また、サイズにはストーリーポイントによる算出を行い、リスクは上記ステップ1での算出結果を当てはめる
（ビジネス価値＋リスク）÷ サイズ ＝ 並び順
バックログの並び順については、しばしPOの主観や開発チームの誘導によって行われてしまうことがあったりするので、上記のような計算式として明示化して表すのは良い方法だと感じた。ぜひやってみようと思う。
⑦スクラムはプロセスではなく、フレームワーク
スクラムをプロセスとして捉えてしまうと、何かチーム内で問題が起きたときに、その問題をプロセスのせいにしてしまうというもの。
これは本当に同感で、スクラムにあまり理解がないメンバーと一緒に開発をしているとしばしこういう声があがり、スクラムと関係ない問題であるにも関わらずスクラムのせいにしてウォーターフォールで開発したいという話があがるということが何度かあったので、非常に共感できた。
賃貸と持ち家の例えも分かりやすく、何か問題あった際に賃貸だと不動産屋に文句を言うけど、持ち家だったら自分で解決するといったように、スクラムをいかにフレームワークとして捉えてもらうようにするというのはスクラムマスターの大事な役割なのだと感じた。
⑧スクラムがもたらすもの
スクラムは問題を解決しません。問題を露わにします。
上記のプロセスの話にも通じるけど、アジャイルを導入したからといって早くリリースできるとか問題が解決するものではなく、スクラムは問題をみえる化するフレームワークというのは非常に納得で、その通りだと思う。個人やチームの問題を浮き彫りにし、みんなの問題にして、いかにみんなでその問題を解決していくか。そういったことができるフレームワークがスクラムだなと思う。
⑨プロダクトオーナーはCRACKであり続ける
バリー・ベームとリチャード・ターナーの著書『アジャイルと規律ーソフトウェア開発を成功させる2つの鍵のバランス』にて紹介されている理想的な顧客を表すCRACKというものがプロダクトオーナーのスキルや特性を上手く要約しているとのこと。そのCRACKとは・・
Collaborative：協力的である
Representative：顧客の意思を代表する
Authorized：権限を持っている
Committed：献身的である
Knowledgeable：知識を持っている
こんなプロダクトオーナーがいたら、まさに理想のプロダクトオーナー像であるなと思う。
まとめ
大企業におけるPOはどうしても他業務との兼務で忙しく、受け身のメンバーが多かったりすると思うけど、本格的にスクラムをやり始めてから4,5年経って感じるのは、スクラムにおいては本当にプロダクトオーナーという役割が大事だということ。今まで何人かのプロダクトオーナーと一緒に開発をしてきたけど、本当にプロダクトオーナー次第で、開発メンバーのモチベーションも変わり、結果プロダクトの質にも影響してくると身をもって感じている。
そのプロダクトオーナーに関する日本で初の指南書である本書は、ぜひ日本中のプロダクトオーナーの皆さんに見てもらえると良いなと感じるお薦めの一冊でした。