スクラムガイドに新たに追加された「プロダクトゴール」とは? あるいはプロダクトゴールの設定には何が必要か?(前編) Regional Scrum Gathering Tokyo 2022

2022年3月3日

代表的なソフトウェア開発手法として知られる「スクラム」を開発したケン・シュウェイバー氏とジェフ・サザーランド氏によるスクラムの公式ガイド「スクラムガイド」。2020年11月付けの最新版には新たに「プロダクトゴール」と呼ばれる概念が導入されました。

スクラムガイドによると、プロダクトゴールはプロダクトの将来の状態を表しており、スクラムチームの⻑期的な⽬標である、と説明されています。スクラムチームにとって非常に重要なものだと位置付けられているのです。

この重要なプロダクトゴールをどのように考え、どう設定すべきなのでしょうか。

1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されたイベント「Regional Scrum Gathering Tokyo 2022」において、サーバントワークス 長沢智治氏によるセッション「プロダクトゴールとは?あるいはプロダクトのゴールを設定するには何が必要か?」で、この点についての解説が行われました。

本記事ではそのセッションの内容をダイジェストで紹介します(この記事は前編後編の二部構成です。いまお読みの記事は前編です)。

プロダクトゴールとは何か? あるいはその設定に必要なもの

長沢です。よろしくお願いいたします。今日は「プロダクトゴール」についてのお話をさせていただこうと思っております。

figセッションはリモートで行われました

プロダクトゴールというのは「コミットメント」=「確約」なので、まずは確約の話からスタートしようと思っています。そこをおさらいしてから、プロダクトゴールの話をしていきたいなと思っております。

そして、プロダクトゴールは単に設定すればよいわけではありません。どうそこに近づいてるのか、それを計測していくのかについては、「EBM」という方法があります。それも紹介していきたいと思います。

fig

このセッションを聞いていただくと、プロダクトゴールとはこんなものだというのが分かるか、というと、そうでもないかなと思います。

ただ、プロダクトゴールを考えていただく上でのきっかけというのは作っていけるのではないかなと。そういう風に構成してますので、そんなスタンスで見ていただければなと思っております。

というわけで話し手は長沢になります。最近、コクヨのINGというデスクチェアを買いまして、座面が360度動く、動きながら考えることができる、考えながらプログラミングができるという非常に優れたプロダクトだと思いましたので、ぜひ皆さんも買ってみてください。

fig

はい、そんな人です。よろしくお願いします。

コミットメント(確約)とは何か?

まずは「確約」の話をします、「コミットメント」です。

コミットとは自らが行うものであり、誰かにコミットさせるとか、してもらうとかではない、という話がありました。有名なMargaret Carterさんも、ベストを尽くすことしかできないですよと言っています。

fig

ここで、スクラムガイドに「経験主義の柱」と「スクラムの価値基準」があるのを思い出してください。

fig

スクラムのフレームワークは、この「経験主義の柱」と「リーン思考」に基づいてできてます。そしてこの価値基準が振る舞いを引き起こし、振る舞いが価値基準を映し出していく。

今回テーマに挙げさせていただいているプロダクトゴールというのは確約=コミットメントとなるわけです。そして確約はスクラムのベースにもなっている経験主義の柱の、特に「透明性」のところに深く関係します。

そしてスクラムには3つの作成物、プロダクトバックログ、スプリントバックログ、インクリメントがありますよね。これらによって透明性がもたらされるし、これらによって透明性をより高くしていくといったような背景があります。

fig

そしてプロダクトバックログというのはプロダクトゴールへ向かうために作っていくものです。

この3つの作成物は透明性と集中を高めるための情報源であり拠り所で、そのうえでコミットメント、確約というものによって進捗を図っていくということができるわけです。

fig

そこでプロダクトゴールとは、設定し、計測をし続ける、というのが大事になります。

前述の通り、コミットメントというのは自らが行うものであり、他人に押し付けられたりするものではないので、契約や他社との約束事ではありません。自分たちがより良いプロダクトを作っていくために、自らが選択してやり遂げるものです。

スクラムの確約と予測

スクラムの中では確約と予測ということはできますが、何かを約束する、契約するっていうことはなかなか難しいですね。

それを絵にするとこんな感じです。

時間軸にはタイムボックス=スプリントがあります。そしてプロダクトゴールを目指していくわけですが、そこに向かっていくための小さなゴールとしてスプリントゴールがあり、その中でインクリメントを作っていく。

fig

スクラムのイベントには、必ずこれはやりましょうというイベントがあります。それぞれ目的があるのですが、それらをざっくりと検査と適応で分類してみたらこんな感じかなといった表になります。

fig

例えばスプリントプランニングであればプロダクトゴールに近づけるように計画を立て、検査するわけです。今どの位置まで来たかなと。それによってスプリントゴールというものを設定して適応するという形になります。

スプリントレビューに関しては、作ったインクリメントがプロダクトゴールに近づいているのかをステークホルダーと検査する機会ですよね。

その結果、適応としては、次のプロダクトバックログに表れます。

プロダクトゴールとは

ここから本来の話プロダクトゴールといったところに入っていきます。

プロダクトゴールを考えるとき、私はいつもこの言葉が頭の中に出てくるんですね。方向が正しければ、踏み出す一歩は大きくなくてもいいですよと。

fig

プロダクトゴールというのはスクラムガイドの最新版で出てきた言葉です。本文の中で15回も言及してます。ゴール自体は40回も出てるんですよね。ぜひ皆さんも数えてみてください。

fig

プロダクトゴールとは、プロダクトの将来の状態であり、計画の対象になります。プロダクトオーナーが策定し、明示的に伝達するものです。

インクリメントとは、プロダクトゴールに向かっていくための具体的な踏み石、と書かれています。

fig

スクラムチームは一度にひとつの目的に集中しましょうと説明されていて、集中する目的がプロダクトゴールです。

また、スクラムチームは「長期的な目標」を、とも説明されていて、これもプロダクトゴールになります。

とにかく集中する、というのがポイントになります。なので、プロダクトゴールは非常に大事なんですね。

なので、ありがちで私もよく相談されるんですが、外向けのプロダクトゴールと、内向きのプロダクトゴールを設定するとか、そういうのはやめましょう。プロダクトゴールはあくまでひとつです。

プロダクトゴールというものがあることによって、それぞれ目指すもの、あとは実現するものでステークホルダーから期待するものっていうのが明確になった。この点が非常に大きいのかなと。

最新のスクラムガイドでプロダクトゴールが出てきたのは、個人的にも非常に分かりやすくなって良い点だなと思ってます。

プロダクトゴールはプロダクトビジョンへの踏み石

プロダクトゴールがあることで、こういうことができます。

fig

まず「最上位の期待値」をマネージできるようになります。これが期待されてるものだ、これを目指していく、ということです。それをスプリントレビューを代表として、毎回のスプリントで出てきたインクリメントに対して見ていく。だからインクリメントはプロダクトゴールへの踏み石という形になるわけです。

それを基にして次のアイディアをプロダクトバックログにしていく。で、プロダクトバックログにはプロダクトゴールを目指していくためのアイテムが並んでいる。

プロダクトゴールとは何なのか、というとプロダクトビジョンへの踏み石です。踏み石の二重構造、三重構造になってる感じですね。

プロダクトビジョンから見ていくと、こんな形で表現できるかなと思います。プロダクトビジョンが真ん中にあって、プロダクト戦略、リリース計画、スプリント計画、そして機能が生まれる。

fig

従ってプロダクトゴールはプロダクトビジョンを目指すためのゴールなわけですよね。そこを間違えないようにする必要がある。

重要なポイントだけを紹介すると、まず、プロダクトバックログを抽象化してプロダクトゴールを作るのは危険なので避けた方がいい。あくまでビジョンがあって、それはマーケットや社会の課題とか、そういったものから映し出されるものでビジョンを表現しましょう。

そうでないと単にチームが作りたい機能を寄せ集めたものになってしまう危険があります。

プロダクトゴールはチームの共通認識を作るためのものですので、意図を伝える目的で設定し伝播していくものになります。解決策にしてしまうと、やるべきスコープを固定してしまったり、やり方をひとつにしてしまったりするので柔軟性がなくなってしまいます。それは避けましょう

最後に、計測できること、そして順序付けができること。

基本的にスクラムチームが目指すのはひとつなんですが、プロダクトビジョンから見れば順番があったりするわけですね。何にせよ計測できることが大事になります。

プロダクトゴールとロードマップ

プロダクトゴールは明示的に示されるものでなければいけません。そのために「FAST」という考え方があります。FASTについてはあとで軽く紹介します。

fig

何はともあれ、ステークホルダーとスクラムチームで共有する共通認識がプロダクトゴールです。一度に目指すものはたったひとつ。スプリントごとに、そのゴールに近づいていってるかを検査をしていく。だから計測できる必要がある。

これがプロダクトゴールの例です。

fig

プロダクトビジョンとして「日本で一番のオンラインドラ焼き屋になる」というのがあるとします。

その場合、例えば1番目のプロダクトゴールが「金沢の顧客に販売できるWebサイトを立ち上げる」で、その次のゴールとして全国展開やそれをさらに拡大していく、というゴールがあるかもしれません。

しかし、まず1番目をカバーしなくてはいけません。ちなみに、なんで金沢なのかというと、どら焼きの売り上げは全国で金沢がトップだと、そういう情報を見つけたので金沢にしました。

そしてこれがFASTです。

fig

頻繁に議論できること、野心的に設定できること、具体的な指標で計測できること、透明性を確保すること、これらを守りつつプロダクトゴールを設定しましょう。

そのためのフォーマットもいくつかあります。ここでは私が気に入ってるものを2つ並べました。

fig

新規プロダクトの場合は上の例が合っていると思います。明確なビジョンを基にして、具体的な課題を克服するための成功路を設定する。

そして今の状態から目指すべき状態に行くための指標が何なのかを明示する、というフォーマットになっています。

下の例はどちらかというと既存のプロダクトです。

別の例として、「プロダクト戦略キャンバス」というのもあります。ここではUberの例を出していますが、基本的には現在の状態が分かり、目指すべき状態というのを設定する、という形です。

fig

≫後編に続きます。後編ではプロダクトゴールをマネジメントする手法の例としてEBMを紹介します。

このエントリーをはてなブックマークに追加
follow us in feedly


関連タグ DevOps / アジャイル開発 / スクラム



タグクラウド(β版)

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準

アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed


最新記事10本