
スクラムとは? アジャイルとの違い、特徴、メリット・デメリットを紹介

市場が急速に変化し、顧客のニーズや価値観も日々移り変わる現代では、システム開発の現場でもより柔軟な対応が求められます。そのようななか、迅速かつ柔軟な開発を実現し、加えて継続的な改善も行える「アジャイル開発」を取り入れる企業が増えてきています。アジャイル開発のフレームワークのうち、特に使用頻度の高い手法が「スクラム」です。今回は、スクラムの概要やメリット・デメリット、実施手順などを詳しくご紹介していきます。
スクラムとは
スクラムとは、アジャイル開発におけるフレームワークの一種です。最大でも10人という少人数のスクラムチームを結成し、「スプリント」と呼ばれる短期間の開発サイクルを繰り返すことで開発を進めていきます。これにより、顧客のニーズをくみ取りながら、価値が最大化されたプロダクトの迅速な開発が可能になります。
スクラム開発のポイントとしては、「3つの役割を持ったメンバーが参加すること」「スプリントを構成する4つのイベントを実施すること」「3つの作成物を活用し、プロダクトの完成までスプリントを繰り返すこと」が挙げられます。それぞれの詳細については後述します。
アジャイルとスクラムの違い
アジャイルとは、「素早い」「機敏な」といった意味を持つ抽象的な概念です。事業開発やプロジェクト管理、組織変革や働き方改革など、さまざまな分野で使われる言葉であり、特にビジネスやITの世界では「方針の変更やニーズの変化など、状況の変化に素早く対応すること」を表す言葉として使われます。
システム開発におけるアジャイル開発とは、開発の工程を機能ごとに分割し、各開発サイクルを短期間で繰り返し実施する開発手法です。一つひとつの開発工程が小さくまとまるため、開発スピードを向上させてリリースまでの期間を短くすることができるほか、柔軟な対応が可能になり顧客のニーズを反映しやすいといった特徴があります。従来の開発手法である「ウォーターフォール開発」と対比して語られることが多いです。
一方、スクラムとはアジャイル開発におけるフレームワークの一つです。アジャイル開発が開発手法の概念であるのに対して、スクラムはその概念を実現する具体的な手法であると言えます。いくつかあるアジャイル開発の手法の中でも、スクラムは特に使用頻度が高い手法です。
カンバンとスクラムの違い
「カンバン」とは、スクラムと同じくアジャイル開発のフレームワークの一つですが、スクラムとは内容が大きく異なります。
カンバンでは、カンバンボードと呼ばれるボードを活用し、タスクの進捗状況を視覚的にリアルタイムで管理します。一方のスクラムは、スプリントと呼ばれる短い反復期間で計画的かつ段階的にタスクを進めます。また、スクラムでは決められたスプリント内で決められた目標を達成することを重視し、タスクの追加や削除は行いません。それに対し、カンバンは継続的な改善を重視するため、タスクの変更に柔軟に対応することができます。
スクラムの特徴
スクラムは、経験から生まれた知識を重視する「経験主義」と、無駄を省いて本質に集中するという考え方の「リーン思考」に基づいています。この2つの考え方を踏まえて定義されているのがスクラムの三本柱です。三本柱とは、「透明性」「検査」「適応」を指し、これらを実現できるように設計されているのがスクラムの特徴です。
-
透明性:良し悪しにかかわらず、すべての事象やプロセスを可視化する
-
検査:チームメンバーの進捗状況や作業プロセスなどに問題がないかを確認する
-
適応:検査結果を踏まえた上でプロセスやプロダクトの軌道修正を行う
また、三本柱はそれぞれ密接に関係しています。プロセスや作業状況の透明性を保つことで進捗状況などの検査が可能になり、正しい検査結果を得ることで迅速な適応が可能になります。
スクラムの価値基準
スクラムでは、「確約(Commitment)」「集中(Focus)」「公開(Openness)」「尊敬(Respect)」「勇気(Courage)」という5つの価値基準が設けられています。スクラムを成功させるためには、これらの価値基準を実践することが非常に重要です。
価値基準 | 概要 |
---|---|
確約 (Commitment) |
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。 |
集中 (Focus) |
スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。 |
公開 (Openness) |
スクラムチームとステークホルダーは、作業や課題を公開する。 |
尊敬 (Respect) |
スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。 |
勇気 (Courage) |
スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。 |
出典:Ken Schwaber & Jeff Sutherland「スクラムガイド」
スクラムフレームワークの開発者によって執筆されたスクラムガイドには、これらの価値基準が具現化されることでスクラムの三本柱に息が吹き込まれる、と書かれています。形式的ではなく、より本質的なスクラムを実施するためには、「三本柱」と「価値基準」の両方の実現が必要です。
スクラム開発のメリット
スクラム開発を取り入れることで、さまざまなメリットが得られます。具体的には以下のようなメリットが挙げられます。
-
作業が効率化し、生産性が向上する
スクラム開発では、各チームメンバーが役割やタスクを分担して開発を行うため、効率的に作業を進めることが可能です。また、優先順位が高い機能から開発を進めていくため、短期間で成果を出しやすく、生産性も向上します。 -
柔軟な仕様変更が可能になる
スクラム開発では頻繁にフィードバックを実施し、その結果を次のスプリントに反映していきます。そのため、急な仕様変更が発生した場合でも、スプリントごとに修正するなど、柔軟な対応が可能になります。 -
進捗状況を把握しやすく、問題の早期発見ができる
スクラム開発ではコミュニケーションを密に取ることを重視し、ミーティングを頻繁に行います。そのため、進捗状況の共有や把握が容易になり、問題の早期発見もしやすくなります。結果としてプロジェクトをスムーズに進めることが可能になります。 -
正確に工数を見積もることができる
スクラム開発では短いスプリントで開発を区切り、さらに機能ごとにも見積もりを行うため、非常に高い精度で工数を算出することができます。 -
チームメンバーの育成が促進される
スクラム開発では、チームメンバーが各自で作業工数を見積もる必要があります。これにより、メンバー一人ひとりの責任感がより一層強くなり、結果として自己研さんを率先して行うようになるなど、メンバーの育成が促進されます。
スクラム開発のデメリット
スクラム開発には多くのメリットがある一方で、いくつか注意すべきデメリットも存在します。スクラム開発を導入するにあたってのデメリットとしては、以下のようなものが考えられます。
-
スケジュールの全体像が把握しづらい
スクラム開発は柔軟な仕様変更が可能である分、仕様変更のたびに開発内容が変わり、スケジュールの全体像を把握しづらいというデメリットがあります。そのため、複雑なプロセス管理が求められる大規模なプロジェクトには、スクラム開発の適用が難しいこともあります。 -
メンバー同士のコミュニケーションが必要不可欠
スクラム開発では、プロジェクトに対して認識にズレが生じないよう、メンバー全員が密にコミュニケーションを取ることが求められます。そのため、開発メンバーを構成する際には人間関係や相性などを考慮しなければならず、結果として人を集めるのに苦労する場合もあります。 -
高いスキルを持ったメンバーが必要
短期間かつ少人数で開発を行うスクラム開発には、高いスキルを持ったメンバーが必要です。業務に対して横断的に対応できるような幅広い専門スキルのほか、タスク管理能力やコミュニケーション能力の高さも重要です。一定以上のスキルを持ったメンバーを集め、最後までメンバーを変えずにプロジェクトを遂行するのが理想です。
スクラム開発に必要なメンバー
スクラム開発のチームは、「1人のプロダクトオーナー」「1人のスクラムマスター」「複数人の開発メンバー」によって構成されます。ここでは、スクラム開発に必要なチームメンバーの役割についてご紹介します。
プロダクトオーナー
プロダクトオーナーは、プロダクト全体の責任者として、スクラムチームから⽣み出されるプロダクトの価値を最⼤化する役割を担います。プロダクトの方向性や意思決定を明確にするためにも、プロダクトオーナーは必ず1人で担当します。
プロダクトオーナーの最大の使命は、プロダクトバックログの作成および管理です。プロダクトバックログとは、ステークホルダーからのニーズを取りまとめ、開発する機能を優先度順に整理したリストのことを指します。このプロダクトバックログの精度はスクラム開発の成否を左右するため、非常に重要な仕事です。
スクラムマスター
スクラムマスターはスクラムを確立させる責任者であり、チームの進捗状況を把握し、作業の妨げになる要因を取り除くなど、チームが集中できる環境を整える役割を担います。開発メンバーのサポートはもちろんのこと、必要に応じてプロダクトオーナーへのアドバイスなども行います。
チームをまとめる役割であるため、よくプロジェクトマネージャーのようなポジションであると誤解されますが、スクラムマスターはトップダウンでの意思決定は行いません。あくまでも奉仕型のリーダーとして、プロジェクトを円滑に推進できるようにサポートすることが仕事です。
開発メンバー
開発メンバーは、実際にシステム開発を行うメンバーです。作業の属人化やコミュニケーションコストの増大を防ぐという観点から、スクラム開発における開発メンバーは3~8人の間で構成するのが適切とされています。
メンバー内では肩書や上下関係は存在せず、テストや要件定義といった特定業務のみを行うサブチームも設置しないため、メンバー全員がすべての領域の業務に対して横断的に対応します。そのため開発メンバーには、設計・コーディング・サーバー構築・テスト・完成品のデモンストレーション・ドキュメント作成といった、非常に多岐にわたるスキルが必要です。
スクラム開発の手順
スクラム開発のスプリントは、「スプリントプランニング」「デイリースクラム」「スプリントレビュー」「スプリントレトロスペクティブ」という4つのイベントで構成されています。ここでは、それらの概要や手順を含め、スクラム開発の進め方をご紹介していきます。
プロダクトゴールとプロダクトバックログの作成
まず、チームが達成すべき目標であるプロダクトゴールと、プロダクトバックログを作成します。これらの作成は基本的にプロダクトオーナーが行いますが、必要に応じてスクラムマスターがサポートに入る場合もあります。
プロダクトバックログは一度作成したら終わりではなく、項目や優先順位の変更、新しい要求の追加など、プロダクトの開発期間中は絶えず更新し続け、最新の状態に保つことが重要です。
スプリントプランニングで計画立案
プロダクトゴールやプロダクトバックログを基に、スプリントの実行計画を立てることをスプリントプランニングといいます。スプリントプランニングでは、そのスプリント内で達成すべきゴール(スプリントゴール)や開発する機能を定義するほか、チームメンバーが実施するタスクやスケジュールに至るまで事細かに計画を立案していきます。
スプリントの期間は、チームの人数やスキルに応じて1週間から1か月程度の期間で設定されるのが一般的です。また、このスプリントプランニングで具現化されたゴールや計画をまとめて、スプリントバックログと呼びます。
デイリースクラムの実施
デイリースクラムとは、スプリントゴールに対する進捗状況を把握し、必要に応じてスプリントバックログを修正・改善していくためのミーティングです。スプリント期間中、毎日実施されるこのデイリースクラムは、その負荷を下げるために同じ時間・場所で開催し、ミーティングの長さも15分程度で行うことが望ましいとされています。
基本的にデイリースクラムは開発メンバーのみで行われますが、スクラムマスターやプロダクトオーナーが参加する場合もあります。
スプリントレビューの実施
スプリント終盤には、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について議論し合うスプリントレビューを実施します。スプリントレビューは実践型の討論会であるため、単なるプレゼンテーションだけに限定せず、実際に動く成果物(インクリメント)を用いて実施することが重要です。
プロダクトオーナーは、このスプリントレビューで得た結果を基に、プロダクトゴール達成に向けてプロダクトバックログの内容や優先順位の見直しを行います。
スプリントレトロスペクティブによる振り返り
スプリントレトロスペクティブは、次のスプリントの品質と効果を高めるため、スプリントの実施内容を振り返るミーティングのことです。このスプリントレトロスペクティブをもって、1つのスプリントが完了します。課題や改善点を洗い出し、それらを次回のスプリントに生かして、チームやプロジェクトを発展させることが目的です。
先述したスプリントレビューは成果物に焦点を当てていましたが、スプリントレトロスペクティブでは作業プロセスやチームのコミュニケーションに焦点を当てるのが特徴です。
まとめ
今回はスクラムについてご紹介しました。スクラムは、アジャイル開発におけるフレームワークの一種です。より迅速な開発を実現するほか、顧客のニーズをくみ取り、プロダクトの価値を最大化することにも大きく役立ちます。
顧客の価値観が日々変化する現代では、スクラムを導入し、市場のニーズにいち早く対応したシステムを構築することが非常に重要といえます。この記事の内容がスクラム開発を実施する上で少しでも参考になれば幸いです。