スクラム開発はソフトウェア開発の現場だけでなく、多くのビジネス場面で活用できるフレームワークです。
本記事では、チームマネジメントの生産性を高められる「スクラム開発」についてわかりやすく解説します。アジャイル開発との違いや、開発手順・メリット・デメリットも合わせて紹介しますので、複雑な業務を効率化するためのヒントとしてご活用ください。
スクラムとは何か？
スクラム（スクラム開発）はソフトウェア開発方法の一種で、3〜9人の小さなチームを作り、1〜4週間程度の短期間で開発を進める仕組みを指します。
スクラムは1995年にアメリカで提唱された開発手法で、プロジェクトの過程では修正や評価がくり返し行われるため、効率よく作業を進められる点が特徴です。
スクラムとアジャイルの違いは？
スクラムと合わせてよく使われる用語が「アジャイル（開発）」です。
アジャイル（agile）は「機敏な」「すばやい」といった意味を持つ英単語ですが、ソフトウェア開発の世界では「より短い期間で開発を進める方法の総称」として知られています。
従来のソフトウェア開発よりも「短期間にすばやく開発できないか」という議論のもとに生まれた考え方で、設計や実装・評価を何度もくり返しながら開発を進めていく手法です。
そして、アジャイル開発にはいくつかの種類があり、その中のひとつに「スクラム」が含まれています。つまり「スクラム」と「アジャイル」の違いは、アジャイルが開発手法全体を示す言葉であるのに対し、スクラムはアジャイルの具体的な手法の一種です。
スクラムチームに必要な3つの役割
スクラム開発を進めるには、3人〜9人程度のチーム編成が必要です。メンバーはそれぞれの役割に分けられ、各人が役割に見合った責任を持ちながら作業を進めていきます。
ここでは、スクラム開発の代表的な役割を3つ解説します。
プロダクトオーナー
プロダクトオーナーは、スクラムチームの意思決定を担う最終責任者で、チーム内に1人設定されます。スクラムは上下関係のない形式が特徴ではあるものの、開発を効率よく進めるには重要な議論の際にはっきりと判断できる人材も必要です。
プロダクトオーナーが担当する業務には具体的に以下が挙げられます。
- プロダクトの方向性を決めてチームに共有する
- プロダクトバックログ（開発に必要なことが記載された一覧表）の作成や更新
- 顧客や関係者との相談対応
- 予算やスケジュールの管理
プロダクトオーナーが決めたことは最終決定であるため、原則変えられません。
プロダクトオーナーは、プロダクトに不透明な部分がないかを随時チェックし、メンバーが理解しやすいよう情報共有を行います。また、スクラムチームのみならず顧客や関係者などとも綿密にコミュニケーションを取るため、広い視野で多くの情報を整理するスキルも求められるでしょう。
スクラムマスター
スクラムマスターは、プロダクトオーナーや開発メンバーをサポートするマネージャーのような存在です。
主な役割は、プロジェクト全体の進行確認やトラブルが発生した場合の解決です。たとえば、プロジェクトの進捗が遅れた際には、原因の特定と排除を率先して行います。ほかにも、プロダクトオーナーが思うように立ち回れていないときには、相談に乗ってアドバイスをするケースも考えられるでしょう。
スクラムマスターは、チームの能力が最大限発揮されるよう、こまやかにメンバーに寄り添う「支援型コーチ」とも言われます。
開発者
開発者は、ソフトウェア開発の場面であればエンジニアやデザイナー・ライターに当たるポジションの人材で、複数人で担当するのが一般的です。
プロダクトオーナーやスクラムマスターの定めた計画やルールに従って、実際に作業を進めていきます。
実務は複数の担当者全員で、開発に関わるすべての作業ができる状態が理想的です。具体的には、分析・設計・コーディング・評価などをそれぞれのメンバーが同じようにできる状況が望まれます。
また、作業の進め方は基本的に開発メンバーに任されていることから、主体的に開発を進められる責任感の強さも求められるでしょう。そのため、さまざまな経験やスキルを持つ優れた人材を、開発者として外部組織から出向させるケースも珍しくありません。
スクラム開発の手順を簡単に紹介
スクラム開発は、チーム構成や役割に加えて決まった手順のもとで進められます。
具体的な開発手法を5つのステップに分けて見てみましょう。
1.プロダクトバックログの作成
まずは、プロダクトオーナーがプロダクトバックログを作成します。
プロダクトバックログは、成果物に対する要望や必要事項を並べた一覧リストのことで、優先順位を付けながら記述する決まりです。メンバーや発注側からのフィードバックを取り入れて、後から順位を入れ替えたり、追加したりしてもかまいません。
また、プロダクトバックログには「ユーザーストーリー」を利用して作成するのが一般的です。ユーザーストーリーは、プロダクトがどのような価値や影響を与えるものなのかをわかりやすく示すための形式を指します。
発注側・受注側の誰が見ても「だれが」「いつ」「何を」「どのように」を理解できるように作成することで、目標や目的を迷わずに作業を進められる点が特徴です。急な仕様変更があっても、プロダクトバックログを見直すことで進捗管理や情報共有がスムーズにできるため、最初に作成します。
2.スプリントプランニング
プロダクトバックログを作成したら、次にスプリント（作業期間）における作業工程やタスクの洗い出しを行います。
スピリントプランニングは開発メンバーごとの計画ではなく、あくまでもチーム全体として作業を期間内に完遂できるかどうかの予測を立てるものです。
また、スプリントプランニングはスクラムチーム内での開発作業を明確にするためのものであるため、チーム内だけでミーティングを行い、発注側には共有しません。プロダクトバックログと同様に、進捗状況に応じて計画を更新する場合があります。
3.デイリースクラム
デイリースクラムは、毎日決まった時間に実施する開発チーム内のミーティングのことです。
バックログやスプリントプランニングをもとに、「計画通りで問題ないか」や「各メンバーの進捗状況」などを確認します。
全体の状況把握やメンバー同士のコミュニケーションの場としても有効です。
デイリースクラムは、15分程度の短時間で済ませることが多く、シンプルに「昨日の成果」「今日の目標」「現在の問題」だけを共有します。方法としてはホワイトボードやふせんなどを利用して、状況を可視化できるスタイルを取り入れてもよいでしょう。
ただし複雑なトラブルなどが発生している場合には、別途時間を取って話し合いの場を設ける判断も必要です。
4.スプリントレビュー
開発作業を完了したあとは、スプリントの終了日に仕上がった成果物をプロダクトオーナーが評価します。
スピリントレビューでは、プロダクトオーナーだけでなく発注側の顧客やスクラムチーム以外の関係者にもフィードバックしてもらうと、さらによいでしょう。
スプリントレビューは、プロダクトバックログの要望をクリアできているかを確認する重要なステップです。そのため、問題があれば、フィードバックで出た意見をもとにプロダクトバックログを修正し、計画を見直します。
5.スプリントの振り返りミーティング
最後に、スプリントの振り返りミーティングをスクラムチーム内で実施します。
次のスプリントにおいて「どのように問題を改善していくか」や「さらなる成果を目指すにはどうしたらよいか」などを話し合うのが目的です。
また、振り返りのミーティングは必ずしも1回で終わるわけではありません。スクラム開発を行う過程で計画が修正されるたびに、スプリントプランニングから振り返りミーティングまでを何度もくり返しながら作業を進めていきます。
このようにスクラム開発は、シンプルかつ明確なステップに分けて、チームが足並みをそろえながら作業をくり返していくのです。
スクラム開発のメリット・デメリット
スクラム開発は、複雑なソフトウェア開発を短期間に効率よく進めるための手法ではあるものの、デメリットがないとも言い切れません。
そこで最後に、スクラム開発のメリットとデメリットをお伝えします。
スクラム開発のメリット
スクラム開発のメリットとして一番に挙げられるのが、生産性を高められることです。
日々のミーティングによって、進捗状況を把握しやすく問題の早期発見もかなうため、結果的に作業の効率化につながります。
また、スプリントと呼ばれる1〜4週程度の期間に区切って作業することから、発注側のフィードバックや急な仕様変更にも柔軟に対応しながら開発を進められるでしょう。スプリントレビューは各スプリントごとに実施するため、大きなスケジュール変更や作業工程の増加にもつながりにくく、大幅な時間短縮も実現できます。
さらに、スクラムマスターの存在によってチームワークを強化できる点もポイントです。メンバーのスキルを正確に把握し、適切な助言やタスク分けを行うことで、モチベーションを下げずに作業していけるでしょう。
スクラム開発のデメリット
一方、スクラム開発のデメリットには、各メンバーに高度なスキルが求められる点が挙げられます。
明確な役割を持って短期間で結果を出す必要があるスクラム開発では、どのような状況でも冷静に議論でき、発注者の急な要望にも対応できる人材が不可欠です。
そのため、開発作業に不慣れな初心者やコミュニケーション力の低いメンバーがいると、かえって作業効率が悪化してしまう可能性があります。途中でメンバーが抜けてしまうことで、開発作業全体がストップするケースも珍しくありません。
また、短い期間（スプリント）に分けて作業を進める仕組みでは、プロジェクトの全体像を把握するのが難しい場合もあります。大規模なプロジェクトだと、スプリントに区切ることで全体スケジュールがわかりにくくなるデメリットがあります。
スクラムを理解し開発チームで有効活用しよう
スクラム開発は、ソフトウェア開発を中心に用いられる自己組織型の開発手法だとお伝えしました。短い期間に区切りながらも、急なトラブルにも即座に対応できる画期的な仕組みは、さまざまなビジネス領域で導入すべきモデルでもあります。
しかしながら、すべてのプロジェクトに適しているとは言えない点も事実です。
開発チームのメンバー編成も難しく、全体スケジュールが不透明になることから、組織を細分化してスプリントを活用しない手法が向いているケースもあるでしょう。
弊社が提供しているワークマネジメントツール「Asana」なら、スクラム開発をしたいけど自社のメンバーでは難しいと感じるプロジェクトでも対応できます。チームの作業工程・スケジュール・連絡も画面ひとつで管理でき、スクラム開発ではデメリットになっていた部分も解消可能です。
まずは無料トライアルでAsanaをお試しください。
