はじめに
お久しぶりです。改善したいマンの三上です。
世間は新型ウィルスで混乱していますが、レアジョブのブログは元気に更新中です!
私事ですが、少し前に丸2日間の研修を経てLSM(Licensed Scrum Master)の資格を取得しました。
レアジョブではアジャイル開発を推進しており、各チームやプロジェクトで積極的に採用されています。
そんな中で弊社のメインプロダクトである「レアジョブ英会話」のリプレース案件を実施することになりました。
この超大型案件を進めるにあたり、まず始めに何から始めたらいいのか考えていく中で
まずはプロトタイプ開発をしよう!スクラムでやってみよう!
という運びになり、まずはユーザーストーリーマッピング(USM)をやってみたので
今回はその記事を書こうと思います。
USMとは?
スクラム開発においてプロダクトの価値を決めるのはプロダクトバックログです。
プロダクトバックログはいくつかのPBI(プロダクトバックログアイテム)が優先度の高いものから順番で並んでいます。
PBIはユーザーストーリー形式になっていて、誰にとって、どんな価値があるのか表現されている必要があります。
ユーザーストーリーは以下の形式にします。
WHO = ○○として
WANT = △△したい
WHY = なぜなら✗✗だからだ
実際に例を上げると、
WHO = レアジョブ英会話の会員として
WANT = 日本語も話せる講師とレッスンしたい
WHY = なぜなら分からない時に日本語で質問したいからだ
のように書きます。
上記は例ですが、ユーザーストーリーの粒度は大小様々になりえます。
このようなユーザーストーリーを優先度が高く直近のスプリントで着手するものほど、より詳細なストーリーにしていく必要があります。
(ちなみにストーリーの詳細化・見積もりの事をリファインメントと呼びます。)
USMは上記のようないくつかのユーザーストーリーで構成されます。
そのユーザーストーリーをナラティブフローと呼ばれる物語の流れに沿って左から右へ時系列順に並べていきます。
USMを作成するメリットはプロダクトの全体像を俯瞰して見れることです。
個人的に、この複数のサブストーリーを経て、全体としてのストーリーが出来上がる感じが
RPG感があって楽しいです。笑
というわけでやってみた
ざっくり以下のような形で進めました。
Timebox
3時間
Agenda
- 目的説明
- ユーザーストーリーマッピング説明
- 現状の機能概要のおさらい
- ペルソナの共有
- ユーザーのアクションを書き出す(全員)
時系列に並べていく。
同じ目的はグループにまとめる。
注:ストーリーとして書く。〇〇として△△したい
注:ストーリーをタスクに分解してはならない
「青い付箋」にユーザーのアクションを書き出す
「オレンジ付箋」にアクションのグループをまとめる - 改善ポイントや欲しい機能を書き出す
「赤い付箋に」ユーザーの気持ちになって欲しい機能を書き出す - 整理(優先順に並び替える)
- 最優先で作りたいものを決める(MVPの確定)
MVP(Minimum Viable Product)とは、まず最初にリリースしたいものになります。
今回はMUST(必ず必要)、WANT(出来れば欲しい)の2つに分類し、MUSTをMVPとします。
※余裕あれば次に達成したいことを決める - プロダクトバックログに組み込む
参加者は開発チームはもちろんPO(プロダクトオーナー)に当たる企画チーム、CTOまでバラエティに富んだメンバーで行いました。
完成したUSMはこちら
オレンジ色の付箋がエピックと呼ばれる単位になります。
例としては「ユーザー登録」、「検索」、「レッスン予約」のような粒度です。
また上部に貼ってある付箋ほど優先度が高いものになります。
やってみて良かったこと
大きく以下の2つ。
・ペルソナを明確にした
・プロトタイプ開発のスコープが明確だった
です。これは企画チームに感謝です。
上記の写真でプロジェクターに映し出しているのが、
レアジョブ英会話の重要ペルソナを言語化したものになります。
ここが明確だと何が良いかというと、ユーザーストーリーを考えるにあたって
最も重要なのがユーザー視点に立つことです。
これは簡単なようで難しいです。なぜなら人それぞれ求めることが違うので当然意見が分かれるときがあります。
またエンジニアあるあるだと思うのですが、
パッと要件を聞いた時に、すぐ実装方法を考えてデータ構造とかアーキテクチャとかを想像しちゃうと思うんです。
それはそれで重要なんですが、今回の場では不要です!
そんな時に役に立つのがペルソナの存在です。
意見が別れたり悩んだときには、ペルソナの気持ちになってその都度振り返ることが出来て、円滑に議論を進めることが出来ます。
また、プロトタイプ開発のスコープが明確だったことにより、どこまでやる・やらないの判断にあまり時間を取られずに進行することが出来ました。
最後に
このUSMを経て、プロダクトバックログを作成し、無事にスプリントが開始することができました。
またスプリント開始時にやったことについても次の記事で書きたいと思います。
それでは、また。