Googleプロジェクト管理：ユーザーストーリー

はじめに

わたしが Google プロジェクト管理:プロフェッショナル認定証で得られた素晴らしい体験を、要点をまとめ小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ "Google プロジェクト管理:プロフェッショナル認定証" を受講してみてください。

前回説明したプロダクトバックログ項目を管理する一般的な方法であるユーザーストーリーについて説明します。

ユーザーストーリーとは

『ユーザーストーリーとは、ユーザーの視点から語られる、機能に関する短くシンプルな説明文のこと』

これは、チームが常にユーザーとユーザーエクスペリエンスを中心としたソリューションを作成するのに役立ちます。ユーザーストーリーは、大きく広い範囲から始まることもあれば、できるだけ小さく、またはできるだけ具体的に分割されることもあります。

スクラムプロジェクトの原動力は、お客様を第一に考えることです。ユーザーストーリーは、顧客が製品に満足することを保証するための重要な要素である。

ユーザーストーリーの3つの要素

• ユーザー（User）
• 行動（Action)
• 価値（Value)

これらの要素にはいくつかの異なる形式があるかもしれませんが、最も一般的なのは

『ある役割を持ったユーザーとして、この行動をして、この価値を得たい』

例）熱心な読書家である私は、近所の支店で本を借りる前にレビューを読んで、興味のある本を手に入れたい。

ペルソナ

効果的なユーザーストーリーを書くとき、チームはユーザーを念頭に置かなければなりません。私はこの段階で、ペルソナやさまざまなユーザーの詳細な説明を作成するのが好きです。時には、名前を付けることもあります。

• レオは私の植物ベンダーで、植物の入手、サプライチェーン、配送のロジスティクスを管理します。
• フェリシティは、私の園芸の専門家です。サポートチームがお客様に植物のお手入れ方法について、本当に素晴らしいアドバイスを提供できるようサポートします。
• ザックはアマチュア家庭菜園家。購入した植物を使って夕食を作りたいと思っています。
• ニアは私の経営コンサルタントで、自宅で仕事をしているのですが、ホームオフィスでビデオ会議をするためにプロフェッショナルな背景を設定したいと思っています。
• レナは花好きで、毎週違う花を飾って自宅を華やかにしたいと思っています。

こうしたユーザーに名前と背景を与えることで、頭の中で彼らを想像することができ、結果として彼らのためにより良い製品を設計することができるのです。ユーザーストーリーを書くと、ユーザーの立場になって考えることができるので、とても楽しいです。

顧客からのフィードバック

既存の製品に機能を追加する場合、過去のイテレーションですでに顧客からフィードバックを得ている場合は、そのフィードバックを考慮するようにします。

I.N.V.E.S.T

ユーザーストーリーは、I.N.V.E.S.T.（投資）という頭文字で表される6つの基準を満たす必要があります。

I（independent）

ストーリーは単独で開始・終了できるものでなければなりません。他のストーリーに依存して完結するものではありません。

N（negotiable）

交渉や話し合いの余地があることを意味します。

V（valuable）

ユーザーストーリーを完成させることで価値を提供しなければならないことを意味します。

E（estimable）

Doneの定義は、チームが各ユーザーストーリーに見積もりを出せるように、明確でなければなりません。

S（small）

各ユーザーストーリーは、計画されたスプリント内に収まる必要があります。もしそのユーザーストーリーが大きすぎる場合は、より小さなストーリーに分割する必要があります。Backlog上で優先順位が低いストーリーは、次のSprintで優先されるまでは大きいままでよい。

T（test）

テスト可能である。テストを書いて、それが受け入れ基準を満たすかどうかを確認することができる。

プロダクトオーナーはユーザーストーリーを書く主な責任者ですが、チームはユーザーストーリーに時間を費やす前に、ユーザーストーリーが明確であるか、投資基準に合っているかをフィードバックする責任があります。

エピック（Epic）

エピックは、関連するユーザーストーリーを管理することを目的としています。この投稿で、「エピック」という言葉の考案者であるMike Cohn氏は、エピックとは「非常に大きなユーザーストーリー」であり、1回のイテレーションでは納品できず、小さなストーリーに分割する必要があるかもしれないと述べています。

チームは、ユーザーストーリーとエピックの書き方、捉え方について、一緒に議論し、共通の見解に到達する必要があります。エピックとは、プロジェクトをまとめるための、より大きなユーザーストーリーに過ぎないということを覚えておいてください。

例）ユーザーストーリー「Web サイトで本のレビューを読みたい」「本をカートに追加したい」に対するエピックは、「Webサイトの作成」になるでしょう。

ここで重要なのは、プロダクトオーナーがユーザーストーリーやエピックを書くことができる一方で、プロダクトオーナーがプロダクトバックログ項目に対して責任を持ち続ける限り、開発者もそれらを書くこともできるということです。

受け入れ条件（Acceptance criteria)

ユーザーストーリーでは、プロダクトオーナーは受け入れ基準と呼ばれるものを作成します。これは基本的に、ユーザーストーリーが完成したかどうかを判断するために使用するチェックリストです。ユーザーストーリーを完成させるには、受け入れ基準のチェックリストを満たす必要があります。

以下は、盆栽のユーザーストーリーの受け入れ基準の例です。

• 購入する3種類の盆栽を閲覧する。
• 3つの木を比較して、自分の家で育てるのに最も簡単で最も難しいのはどれかを知ることができる。たぶん、それぞれの植物の横に、初級、中級、上級の表記があるはずです。
• 肥料や刈り込み鋏など、特定の盆栽の手入れパッケージを購入できる。
• 盆栽冊子シートや盆栽に同梱されているお手入れ冊子にオンラインでアクセスできる。
• バーチャルベルデのFAQページで、盆栽のトラブルシューティングのページを見ることができます。

プロダクトバックログの精度

ユーザーと対話し、興奮できる現実のもののように感じられます。プロダクトバックログの各ユーザーストーリーは、このように書かれるべきです。

• 優先順位が高いものほど、 詳細でグレーゾーンが少ない のは当然です。
• 優先順位の低い項目を曖昧にしておくことで、将来的に優先順位が下がるかもしれない項目に取り組む 時間を節約 することができるのです。