なぜスクラムによるアジャイル開発が注目されているの？

　スクラム開発はソフトウェア開発の現場でよく利用される方法で、アジャイル開発とセット利用されることが多いです。昨今のソフトウェア産業では、ユーザーのニーズの移り変わりが早く、開発している途中でクライアントからの要求が変わったり、スピーディーにリリースすることが求められています。

　そのため、プロジェクト開始時に決定されていない事が多く、不確実性が高いプロジェクトが増えています。このような場合に従来の開発手法であるウォータフォール型の開発を適用することは不可能です。

　ウォーターフォール型では要件定義・基本設計・詳細設計・実装（プログラミング）・単体テスト・結合テスト・システムテストを経て、リリースの流れで進めますが、詳細設計の最中に要件が変わった場合、「要件定義」に戻らなければならなくなるからです。

　こんなときに、アジャイル/スクラム開発の手法を使うこと、クライアント（ユーザー）のニーズを常に更新しながら開発を進めていくことが出来るのです。

スクラム開発とは

　スクラム開発とは、１９９０年代にジェフ・サザーランド氏とケン・シュエイバー氏という方達が中心になって作られたもので、Scrumの名前は日本人である野中郁次郎氏と竹内弘高氏によって提唱されたものです。

　スクラム開発では、プロジェクトのゴール（プロダクトを作りあげること等）に向けて、チームが一丸となって取り組むべき作業・会議・成果物を定めます。具体的には以下のような役割と作成物、会議を進める必要があります。

スクラム開発で作る物

プロダクト/製品

　プロジェクトのゴールは、ユーザーに対して売上をあげられるような製品や、事務作業等を簡素化できるようなソフトウェアなどを開発していくことです。スクラム開発でも同様で、最終的なプロジェクトの目的に対して、プロダクト/製品を作成（開発）していきます。

プロダクトバックログ

　プロダクトバックログとは、プロダクト/製品を開発するにあたって、どの優先度で要求を実現していくかを視覚化したものです。各要求では必ず優先度が重複しない形になっている必要があり、プロダクトバックログを見れば、どの要求から手を付ければよいか分かるようになっていることが大切です。

スプリントバックログ

　スプリントバックログとは、プロダクトバックログを具体的にタスク（作業）として分割したものです。プロダクトバックログはプロダクトオーナー（後述）が作成するものですが、スプリントバックログは開発メンバー（後述）が作成するものになります。

スクラム開発での役割

プロダクトオーナー

　プロダクトオーナーとしての大きな役割は、プロダクトに対して最終的な決定権限を持っていることです。同時にプロダクトに対して権限を持つということは、プロダクトバックログに対しても最終決定権元を持っています。

　スクラム開発を始めるにあたって、プロダクトオーナーは必ず１人必要で、以下の役割を持っています。

　もちろん、常にプロダクトバックログを１人で更新したり、ステークホルダーの説明をプロダクトオーナのみがする必要はありませんが、最終的な権限と責任を持っているのはプロダクトオーナーです。

スクラムマスター

　スクラムマスターとは、スクラム開発の手法を開発メンバーに理解させたり、会議の進行を行ったりする、スクラム開発のリード役と言えるでしょう。役割としてはスクラムを円滑に回していくための全ての作業を担っており、スクラム開発における指南役となります。

　プロジェクト立ち上げ期では、スクラム開発が浸透していない場合が多々あるため、スクラム開発を行うための準備を行ったり、スプリント期間中にはプロダクトバックログの書き方、スプリント計画（後述）の作り方などスクラムに対して様々な事を積極的に行う必要があります。

　一方、スクラムマスターの最終的な目標としては、プロダクト/製品を作り上げるだけでなく、スクラムマスター自身がいなくてもチームが運営されることが役割として存在します。なぜならスクラムマスターはスクラム開発の指南役ですので、チームが成熟すればスクラムマスターは必要なくなるからです。（少しさびしいですが、、）

　プロダクトオーナーと違って明確な作業だけでなく、抽象的な仕事を自ら生み出して率先して行っていく力が求められますので、自発的にチームを良くしたいという方が向いていると思います。

開発メンバー

　開発メンバーはその名の通り、実際にプロダクト/製品を開発するメンバーです。通常３名から９名で構成されることが多く、３名より少ない場合は属人化が避けられず、９名以上になる場合はコミュニケーションによる時間が掛かりすぎてしまうので、３名から９名の間に抑えることが必要です。

　開発メンバーはプロダクトを開発するために、要求分析、システム設計、実装（プログラミング）、テストを行う必要があり、これらは特定のチームとして機能させるべきではありません。例えば８名の開発メンバーがいる場合に、「特定の２名がテスト担当」のように振り分けるのではなく、全員がプロダクトを開発するための工程をできるようにするのが理想です。

　もちろん技術スキル・知識の差はありますが、プロジェクトチームとして機能横断的なチームを作り上げることが強固で柔軟なチームを作ることに繋がりますので、できる限り各メンバーが複数の作業をできるようなチーム作りをする必要があります。

スクラム開発の会議体

スプリントとは

　会議体を知る前にスプリントについて知っておく必要があります。スクラム開発におけるスプリントとは、固定された期間を予め決めておき、スプリント期間中に計画、設計、開発、テストなどのプロダクトをリリースするための判断に必要な全ての事を行います。また、スプリントの期間はプロジェクトが始まった後に変更してはいけません。

　例えば、２週間スプリントのプロジェクトの場合、２週間ごとにプロダクトバックログにある作業を行っていき、スプリントの最終日にはリリース判断ができるプロダクトが出来ている事が必要です。

　大体多くの現場では、スプリント期間は１週間から４週間に設定されていることが多く、短すぎると作業を終えられなくなり、長すぎるとユーザーからの要求変更に対応することができなくなってしまうので、基本的には１ヶ月以内に定めましょう。

バックログリファインメント

　バックログリファインメントでは、バックログをREADY(着手可能）な状態に持っていく会議です。通常バックログはプロダクトオーナーが作成しただけでは不十分で、開発者たちに作業ができる状態まで落とし込んで貰う必要があります。

　また、バックログが少ない場合などにも、どんなバックログが必要かを議論し合う場としてりようすることもよいでしょう。

デイリースクラム

　デイリースクラムでは、スプリント期間中毎日行われるもので、コロナ下ではテレビ会議などが主流になってきましたが、基本的には毎日、同じ場所、同じ時間で状況を確認するための会議です。

　時間としては15分ほどが最適で、朝にする必要はありませんが、個人的には朝10時や11時頃に実施するのが良いと考えています。デイリースクラムでは開発チームに対して以下を確認します。

　注意点として、デイリースクラムで問題が発見された場合に、その場で解決しようとしてはいけません。問題解決が必要である場合には、デイリースクラム以外で別の会議を設けましょう。

スプリント計画

　スプリント計画では、スプリントを始めるために必要な会議で、次のスプリントで何を作るのか、どのように作るのかを計画します。

　通常２部構成で計画が行われる事が多く、１部ではプロダクトオーナー、スクラムマスター、開発メンバーで、次のスプリントで何を実現したいかをプロダクトオーナー説明してもらいます。

　続いて２部では要求された項目に対して、開発メンバー内が必要な作業を洗い出していきます。通常プロダクトオーナーが作るバックログでは、「〇〇の機能がほしい」のように作られますので、開発をする際にはタスクとして落とし込む必要があります。

スプリントレビュー

　スプリントレビューでは、スプリント中に作成されたプロダクト/製品について、プロダクトオーナーがレビューを実施します。ここでプロダクトバックログの要求が完全に満たされているかを確認することで、無駄な手戻りを発生させずに進めることが可能になります。

　注意点として、レビュー時には実際に動作しているものを見せる必要があり、単に説明をしたりパワポで見せるということはいけません。アジャイル開発では常に動作するものをリリースすることが求められているため、開発メンバーはスプリント内で必ず動作するものをレビュー物として提出しましょう。

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

　スプリントレトロスペクティブとは、前スプリントでプロダクト開発での作業を実施する上で、問題がなかったか、もっと成果を出すためにできることはないかを話し合う場です。いわゆる「振り返り」です。

　レトロスペクティブでは、あくまでチームに対しての問題点や改善点を上げ、より良いチームしていくことが目的ですので、個人を攻撃するようなことは絶対にしてはいけません。

　振り返りの方法としては、KPTが最も使われているもので、K「Keep」、P「Problem」、T「Try」の略になります。これらをチームで洗い出し、次のスプリントでより良くなるためにTryを実施します。

スクラム開発のメリットは？

　スクラム開発の説明は以上になりますが、いかがでしたでしょか。アジャイル開発は柔軟に出来るというイメージを持っていた方も多いかと思いますが、スクラム開発を組み合わせた場合、役割・作成物・会議体は必ずプロジェクト開始前に決めておく必要があります。

　そのため、アジャイルの要素を組み合わせつつ、開発スタイルを固定化することで、柔軟にかつチームを恐子することが出来ます。スクラム開発のメリットは以下です。

　逆にスクラム開発を失敗させてしまうパターンというのも存在するので、下記を参考にしてみましょう。

スクラム開発の半数が失敗？　失敗させるプロセスアンチパターン１０選

アジャイル開発手法の１つであるスクラム開発では、ソフトウェア開発を柔軟に正確に進めることを可能にします。一方間違った方法で行っていれば、上手く行きません。そんな失敗するパターンを10選まとめました。

techgrowup.net

　また、スクラム開発をもっと知りたい方は、下記のような本を読んでみてください！