スクラム開発とは

スクラム開発とは

　スクラム開発とは、アジャイル開発の一種です。ほかの呼び方に、スクラム、スクラムフレームワーク、といったものがあります。スクラム開発では、10人以下の小規模なチームを作り、そこに、プロダクトオーナー、スクラムマスター、開発者という役割を定め、システムの機能ごとに、計画→設計→開発→テスト→リリースという流れを繰り返していく開発です。システム全体の完成を待たずに、ユーザーからのフィードバックをもらうことができるので、成果物を、よりユーザーが求めているものに近づけていくことができます。

　なお、ここでいうアジャイル開発とは、システム開発の手法で、要件定義→基本設計→詳細設計→開発→テスト→運用のサイクルを機能ごと繰り返し行っていく形式の開発手法のことです。顧客の要望に迅速に対応できたり、顧客からのフィードバックを開発に取り入れていくことができる手法だと言えます。

定義

　公式に定められたスクラムガイドによると、スクラムの定義とは、「複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである」と述べられています。もう少しくだけた言い方をするなら、チームでシステムを少しずつ作って、確認・改善をくり返しながら、ユーザーにとって価値のあるものを素早く届ける方法、だと言えます。

　特に、コミュニケーションを重要視した手法といえます。なぜなら、スクラム開発では、チーム内でタスクを割り振り、日々のコミュニケーションを取りつつ開発を進め、さらには、完成品をこまめに見せて、ユーザーや関係者からフィードバックをもらうといった形で開発が進められるからです。それゆえ、コミュニケーションに問題があると、それぞれの業務に影響がでて、開発が遅れてしまうことがあります。

実現するべき3つの柱

　スクラム開発では、「計画→設計→開発→テスト→リリース」という一連の流れをスプリントと呼び、これを繰り返すことで開発が進んでいく。スプリントをうまく機能させるには次に挙げる３つの柱が重要になってくる

透明性 (Transparency)

　スクラム開発において、チーム全体に今、なにが起きているのか・どう進んでいるかを共有することは非常に重要です。タスクを見える化しておくなら、透明性の実現に役立つことでしょう。透明性が担保されているなら、早期に問題を把握することができ、また、すべてのメンバーが正しい判断をくだすことができるようになります。

検査 (Inspection)

　ここでいう検査とは、スクラム開発においての成果物を、こまめに、そして、正しい方向に進んでいるかどうか確かめることを指します。検査を十分に行っているなら、前もって問題点を把握でき、対応策がとれますし、ユーザーが求めているものからのズレを修正するときにも、早い段階で対処することができます。無駄なく、価値のあるものを作ることを目的とします。

適応 (Adaptation)

　ここでの適応とは、検査の結果を見て、必要ならすぐにやり方や計画を変えることを指します。これ以上、無駄なものをつくらないように、すぐに業務のプロセスや成果物を修正する必要があります。

　ここでは、スクラム開発の3つの柱について紹介しました。この３つの柱は互いに関係しあっています。というのも、見える(透明性)→気づく(検査)→動く(適応)という問題に対処していく方法の根幹をなすものだからです。スクラム開発に取り組み際にはぜひ注意するようにしましょう。

原則

スクラム開発という手法を取り入れる上で役立つ６つの原則を紹介します。

経験主義に基づくプロセス管理

　経験主義とは、経験から知識が生まれ、開発で必要となる意思決定が観察に基づいておこなわれるという考え方のことです。スクラムはこの経験主義と無駄を省くリーン主義という考え方を根底にもっています。ここでいう、経験主義に基づくプロセス管理とは、先に挙げた３つの柱、透明性、検査、適応に重きをおこうというルールです。まだ不明瞭な問題や明確な解決策がない場合には、実践から学び、解決策を導いていくという姿勢とも言えます。

自己組織化

　スクラム開発ではチームメンバーそれぞれにタスクと責任があります。メンバーそれぞれが自律的に動き、協力しあうことでより創造的な作業が可能になります。

協力する

　チームが最大の価値を発揮するには、スプリント中または終了後も協力しあう姿勢が昼用であるということ。

目標を見定めて優先順位を決定する

　スクラム開発の最大の目標は、顧客にビジネス価値のあるもの(顧客が満足するもの)を提供することである。プロジェクトの最初期から、この目標を見定めて優先順位を決定することが必要とされる。

時間を区切る

　スクラム開発において、スプリントそのものであったり、デイリースクラム、振り返りなど時間で区切られたタスクが多数存在する。次々とタスクをこなし、仕事の質を高めていくスクラム開発において、仕事を時間によって区切ることは重要。

継続的な改善

　スクラム開発において、最初に出来上がったシステムやソフトウェアが最善のものであることはほとんどありません。反復的に改修・開発を行うことで、チームは顧客のニーズにうまく対応したものを作り出すことができます。

価値基準

　上で紹介したスクラム開発に必要な３つの柱を実現するために、チームメンバーそれぞれはどのような価値基準を持てば良いのでしょうか。それは下記に挙げる５つです。

確約（Commitment）

チーム全体で目標に対して責任を持ち、やり遂げる意志を持つこと。

集中（Focus）

最優先の目標（スプリントの目標、機能・製品の価値向上など）に集中し、他のことに気を取られないようにすること。

公開（Openness）

自分の作業、課題、進捗などをチーム内で正直に共有し、透明性を保つこと。

尊敬（Respect）

チームメンバー全員がお互いの意見や貢献を尊重すること。

勇気（Courage）

困難や不確実性に立ち向かい、必要なことを正直に言ったり、挑戦したりする勇気を持つこと。

これらの価値基準をどれほど達成できているかがスクラムの成果につながります。ぜひ、チーム全体でこの価値観を共有するようにしましょう。

スクラム開発のメリット

スクラム開発には以下のようなメリットがあります。

変化に柔軟に対応できる

　スクラム開発では、スプリントと呼ばれる、長くても1か月ほどの開発期間をくりかえしていきます。言い換えると1か月ごとに計画の見直しをする機会があるので、顧客の要望が変化したり、ニーズが変化したときに、仕様変更が生じたとしても柔軟に対応することができます。

タスクを効率的に進められる

　スクラム開発では、後述するようにチームメンバーのそれぞれの役割が明確に決められています。プロジェクトは、「プロダクトオーナー」「スクラムマスター」「開発者」の3つの役割に分担して進められます。各メンバーは自分のタスクを正確に認識できるため、効率的に作業を行うことができます。

　また、スクラム開発では、優先度の高い機能から開発が進むため、短い開発期間で最大限の効率を追及することができます。そして、都度、顧客からの要望を取り入れることができるため、プロジェクト終盤での、手戻りなどを少なく抑えることができます。

工数の見積もりが正確になる

　スクラム開発では、チームメンバーそれぞれがタスクを把握した上で、短い開発期間(スプリント)を繰り返します。チームメンバーそれぞれの視点が入ること、短い期間の見積もりであること、経験をもとに過去のスプリントから作業量を割り出せることなどの理由により、工数の見積もりの正確性が高まります。

進捗が見える化される

　スクラム開発では、後述するようにデイリースクラム、スプリントレビューなど、短いサイクルで、進捗が全メンバーに共有・可視化されていきます。それで、各メンバーは、自分が今、何をするべきなのか、誰のタスクに問題が生じているのか把握しやすくなります。タスクに対する責任感も培われるので、メンバーの成長にもつながる側面があります。

ユーザーの満足度を高めるプロダクトをリリースしやすい

　前述したように、スクラム開発では、スプリント毎に計画の確認・見直しが行われます。特に、スプリントレビューでは、成果物を顧客に確認してもらえる機械があります。このよう、スクラム開発の現場では、プロダクトに顧客の要望を取り入れたり、顧客と開発側の認識の齟齬を発見する機械が多く設けられています。そのため、顧客と開発の距離も近づき、ユーザーの満足度の高いプロダクトをつくりあげることができるようになります。

スクラム開発のデメリット

　多くのメリットが存在するスクラム開発ですが、コミュニケーションを重視するスタイルゆえに、下記のようなデメリットも存在しています。

開発スケジュールの全体像が把握が難しい

　スクラム開発では、仕様変更が起こりやすく、その度に開発内容が変更されるので、プロジェクト全体の開発スケジュールが把握しづらくなります。仕様変更のたびに、開発の方向性が変わることがありますし、当初の予定にない要件が追加されていくスコープクリープを引き起こす場合もありえます。

　開発スケジュールを把握することの難しさは、各スプリントの目的とインクリメントを明確に定義することによってある程度回避することができます。さらに、スクラムチーム全体に何を「完了」とするかを明確に理解させ、「完了」を超えないようにしておくならさらに効果的でしょう。

人員が欠けるとプロジェクトに遅れが生じやすい

　スクラム開発では、短期間かつ少人数での開発となります。それで、途中で人員が欠けるような事態になると、プロジェクトそのものに遅れが生じることがあります。プロジェクトに必要なスキルをもったメンバーを過不足なく集める必要があるので、チーム編成には慎重さが求められます。

　編成されるチームメンバーには、技術的なスキルだけでなく、短期間で成果をださなければならないことへのプレッシャーに耐えられること、また、自発的に動くことができるなど多くの要素が求められます。

円滑なコミュニケーションが不可欠

　前述したようにスクラム開発にたびたびの仕様変更はつきものです。それで、スクラム開発には円滑なコミュニケーションが必要不可欠だと言えます。コミュニケーションが円滑に図られていないと、仕様変更のたびに、メンバー間で認識のズレが生じかねません。また、より良いプロダクトをつくるためにも、顧客とのコミュニケーションも欠かせません。チームメンバーにはコミュニケーションを取ることを苦としない方を選ぶようにしましょう。

ミーテイングの多さが負担になる

　デイリースクラム、スプリントレビュー、レトロスペクティブなど、定期的な会議が多いため、負担に感じる人もいます。このような時には、デイリースクラムの記録をつけて、チームにとって何が役立ち、何が役に立たないのか明確にするようにしましょう。そうすれば、メンバーのミーティングへのモチベーションの低下を避けることができます。

スクラム開発のメンバーとその役割について

スクラム開発では、以下のような役割がメンバーに割り当てられています。

このうち、プロダクトオーナーとスクラムマスターは各１人づつ、チームの残りは開発者となります。チームは全体で10人以下の小規模なものとなります。

プロダクトオーナー

　プロダクトオーナーはプロジェクトの責任者としての役割を果たします。開発の方向性を定め、スクラムチームがつくりあげるプロダクトの価値を最大化する重要な責任があります。ユーザーや顧客からの要望を吸い上げ、記録し、チームやステークホルダーに共有したり、チームが迷わず開発を進められるように質問に答えたり、仕様を明確にします。

　プロダクトオーナーが果たす仕事の一つであるプロダクトバックログの管理について説明しましょう。プロダクトバックログとは、プロダクトを完成させるために、何をどんな順番で作っていくかを決めたロードマップのようなものです。プロダクトオーナーは、プロダクトバックログを管理し、次に何を納品するべきかなどのプロダクトゴールを明確にします。また、顧客からの要望はこのプロダクトバックログに記録されます。最終的に、プロダクトが納品できる状態であるかを確認することもプロダクトオーナーの役割です。

スクラムマスター

　スクラムマスターは、チームがスクラムのルールや価値観に従って働けるように支援します。チーム内でのコミュニケーションが円滑にされるように責任を負います。チームが最高の力を発揮できるように環境を整えるために働きます。

　開発業務の進捗管理をすることがその役割だと言えます。開発の進捗を追いかけ、問題となっていることはないか確認し、問題があればその原因を解決するために働きます。難しい問題が発生した場合には、スクラムマスターが解決するように努め、チームが開発に集中できるように環境を整えます。そして、様々なスクラムイベントを開催します。デイリースタンドアップミーティングを進行したり、スプリント計画、スプリントレビュー、振り返りミーティングを開催して、スクラムチームの進行役として働きます。

　また、スクラムマスターの役割には、プロダクトオーナーの支援も含まれています。プロダクトゴールの定義やプロダクトバックログの管理や、スクラムチーム内での共有なども含まれ、プロダクトオーナーが機能しないときにはアドバイスを与える立場でもあります。「調整役」「サーバント」と呼ばれることもあります。

開発者

　スクラム開発における開発者とは、実際にプロダクトを作る人たちを指します。プログラマーだけでなく、デザイナー、テスター、アナリストなども含まれます。継続的な改善を達成するためにも、各人は自律的に行動できる人で、チームに協力的である必要があります。自分の専門分野だけでなく、設計やドキュメント作成、コーディング、テスト、運用など非通りのスキルを備えていなければなりません。すべてのメンバーがすべての領域で業務を担当できるようになることが理想的です。プロジェクトの最終的な成果物であるインクリメントを完成させるために作業を行い、その品質に責任をもつことになります。また、実際の作業をどのようにすすめていくか、自己組織化して決めていくことも開発者の責任です。

スクラム開発の大まかな流れ

スクラム開発では、スプリント(通常２週間から1ヶ月ほど)という作業期間を繰り返し、それぞれの期間の最後に成果物が作成されます。チームはプロダクトを常に改善していく意識をもち作業に取り組みます。これに加えて、毎日行われるデイリースクラムと、スプリントレトロプロスペクティブ（振り返り）という工程が存在します。以下に、簡単なスクラム開発の流れを紹介します。

1．プロダクトバックログの作成 

　まずプロダクトバックログとは、前述したように、プロダクト完成までのロードマップのようなものですが、より詳しく説明するなら、開発するプロダクトの機能や改善要素に優先順位をつけてリストにしたものです。このプロダクトバックログの中で、顧客の要件から、優先度の高い機能や改善点を明確なものにしていきます。通常、プロダクトオーナーが、ざまざまな側面を考慮して作成しますが、開発者の意見が取り入れらることもあります。

2．スプリントプランニング（スプリント計画） 

　スプリングプランニング（スプリント計画）とは、スプリントバックログをもとにつくられた、開発メンバーが実施するタスクやスケジュールを定めたものです。はじめに、これから始めるスプリントで、プロダクトのどの価値を高めたいのか、チーム全体の目的を定義づけします。そして、それを達成するための作業を洗い出し、どのように作業を進めるかを決定します。そして、タスクや作業ごとにスプリントバックログを作成します。このとき、決まった期間内でどこまでの工程を進めるのか明確にしておきましょう。

3．デイリースクラム 

　デイリースクラムとは、スプリント中に毎日、同時刻に行われる15分ほどの会議のことです。各メンバーのタスクの進捗状況や、昨日終えたこと、今日行うこと、起きている問題などをチーム内で共有することが目的です。問題や課題の状況によっては、スプリントバックログを修正することも必要になるでしょう。

　通常は、開発者がその日の作業計画を共有し、プロダクトオーナーとスクラムマスターが、全体の状況を把握するようにします。このような短時間のミーティングが頻繁に行われるため、スクラム開発では、開発者が抱える問題を迅速に把握、対処することが可能になります。

4．スプリントレビュー

　スプリントレビューとは、スプリント期間の終盤に開かれるミーティングです。参加者はチームメンバーだけでなく、顧客を含むステークホルダーがそろいます。開発チームがスプリントの成果として、動くアプリケーションでのデモを行います。このレビューでは、成果物がバックログの基準をみたしているかどうかを確認し、改善点を見出し、次の開発の方向性を決定づけていきます。

5．スプリントレトロプロスペクティブ（振り返り）

　スプリントレトロプロスぺクティブは、スプリントを振り返るために開かれるミーティングです。スプリントレビューと同じスプリントの最終日に開かれることが多く、混同されやすいですが、スプリントレビューが成果物に着目するのに対して、スプリントレトロプロスペクティブでは、スプリント期間中のチームの対応や進め方に着目します。良かった点や改善点を洗い出し、次のスプリントでどのように活かすことができるかを考えていきます。

スクラム開発での３つの成果物

ここでは、スクラム開発で作成される３つの成果物について紹介します。上で紹介した図解中の赤枠部分、プロダクトバックログ、スプリントバックログ、インクリメントが存在します。

プロダクトバックログ

　プロダクトの改善に必要なすべての機能や要件のリスト。プロダクトオーナーが管理し、優先順位をつけて更新します。プロダクトバックログに含まれているものすべてがチームの仕事というわけではなく、チームが取り組む仕事の選択肢だと考えます。プロダクトオーナーはチームからの情報、市場、顧客からの要望などから、このプロダクトバックログを更新していきます。

スプリントバックログ

　スプリント中にチームが取り組む作業項目のリスト。プロダクトバックログをもとに作られます。開発メンバーが実施するべきタスクを選び、スプリント内で達成することを目指すものです。必要に応じて、リアルタイムで更新されていきます。このスプリントバックログには、スプリントゴール、スプリントで選ばれたプロダクトバックログアイテム、そして、そのプロダクトバックログアイテムを実装するための作業計画が含まれています。

インクリメント

　インクリメントとは、スプリントの終わりに完成しているリリース可能なプロダクトの一部です。以前に作成されたインクリメントに追加され、プロダクトとして成長していきます。プロダクトゴールを達成するために必要となる「完了」の定義をみたす成果物となります。場合によっては、スプリントレビューで、ステークホルダーに提示され、「完了」かどうかの判断がなされます。「完了」と判断されない限り、リリースすることはできません。

まとめ

　今回はアジャイル開発の手法のひとつであるスクラム開発について紹介しました。少人数のチームで、短期間の開発に取り組み、コミュニケーションを重視する手法です。短いサイクルで開発が進むので、仕様変更に対応しやすい特徴があります。一方で、チームとして何を目標とするのか明確にしておかなければプロジェクトの計画を立てづらくしてしまう側面もあります。スクラム開発のメリット・デメリットをよく理解し、効果的に用いることができれば、より品質の高いプロダクトを作り上げることができるでしょう。

お問い合わせはこちら

この記事をシェアする