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

2022年3月3日

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

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

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

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

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

プロダクトゴールをどうマネジメントしていくか:Evidence Based management

ここまでで、プロダクトゴールとはこういうものです、という説明をしました。説明するのは簡単ですが、プロダクトゴールを関係者とちゃんと考えて作るというのはそんなに簡単な話ではもちろんありません。

いまは不確実性が高い時代と言われていますので、ゴールを設定しても、そのとき予想した通りの未来にはいかないのですね。

ですので、従来のビジネスの考え方やマネジメントの方法から、経験的なマネジメントのフレームワークにできればいいのかなと考えています。

なぜかというと、ビジネスにしろプロダクトにしろ、つねにループをぐるぐると回すことになります。その中で様々な指標、先行指標や遅行指標などが絶対に存在します。これらを考えていかなければいけないとすると、おのずとそれにマッチしたようなマネジメントだったり、やり方だったりを取っていくことが、これから必要になってきます。

fig

そこで、エビデンスベースのマネジメント、EBM(Evidence Based Management)というものを紹介します。

こちらは経験主義に基づいたマネジメントフレームワークで、スクラムの生みの親の1人、ケン・シュウェーバーさんが中心になって開発されました。

EBMの大きなポイントとして、ゴールの設定の仕方、重要価値領域、実験のループというものを定義しています。EBMには、研修や認定試験もありますので、興味のある方は受けてみてください。

fig

EBMの重要価値領域は、大きく2つに分かれます。「市場価値」と「組織的な能力」です。市場の価値を見るのはビジネス上非常に大事ですよね。そして組織にその市場価値を提供する能力がなければ意味がない。

すると、市場価値には「未実現の価値」、つまりこれから実現する価値と、現在提供できる「現在の価値」が必ずあります。

fig

組織的な能力では、新しい価値を「市場に出すまでの時間」と、それを作る「イノベーションの能力」があるか、その環境があるかどうか、という要素があります。

ビジネスアジリティやビジネス価値を考えるとき、この4つを必ず考えなくてはいけませんし、これらに基づいた指標を計測しなくてはいけないんですね。このことをビジネス層から強く推奨してほしい。

そうでなければ「スクラムでやりましょう」「プロダクトゴールを作りましょう」と言ってもなかなか協力してもらえなかったりすることになります。

これら4つを先ほどの指標でマップするとこんな形になりそうです。必ずこうなるとは限りませんけれども。

どちらにせよ言えるのは、この4つのバランスが重要になるといったところになります。

fig

EBMでは、経験主義に基づくゴール設定の仕方もガイドしています。そこでは、「戦略的ゴール」と「中間ゴール」と「即時戦術ゴール」という3つの段階を設けましょうと説明しているんですね。

例えば、今起きてる新型コロナウイルスの対策を考えると、「病気の影響を根絶したい」という大きなゴールがあるとして、それだと非常にフワッとしてますよね。

そこで「ワクチン」という中間ゴールを置く。さらに、ワクチンのために何をやるのかを考える、そのようなアプローチが考えられます。

fig

問題はそれと「プロダクトゴール」がどう関係するのか。この関係ができると、ビジネスを見ている人とプロダクトを作る人とのコミュニケーションがとりやすくなるのですが、このマッピングは現場の状況によって変わってくる。

言えるのは、戦略的ゴールだとちょっと抽象度が高すぎ、目標としても高すぎですね。なので中間ゴールもしくは即時戦術ゴール、もしくはその中間あたりがいいのではないかと思います。

fig

まとめ

まとめます。

fig

プロダクトゴールは共通認識のために必要ですということ、ビジョンへの踏み石になってるということ。そして計測することが大事になります。

ただしスコープを固定するようなものにならないようにしてください。つまりプロダクトバックログを抽象化して正当化して、我々のゴールはこれです、というやり方は避けた方がいいです。

そして、一度決めたから見直さない、というものではありません。現状をちゃんと見た上で、変えていくという勇気も必要になります。

それぞれ関連する項目も並べておきましたので参考にしてください。

ということで、私からは以上となります。ご参加いただきましてありがとうございました。またぜひ皆さんと議論がしたいと思っております。

公開されているスライド

このエントリーをはてなブックマークに追加
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本