もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

CSPO研修(認定スクラムプロダクトオーナー研修)で学んだ「ROIを考え抜く姿勢」

今回はCSPO研修での学びをまとめます。

 

CSPO研修とは?

CSPOとは"Certified Scrum Product Owner"の略で認定スクラムプロダクトオーナーという意味です。認定スクラムトレーナー(CST)によって開催される Scrum Alliance 認定のCSPO研修を受けることで認定されます。

training.odd-e.jp

 

つまりこの研修を受けて認定されたら「あなたをスクラム開発のプロダクトオーナーとして認めます」となるわけです。

 

プロダクトオーナーとプロダクトマネージャーの違いは?

このブログは「プロダクトマネージャー」について書いていますが、プロダクトマネージャとプロダクトオーナーは違います。

 

まずプロダクトオーナーはスクラム開発の役割の一つです。よってスクラム開発をしていない組織ではプロダクトオーナーは存在しません。

 

 

次にプロダクトオーナーの定義を見てみましょう。

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

 

https://www.scrumguides.org/scrum-guide.html#team-po より引用

 

最初の太字の箇所の通り、「開発チーム(=スクラムチーム)の仕事によって生み出されたプロダクトの価値を最大化する」のがプロダクトオーナーのミッションです。 

プロダクトマネージャーも「プロダクトの価値を最大化する」ことに対して責任を持つのは同じですが、プロダクトマネージャーは開発チームのみならずセールスやマーケ、CSなどあらゆるリソースを使ってプロダクトの価値を最大化することがミッションです。(これはあくまで持論なので、別の考え方もあると思います。)

 

どんな研修か?

3日間朝から晩まで研修をします。座学も少しありますが、ほとんどがワークショップです。認定の基準は「プロダクトオーナーとしての心構えや知識、行動を身につけられたか」であり、特にテストとかがあるわけではないので積極的なワークショップへの参加と発言が求められます。

 

だいたい30人くらいの受講生に対して、トレーナー(CST)は1人です。ちなみに私の時は江端さんという方がトレーナーでしたが、凄まじいトレーナーでした。受講生それぞれの発言を全て覚えていて、前回の発言と矛盾していると刺されます。

とにかく受講生に「考えさせる」ことがうまく、なかなか答えを言ってくれません。また本質を理解していないと江端さんの言っていることも理解できないので、一瞬たりとも気の抜けない研修です。(眠くなることは全くありませんでした)

 

研修の内容がネタバレすると学習効果が薄くなってしまうので細かい内容については言及しません。

 

この記事では研修から得た一つの大事な観点をまとめます。

 

 

ROIを考え抜く姿勢が大事

まず研修の冒頭ではプロダクトオーナーの役割が定義されました。

 

スクラムチームのROIを最大化する」

 

つまりスクラムチームに投入した"I"(=Investment)から発生する"R"(=Return)を最大化することが役割です。

なお上述した通り、あくまでプロダクトオーナーの責任範囲はスクラムチームであり、その他のステークホルダーは対象外となります。

 

ではここで言う"I"(=Investment)と"R"(=Return)は何か?

 

Investmentは人・モノ・金がよく言われますが、それ以外にも時間なども含まれます。

Returnはプロダクトにおける価値で、例えばプロダクトのユーザ数やCVRなどです。ただしこのReturnの定義をわかりやすいユーザ数とかCVRとかだけに限定してしまうと、プロダクトバックログにおける技術的負債解消やチーム成長などのタスクの優先度が必然的に下がってしまうので、Returnの定義に制約はつけない方が良いです。

そこで「誰に対する価値なのか」を定義するとわかりやすくなります。ユーザやクライアントに限らず、ステークホルダーやチームメンバーという選択肢もあります。(研修ではこの「誰」を"Market"と表現していました。)

ただしReturnは「測定可能であること」が求められます。何をもって「最大化したのか」を評価する必要があるためです。また最大化はあくまで相対的なものなので、まずは現状の測定をし「現状からどれくらい変わったのか」を表せるようにならないといけません。

CVRであればすぐに測定できますが、例えば技術的負債の測定は容易ではありません。「技術的負債によって発生した不具合や手戻りによる時間的ロス」を可視化するような取り組みが必要です。

 

ここが一つ難しいところです。

 

次にROIを考える上では下記の表の考え方が重要になります。

f:id:swnws322:20181126224020p:plain

まず大前提としてInvestmentもReturnも実績(=未来)はコントロール不可能です。スプリントを回している際に予期せぬ事態が発生したり、市場や競合などの環境の変化によって実績も変わっていきます。

コントロール可能なのはInvestmentの予想だけ。Returnの予想もある程度は可能ですが、未熟なチームでは予測基準が無いためあてになりません。

 

つまりプロダクトオーナーは

「Returnを最大化するためのInvestmentをコントロールして投入すること」

が重要な仕事になります。

それさえやれば実績は自然とついてくるのです。ついてこない場合は、Investmentのコントロールが不十分か、Return予想のロジックが間違っているということになります。

 

イメージはこんな感じです。

 

f:id:swnws322:20181126230148p:plain

 

この「Investmentのコントロール」にはコツがいります。

重要なのは「Returnの制約にならないこと」です。つまりそのInvestmentを投入すると、提供するReturnの種類が決まってしまうような事態を避けるという意味です。

例えば、カスタマーへの機能の充実化が今最大化すべきReturnと定義した場合、クライアント担当部署からInvestmentをもらってしまうと、クライアントのための機能をReturnとして期待されてしまいます。そうなると本当のReturnの最大化が不可能になってしまいます。もちろんこの場合カスタマー担当部署からのInvestmentであれば、目的が一致するため問題ありません。

この制約条件も気にしながらInvestmentをコントロールして準備し、スクラムチームに投入する必要があります。

 

まだスクラムチームが未熟なうちは、このInvestmentを可能な限り少なくすることをオススメします。Investmentが大きいほど複雑性が増し、Returnの予想と実績の乖離度合いが大きくなります。まずは小さくスプリントを回して実績を積み、コントロールのコツとReturnの予想ロジックを磨きながら少しずつInvestmentを大きくしていくと、大きな失敗の発生リスクを軽減できます。

 

 

ここまでROIの考え方をつらつらと書いてきました。ROIと一口で言ってもこんなにもいろいろ考慮して定義しなくてはいけません。研修では3日間ずーっとこの考え方が徹底できているか問われます。問われすぎて2日目の夜に「身の回りのこと全てをROIで表現しないといけない世界で苦しむ夢」を見ましたw

 

考え方は理解していても、意外と実践できません。

例えばReturnが測定可能と思っていても測定方法が厳密に定義できていなかったり、InvestmentがReturnを生み出す活動以外に使われてしまっていたりと、自分ではちゃんとやってるつもりなのに論理的に矛盾してしまったり欠陥があったりします。こういうところをトレーナーの江端さんに次々と指摘されます。

これはもう実践あるのみです。理論を理解しただけでは不十分です。なのでぜひこの研修でトレーニングを積み、かつ自分の現場で実践することをオススメします。

 

まとめ

というわけで、CSPO研修で学んだプロダクトオーナーとしての大事な役割についてまとめました。プロダクトオーナーは「ROIを考え抜く姿勢」が求められるということをしっかりと心に刻むことができました。これ以外にもこの研修では「Doneの定義」や「プロダクトバックログの作り方」など様々なことを学べます。

費用は高いですが、スクラムチームのプロダクトオーナーを目指す方、既に実践していてレベルアップしたい方は受けてみてください。

 

最後になりますが、私はこの研修を受けて無事にCSPOに認定されました。認定基準が明示されていないので正直不安でしたが、このアイコンを名刺につけられるようになってよかったです。

f:id:swnws322:20181126234015p:plain

 

【スポンサーリンク】