スクラム開発の全体像 – スクラム概要とスクラム開発のイベント進め方

はじめに

スクラムは「軽量」「理解が容易」という観点から選択される機会が多い、アジャイルのフレームワークです。
しかしスクラムは経験主義を基本としているため、習得するには経験と慣れが必要になってきます。

ここでは、スクラムとは何かを説明の後に進め方の全体像について解説します。

アジャイルについて知りたい方は、別記事「【アジャイル概要】アジャイルが求められる理由と、アジャイルでよくある誤解６選」を参考にしてください。

スクラムの概要

スクラムとは

スクラムは1990年代に登場したフレームワークです。
命名がラクビーのスクラムに由来しているとおり、人やチームワークを重要視した開発プロセスです。
チームメンバの役割、イベントやルールを決め、全員が主体的に行動することで最大の成果を上げることを目的としています。

ウォーターフォール開発のように１度に全ての機能をリリースするのではなく、小さい機能を少しづつリリースします。
少しづつ動かして確認することで、価値ある機能となるように軌道修正しながら開発できます。
そのためリリースした機能が使えない等のリスクを抑止するとともに、本当に現場で求めていた価値ある機能を提供します。

スクラムの特徴

スクラムは経験主義（経験的プロセス制御の理論）を基本にしています。
つまりチームが経験値を積むことで成長することですが、そのために次の３つの特徴を関係者全員が理解している必要があります。

透明性

• 発生している問題や課題がチーム内で見える化される
• 管理方法を標準化することで全員が共通認識を持てる
  

管理方法については、別記事「【スクラム解説】プロジェクト管理」を参照ください。

検査

• 成果物や進捗を頻繁に確認し、問題をすばやく検知する
  

適応

• プロセスや成果物に問題がある場合は速やかに改善する
  

スクラムの価値基準

スクラムでは自己組織化が前提となっています。
自己組織化とはリーダが陣頭指揮をとるのではなく、チームメンバが自立的にプロジェクト運営することです。

そこで、開発チームに求められるのが次の５つの価値基準です。
抽象的ですが、チームとしてベクトルを合わせるために必要な基準となります。

確約

スクラムはチームとして活動します。
スクラムの活動において、ビジネス価値を創出し続けるためにチームメンバとして積極的に活動することを約束します。
※確約とは無理してでも納期遵守する意図ではありません。

勇気

チームで活動していると、言いにくいことや指摘しにくい場面も出てきます。
そのようなときに、勇気をもって発言したり行動することが求められます。

集中

予定している作業に集中して取り組みます。
またメンバが集中して作業に取り組めるよう、外部からのノイズや予定外タスクの発生を抑止する取り組みを行います。
外部との調整はスクラムマスターなどの役割です。

公開

進捗や品質、問題などをチーム内だけでなく他者にもオープンにします。
作業状況の透明性だけでなく、メンバ間で情報共有することも含まれます。

尊敬

開発チームや顧客など、スクラム開発に関わる人は、皆がお互いに尊敬して接することが大切です。
相手を否定したり、人を見下すような人がいる環境ではスクラムは失敗するでしょう。

顧客との関係性

顧客と開発メンバとの関わり合いは、スクラムとウォーターフォールで大きく違います。

ウォーターフォール
開発が失敗しないため、プロセス重視する「計画駆動型」

スクラム
ビジネスが成功するために人重視する「価値駆動型」

スクラムの人重視は開発チームだけでなく顧客含めたステークホルダー全体です。
ウォーターフォールでは顧客が開発チームに丸投げするやり方でもプロジェクトは成り立ちましたが、その方法だとスクラム（というよりアジャイル全般）では確実に失敗します。
顧客と開発チームが肩を並べて進めることが大切です。

スクラムの作成物

プロダクトバックログ

プロダクト（完成成果物）を開発するために必要な機能をまとめ、作業着手する優先順位を付けた一覧です。
成果物を作成するTODOリストと考えるとイメージしやすいと思います。
このプロダクトバックログで定義した機能を開発チームに説明して実装していきます。

例えば、会員登録という機能があれば、「検索画面」「詳細画面」「登録画面」のように機能を分割します。
そして次に「登録画面」を作成する場合、どのような機能を実装する必要があるか開発チーム含めて協議して進めます。

そして開発が進んだ結果、新たに「再登録画面がほしい」という要件追加が出たとします。
その場合、新たにプロダクトバックログに追加したうえで、開発の優先順位を見直します。

プロダクトバックログの詳細については、別記事「プロダクトバックログ解説」を参照してください。

スプリントバックログ

開発チームはプロダクトバックログを受け取ったら、それらを開発するためのタスクをさらに詳細化します。
この詳細化したタスクをスプリントバックログと言います。

例えば、プロダクトバックログで「登録画面」を実装することになった場合、「画面作成」「ビジネスロジック作成」「DB構築」のように、細かい作業に分割して担当割り振りを行います。

このスプリントバックログの管理は開発チームが行います。
もし作業中に新しいタスクが必要と判明した場合、このスプリントバックログを更新します。

インクリメント

成果物をまとめたリリース物のことで、前回のリリース分と今回のリリース分が合わさった最新バージョンです。
スクラムはスプリントという単位で成果物を作成するのですが、スプリントの終了時点でインクリメントは完成されている必要があります。

インクリメントはテスト完了しており正常動作する成果物です。

スクラムチーム

スクラムチームは「プロダクトオーナー」「スクラムマスター」「開発チーム」という３つの役割があります。
この役割に上下関係はなく、自己組織化されています。
ウォーターフォールではリーダがメンバに指示を出していましたが、スクラムでは開発メンバが自分たちで考えて行動します。

スクラムの経験が少ないと、自己組織化した行動をとるのは非常に難しいです。
最初のうちは慣れることを目的として、小さな作業から進めていくのが良いでしょう。

プロダクトオーナー

価値ある成果物を作成するために何を作るのか判断し、その結果に責任を持つ人です。
プロジェクトのゴールとミッションを踏まえ、顧客や現場のニーズを引き出します。
プロダクトバックログを管理し、タスクの明確化と優先順位付けを行います。
このプロダクトバックログを開発者に説明し、内容を十分に理解してもらうことも重要です。

ちなみにプロダクトオーナーは必ず１名だけです。
責任が分散したり、方向性が定まらないので複数人で分担してはいけません。
委員会のような会議で判断することも同様にNGです。

スクラムマスター

スクラムマスターはウォーターフォールでいうプロジェクトリーダと違います。
開発チーム、プロダクトオーナー、組織への様々な支援を行うことで円滑にスクラムを推進するサポーター的役割を担います。

プロダクトオーナーへの支援

プロダクトオーナーと開発チームの橋渡しを行います。
プロダクトオーナーは業務に特化した人が多く、システム開発に明るくない人も多いため、スクラムの進め方やツール説明などもたんとうします。
また会議などの各種ファシリテートも行います。

開発チームへの支援

開発チームのメンバが全てスクラムの有識者とは限りません。
新規メンバの参加、またはチームを新規立ち上げる場合など、メンバに対してスクラムの進め方をレクチャーする役割があります。
そのためスクラムマスターはスクラムの経験者である必要があります。

開発を進めていると外部から想定外の作業や打ち合わせが来ることもあります。
そういった依頼を開発チームが対応していると進捗に遅れがでるため、スクラムマスターが間に入って調整を行います。

開発チームのメンバは、困ったことがあればスクラムマスターに相談します。
それに対してフォローやアドバイスをしたり、必要あれば外部との調整を行います。
あくまで支援やフォローであり、開発メンバに直接指示は出しません。

開発チーム

プロダクトオーナーが作成したプロダクトバックログをもとに成果物を作成します。
自己組織化されていることが前提であり、チームの運営やスクラムの管理は開発チームが自分たちで行います。

ちなみに成果物を作成する作業は全て開発チームの中で完結させます。
例えばインフラがわかる人がいないので一時的に外部から調達する、ということは認められません。
そういうスキルが必要であれば、最初からスキルを持ったメンバを開発チームに参加させます。

開発チームの規模は3～9名が妥当と言われています。
これにはプロダクトオーナーとスクラムマスターは含まれていません。
1～2名では少なすぎてチームとして相互作用による生産性向上につながりません。
逆に10名以上になると調整作業が増えたり、プロセスが複雑化するなどデメリットが多くなります。

スクラムで大規模開発したいのであれば、SAFeという大規模向けフレームワークがあるので、そちらを活用します。

スクラムのイベント

スクラムでは、決められたタイムボックスの中で決められたプロセスを行います。
このタイムボックスをスプリントと呼び、スプリントを何度も繰り返すことで機能を実装していきます。
ここでは、そのスプリント内で行うプロセスについて解説します。

スプリント

スプリントは機能を実装する１つのプロセス群で、正常動作するインクリメントを作成します。
このスプリントの中で、以降に説明する「スプリントプランニング」「デイリースクラム」「スプリントレビュー」「スプリントレトロスペクティブ」を実行します。

１回に行うスプリントの期間は固定であり、どのスプリントも増減しません。
プロダクトバックログから実装する機能を選択しますが、その時にスプリントで実装できる範囲であることを考慮します。

ちなみにスプリントの期間は最長でも1か月です。
期間が長すぎるとスクラムの特徴「適応」のように、フィードバックを受けて素早く改善することができません。

スプリントプランニング

スプリントの開始時に作業内容を計画することをスプリントプランニングと言います。
スプリントが1か月の場合、1回のスプリントプランニングで使用する時間は最大8時間と決められています。
もしスプリントが1週間であれば2時間以内に完了するようにスケジュールします。
それ以上の時間をかけると作業時間が減るため避けます。

まず計画としてプロダクトバックログから実装する機能を選定します。
実装機能と、１回のスプリントでできる作業量、プロジェクト状況をプロダクトオーナーと開発チームが協議して調整します。

実装するプロダクトバックログが決定したら、開発チーム内でスプリントバックログを作成します。
スプリントで作成する成果物を明確にするためスプリントゴールも合わせて作成します。
ここで定めた成果物を作成することでスプリントが終了することになります。

これらスプリントバックログとスプリントゴールを作成したら、開発チームはプロダクトオーナーとスクラムマスターに説明します。

スプリントプランニングの詳細については、別記事「スプリントプランニング」を参照してください。

デイリースクラム

毎日、作業開始前に15分程度の時間を使ってメンバ間の情報共有をします。
具体的には各メンバの以下情報を共有します。

• 昨日やったこと
• 今日やること
• 問題点があるか

これらの情報を共有したうえで、スプリントの進捗が最適化するように計画を見直したり、遅延への対処を行います。

ここで注意ですが、このデイリースクラムでは作業計画にポイントを絞って会話します。
作業内容の詳細に言及すると時間がかかり、参加メンバ全員の開発作業を止めることになります。
もし必要あればデイリースクラムが終わった後に個別で打ち合わせをセッティングします。

スプリントレビュー

スプリント終了時、成果物であるインクリメントを検査します。
この検査とはプロダクトバックログで選択した機能が想定通り実装されていることをステークホルダーとスクラムチームがチェックします。
当然、テストは完了している状態で、スプリントプランニングで作成したスプリントゴールを達成している成果物が検査対象です。

検査では完成した成果物を動作してデモを行い、以下の確認を行います。

• インクリメントのリリース可否判定
• プロダクトバックログの精査
• 次のスプリントで何を実装するか

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

レトロスペクティブとは「振り返り」のことで、スプリントの作業内容を振り返って改善計画を立てます。
スクラムは経験主義のため、振り返りを行い経験値を積むことでチームの能力向上につなげます。

レトロスペクティブの実施方法はプロジェクトによって様々ですが、よく使われる方法として「KPT」があります。
　K（Keep）：よかったこと、継続したいこと
　P（Problem）：問題点、改善すべきこと
　T（Try）：次回のスプリントで取り組む対策

ポイントは問題点だけでなく良かったことも明確にすることです。
上手くいったことを明確にすることで、次回以降も意識して継続することができます。