「急いで作って！」と言われたとき、私がまずやること→Miroだけでスクラム
VTeacher所属のSatomiです。
※ 本家Miroさんからコメントをいただいたので掲載します！
ミロジャパン高山です。本記事ではMiroについてご紹介頂き誠にありがとうございます。大変参考になります。もし本記事の趣旨にあっていればですが、以下の２つのテンプレートを日本語対応をしましたので、よろしければ、リンクを付与頂けますと嬉しいです。
スクラムボード：https://miro.com/ja/online-scrum-agile-tool/
マインドマップ：https://miro.com/ja/mind-map/
或る日突然、「100万円のプロモーション予算がついたから急いで作って」と頼まれました。
※ちなみにプロモーション予算（100万円）に人件費は含まれないそうです。
そして、偉い人から下の画像が送られてきました。
（「4月1日に夢を語る」という PR TIMES の企画だそうです）
プロダクトバックログを覗くと・・・
下のようにアイテムが登録されていました。
| プロダクトバックログ | 概要 | Done（完了）の定義 |
|---|---|---|
| アイテム1 | 受験料の全額負担は難しい（現時点では夢である）が、一部負担のキャンペーンならできるので、そのための機能を作ってほしい | キャンペーンイベントを成功させること |
ざっくりだ・・・😅 😅 😅
受験料の全額負担は難しい（現時点では夢である）が、一部負担のキャンペーンならできるので、そのための機能を作ってほしい。
そしてDoneの定義 🤔
キャンペーンイベントを成功させること
えーと・・・。開発チームとしての観点で読み取ると、
「100万円を受験生で山分けする機能を作って」ということ？
- というと、受験生1人当たりいくらで分配するの？
- では、獲得条件は？
・・・
大きい会社であれば、企画専門の部にお願いして具体的な形にしてもらえば良いのですが、
弊社は小さいのでエンジニアが兼務する場合がよくあります。
そこで私がこのようなときに、何をしているかを整理しました（現在進行形です）。
対象読者
- 小規模（1ヶ月程度の）開発案件を依頼された人
- Done（完了）の定義がいつも曖昧で辛いと思っている人
- スクラムを勉強したい人
- Miroを試したい人
アジャイル/スクラムについて
使うツール
Miroを使います。オンラインホワイトボードです。リモートワークでの共同作業に便利です。
Miroはアジャイル開発用の専用ツールではありませんが、手軽に描けてシェアも楽なので、ミロだけでどこまでやれるかを試しています。
殴り書きの感覚でMiroにお絵描き
下のような手順で、殴り書きの感覚でシャシャッとMiroに書いていきます。
スクラム
スクラムをさらっと復習します。スクラムはアジャイル開発のフレームワークのひとつです。
-
プロダクトオーナー/スクラムマスター/開発メンバー
登場人物はプロダクトオーナー・スクラムマスター・開発メンバーです。実際にはステークホルダー（顧客・社長など）やプロデューサー、デザイナーなども関わりますが、スクラムはエンジニアチームの話です。 -
スプリント
スプリントは「短い距離を全力疾走」の意味で、100メートル走などの陸上競技はもちろん、ラグビーやサッカーでも使われる言葉です。ソフトウェア開発におけるスプリントは、言うなれば「1週間走」です。- スプリント（1週間走）※推奨は2週間ですが1週間が多い
- スタート（開発開始）
- ゴール（リリース）
- スプリント（1週間走）※推奨は2週間ですが1週間が多い
-
リリース
原則、毎スプリントリリースですが、リリースができない場合もあります。重要な点は「完璧である必要はない」です。もちろんバグはNGですが、プロダクトバックログの完了定義を満たしていれば（最低限のテストを行って品質を保証し、デザイン・機能も及第点であれば）リリースしてしまいます。動くものを見てもらったとき、それが叩き台となって多くの意見が出るのですが、意見はプロダクトバックログに再登録してもらい、別のスプリント（別の1週間）で対応します。 -
プロダクトバックログ/スプリントバックログ
プロダクトバックログ（完成までの残作業一覧）にやりたいことが登録されますので、これを分析し、タスク（作業の最小単位）に分割し、各タスクの担当を決めて、いつ行うかを計画します（スプリント計画）。今週やることをスプリントバックログに登録します。
Done（完了）の定義はたいてい曖昧
プロダクトバックログに書かれることは、たいてい曖昧です。とてもふわっとしています。
今回の例ですと、以下の通りです。
| プロダクトバックログ | 概要 | Done（完了）の定義 |
|---|---|---|
| アイテム1 | 受験料の全額負担は難しい（現時点では夢である）が、一部負担のキャンペーンならできるので、そのための機能を作ってほしい | キャンペーンイベントを成功させること |
このDone（完了）の定義を、少しずつ紐解いていく必要があります。
この作業はプロダクトオーナーの仕事ですが、開発メンバーがやるケースも多いです。
Miroのマインドマップを使ってみます。
マインドマップ
Miroを開き、左側のツールバーから「Mind map」を選択します。
「重要だけど抽象的なキーワード」を中心に配置し、連想ゲームのように思いつくままに書き込んでいきます。わからないところはプロダクトオーナーに聞きます。プロダクトオーナーがわからなければ、さらにわかる人（ステークホルダー等）に聞いてもらいます。
少なくとも、自分が思いつく範囲の疑問は全て書き出し、解消しておきます。
今回の例ですと、
- 受験生1人当たりいくらで配分するの？
- 獲得条件は？
- 対象は高校3年生だけ？
- iPhoneユーザーだけ？
- 運営上のルールは？
など
プロダクトバックログの内容をヒントに細かく紐解いていきます。
ユーザーストーリー
マインドマップに要望をまとめたら、次はユーザーストーリー（簡易的なもの）を書きます。
マインドマップで整理した要望について、機能として何が不足しているか、ユーザーフロー的に矛盾が無いか等を洗い出します。
Miroを開き、左側のツールバーから「Diagramming」→「Basic Shapes」を選択します。
（Miroの有料版であればUMLが使えます）
プロダクトが完成したときを想像し、とても具体的な使用例・利用手順を頭から書いていきます。
「ざっくりだけど、まあまあOKかな？」のレベルまで完成したら（現時点では間違っていても良いです。気付いたときに修正します）、機能として不足しているところ（新規開発や改修する必要があるところ）を「Card」に変換してください。
手順: アイテム選択後にカードアイコンを選択します。
かんばん
ユーザーストーリーができたら、かんばんを作成します。
Miroを開き、左側のツールバーから「Kanban」を選択します。
ユーザーストーリーでCardにしたところをコピー（Cmd + C）して、Kanban上にペーストします。ペースト後、ドラック＆ドロップで To do に移動します。
※ユーザーストーリーの全てのCardを To do に置いてください。
※優先順位が高い順に並べてください。
見積もり（フィボナッチ数字）
ユーザーストーリーの全てのCardを To do に置いたら、次は見積もりを行います。
フィボナッチ数字を使います。
フィボナッチ数字のうち、 1/2/3/5/8 を使うことにします。
数字の意味は3を基準として、相対的な開発時間の長・短を表しています。
- 1ポイント: すぐに終わりそう
- 2ポイント: 基準よりは早く終わりそう
- 3ポイント: 基準となる開発時間
- 5ポイント: 基準よりは時間がかかりそう
- 8ポイント: とても時間がかかりそう
Cardのタグ機能を使って、フィボナッチ数字の 1/2/3/5/8 を登録します。
その後、見積もりの基準となる「3ポイント」となりそうなCardを選んでください。
それと比較して早くできそうか、時間がかかりそうか、各Cardに数字のタグを登録していきます。
（開発メンバー全員で決めるのが良いです。多数決で良いです）
バーンダウンチャート
全てのカードに見積もりポイント（1/2/3/5/8のいずれか）を入力したら、次はそのポイントを合計してください。それをバーンダウンチャートにします。
Miroを開き、左側のツールバーから「Chart」を選択します。
Miro上のチャートをクリックすると、右側にテーブルが表示されるので、下記を参考に入力してください。
| 時間 | 計画 | 実績 |
|---|---|---|
| Sprint 1 | 見積もりポイントの合計を書く | 0 |
| Sprint 2 | 0 | 0 |
| Sprint 3 | 0 | 0 |
| Sprint 4 | 0 | 0 |
| Sprint 5 | 0 | 0 |
| Sprint 6 | 0 | 0 |
| Sprint 7 | 0 | 0 |
| Sprint 8 | 0 | 0 |
| Sprint 9 | 0 | 0 |
| Sprint 10 | 0 | 0 |
| 足りなければ追加 | 0 | 0 |
1スプリント（1週間）でいくつくらい消化できるかを予測し、それを減らしていきます。
この「見積もりポイントの消化速度」をベロシティ（Velocity＝速度）と言います。
実際はやってみないとわからないので、実績は別に記録していきます。
ここでは下記の条件でチャートを作ってみます。
- 見積もりポイントの合計
- 27ポイント
- 1スプリント（1週間）で消化できそうな見積もりポイント（ベロシティ）
- 5ポイント/スプリント（予測）
見積もりができました！
6スプリントなので、6週間かかることがわかります。
ステークホルダーとすり合わせ
完成予定日が出たので、プロダクトオーナーとステークホルダーに連絡しましょう。ステークホルダーとは、たいていがプロダクトの依頼元（顧客・取引先・株主・経営者など）です。
どうしても「もっと早くできない？」となるでしょうから、バーンダウンチャートを見せて、ベロシティの話をします。
計画の段階で「〆切ありき」な無茶なベロシティを設定しても、計画の精度が下がるだけです。
無理のないベロシティを設定し、人が足りないようでしたら増員をお願いします。
スプリントを回していく
-
スプリント開始時
今週は何をするのかを決めます（スプリント計画）。
「かんばん」から着手するCardを選択し、担当と終了予定日を登録し、To do→In progress(進行中) に移動します。タスクが完了したらDoneに移動します。 -
スプリント終了時
バーンダウンチャートに実績を登録します。
1スプリント（1週間）で何ポイント消化できたか（＝ベロシティ）が重要です。残ポイントを実績に登録しましょう。計画時のベロシティと差異が生じると思いますので、実績のベロシティを使って、計画の値を変更することで精度が高まります。プロダクトバックログに何か追加されていたら、そのポイントを上乗せしてください。
補足: Cardにメンバーの名前や、完成予定日を登録できる。
さいごに
実際のサービスをさわってみてください（現在進行形）。
https://prtimes.jp/main/html/rd/p/000000017.000051650.html
リモートワークであればこの記事も参考にしてください。
(C) いらすとや
Discussion