はじめに
こんにちは、「ZOZOMO」のブランド実店舗の在庫確認・在庫取り置き機能の開発を担当しているZOZOMO部OMOブロックの木目沢です。先日、プロダクト開発メンバーとビジネスメンバー合同で2日間の「ユーザーストーリー」ワークショップを開催しました。
1日目は「キャンプ」を題材にユーザーストーリーの型と会話を体験し、2日目は実際のZOZOMO店舗在庫取り置きでユーザーストーリーを書き、優先順位を決めて実際に開発するところまで行いました。
この記事では、その2日間をまとめて振り返ります。
目次
- はじめに
- 目次
- 開発チームの課題感と、ワークショップのねらい
- なぜ「ユーザーストーリー」なのか？
- 1日目：キャンプでユーザーストーリーの型を体験する
- 2日目：実プロダクトで優先順位を決め、その場で開発まで
- おわりに
開発チームの課題感と、ワークショップのねらい
まず前提として、私たちOMOブロックは「開発専門の部署」です。これまでは、ビジネス部門などから依頼（要望や企画）を受けて、それを実現するための開発をする、という流れが中心でした。
もちろん、そのやり方でもプロジェクトは作れます。ただ、続ける中でいくつものモヤモヤが見えてきました。
- 開発メンバーのアイデアが入りづらい──開発メンバー一人ひとりは「開発者」という属性だけでなく、それぞれ異なるバックグラウンドや視点を持っている。そうしたメンバーのアイデアが活かされにくい状況はもったいない
- ビジネスと開発のやり取りが「依頼」と「回答」になりがちで、多くのミーティングが組まれたり、Slackの会話が延々と続いたりする
- 結果として、いわゆる社内の「請負開発」のようになっている
- ゴールや背景、ユーザーにとっての価値がよく見えないまま開発してしまうことが多かった
「これって、誰のどんな課題を解決したくてやっているのか？」
「この機能を作った先に、どんなアウトカムがあるのか？」
そういった肝心な部分が曖昧なまま、「仕様どおりに作ること」に引っ張られてしまうのは開発側にとっても力を発揮しにくい状況です。ビジネス側にとっても、本当に欲しかったものとずれる原因になります。
OMOブロックが持っている技術的な知見とビジネス側のアイデアを掛け合わせ、さらに各メンバーそれぞれのバックグラウンドや視点を活かし、一緒にインクリメントを積み上げていきたいと考えています。
「開発」「ビジネス」という役割をはっきりと分けて仕事をするのではなく、役割の垣根を超えて、全員が“プロダクトが目指す世界・ユーザー価値・アウトカム”に焦点を当てている状態を目指したいと考えています。
最終的にはこのようなことを目指したいと考えています。
スクラムガイド2020では、プロダクトについて以下のように定義されています。
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
ここでは、プロダクトは「手段」であり、「価値を提供すること」が目的であると示されています。
開発チームが作るだけという状況はプロダクトではなく、プロジェクトです。プロダクトを作っていくという状況をつくるべく、ZOZOMO店舗在庫取り置きではスクラムを採用しました。
そして、今回開発とビジネス間における会話のための道具として、ユーザーストーリーを活用することにしました。
ユーザーストーリーを共通言語にして、ビジネス・開発それぞれ同じ土俵で会話できるようにする第一歩として、このワークショップを企画しました。
なぜ「ユーザーストーリー」なのか？
ユーザーストーリーを一言でいうと、「価値のアイデアを、会話しやすい形に翻訳したもの」です。
ビジネスと開発の間には、どうしても“言語のギャップ”があります。
- ビジネス側は「売上」「会員数」「体験価値」などの言葉で語る
- 開発側は「API」「スキーマ」「パフォーマンス」「テストケース」などの言葉で語る
どちらも間違っていないのですが、別々の言語のままでは、会話のハードルがどうしても高くなります。
そこで登場するのが ユーザーストーリーです。アイデア（価値の定義）は、次のような形で表現できます。
- 【WHO】◯◯において。
- 【WHAT】XXXしたい。
- なぜなら【WHY】〜のため。
- 【AC(Acceptance Criteria)】それは何ができれば実現したと言えるか。
このフォーマットによって、以下のような効果が期待できます。
- WHAT（なにがしたいか）／WHY（背景・価値）を、ビジネスと開発とで同じ言葉で共有できる
- AC（Acceptance Criteria：受け入れ基準）は技術の用語を使わず、「なにができればWHAT/WHYが実現できているか。検証可能なものを書く」ことで、ビジネス側も理解しやすくなる
- 結果として、ユーザーストーリーを中心に自然な会話が生まれる
- ユーザーストーリーはそのままプロダクトバックログアイテムとなり、実装からスプリントレビューまで一貫して利用できる
つまりユーザーストーリーは、ビジネスと開発の垣根を取り払うためのツールになりうるのです。
私たちは、この「共通言語」をきっかけに、開発だけでなくビジネスも含めたチーム全員が、ユーザー価値とアウトカムにフォーカスする状態を作っていきたいと考えています。
1日目：キャンプでユーザーストーリーの型を体験する
ここからは、2日間の流れを順番に振り返ります。まずは、ユーザーストーリーの基本を“遊びの題材”で体験した1日目からです。
メインワーク１：キャンプで“WHAT”を考える
今回のワークのお題は、“夏の北海道にキャンプへ行く” という設定です。3チームに分かれてこの設定をもとにユーザーストーリーを作成していきます。
このシナリオに基づいて、「キャンプで何をしたいか？」＝WHATについてブレインストーミングを実施しました。
WHOは各チームのメンバー、つまり「私たち」です。
Miroの付箋には、各チームからさまざまなWHATが出ました。
- 森林浴したい
- 渓流釣りしたい
- 芝生を歩きたい
- 焚き火したい
- キャンプファイヤーしながら合唱したい
- 水辺を散策したい
ここでは“良し悪し”をつけるのではなく、まずは出し切ることが目的です。「キャンプ」という1つの体験にも、こんなに多様な望みがあるのかと、チーム内でも驚きがありました。
メインワーク２：WHYを考える──価値の核心を探る
次のステップは WHY（なぜそれをしたいのか？） を書き添えることです。
例えば、“森林浴したい”に対しては、こんなWHYが出てきました。
- デジタルデトックスのため
- 何もしていないことをしてみたいから
- リラックスしたいから
WHYを書いていくほど、単なる行動（WHAT）が、「その人にとっての価値」に変わっていくのがわかります。
あるチームでは、「WHYが深まるほど価値が整理されていく感じがする」という感想も出ていました。
メインワーク３：WHAT/WHYを“実現したと言える”受け入れ基準＝AC(Acceptance Criteria)をつくる
続いて、ユーザーストーリーの肝とも言えるAC（Acceptance Criteria：受け入れ基準）です。
ACとは、ざっくり言うとWHAT/WHY を実現した、終わった、と言える客観的な基準のことです。
ACは技術の言葉を使わず、「なにができればWHAT/WHYが実現できているか。検証可能なものを書く」ことがポイントです。
- WHAT：森林浴したい
- WHY：リラックスしたいから
たとえば、このWHAT/WHYに対して、あるチームが出したAC案は次の通りでした。
- まずは森林と呼べる場所へ行くこと
- デジタルデバイスの電源を8時間以上OFFにすること
- リラックスしたと感じたこと（アンケートなりで確認）
ACで大事な点の1つは、ACを「技術仕様のリスト」にしないことです。
「APIレスポンスが〜」「DBが〜」といった実装寄りの言葉ではなく、あくまで利用者視点で『できている状態』を書きます。そうすることで、ビジネス部門のメンバーもストーリーの完了イメージを掴みやすくなります。
この「ビジネスでも理解できるAC」を軸に、実装方法は開発側で柔軟に検討することに、ビジネスと開発の役割分担と協調のポイントがあります。
また、ユーザーストーリーワークショップの題材では、技術的な実装は関係ないため技術的な言葉を意識することなく、検証可能なものという制約に集中できるのが狙いでもありました。
客観的な形で必ず検証可能なものであることもACでは重要です。
最終的にできたユースケースはこちらです。
メインワーク４：環境が変わればACも変わる──秋キャンプに変更
ワークショップの後半では、「急に秋の北海道キャンプに変更！」というイベントが発生します。
WHAT/WHYは変えないまま、季節変更に伴ってACを見直してもらいました。
夏と秋では、以下のように前提条件が大きく変わります。
- 気温
- 日照時間
- できないアクティビティも出てくる
その変化を踏まえ、例えば「森林浴したい」のACは、以下のように現実的な条件が追加されました。
- 寒さ対策で1時間ウォーキングする
ここからの学びはとてもシンプルで重要です。
ACは固定ではなく、状況に応じて調整・交渉してよいということです。
だからこそ、ビジネス側も「これなら現場目線でOK」「ここは譲れない」といったコメントをしやすくなります。リファインメントやレビューの場で、一緒にACを調整していくイメージです。
追加されたACを含む、最終的なユースケースはこちらです。
1日目の振り返り：ユーザーストーリーは“会話”のための道具
ワークを通して印象的だったのは、付箋そのものより、付箋をきっかけにした会話の方が重要だったということです。
WHAT/WHY/ACを作っていく過程で、以下のようなやり取りが自然と生まれ、議論の質が上がっていきました。
- 「それって本当にWHYに沿ってる？」
- 「そのACだと何が嬉しいんだっけ？」
- 「それならもっと良い表現があるかも」
ユーザーストーリーは、単なるアウトプットではなく、価値を共通理解するための“会話”のために必要な道具なのだと体感できた1日目でした。
2日目：実プロダクトで優先順位を決め、その場で開発まで
2日目は、1日目で身につけた型と感覚を、実際のZOZOMOプロダクト開発に適用する日です。
実プロダクトでユーザーストーリーを出し切る
まずは対象となるプロダクトを1つ選び、そこに対して「こうなったらもっと良くなるはず」というアイデアを、チームメンバー全員で付箋に書き出していきました。
ここでもフォーマットは同じです。
- 【WHO】◯◯において。
- 【WHAT】XXXしたい。
- なぜなら【WHY】〜のため。
- 【AC(Acceptance Criteria)】それは何ができれば実現したと言えるか。
ビジネス側からは「この指標をもっと改善したい」「この業務オペレーションを減らしたい」といった声が上がりました。開発側からは「このフローは技術的に改善余地がある」「この組み合わせならすぐ試せそう」という意見も出ました。役割を超えてどんどんストーリーが出てくるのが印象的でした。
プロダクトオーナー×開発チームで優先順位付け
次に行ったのが、出てきたユーザーストーリーの優先順位付けです。
評価の軸はシンプルに2つだけに絞りました。
- 価値の高さ
- 開発のしやすさ（実現コストの低さ）
Miro上に2軸のマトリックスを用意し、プロダクトオーナーと開発メンバーが会話しながら各ストーリーの位置を決めていきます。
- 「このストーリーについて、価値は高いけど既存システムへの影響が大きいのでコスト高め」
- 「これは小さいけど、いますぐ改善するとユーザー体験の印象がかなり変わりそう」
- 「この2つは似ているので、まとめて1つのストーリーにしませんか？」
といった議論を通じて、価値とコストをセットで考える感覚を共有できたのがよかったポイントです。
このプロセスを経てマトリックスの右上（＝価値が高くて、かつ開発しやすい）に位置するストーリーの中から、「取り組むべき1つ」を決定をしました。
このストーリーは実際にプロダクトバックログに積まれ、リファインメントを経てスプリントで実装されました。
ワークショップ全体を通しての学び
2日間を通じて学んできたユーザーストーリーですが、最後に書籍の引用からユーザーストーリーの定義を振り返ります。
『「ユーザーストーリ」はＸＰで提唱されたプラクティスで、 ユーザーの言葉で書かれた機能の説明である。 そのものではないが、従来の「要求仕様書」を置き換えるものだ。 このユーザーストーリはアナログを重視し、 紙のカードに書いて会話によって伝えることが推奨されている。』 (引用)アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 平鍋 健児 (著), 野中 郁次郎 (著) No 584 ※ 「ユーザーストーリ」と記述されていますが、原典を尊重し、そのまま引用しております。
開発・ビジネスの役割を超え、全員がユーザー価値・アウトカムにフォーカスする第一歩として、このワークショップは良いきっかけになりました。
おわりに
ユーザーストーリーワークショップ実施から3か月が経過しました。ワークショップの効果は非常に大きく、以下のような変化が起きています。
- ビジネスチームのメンバーがリファインメントへ参加するようになり、ユーザーストーリーをベースとして会話するようになった
- スプリントレビューにも積極的に参加してもらうことになり、多くのフィードバックを得ながらプロダクトを進められるようになった
- プロダクトオーナーにビジネスチームのメンバーをアサインすることになり、ビジネスと開発の距離がさらに近くなった
- ビジネスチームのメンバーも開発チームのメンバーもアイデアを出しやすくなった
今後もユーザーストーリーを起点に、ビジネスと開発が一緒になってプロダクトを育てていく取り組みを続けていきたいと思います。
以上、ZOZOMOユーザーストーリーワークショップ全2日のレポートでした。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。最後までご覧いただきありがとうございました！
