CSPO 研修でのマナビ
はじめに
品質マネジメント部の伊藤です。
品質マネジメント部のリーダーでありつつ、アプレッソの主力プロダクトであるDataSpider Servista の スクラム開発におけるプロダクトオーナーを担当してます!
本記事は、2/7(水) ~ 2/9(金) に、認定スクラムプロダクトオーナー研修に参加してきて得たものまとめたものです。
※認定スクラムプロダクトオーナー研修(CSPO)は、認定スクラムトレーナー(CST)によって開催される Scrum Alliance 認定研修です。
Scrum におけるPOとは
PO とは ROI を最大化することに責任を持ちます。
「ROI」を最大化するには、Investment(投資)を減らし、Return (効果) を増やす必要があります。
「I」と「R」を考えるとき、「R」を増やす方に注目してしまう人が多いのではないかと思いますが、まず考えるべきは「I」です。
というのも、「I」はコントロールしやすく定義しやすいですが、「R」はコントロールしにくい上、定義しにくいからです。
「I」と定義してみると以下のようなものがあげられます。
- 時間
- お金
「R」を定義してみます。
- お金
- 技術
- スキルアップ
- 効率化
- プロダクト価値の向上
- 喜び
・・・などなど
「R」は、どのような人 (モノ) によっても変わってきますし、影響範囲(※)をどこまでにするかによっても変わってきます。
(※) あるプロダクトの改修を行った場合、プロダクトそのもの価値向上はもちろん、それを使うユーザへのプラスの影響、さらには開発者の技術力向上にもつながるかもしれません。さらにその先・・と考えると影響範囲は無限大になりそうです。
ということもあり、コントロールしやすく定義しやすい「I」から考え、どうすれば「I」を減らせるのかということを考えていくのが定石といえます。
その次に「R」を考えていきますが、前述の通り難しい課題であります。
各プロジェクトやサービスのコンテキストによっても大きく変わるため、どうすればよいかという明確な答えはありませんが、常に意識していくべき課題です。
様々なステークホルダーが気にするポイントでもあるため、プロダクトの価値を明確にしておくというのも PO にとって大事な仕事です。
※ちなみに研修期間中は、ひたすら ROI について深く考えさせられる内容でした。
いかに普段の業務で、ROI を考えていないなぁと痛感・・・(ツライけど充実
印象深かった学び
ここからは特に印象に残ったキーワードを元に、研修を振り返ってみます。
「優先順位はPOが決めるものじゃなく、決まるもの」
スクラムガイドには、バックログの優先順位は PO が決定するとあります。
となると矛盾しているように見えますが、真意は別のところにあります。
ここで伝えたいことは、PO の勝手な判断で優先順位を決めてはならないということです。
PO の勝手な判断とは、以下のようなことです。
- 目先の要望を優先してしまい、本質的にやるべき課題の優先度を下げる
- 技術的負債の影響度は明確ではないが、不安なため優先度を上げる
- 存在しないユーザ像を勝手に作り上げ、求められていないサービスを提供する
などなど...
これらは根拠が弱く、PO の嗜好や思考が大きく影響しています。
これでは、マーケットの ROI を最大化することはできません。
ではROIを最大化するには、どうするべきか。
それには、優先順位を決めるにあたって必要な情報をしっかりと集めることです。
極端な話、情報が完璧であれば、どのPOが優先順位をつけても同じ並びになるということです。(PO がそれなりに優秀であることが前提になるとは思いますが...)
それが 「優先順位はPOが決めるものじゃなく、決まるもの」の真意です。
根拠ある情報が十分そろえば、必然的に優先順位が決まるということです。
「PO のマーケット」
PO のマーケットとは、どの範囲でしょうか。
つまり PO は誰 (何) に対しての ROI を最大化する必要があるのでしょうか。
答えは、「プロダクトに関わる人(もの)すべて」です。
つまり・・・
- プロダクトそのもの
- プロダクトを利用するユーザ
- スクラムチーム
- スクラムマスター
- その他もろもろのステークホルダー
などなど、挙げればキリがありません。
プロダクトのみに注目してしまいがちですが、プロダクトに関わる人たちの ROI が向上すれば、結果的によりよいプロダクトにもつながります。
PO がマーケットと考えるべき範囲は、実はかなり広大なのです。
「ROI を最大化させる際の PO の思考性 」
どの課題を解決して、どのくらいの効果が見込めそうか。
それらを考える上で PO としてはどのように考えたらよいでしょうか。
基本的な考え方としては「ポートフォリオ」で考えます。
課題の特性によって分類し、より多くの分類に属する課題に効果があると考えられる施策を打つようにします。
例えば、A、B、C という特性の分類があり、A、B、C それぞれに課題が 3 つずつあると仮定します。
その際に、以下のどちらの施策を選択したほうがよいでしょうか。
- 特性 A に属する、3 つの課題を解決する施策 X
- 特性 A、B、C に属する課題を 1 ずつ解決する 施策 Y
選択すべきは、「施策Y」です。
特性Aの課題が実現場では課題ではなかった場合など、想定課題が誤っていると「施策X」はまったくの無駄になってしまいます。
その点、「施策Y」は特性Aが外れても、それ以外が外れなければ、まったくの無駄になるということはありません。
これがポートフォリオ的な考え方です。
つまり、似たような課題を多く解決する施策をうつのではなく、より多くの特性の課題を解決する施策をとるほうが得策ということです。
そのためにはまず、多くの課題を見つけておき、その課題の特性の数もより多く持っておく必要があります。
よって、課題を見つける際には、もっとも重要な課題のみをピンポイントで見つけにいくのではなく、重要そうではないものも含めて持っておくべきです。
「リカバリープラン」
冒頭の方で、「Investment(投資)」を減らすことをまず考えるべき、というような話をしましたが、プロダクトを開発して利益を得ることだけに焦点を挙げれば、開発作業は、「I」にしかなりません。
想定どおり物事が進めば、スムーズに開発が進みますが、現実的にはあらゆる場所に落とし穴が潜んでいて、想定外のコストが発生します。
よって、POとしては想定外のことが発生した場合に、いかに低コストで軌道修正できるかが求められます。
そのためには複数のリカバリープランを用意しておく必要があります。
例えば、プロダクトバックログリファインメントにおいて、PBIの内容を開発チームと精査していたとします。
その際、受け入れ条件が開発する上で現実的ではないとなったら、POが持ち帰って再検討しなくてはいけなくなります。
このような想定外の事態に対応するために、PO としてはリカバリープランを複数持っておく必要があります。
この例ですと、例えば受け入れ条件案を複数準備しておけば対応できたかもしれませんし、PBI の内容だったり大きさを変化できるように準備しておく必要があったかもしれません。
いずれにせよ、PO としては様々なことを想定して、様々な対策を考えておく必要があります。
なお、研修中に言われたこととしては、1つの PBI に対して、リカバリープランを3つは用意する必要がある、とのことです・・・。がんばります!
最後に
印象深かった学びを中心に紹介しましたが、いかがだったでしょうか。
これらは研修中に学んだことの、ごく一部です。
しかも、一番印象深かったことはこの記事には載せていません。
なぜならば、一番印象深かったことは研修中の「体験」そのものだからです。
こればかりは体験してもらう必要があり、言葉で伝えることができません。
知識を得ただけではなかなか行動を変えることは難しいものです。
体験によってマインドや考え方に変化が生じ、行動が変わってくるのではないかと思います。
研修受講による ROI を最大化するためにも、得られたものを元にしてこれからの活動に活かしていこうと思います。