はじめに
こんにちは。カイザーです。
今回はプロジェクト開発手法の1つである「スクラム開発」のフレームワークについて、まとめてみました。
スクラムの特徴
シンプルなフレームワークであること
スクラムのフレームワークはシンプルで軽量です。ルールブックと呼ばれる「スクラムガイド」はたった17ページしかありません。しかし、スクラムは「フレームワーク」であり、問題を簡単にするものではありません。
難しい課題は、難しく、様々なケースに当てはめて、柔軟にスクラムを考える必要があります。そのため「習得は困難」とされています。
素早い反復を繰り返すこと
スクラムでは、フィードバックループを短期間で反復させながら、開発を進めます。そうすることにより、素早いフィードバックを得ることができます。また、問題があったとしても小さいうちに迅速に対応してしまうのも、スクラムの特徴です。
検査・適応・透明性
スクラムでは、様々な事がらについて、検査・適応を行います。例えば、スプリントレビューではそのスプリントで完成したプロダクトを検査します。その結果は、今後の開発に適応されていきます。(スプリントレビュー)
また、デイリースクラムも検査と適応の場です。毎朝、メンバーの状況共有を通じて検査し、スプリントゴールを達成するための障壁がある場合は、チームでそれを解消するために適応します。
さらに、スクラムでは、プロダクトだけでなく、そのプロセスに対しても、検査と適応を行います。(スプリントレトロスペクティブ)
こうした検査・適応をうまく行うために、「透明性」を心がける必要があります。つまり、重要な情報には、プロジェクトに関わる全員がアクセスできるようにし、誰もがそれについて確認したり、議論したり出来るようにしなければなりません。
また、スクラムでは「分からないことを受け入れる」としており、このような「検査・適応」を繰り返すことにより、チームが学習し、より良いプロダクト(価値)を考えて実践できるようになったり、より良いやり方を考えて実践できるようになるとしています。
スクラムの役割
スクラムでは、「プロダクトオーナー」「スクラムマスター」「開発チーム」が1つのスクラムチームとなります。スクラムチームは、自己組織化し、機能横断的であると言われています。
自己組織化チームは、作業のやり方や順番について、最善策を自ら考え選択します。いちいち、チーム外から指示を受ける訳ではなく、能動的なチームである必要があるのです。
機能横断的チームは、この1つのスクラムチームで、プロダクトを「完成」させることのできる能力を持っている必要があります。
また、「プロダクトオーナー」「スクラムマスター」「開発チーム」は役割であり、役職ではありません。そこにピラミッドのような上下関係はなく、お互いの役割を達成するために、各々のが責任、協力してゴールを達成します。
プロダクトオーナー
プロダクトバックログの管理に責任を持つ1人の人間であるとされています。
プロダクトバックログは、簡単に言うと「実現したいことリスト」です。
詳細は後ほど説明します。
プロダクトオーナーの役割は以下です。
- 開発する機能やその優先順位を決める。
- 最も価値の高い作業から行われるようにする。
- どのようなプロダクトを開発すべきか、明確なビジョンを持っている
- さらに、明確なビジョンを関係者全員に伝える。
こうした役割を達成するため、プロダクトバックログの管理に責任を持ちます。
スクラムマスター
スクラムマスターは、スクラムの価値・原則・学びを全員に浸透させる手助けをします。
そのため、プロジェクトリーダーのように、開発するプロダクトの方向性を決めたり、コントロールしたりはしません。
あくまで、スクラムを全員に浸透させ、円滑にスクラムが進むように、手助けするのが役割です。
- スクラムチームのコーチとなり、スクラムのプロセスでリーダーシップを発揮する。
- チームに課題や障害があるとき、迅速に解決できるようにファシリテートする。
- 外部からの妨害からチームを守り、チームが価値を生み出すことに集中できるようにする。
開発チーム
実際に、プロダクトを設計・開発・テストできるチームです。
- 自己組織化し、プロダクトオーナーの要求を達成する方法を、自ら決定しなければならない。
- 機能横断的で、エンジニア・プログラマ・UIデザイナなどといった、プロダクトを開発するのに必要な人たちが、1つの開発チームとなります。
- 1つの開発チームは、5人〜9人だと言われています。
- 大きなプロジェクトでは、小さな開発チームを複数持ちます。
- ただし、その場合でも、各チームは機能横断的なチームメンバーとなっている必要があります。
プロダクトバックログ
プロダクトバックログは、一言で言うと「実現したい要求リスト」です。
最終的には、プロダクトオーナーが責任を持って管理します。
また、プロダクトバックログの要求の一つひとつを「プロダクトバックログアイテム」と呼びます。
- 優先順位の高い順番に並び替えられている。
- プロダクトバックログには、新規機能や既存機能への改修のほか、バグ改修、保守作業なども含まれます。
- プロダクトバックログは誰が追加しても良いですが、最終的にはプロダクトオーナーが責任を持ちます。
- プロダクトバックログアイテムに対し、開発チームが見積もりを行います。
- プロダクトバックログは随時更新します。
スクラムのイベント・活動
スプリント
スクラムでの開発は、短期間にタイムボックス化された反復を繰り返して行われます。これを「スプリント」と呼びます。
- 期間は、最長1ヶ月。
- 期間は、毎回同じでなければならない。
期間が短期間で、かつ固定化されているので、ウォーターフォールと比較して、計画を立てるのが容易になります。
スプリント計画会議
スプリントの初日に実施し、そのスプリントでの作業を計画します。
これにも時間制限があり、スプリントが2週間の場合、最大で4時間で終わらせる必要があります。
- チーム全員が参加する。
- プロダクトバックログの中から、スプリントに当てはまる分だけ、最も優先順位の高いアイテムを選びます。
- チームが少し余力を持った状態とすべきと言われています。あまりカツカツになると、チームの作業効率が落ちるためです。「持続して」開発できる量にする必要があります。
- 選んだプロダクトバックログに対し、「どのように」完成させるか決め、タスクに分解します。
デイリースクラム
スプリント計画会議で、そのスプリントで何をどのようにやるか合意できたら、スプリントの実施がスタートします。
スプリントの実施中、チームの状況を検証・適応するための機会が、デイリースクラムです。
- 毎日同じ時刻に15分以内で行う。
- 開発チームのためのミーティングである。
- 開発チームメンバー全員が「昨日何をやったか」「今日何をやるか」「達成を妨げる障壁」を共有します。
- デイリースクラムは問題解決の場ではないため、必要に応じて、必要なメンバーだけで別途ミーティングする。
スプリントの実施
スプリント計画会議で計画し、合意したアイテムについて、開発チームはスプリント内の「完成」を目指して開発を進めます。
- スプリントの実施中に、開発チームは作業を「完成」させる必要があります。
- 完成の定義は様々ですが、一般的なソフトウェア開発では、「設計・開発・テスト・ドキュメンテーションが完了していること」とすることが多いそうです。
- 短いスプリントですが、テストはフルで行う必要があります。なぜなら、「完成」とは開発チームが、開発した機能を自信を持ってリリースできる状態にしておく必要があるためです。
スプリントレビュー
「完成」したプロダクトを、関係者全員にデモし、プロダクトの検査を行う機会です。
これにも時間制限があり、スプリントが2週間の場合、最大で2時間で終わらせる必要があります。
自分たちの開発したプロダクトに対して、検査と適応を行うスケジュール化された機会です。
これを、スプリント毎に必ず行うことで、スクラムチームは頻繁なフィードバックを得ることができます。
- スプリントでの成果についてデモした上で話し合う。(検証)
- NGであったり、更なる追加要望があれば、プロダクトバックログへの適応を行う。
- 顧客やステークホルダーは、スプリントでの成果に追いつき、フィードバックをすることができる。
- スクラムチームは、フィードバックを受けることで、自分たちの開発したプロダクトの正しい方向性や、価値について、より深く知ることができる。
スプリントレトロスペクティブ
スプリントの1番最後のイベントです。いわゆる「振り返り」です。スクラムチームやスクラムのやり方を検査し、次のスプリントへの適応をする機会です。
これにも時間制限があり、スプリントが2週間の場合、最大1時間半で終わらせる必要があります。
- 良かった点、うまくいかなかった点を議論します。
- その中から、改善点を見つけ、次のスプリントで実際に改善する項目を決めます。
- スクラムでは、継続的な改善が大切だと言われていて、必ずスプリントの最後に振り返ることで、次のスプリントで「もっとうまくやる」ために、更なる高みを目指します。
ここまで終わったら、1スプリント終了です。翌日からは、1番初めに戻り、スプリント計画会議からスタートです。
さいごに
スクラムのフレームワークはシンプルですが、実際には様々なシチュエーションに応じて、柔軟に対応する必要があると思います。
スクラムガイドをルールとしつつ、各スプリントで、スクラムのやり方を良くしていきたいものですね。
おすすめ書籍
