プロダクトゴールについて考えてみる

ふと早朝(朝3時)に目が覚めてしまい、プロダクトゴールについて色々考えた。

自分の中に存在する"点"がつながる時はいつも夜中に目が覚めてしまう。寝ている時に一番自分は思考が進んでいる。

プロダクトゴールとは何か

スクラムガイドにはプロダクトゴールへの言及がある。それもそのはず、スクラムガイド2020年版で追加された概念だからだ。

プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画の ターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバック ログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。

プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステーク ホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物 理的な製品である場合もあれば、より抽象的なものの場合もある。

プロダクトゴールは、スクラムチームの⻑期的な⽬標である。次の⽬標に移る前に、スクラム チームはひとつの⽬標を達成（または放棄）しなければならない。

比較的最近(5年以内)に策定された概念であり、まだまだプロダクトゴールを策定していないというスクラムチームは多いと聞く(2022年時では5%というアンケート結果がある)

ゴールは大切だ。ゴールの存在によってチームや個人は"集中"することができる。ゴールがない状態では個人おろかチームは集中することが難しい。それは、自分がなぜ今それに着手しているかがわからないからだ。

スクラムガイドの記述を読む限り、プロダクトバックログの残りの部分はプロダクトゴールを達成する「何か(what)」であると書かれている。つまり逆説的に言えば、プロダクトゴールがない状態ではプロダクトバックログは何もないということだ

そしてこのプロダクトゴールは長期的な目標であり、スクラムチームはひとつの目標を達成 or 放棄しなければならないという記述がある通り、単一の目標に対して"集中"することが意図として汲み取ることができる。

プロダクトゴールのためのスプリントレビュー

まずスプリントレビューに対するスクラムガイドの記述を読んでみてほしい。

スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。 スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対す る進捗について話し合う。スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成 され、⾃分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者 は次にやるべきことに協⼒して取り組む。

ここから読み取れる通り、ステークホルダーに作業の結果(つまり、スプリントで生み出したインクリメント)を提示し、プロダクトゴールに対する進捗を話し合うのがスプリントレビューでやることだと書いてある。

そして、この後文も読むとスクラムチームとステークホルダーはプロダクトゴールを中心に見据えつつ、スプリントで達成されたことについてレビューすることで一丸となっている構造が伺える。

つまり、プロダクトゴールというスクラムチームとステークホルダーを束ねるゴールの存在こそが、組織という単位を求心していく要素なのだと捉えた。

プロダクトゴールのためのインクリメント

インクリメントは、プロダクトゴールに向けた具体的な踏み⽯である。

インクリメントもまた、プロダクトゴールに向けた具体的な踏み石であると明確に記載されている。つまり、なぜ今そのインクリメントを生み出そうとしているのか?と聞かれた時に「こういうプロダクトゴールのため」と言えるものであるということだ。

これがなかった時、なぜそのインクリメントを今生み出そうとしているの?と聞かれた時に回答としては「わかんにゃい...」となるのが関の山かもしれない。

プロダクトゴールが生まれた背景

プロダクトゴール（そしてスプリントゴール）がないと、スクラムチームはタスクの処理に集中するばかりで、「価値の創出」からは遠ざかり、いわゆるフィーチャーファクトリーになります
(引用: https://www.ryuzee.com/contents/blog/14603)

今回は詳しく背景にある歴史までは追えていないが、この引用からある程度わかるように、スクラムチームがフィーチャーファクトリー化しまうケースが多発してしまったからだと伺える。

それもそのはず、プロダクトゴールという長期のゴールがなければスクラムチームはスプリントレビュー毎に発生するフィードバックに無限に対応したり(ここが尽きることは人間の性質上ない)、無限にその場その場対応が続くことになる。この現象が「スクラムは無限に走っている」というふうに揶揄される一因なのかもしれない。

プロダクトゴールのためのスクラムチーム

そもそもとして、スクラムチーム自体が「プロダクトゴールのために集まった単位」であると書かれている。

スクラムの基本単位は、スクラムチームという⼩さなチームである。スクラムチームは、スク ラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。スクラムチーム内 には、サブチームや階層は存在しない。これは、⼀度にひとつの⽬的（プロダクトゴール）に 集中している専⾨家が集まった単位である。

逆説的に言えば、プロダクトゴールがない場合はスクラムチームとして集まれていないグループ(言い方はかなりきついが)とも捉えることができる。つらたん。

実体験としてのプロダクトゴールの不在

自分自身の経験として、プロダクトゴールが不在の時の開発は基本的に機能ベースでの開発になっていたように感じる。この機能をいつまでにリリースする、ということが主軸になっていて、出すことが第一目標として存在しているので、その後のフィードバックループは生まれづらいような状況である。

また、スプリントレビューの場で「何のためにフィードバックをもらうか」がわからなくなってしまっているケースもある。

プロダクトゴールに対して適応していくためにインクリメントを提示してフィードバックを貰いつつ、ステークホルダーとプロダクトゴールへの進み方を議論するのがスプリントレビューなのだとしたら、プロダクトゴールがないスプリントレビューは何になるのだろうか。

ただ作ったものの品評会になるし、ステークホルダーもどの観点でレビューをすればいいのかわからず、ただただ疑問やデザイン面での指摘をする他にない。

それに加えて、スプリントゴールを精緻に作る意味や価値がなくなる。なぜなら、プロダクトゴールがなければ、スプリントゴールは「スプリントの目標」にしかならないため、価値基準である必要がないし、スクラムチームが運用しやすい内部のアウトプット目標に引力が働いてしまう可能性が高い。

プロダクトゴールがアウトカム、インパクトがベースになるものとしたら「スプリントゴールはそのアウトカム、インパクトをどうやって達成するか?そのために今スプリントで何をできるようにした」という点でのスプリントゴールになるが、プロダクトゴールが存在しない場合は「ある機能リリースのための中間報告点のため」のスプリントゴールになる。

これはただの中間成果物で本来アジャイルが無くそうとしていたものではないのだろうか...。

プロダクトゴールによって健全なスプリントレビューの議論が行える。

組織目標とプロダクトゴール

組織では評価制度のために目標管理を入れているケースがちょこちょこある。

目標管理はそもそも人事評価のためではなく、経営管理のためのツールなんだぞという気持ちもありつつも一旦は端に置いておく。

この評価制度によって少しスクラムと整合性が取れない部分が生まれているようにも感じるので、そこに対しての見解をつらつらと垂れながしてみる。

チーム目標とプロダクトゴール

チーム目標とは、チームが追う目標のことである。そのまんま。

ただこのチーム目標というのは、スクラムの目線も含めつつ考えるとプロダクトゴールなのではないか?という疑問が思い浮んでくる。

前述で、スクラムチームは「これは、⼀度にひとつの⽬的（プロダクトゴール）に 集中している専⾨家が集まった単位である。」という風にスクラムガイドで定義されている。

つまり、プロダクトゴールを達成するのがチーム目標であり、チーム目標はプロダクトゴールなのではないかと捉えることができる。

そう考えた時に、チーム目標を憲章として掲げているのは、本来のあるべきではないように感じる。

チーム目標がプロダクトゴールなのであれば、その目標はスプリントレビューで検査される存在であり、その目標を達成するために、チームはスプリントゴールを立てていく必要がある。

つまり構造的に、毎スプリントごとにプロダクトゴールへの進捗がはっきりと検査される構造になる。これはチーム目標の憲章化を避けるための構造としては十分である。

ただここで気を付けないといけないのはプロダクトゴールは「アウトカム、インパクトのどちらか」をベースに決められることである。ここで「アウトプット」や「アクティビティ」をベースに決めてしまうとマイクロマネジメントが非常に発生しやすい構造になってしまう。罠は多い。

個人目標とプロダクトゴール

個人目標においても、プロダクトゴールと整合性を持ちつつも、プロダクトゴールのような運用をしていくのが良さそうな気配を感じている。

がむしゃらに目標を立てるのではなく、チーム目標(つまりプロダクトゴール)と整合性を持たせつつも個人のプロダクトゴールを設定し、そのプロダクトゴールに対するスプリントゴールをスプリント毎に策定し、検査していく構造のことを指す。

とはいえ、この部分についてはただの仮説でしかないので強くは主張はできない。

しかし、このような構造にすることで個人目標の形骸化や個人利益への傾倒を避けることができるように感じている。

ただここで気をつける点として、分割統治になっているかどうかも考慮する必要があるということだ。

個人目標を立てるということは、個人は個人目標に注力する。これは避けようがない構造上そうなるようになっている。

つまり、個人目標をすべて統合した時(つまり分割統治)になっていない時に、プロダクトゴールは破綻する(達成できない)可能性がある。この可能性を留意しつつ運用していく必要があるので難易度がある。マネジメントはむずかしい。

そして、ここで立てる目標としてもやはりアウトカムやインパクトがベースになっているべきだと感じる...が、正直やってみないとわからない。

なぜなら、個人(自分が自分)でマイクロマネジメントするのは良い可能性があるからである。

しかしよく考えてみると、昨今ではその自分マイクロマネジメント姿勢がリソース効率を強め、個人にゆとりが持てなくなってしまい、燃えつきたりしてしまう事象も多く見受けられる。

やっぱりアウトカムとかインパクトベースがいいかもしれない。

スクラムは組織にも食い込む必要がある

おそらく今世間的にベーシックとされている目標制度や立て方、考え方はかなり従来の考え方に強くひっぱられているように感じる。

OKRとかも名前にある通りObjective(目標)が1つあり、その下にKeyResult(これらが達成できていれば目標も達成できている状態と言える指標)を決めていく構造になっている。

しかし、大半はこのKeyResultが自己目標化してしまうケースが少くないと感じている。

だが、このKeyResultを自己目標化してしまうと本来の目的(目指したいアウトカムやインパクト)が達成されない、つまり分割統治になっていない場合は達成されないケースが発生してしまう。これは本末転倒とも言える。

ただ正直ここに関しては、そこまで自信がないので強く主張はできない。まだまだ自分自身も実践と経験が足りていないからである。

スクラムマスターとして

スクラムマスターとしては、スクラムの価値観を弱化させてしまう要因はできる限り取り除いていくことである。

今回では「集中」を弱化させてしまうプロセスが存在するというふうに捉えることができるため、いかにチームの「集中」を取り戻すか、ここに責任を持って取り組んでいきたい。

さいごに

いろいろとつらつらと書いているが、プロダクトゴールを決めたら全部うまくいく!という話でもない。

たぶん、プロダクトゴールがあれば立て方でまた課題が色々出てくるだろうし悩みも出てくることだろう。

ただそれは「挑戦した者だけが見えるもの」であり、やらない理由にはならない。やってみないと課題なんて大体見えないので、今後も一生改善し続けるしかない。

はあ、資産運用とかで働かなくても済むくらいのお金を得て一生ゲームをして生きていきたい。