【スクラム】概要

スクラム開発とは？

アジャイル開発手法の一つで、アジャイル開発で最も有名な手法です。

スクラムガイド

スクラムのルールは以下で定義されている。2010年に初版がリリースされて、1〜2年おきにルールは更新されています。

役割

スクラム開発では役割を3つ決めます。

• プロダクトオーナー
• スクラムマスター
• 開発チーム

プロダクトオーナー

責任者でプロダクトバックログやスプリントバックログ等を使用して開発機能の優先順位を決めます。1プロダクトにつき1人です。

プロダクトを生み出す価値を最大化する必要があります。

やること

• プロダクトのビジョンを明らかにし、周りと共有する。
• おおよそのリリース計画を決める。
• 予算を管理する。
• 顧客、プロダクトの利用者や、組織の関連部署などの関係者と、プロダクトバックログの項目の内容を確認したり、作成順や、実現時期を相談する。
• 既存のプロダクトバックログの内容を最新化する。
• プロダクトバックログの内容を関係者が理解できるよう説明する。
• プロダクトバックログ項目が完成しているか確認する。

どうやって選ぶか？

• スクラムは認定資格や、研修制度が整っているので、そうした資格持ちの人や、研修に行ってきた人から選ぶのはあり。
• アジャイル開発に慣れている人
• プロダクトオーナーに近い仕事を普段からしている人（色んな意見を整理して偉い人に報告する作業をしてきた人）
• マーケットのことを知っている人
• 関係者の合意を取るために役職や権限を多く持っている人

ただ、一番大事なのは「自分たちが作るものに対してより良いものを作る」と熱心に取り組んでくれる人を選ぶと良い。

スクラムマスターと兼任しても良い？

これは絶対にダメ。プロダクトオーナーは作るものをより良くすることに注力しなければならないため。

プロダクトバックログ

開発対象のシステムやソフトウェアで最終的に実現されるべき要求機能や要素をまとめたものです。機能の要求全体と優先順位の確認に使われたりもします。プロダクトとして何を作るべきかを管理し、その優先順位をプロダクトオーナに判断してもらいます。

スクラムにおいて、機能や要求、要望、バグなどプロダクトに必要なものを抽出して順番に並び替えたリストを作成します。プロダクトにつき1つ用意します。

一度作ったら終わりではなく、絶えず要求が来たり、作る順番も要求に合わせて改善していきます。

内容

以下のようなことが書かれている。

• 絶対に実現したいこと
• リリース不可と思われる項目
• できれば実現したいこと

順番

その項目が実現されたときに得られる価値や、リスク、必要性によって決定します。順番が上位のものから開発します。上位のものほど内容が具体的で詳細が見えているものになります。見積もりは時間など絶対的な数値ではなく、作業を相対的に現したものが使われます。

書き方

特に決まっていないが、「ユーザーストーリー」という形式で書くことが多いです。

ユーザーストーリーとは？

実際に使うユーザーに何を提供して、その目的を簡潔に記述するやり方。プロダクトバックログを表現する手法として一般的に使われています。

ポイント

「実現したい機能」だけでなく「なぜそれが必要なのか」の意図を意識することが重要。

なぜなら、スクラムオーナーは実現したいことがあり、開発チームはどう実現するかの思考の違いがあり、そのズレが発生する可能性はある。その際に、意図まで伝えていることにより自ずと「どう実現するのか」という部分でも深い部分まで考えて実装することが可能なため。

最終的な責任

作成や、更新は開発チーム全体で行いますが、最終的なプロダクトバックログの責任は「プロダクトオーナー」に属します。

スプリントとは？

最長1ヶ月までの固定の期間に区切って繰り返し開発を行います。この固定期間のことを「スプリント」と呼びます。

開発チームは1スプリントの中で、計画、設計、開発、テストなどプロダクトバックログ項目を完成させるのに必要な作業を全て行います。

なお、途中で作業の意味がなくなった場合などは、プロダクトオーナーの意思によりスプリントを中断させることは可能です。

メリット

• 固定の期間を決めることで開発チームにリズムができ集中できる。
• 全体ゴールに対する進捗が把握しやすくなる。
• リスクに対応しやすくなる。

設定する期間

短くて1週間、長くても4週間を設定し、週間単位で行います。

期限に間に合わなかった場合

たとえ、スプリント最終日に期限に間に合わなかった場合でも、スプリントは終了して期限延長は行わないです。

スクラムマスター

スクラムを回す役割です、色んな案件を兼任していたりします。

スクラムがうまく行くように全体を支援します。スクラムのルールや作成、進め方をプロダクトオーナーや、開発チームに理解させて、効果的な実践を促し、スクラム外にいる人から妨害や割り込みからプロダクトオーナーや開発チームを守ります。

役割

• まだスクラムに慣れていないチームでスクラムのやり方を教える。
• 他のスクラムマスターと協力しながら組織全体に対して支援を行う。（発展的な役割）

プロダクトオーナーと兼任しても良い？

基本的にはダメです。プロダクトオーナーはより良いものを作ってもらうことに専念してもらい、スクラムマスターは開発チームをうまく回すことに専念します。

具体的な作業

スクラムがうまくいっていない障害一覧を作成する。

障害となり得るものの一覧を保持しておきます。スクラムチーム全体で見える位置に整理しておくとなお良いでしょう。どれも解決が簡単ではない課題が多いです。

例

• デイリースクラムが15分以内に終わらない。
• プロダクトオーナーがデイリースクラムに参加できない。
• 他部署からの割り込みが多くて作業に集中できない。
• メンバーのスキル不足（テストコードの書き方を知らない。）

開発チーム

実際に手を動かして開発をする人たちです。4～8人で兼任したりします。

主な役割は、プロダクトオーナーが順位づけしたプロダクトバックログ項目を順番に開発していくことです。

構成

3〜9人で構成されます。

3人未満の場合

個人のスキルに依存してしまいます。チームとして活動した効果が減ります。

10人以上の場合

コミュニケーションコストが増えて開発効率が落ちます。なので、開発チームを分割してサイズを適切に分ける方が良いです。また、開発チームを分ける場合はそれぞれのチームでスクラムマスターを配置するのが一般的です。（プロダクトオーナーは分ける場合でも意思決定を明確にするために一人が望ましい。また、プロダクトバックログも一つにします。）

機能横断的

開発チームは、以下のようなことを横断的に行います。

• 要求分析
• サーバー構築
• コードを書く
• テストを書く

開発チーム内での仕事の進め方

開発チームメンバーの合意の元に決めて、外部から仕事を指示されるようではいけない。これを自己組織化と呼びます。

開発サイクル（イテレーション）

1〜4週間の短いスパンで開発を繰り返します。これをイテレーションと呼びます。

スクラム開発の流れ

1.リファインメント

「スプリントバックログ」や「タスクボード」という物を使って、Todoと今日やることやったことを日々確認します。

タスクボード

チームのメンバが見る壁やホワイトボードに「ToDo（未着手）」「Doing（実施中）」「Done（完了）」に分けてタスクを掲示します。

スプリントが順調に進んでいるかどうか確認するのによく使われています。スプリント内で実施するプロダクトバックログの項目とそのためのタスクを開発チームに見えるところに貼り出す。タスク状況がわかるように「未着手（TODO)」、「着手（Doing)」、「完了(Done)」に分けておく。

これをスプリントバックログとしているスクラムチームも多いです。

必要なもの

• 付箋
• ホワイトボード

注意点

それぞれのタスクを最新の見積もりに更新するのも忘れないようにすべき。

デイリースクラムとは？

スプリントプランニングが終わった後に、開発チームがスプリントゴールや、選択したプロダクトバックログ項目の完成に向けて日々作業を進めていくことになります。そこで毎日行われるのがデイリースクラムになります。多くは立ったまま行われます。

デイリースクラムでやること

• スプリントバックログの残作業の確認
• このまま進めてスプリントゴールを達成できるのか確認

タイミング

毎日、同じ時間、同じ場所に開発メンバーが集まって検査する。日本では「朝会」と呼んだりもしますが、必ずしも朝である必要はないです。

参加者

参加者は基本開発チームで、スクラムマスターは必要や要望があれば参加して司会などを行います。それ以外の人がもし参加する場合は進行の邪魔にならないように配慮する必要があります。

時間

15分で延長はないです。長時間の打ち合わせでは集中力がなくなり問題を見逃してしまう可能性があります。

注意点

「問題解決の場」ではない。「問題を発見する場」です。

問題の発見例

例えば、事前に3時間で終わる作業と伝えていたのに8時間かかってしまうようであれば、その見積もりは8時間になり問題が発生しているといえます。

2.スプリントレビュー

スプリントの最後に、プロダクトオーナー主催でスプリントの成果をレビューするイベントを開催します。これをスプリントレビューと呼びます。プロダクトオーナーはスプリントレビューに必要なステークスホルダー（利害関係者）を招待します。

目的

プロダクトに対するフィードバックを得ること。スプリント中に作成したインクリメントを実際に動作する環境を見ながら確認できるように披露します。実際に操作しながら内容を説明したり、実際に触ってもらってフィードバックを引き出します。

デモできるもの

完成したものだけです。なので、スプリントレビュー前にプロダクトオーナーと開発チームの間で完成したプロダクトバックログと完成してないプロダクトバックログを明らかにしておく必要があります。

議論内容

• スプリントで完成しなかったプロダクトバックログ項目について説明する。
• スプリントでうまくいかなかったこと、問題点、解決策について議論する。
• プロダクトオーナーがプロダクトの状況、ビジネス環境について説明する。
• プロダクトバックログに追加項目有無について議論する。
• 問題点について議論する。
• 現在の進捗を踏まえてリリース日や、完了日を予測する。

使える時間

1ヶ月スプリントであれば4時間。１週間の場合は1時間とする。

3.スプリントプランニング

以下のことをスプリントプランニング（スプリント計画会議）で決定します。

• スプリントで何を作るのか？（What)
• どのように作るのか？（How)

事前準備（プロダクトバックログリファインメイント）

スプリントプランニングをする前にスプリントバックログ上位の項目に関しては事前準備が必要になる。これを「プロダクトバックログリファインメント」と呼びます。）、この時間はスプリントの10%以内にするのが一般的です。

• 項目の中身を具体化する。
• 項目の疑問点を解決する。
• 項目は何ができたら完成なのか（受け入れ基準）明らかにする。
• 項目を自分たちが扱えるサイズに分割する。
• 項目を見積もる。

使える時間

1ヶ月スプリントであれば8時間、スプリント期間が短いならそれに応じて短くします。

スプリントで何を作るのか？

プロダクトオーナーが今回のスプリントで達成したい目的を明らかにします。それを達成するために完成させるプロダクトバックログ項目を選びます。選択する項目は、プロダクトバックログ内の上位項目になるのが一般的です。

どのように作るのか？

選択したプロダクトバックログ項目ごとに具体的な作業内容を洗い出して作業計画を立てます。

スプリントバックログ

現在実行中の開発サイクルで実現するべき機能仕様をまとめたものです。プロダクトバックログで管理している項目を開発するために必要なタスクを分解して作成します。

「選択したプロダクトバックログ項目」と「作業一覧」を合わせた呼び名がこれです。開発チームの作業計画にあたります。スプリント期間中に自由に作業を追加したり、削除したりができます。個々の作業は一日以内で終わるようにします。

4.スプリントレトロスペクティブ

スプリントレビュー後のスプリント内の最後のイベントです。

直近のスプリントの中でプロダクト開発に関わる活動において問題なかったか、もっと成果を出すためにできることがないか検査を行い、次回のスプリント以降で必要なアクションを決めます。日本ではよく「振り返り」と呼ばれています。

スプリントレトロスペクティブで出たアクションアイテムのうち最低一つは次のスプリントのスプリントバックログに含めるように明記されてます。

使える時間

1ヶ月のスプリントであれば3時間、期間に応じて少なくしていきます。スプリント期間に関係なく毎週スプリントレトロスペクティブを実施する例もあります。

作業見積もり

スクラムにおいても、作業の見積もりが難しいという事実は変わらないです。

相対見積もり

基準となる数字を決めて、それとの比較で作業量を考えていく手法です。

基準を決める

まずは、基準となるバックログ項目を決めます。作業内容を具体的にイメージできるものが望ましいです。その作業に適当な数字をつけます。

あまりに簡単な作業は避ける

基準があまりに簡単すぎると、比較先が何百倍とかにもなってしまいうまく数字を出せない形になってしまいます。目安としては比較した時の開きが10枚程度に収まるくらいが丁度良いです。

具体的な決める手順

作業を以下三つの基準に分類します。

• 簡単に終わりそう
• 少し大変そう
• 結構大変そう

その中で「少し大変そう」と思った作業量が少ないと思う順に並べて真ん中くらいのものを基準として選定します。

比較する

基準となるバックログ項目と比較して他の作業が簡単だと思えば小さい数字、難しいと思えば大きい数字をつけます。

誰が見積もるか？

多くの知識と情報を持っている専門家に任せたほうが安心。最も詳しい人にお願いすべき。