プロダクトゴールとは何か
みなさんこんにちは。@ryuzeeです。
2020年版のスクラムガイドで「プロダクトゴール」が登場してから5年近く経ちましたが、いまだにプロダクトゴールを設定していないチームや、うまく使えていないチームをたくさん見かけます。 ときには、「うちは目の前のスプリントに粛々と取り組むだけなので、あんまり関係ないです」と言われたりすることもあります。
しかし、スクラムは「ゴール指向のフレームワーク」です（2020年版の改訂でさらにそのトーンが強くなりました）。 ゴールがなければ、そこに至る道筋を計画することも、進捗を検査することもできません。
先日支援先の相談タイムでもプロダクトゴールが話題になったので、ちょっと整理したいと思います。
なお、この話の多くはスプリントゴールにも当てはまります。
プロダクトゴールとは？
まずは、何はともあれスクラムガイドです。スクラムガイド2020で、プロダクトゴールという単語は15回登場します（更新履歴に6回登場するので、あわせて21回です）。
確約（コミットメント）：プロダクトゴール
プロダクトゴールは、プロダクトの将来の状態を表している。 それがスクラムチームの計画のターゲットになる。 プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
（中略）
プロダクトゴールは、スクラムチームの長期的な目標である。 次の目標に移る前に、スクラムチームはひとつの目標を達成（または放棄）しなければならない。
つまり、プロダクトゴールとは「スクラムチームが長期的に目指すべき未来の状態」です。
このスクラムガイドの「長期的」という単語には注意が必要です。 スクラムガイドは意図的に不完全なので、当然のことながら長期がどれくらいの期間を指すのかについての記述はありません。実践者が自分で考える必要があります。 すなわち、具体的な期間はプロダクトが置かれている状況や組織によって大きく変わります。 長期というのが3か月を指すこともあれば、半年や1年を指すこともあります。 また、毎回同じ長さである必要もありません。前回のプロダクトゴールの目標達成期間は3か月だったけど、今回は5か月にする、というのもありです（一方で、大きな会社の場合は3か月とか半年にすると、事業計画などとの整合が取りやすいかもしれません）。
スプリントゴールが1か月以内という短期の単位であるのに対し、プロダクトゴールは数か月〜1年程度を視野に入れた目標と考えるとよいでしょう。
スクラムの3本柱は「透明性・検査・適応」です。スクラムチームは自らが作るもの、プロセスなどを日々検査し、適応しなければいけません。したがって、当然のことながらプロダクトゴールの達成状況も検査の対象です。検査を行うためには、プロダクトゴールの具体性が必要になります。
プロダクトビジョンとの違い
「プロダクトビジョンと同じじゃないの？」と言われることもありますが、プロダクトビジョンとプロダクトゴールは別ものです。 プロダクトビジョンは長期的な理想、プロダクトゴールはその途中のマイルストーン、スプリントゴールはそれを実現する一歩と考えると、理解しやすいかもしれません。 ざっくり表にすると以下のようになります。
| プロダクトビジョン | プロダクトゴール | |
|---|---|---|
| 定義 | プロダクトの最終的な理想像。抽象的な未来の方向性 | プロダクトビジョンを実現するための中間的な目標 |
| 性質 | 抽象的・インスピレーショナル（鼓舞するもの） | SMARTな（具体的・測定可能・達成可能・現実的・期限付き）目標 |
| 評価タイミング | 特定の期限はない。評価し続ける | 達成や放棄のタイミングがある。1つを達成または破棄すれば次のゴールに進む |
| 目的 | プロダクトが「なぜ」存在するのかを示す | スクラムチームが「今、何を目指しているか」を示す |
| 例 | 「すべての中小企業が自分たちの会計をシンプルに管理できるようにする」 | 「3か月以内に、ユーザーが請求業務にかかる時間を半分に短縮できるようにする」 |
プロダクトゴールはなぜ1つだけなのか？
スクラムには5つの価値基準があります。その中の1つが 集中（Focus） です。 本当に重要なことに集中することで、ゴール達成の可能性を高めます。 そのためスクラムでは、スプリントゴールもプロダクトゴールも1つです。
しかし、研修やコーチングで「スプリントで複数ゴールを設定したいんですが……」 とか 「今回のプロダクトゴールは3つです！」みたいな話をよく聞きます。
本当に達成すべきゴールが複数あるなら、まず1つを選んでそれを確実に達成することに集中しましょう。 その上で、次のスプリントやゴールを考えてください。 でも、まだ1つのゴールすら明確に描けておらず、1つのゴールを達成した実績もないのに、いきなり複数設定しようとするのは、無謀としか言いようがありません。どうせ達成できません。 「全部大事」は「何も大事じゃない」と同じです（何度言っても「でもでも、だって」って言われるんですが）。
しかし、冷静に考えると1つづつ終わらせたほうがよい点がたくさんあります。
たとえば、3か月間で達成したいプロダクトゴールが2つあるとします。それぞれのゴールで1.5か月分の作業が必要だと見積もっています。
このとき、チーム全体が1つのゴールに集中すれば、1.5か月で最初のゴールが達成できます。 そして、残りの1.5か月で次のゴールに取り組めば、合計3か月で2つのゴールを達成することができます。
一方、「どっちも大事だから」と2つのゴールに並行して取り組んだらどうなるでしょうか？
- 作業が分散し、どちらも1.5か月では終わらない
- コンテキストスイッチのオーバーヘッドが増える
- 作業の順番の判断がぶれやすくなる
- 外部の変化（マーケットや顧客要望）に対応しづらくなる
- ゴールの達成は最短でも3か月後（だけどたぶん無理）
これはリトルの法則（平均スループット＝平均作業量÷平均リードタイム）の視点でも説明できます。複数のことに同時に取り組むと、リードタイムは伸びます。つまり、あれこれに手を出すとどれもなかなか終わりません。 一方で、全員で1つのゴールに集中すれば、1つの価値を早期に顧客に届けることができます（お金も生むかもしれません）。 そしてそこからフィードバックを得て、次に活かすことができます。
プロダクトゴールがあると何が変わるか？
2022年のあるカンファレンスで「プロダクトゴールを設定していますか？」という問いに手を挙げた人は、わずか5％だったという話があります（出典）。さすがに今はもう少しマシな状況になっていると思いますが、それでもまだプロダクトゴールを設定していないチームをたくさん見かけます。プロダクトゴール（そしてスプリントゴール）がないと、スクラムチームはタスクの処理に集中するばかりで、「価値の創出」からは遠ざかり、いわゆるフィーチャーファクトリーになります（参考: スクラムがフィーチャーファクトリー化しているサイン）。
一方でプロダクトゴールがあれば以下のような点に変化が出ます。
1. スプリントレビューが価値中心になる
プロダクトゴールが明確になると、スプリントレビューで「それって、誰が喜ぶんでしたっけ？」 「この機能でゴールに対してどれくらい進んだことになるの？」といったような問いが自然に出るようになります。 すなわち「提示したインクリメントによってプロダクトゴールに近づくか？」という観点からフィードバックを受けられるようになります。
2. プロダクトバックログアイテムの順番が明確になる
新しいアイデアが出てきたときに、「それって今のプロダクトゴールに役に立ちますか？関係ありますか？」という視点でプロダクトバックログアイテムを取捨選択できるようになります。 新しいアイデア自体は貴重ですが、新しいアイデアは魅力的に見えてしまうため、無自覚に取り入れると道を逸れてしまいがちです。 それを防ぎ、順番を決める軸としてプロダクトゴールを使います。 たとえば、ステークホルダーからの要望はいつでも扱いが難しいですが、プロダクトゴールがあることで、少なくともプロダクトゴールに関係のない要望については、明快に「ノー」を言えるようになります。
3. チームの集中が高まる
プロダクトゴールは、同時に複数設定できません。1つだけです。 ゴールが1つであれば、余計なことを考える必要がなくなり、スクラムチームは集中して仕事に取り組めるようになります。 また、スクラムチームの全員が1つのプロダクトゴールを強く認識していると、ゴールを早く達成するためのアイデアや選択肢を自らが考えられるようになります。そのような状態になれば、プロダクトオーナーがプロダクトバックログアイテムを細かく準備しなくても、プロダクトバックログリファインメントなどの場を通じて、より良いプロダクトバックログアイテムが生成できるようになります。
プロダクトゴールの書き方
プロダクトゴールは進捗を検査できる具体的なものである必要があります。プロダクトゴールを達成できたかどうかはプロダクトオーナーが中心になって判断しますが、恣意的に判断しても意味はないですし、そんなプロダクトゴールではステークホルダーの賛同も得られません。
以下のような条件を満たすように書くことをお勧めします。
- 目的を重視する：「ユーザーが◯◯できるようにする」「ビジネス成果として◯◯を向上させる」のような形で、アウトプットではなく、アウトカムやインパクトに関連するものにします
- 手段は書かない：「レコメンド機能を実装する」のような具体的な手段は避けます。プロダクトゴールを実現できれば、そこに至るHowに柔軟性があったほうがよいです。複雑な領域ではあとから良い案が見つかることもあります。最初から機能などの具体的な手段を書いてしまうと、変更の余地がなくなってしまいます。「レコメンド機能を実装する」のようなものの代わりに、「ユーザーが適切な選択を素早くできるようにする」のように設定をすれば、実現手段は変更が可能です
- 計測可能にする：「定期利用者数を20％増やす」など、成果としての変化が分かるのが理想です。ただしアウトカムやインパクトは遅行指標であることも多いので、代替指標を検討しなければいけないこともあります。
- 協力を得て作る： プロダクトオーナーが1人で作るのではなく、ステークホルダーやスクラムチームが協力して作ります
スクラムチームヘルスチェック
スクラムイベントなどで、スクラムチームに「プロダクトゴールは何か？どうやって計測するか？」を聞いてみてください。全員が何も見ずにスラスラと答えられる状態が理想です。
