スクラム開発とは？ 開発の流れやメンバーの役割、メリット・デメリットを解説します

サービスやプロダクトの開発に携わっている人なら「スクラム開発」という言葉を聞いたことがあるでしょう。スクラム開発は、システム開発手法のひとつで、「計画→設計→実装→テスト」といった開発工程を、機能単位の小さなサイクルを繰り返すことで開発を進めていく、アジャイル開発の一手法です。

今回は、スクラム開発の概要や、開発の流れ、メリット・デメリット、携わるメンバーの役割などを紹介しながら、スクラム開発とはどのようなものかを詳しく解説します。

スクラム開発とは？

小さなサイクルで開発を行う「アジャイル開発」の一手法

スクラム開発は、アジャイル開発の一種です。

アジャイル開発は、機能単位の小さいサイクルで開発を繰り返す手法です。工程を後戻りしない前提で行う従来のウォーターフォール開発とは異なり、開発途中の仕様変更に強く、開発期間の短縮やコストの抑制が実現できることが特徴となっています。

また、アジャイル開発では各プロセスに目標や成果物が設定されているため、それらを満たすことで、自動的に品質が担保されます。こうした特徴により、サービスインまでの時間が短縮でき、スピードが求められる現代のソフトウェア開発において、欠かせない開発方法となっています。

メンバーは3つの役割に分かれて開発を行う

アジャイル開発には、シンプルさを開発方針に据える「エクストリーム・プログラミング（XP）」や、2週間程度の短い期間でシステムを作る「ユーザー機能駆動開発（FDD）」などがありますが、もっとも有名な手法が、ここで紹介する「スクラム開発」です。

スクラム開発に携わるメンバーには、「プロダクトオーナー」「開発者」「スクラムマスター」などの固定した役割が与えられ、いつまでに何が必要かという視点からタスクを割り振り、メンバー各々が開発計画を決めて、進行状況に責任を持ちます。

スクラム開発では頻繁にミーティングが行われるため、チームワークや、メンバー間のコミュニケーションが非常に重要です。スクラム開発成功のカギはコミュニケーションにあるといっても過言ではありません。

なお、スクラム開発という名前がつく前から、日本企業では同様の開発手法が取られていました。1980年代半ば、既にホンダやキヤノンなどの日本企業で行われていたといわれており、日本でも親しみのある開発手法といえるかもしれません。

開発単位は「スプリント」に区切られる

スクラム開発では、アジャイル開発の基本どおり、開発期間を短く区切って開発を行います。この開発期間の単位は「スプリント」と呼ばれ、短くて2週間、長くて1ヵ月程度に設定されます。

こうした手法を取ることで、開発途中での仕様変更に柔軟に対応できるメリットがあります。また、スプリント単位で開発期間を見積もることができるため、作業工数を予測しやすく、結果として開発期間の短縮に繋がります。

スクラム開発に携わるメンバーの役割

スクラム開発に携わるメンバーは、「プロダクトオーナー」、「スクラムマスター」、「開発メンバー」のどれかの役割を担います。ここでは、それぞれについて詳しく紹介します。

プロダクトオーナー

スクラム開発における「プロダクトオーナー」は、製品開発の方向性を決める責任者です。顧客の要望を正確に把握し、プロダクトに責任を持ちます。

プロダクトオーナーの主な任務には次のようなものがあります。

・顧客ニーズの把握・要件定義

・開発作業の優先順位及びゴールの明示

・顧客・関連部署とチームの窓口的役割

・プロダクトバックログの管理

プロダクトオーナーは、顧客の要求を正確に把握したうえで、コスト面及び、開発時間とのバランスを取りながら、本当に必要な要件に絞って、開発の内容と作業の優先順位を決めていく必要があります。

さらに、顧客とチームの窓口・仲介役になるのも、プロダクトオーナーの重要な仕事です。顧客からは信頼を獲得し、チームメンバーには分かりやすく的確な指示をすることが求められます。高度なコミュニケーション能力も求められるでしょう。

そして、もうひとつ重要なのが、プロダクトバックログの作成・追加・削除などの管理業務です。プロダクトバックログとは、開発に必要なものをリストアップして、そこに優先順位をつけて並べたリストのことです。

スクラム開発は、このプロダクトバックログに従って行われるため、プロダクトオーナーは常に内容を更新しなければなりません。効率のよい開発は、プロダクトオーナーにかかっているといえます。

スクラムマスター

スクラムマスターは、プロダクトオーナーとスクラムマスター、開発メンバーからなるチーム「スクラム」の責任者です。スクラム開発において重要なミーティングを取り仕切り、プロジェクトが円滑に進むよう開発メンバーのサポートを行います。

スクラムマスターの主な任務は次のようなものです。

・各ミーティングの実施

・開発メンバーのサポート

・円滑なプロジェクト進行

スクラム開発にはさまざまなミーティングがあります。各スプリント（開発単位）で行うことを話し合う「スプリント計画ミーティング」、進捗状況の把握のため毎日行う「スタンドアップミーティング」、各スプリントの振り返りを行う「スプリントレビューミーティング」などがあり、その実施と進行役はスクラムマスターの役割となります。

スクラム開発においてミーティングは非常に重要な役割を果たしており、このミーティングにおけるコミュニケーションが円滑であることは、開発の成功のカギとなっています。

また、プロジェクトが計画どおりに行かない場合に、開発メンバーと協力して原因を突き止め、遅れを最小限に食い止めます。さらに、プロダクトオーナーが作成したプロダクトバックログに沿って、開発メンバーが業務を進められるようサポートするのもスクラムマスターの役目となります。

さらに、プロダクトオーナーや開発に携わる外部メンバーが、本来必要のない開発や、無謀な要望を行った場合に、それらを修正する役目も担います。

開発メンバー

実際にプロダクトの開発を担うのが開発メンバーです。スクラム開発において、開発メンバーの立場は平等であり、役職、年齢などによって上下関係ができることはありません。

開発メンバーの主な任務は次のようなものです。

・設計

・コーディング

・テスト

・運用

スクラム開発では、参加するすべてのメンバーが、設計・コーディング・テスト・運用のスキルを保有していることが求められます。「設計者」「プログラマー」「デザイナー」といった区分けはなく、プロダクトを横断的に作れる能力を持ったメンバーにより開発が進められていきます。

とはいえ、これはあくまで理想で、多少の苦手分野があったとしても、開発メンバーの間で作業を融通し合いながら開発を進めていくことになります。その中で、最終的にはすべてのメンバーが横断して仕事ができる状況を目指します。

スプリントの流れ

スクラム開発は、「スプリント」と呼ばれる開発単位を基準に行います。このスプリントは、2週間～1ヶ月程度に設定されることが普通です。ここでは、スプリントの流れについて紹介します。

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

プロダクトバックログとは、開発工程における優先順位を明確にしたリストです。バックログとは「未処理リスト」という意味なので、プロダクトにおいて処理待ちのものをまとめたものと考えるとよいでしょう。

プロダクトバックログには以下のようなものが含まれます。

・機能

・バグ修正

・設計変更

・機能の改善

・技術的負債

・新機能のアイデア　など

プロダクトバックログは、プロダクトオーナーが作成し、プロジェクトが終了するまで更新を続けます。開発におけるロードマップとして業務の進捗が確認できる重要なもので、プロジェクトの成功を左右するもののひとつといっていいでしょう。

スプリント計画ミーティング

今回のスプリントで実装する項目を一覧にした「スプリントバッグログ」を決定するミーティングです。プロダクトバックログをもとに仕様や工数を詳細に見積もり、担当者を決定します。

スプリントバックログは、開発チームが自分たちのために作成するもので、発注者には共有されません。プロダクトバックログと同様、進捗に応じて内容が更新されます。

スタンドアップミーティング

スタンドアップミーティングとは、スプリントの期間中、毎日同じ時間に全員で行うミーティングのことです。「デイリースクラム」とも呼ばれ、かかる時間は5～15分ほどです。

内容は、昨日までの作業状況や、今日予定している作業の内容などの報告を行ったり、開発で障害になっている問題点などをチーム全体に共有したりします。

スタンドアップミーティングの内容を共有することは大変重要で、終了後は必ずプロダクトオーナーに共有します。その際、別途ミーティングの時間を取って検討すべき内容や項目があるかも伝えます。

スプリントレビューミーティング

スプリントの最終日に、プロダクトオーナーが成果物をチェックする場がスプリントレビューミーティングです。

プロダクトオーナーは、プロダクトがスプリントバックログの要求を満たしているかを確認し、問題が見つかった場合リリースは先送りされます。

品質検査の側面が大きいため、プロダクトオーナーだけでなく、営業担当者や顧客が参加するケースもあります。

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

スプリントレトロスペクティブは、今回のスプリントを振り返るためのミーティングです。いわゆる「反省会」であり、次のスプリントへ向けて開発メンバーが全員で議論し、課題を共有します。

ここで、スプリントのよかった点、悪かった点を洗い出して、次のスプリントに活かすことが、スクラム開発の成功に繋がるといえます。また、場合によっては、次のスプリントのゴールを決める場合もあります。

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

スクラム開発には数多くのメリットがありますが、一方でデメリットもあります。スクラム開発の特性を理解することが、プロジェクトの成功には不可欠といえます。

スクラム開発のメリット

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

・生産性の向上

・仕様変更に対して柔軟に対応できる

・工数見積もりの精度が高い

・問題を早期に発見できる

スクラム開発は、チームメンバーが協力してシステム開発を行うため、効率よく作業が進められます。また、スプリントを設定しているため、短期間で成果が出やすく、モチベーションの向上や生産性の向上が期待できます。

スプリントが設定されていることで、開発途中の仕様変更も容易になっています。手戻りの工数を削減できるため、急な変更でもロスを最小限に抑えられます。工数の見積もりもスプリントごとに行われるため、従来型の開発手法よりも正確に工数を把握できることもメリットです。

また、スクラム開発では毎日のミーティングで問題が共有されるため、問題を早期に発見できます。これらが、スクラム開発の主なメリットです。

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

一方で、スクラム開発には以下のようなデメリットもあります。

・開発メンバーに求められるスキルが高い

・開発スケジュールの全体像が見えづらい

・コミュニケーション能力が求められる

スクラム開発では、設計者やプログラマー、デザイナーなどの区分けがなく、プロダクトを横断的に作れる能力を持ったメンバーが求められます。そのため、開発メンバーに求められるスキルはどうしても高いものとなります。エンジニアの人材不足が叫ばれている状況下では、人員確保が難しい場合もあるでしょう。

また、スプリントを繰り返す開発スタイルのため、俯瞰してスケジュールを見ることが難しい側面があります。スケジュールを俯瞰して把握できる点においては、ウォーターフォールモデルが優れています。

スクラム開発は、ミーティングが多いことも特徴です。そのため、コミュニケーションが苦手なメンバーにとっては負担となり、能力が発揮できないケースもあります。スクラム開発に携わるメンバーの選定は、開発スキルに加え、コミュニケーション能力を重視する必要があります。

まとめ

今回は、スクラム開発とはどのようなものかを紹介するとともに、スクラム開発に携わるメンバーの役割や、スクラム開発の大まかな流れ、メリット・デメリットなどをついて解説しました。

スクラム開発はチーム主体の開発モデルであり、プロダクトの開発スピードを高め、柔軟な開発を実現します。スケジュールが見えなくなりやすい点には注意が必要ですが、適切な人員配置ができれば、開発期間を短縮しながら、プロダクトの品質を高めることができるでしょう。