#Sprint 3 いざ、アジャイルでスプリントを回す！（前編）
こんにちは、Yachiです。
前回は、Scrumを開始する前に最初に行う“準備“について書きました。
今回は、Scrumを実際に回すスプリント期間中のアクションについて、ポイントを絞って書きます。
1.Scrumの全体像
Scrumでは、
3つのロール（①プロダクトオーナー、②スクラムマスター、③開発チーム）がそれぞれの役割を遂行し、
5つのイベント（①スプリントプランニング、②デイリースクラム、③スプリントレビュー、④スプリントレトロスペクティブ、⑤バックログリファインメント）を通じて、
3つの成果物（①プロダクトバックログ、②スプリントバックログ、③リリース可能なプロダクト）を出します（図1）。
図1:スクラムの概要を1分で理解できるイラスト【2018版】引用
この1サイクルを“スプリント“と呼び、Scrumでは、期間を定めたスプリントを繰り返しながら開発を行います。
スプリントは1～4週間に設定されることが多いですが、プロダクトの開発規模や開発メンバーの人数、チームの成熟度によって変わります。
スプリント期間は、開発規模が大きい/成熟したチームであれば長め（3～4週間）に設定し、開発規模が小さい/経験の少ないチームであれば短め（1～2週間）に設定すると良いです。
スプリント期間を固定する理由は、一定期間内の作業スピードを測り続けることで、課題を可視化しプロセスそ改善できるようにするためです。
プロダクトの作成が終わらないからといって検査のタイミングを延期したりすると、何が遅延の課題で、何を改善すべきかが分かりづらいですよね？
このように、“誰が、どのように、何をやるのか“が定義され、再現しやすいのがScrumの特徴です。
これが、Scrumの全体像です。
2.プロダクトバックログを作る
スプリントを回す際、初めに行うのが、プロダクトバックログの作成です。
プロダクトバックログとは、プロダクトに必要な機能を一覧にしたものです。これらは、求められる機能を網羅的に出した後、プロダクトオーナーが優先順位をつけて並べ替えます。
プロダクトバックログの作成において重要なのは、漏れがないように要望（機能）を書き出すことです。
ですので、チーム内の特定の人物がプロダクトバックログを作るのではなく、チームメンバー全員が付箋などで意見を出し合い可視化することが大切です。ホワイトボードの前で付箋を貼ったり書いたりしている、アレです。
☝貼り付け式のホワイトボードは、チーム専用の会議室がなくても持ち運びが容易でおススメです。
また、プロダクトバックログの書き方は機能ベースでなく、ユーザーの要望やその理由を書いた“ユーザーストーリー”で書くこともあります（図2）。
通常プロダクトオーナーは“何を実現したいか”を考え、開発チームは“どのように実現するか”を考えます。このロールの違いによるイメージギャップを解消するために、ユーザーでの要望を具体的に書くことが有効です。
図2:プロダクトバックログ （ユーザーストーリー）
...ん？
ところで、見積りってなんだ？
3.プロダクトバックログを見積る
ここに記載する“見積り”とは、時間や予算のことではなく、作業の量を指します。特定の機能を完成させるためにどれくらいの作業量が必要なのかを見積るということです。
見積りにおいて重要なのは、スピードと対話です。
スピーディに見積るために用いるのが、フィボナッチ数（1,2,3,5,8,13,21...）など数字を使った“プランニングポーカー”です。数字の書かれたカードを開発メンバー同士で出し合い、特定のプロダクトバックログを基準値とした相対見積りを行います。
基準となるプロダクトバックログは、具体的な作業量が見えているものを選び、その基準の数値を「3」（←これは何でもよい）とした時に、どの程度の作業量かを見積るものです。
これだけ聞くと、
「ちょっとちょっと、そんな適当な見積りで良いのー？」
と、思ってしまいますよね。
あくまでスピード重視で、適当に行うわけではありません。そのうえで重要なのが、開発チームが対話をしながら見積ることです。
Scrumでは、すべての開発に開発チーム全員が関わることを想定しているため、特定の開発に慣れているメンバーも、慣れていないメンバーも見積りに関わり対話をすることで、懸念点を洗い出すことができます。
このように、各プロダクトバックログの見積りから、合計の見積もりを出すことができます。そうすることで、作業期間や必要な人員を検討することができるわけです。
例えば、合計が100ポイントで、1スプリント（2週間）の場合、1スプリント10ポイント行える見積りであれば、20週間で作業を終えることが予測できます。作業期間が決まっている場合も同じ考えです。例えば、10週間という決められた期間であれば、50ポイント分くらいまでが完了できる見込みとなります。
どうでしょう。なんとなくイメージはできましたか？
プロダクトバックログの見積りまで終われば、プロジェクトの全体像が可視化され、どの順序で着手すれば良いかメンバー全員の理解を揃えることができます。
4.スプリントプランニングを行う
プロダクトバックログを作成することで、必要な機能の全体像や大まかな作業のイメージはできますが、スプリント内の具体的なアクションは見えてきません。
そこで次にやるのが、“スプリントプランニング“です。
スプリントプランニングでは、スプリント内に実施するプロダクトバックログを選択し、それらをタスクレベルに分解します。
プロダクトバックログを選択する際に考える必要があるのが、ベロシティです（図3）。
ベロシティとは、1スプリントで実施できるタスク量（見積りのポイント数）を指し、チームのパフォーマンスを測る指標となります。各スプリントのベロシティを測定し続けることで、チームの一定のスピードが見えてきます。
このベロシティを基準に、優先順位の高いプロダクトバックログを選択していきます。この際、確実に終わる計画を立てることが重要です。
図3:スプリントプランニングでは、ベロシティを基準に確実に終わる計画を作る
次に、選択したプロダクトバックログをタスクレベルに分解します。分解する際にタスク単位でも見積もりを行います。この見積もりの単位は“時間”を用いるのが一般的です。
また分解したタスクを、To-Do／Doing／Doneに整理します（図4）。そうすることで、メンバー全員が、スプリント内で実施すべきタスクが何で、何が進んでいて、何が残っているのかを一目で理解することができます。
図4:スプリントバックログをTo-Do／Doing／Doneで整理する
スプリントプランニングにおいて気を付けなくてはならないのが、無理な計画を行うことで、辻褄を合わせたり、問題に蓋をしてしまったりすることです。（例えば、デモに間に合わないため、本当は実施すべきテストをスキップしてしまうなど）
そうすると、プロジェクトの後半で重要な問題として浮上していくるし、そもそも、ベロシティが意味をなさなくなってしまいます。ベロシティは、何か問題が発生しているか把握するうえでの重要な手掛かりとなるため、無理な計画をせず、ピュアなデータを測る必要があります。
リリース前は期限が気になり、ストレスがかかるものです。無理のない計画をするだけでなく、良くない状況を隠すようなことが絶対に起こらないよう、心理的安全性の確保や失敗を学習・改善に変えようという雰囲気を醸成することが、非常に重要です。
ですので、非常にベタですが、何か問題や言いづらいことを報告してくれたメンバーには、必ず「ありがとうございます」と伝えるようにしています。
☝チームマネジメントに携わる全ての人に読んでいただきたい良書。アジャイルの要素も多く盛り込まれています。心理的安全性やエンゲージメントはビジネスKPIとの相関は明らかになってきているため、今後一層重要視されていくと思います。
5.まとめ
最後に要点をまとめます。
・Scrumでは、スプリント期間を固定し（1～4週間）、一定期間内の作業スピードを測り続けることで、課題の可視化やプロセスの改善を促す
・プロダクトバックログは、チーム全員で出し合い、ユーザーの要望やその理由を書いた“ユーザーストーリー”で書き並べる
・プロダクトバックログの見積りは、開発チームが対話をしながら、相対見積りでスピーディに行う
・スプリントプランニングは、スプリント内に実施するプロダクトバックログを選択・タスクレベルに分解し、To-Do／Doing／Doneに整理する
・ベロシティは、何か問題が発生しているか把握するうえでの重要な手掛かりとなるため、無理な計画は立てない
次回は後編です！
この記事が気に入ったらサポートをしてみませんか？