YAZエンジニアが運営するメディア

システム開発やソフトウェア開発では、目的や状況に応じたフレームワークが採用されます。長らく一般的だったウォーターフォールモデルのほか、日本でも少しずつ普及してきたのがアジャイルソフトウェア開発です。そのなかでも代表的なスクラム開発は代表的なフレームワークといえます。
各開発プロセスの特性は開発者だけではなく発注者側にも知っておいていただきたい知識です。こちらでは、スクラム開発の概要や一般的な流れ、メリット・デメリットについてお話しします。

スクラム開発の基礎知識

スクラム開発はどのような手法なのでしょうか。スクラム開発の概要、他の開発手法との違いについてご紹介します。

スクラム開発とは？

スクラム開発は、少人数のチームに分かれて短期間で開発を行う手法です。スプリントと呼ばれる一定期間ごとに機能単位で開発を行います。
ラグビーの試合再開の型である「スクラム（scrum）」が由来です。集団で力を合わせることを意味します。スクラム開発も、ラグビーのスクラムのようにチームが一丸となった開発を行う点が特徴です。

スクラムのチーム人数は3～10人程度が目安です。メンバーに役割を設定して開発を行います。リーダーやマネージャーなど牽引する役割も設けられますが、1人に責任を押し付けることはありません。メンバー各自のセルフマネジメントが重視される開発手法です。

スクラム開発とウォーターフォール型開発との違い

ウォーターフォール型開発（ウォーターフォールモデル）は、あらかじめ立てた開発工程を計画通りに実行していく開発方式です。滝を意味する「ウォーターフォール（waterfall）」が由来となっています。要件定義から設計、製造、テストまでの工程を１つ１つ順番に進めていきます。工程ごとにレビューを行いながら進めるため、時間もかかり、前の工程に戻ることが難しい開発手法です。

スクラム開発は、ウォーターフォール型開発とは概念が異なる「アジャイル型開発（アジャイル開発）」で用いられる開発手法のひとつです。アジャイル型開発とは、システム開発を小さな単位に分け、プロジェクトを進めていく開発方式です。優先順位の高い機能から開発し実装していきます。
スクラム開発のほかに、エクストリーム・プログラミング（XP）、ユーザー機能駆動開発（FDD）などの手法があります。

なお、アジャイル開発ではイテレーションという開発サイクルを回し、優先度が高い機能から順にリリースしながらシステムを完成に近づけていきます。スクラム開発におけるイテレーションに該当するのがスプリントです。スクラム開発でもイテレーションと呼ばれる場合もありますが、基本的に同じ意味と考えて問題ありません。

スクラム開発の流れ

スクラム開発はどのように進めていくべきなのでしょうか。一般的なスクラム開発の流れをご紹介します。

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

プロダクトバックログとは、プロダクトへの要望を一覧形式でまとめたもののことです。各項目は優先順位が付けられています。プロダクトオーナーによって定義づけられるのが一般的です。開発メンバーによるフィードバックも反映されます。
開発中はプロダクトバックログの管理が常に行われます。また、リストの順位付けは、後述するスプリントバックログの作成に必要です。

プロダクトバックログを作成する際に用いられるのがユーザーストーリーです。ユーザーストーリーとは、開発システムがユーザーにとってどのような価値を与えるのかを示す概念のことです。発注側と開発側の共通言語としても用いられるため、専門用語を使わず一般的な言葉で記述することが求められます。スプリントの短いサイクルのなかでもユーザーの視点を見失わずに開発を続けていくために必要な要件です。

STEP2：スプリントプランニングミーティング

「スプリントバックログ」を決定するためにミーティングを行います。スプリントバックログとは、今回のスプリントで実装する項目を一覧形式でまとめたものです。プロダクトバックログをもとに、詳細な仕様や担当者を決め、工数見積もりを行います。この工程は「スプリント計画会議」とも呼ばれます。
スプリントバックログは発注側に共有されることはなく、開発側が開発のために作成します。また、開発の進捗に応じて更新されるケースも一般的です。内容は、後述するデイリースクラムで体的に確認・精査されます。

STEP3：デイリースクラム

スプリントの期間中は毎日同じ時間にミーティングを行います。作業前に、全員で状況報告や問題の共有、仕事の進め方の確認などを済ませるのが目的です。開発チームのコミュニケーションを充実させる意味合いもあります。
デイリースクラムは朝に短時間で行うのが一般的ですが、必ずしも朝に行う必要はありません。単に進捗報告の場とするだけではなく、問題をチーム全体で共有することが重要です。また、デイリースクラムの終了後は内容をプロダクトオーナーに共有します。

STEP4：スプリントレビュー

スプリントの最終日に、デモンストレーションを実施してプロダクトオーナーが成果物をチェックするスプリントレビューを行います。スプリントバックログの要求を満たしているか確認するのが目的です。スプリントレビューで問題が見つかれば、リリースは先送りとなります。
営業担当や顧客など、ステークホルダーにも参加してもらえると理想です。さまざまな視点から条件を満たしているか判断できるようになります。

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

今回のスプリントの振り返りのためにミーティングを行います。次回のスプリントへ向けてチームメンバーが議論し、課題を改善することが重要です。
以降、スプリントごとに、STEP2～STEP5の流れを繰り返します。

スクラム開発のチーム構成

スクラム開発では、チーム内のメンバーが3つの役割（ロール）に分かれます。以下では、「プロダクトオーナー（PO）」「スクラムマスター（SM）」「開発メンバー」という3つの役割について解説します。

プロダクトオーナー（PO）

プロダクトオーナー（PO）は、プロダクトの責任者としての役割を担います。メンバーへの情報共有や説明を行い、開発を推進していくロールです。主に、優先順位決め、スケジュール調整、予算管理などの業務を行います。
一般的にプロダクトオーナー自身は開発を行いません。また、作業の細かな指示を行うこともありません。プロダクトバックログの管理やチームのマネジメント、ステークホルダーへの決定事項共有などに注力します。

スクラムマスター（SM）

スクラムマスター（SM）は、プロジェクトを円滑に進行させるための調整役を担うロールです。チームとチーム外の関係者の間に立ち、必要に応じて交渉や相談を行います。開発メンバーへ均等に業務を配分するほか、特定のメンバーに負担が集中しないように考慮するのも仕事です。
スクラム開発がうまく回るように調整するのが役割ですが、開発メンバーを兼任するケースもあります。

開発メンバー

開発メンバーはプロダクトの開発を行います。スクラム開発では、メンバー各自が一連の開発スキルを有している状態が理想です。得意・不得意にかかわらず、全分野の作業を担当する可能性があるため、設計、コーディング、テストの開発スキルにまんべんなく精通しているメンバーが求められます。

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

開発モデルは特性を理解し、状況やプロジェクトに併せて採用することが大切です。スクラム開発にもメリットとデメリットがあります。以下のようなメリット・デメリットを理解しておきましょう。

スクラム開発のメリット

• 生産性の向上が期待できる

スクラム開発によるメリットのひとつが、生産性の向上につながる点です。チームメンバーが協力しながらシステム開発を行うため、効率的に作業を進められます。モチベーションの維持や、サポート体制の充実化などにもつながるでしょう。

また、スプリント単位で期間を設定するため、従来よりも短いスパンで必要とされる機能の開発・実装を行います。各スプリントで動作可能な機能を開発し、必要な機能が出揃ったタイミングでリリースできるため、短期間で成果を出しやすい点もメリットです。

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

システム開発では急な仕様変更が必要になる場合もあります。最初に要件定義を行うウォーターフォールモデルとは異なり、アジャイル開発は仕様変更を想定した開発モデルです。スクラム開発もアジャイル開発の柔軟性を踏襲しています。
スクラム開発のスプリントは短めに設定されており、成果物に対して受けたフィードバックを次のスプリントに反映させるため、仕様変更に対応しやすい点がメリットです。手戻りの工数を削減することもできます。

• 問題を早期に検知しやすい

スクラム開発で毎日実施されるミーティングでは、問題の共有が行われます。このことから、問題を早期に発見できる点がメリットです。さらにスクラムマスターが問題を明確にし、メンバーでの解決を目指すため、プロジェクトの進捗がスムーズになるでしょう。

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

スクラム開発では、スプリントごとに工数見積もりが行われます。ウォーターフォールモデルとは異なり、機能ごとの小さな単位で見積もりを行うため、高い精度で見積もりできる点がメリットです。このことから、工数を正確に把握できます。

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

• 参加メンバーに一定以上のスキルが必要

短期間で開発する必要があるため、参加メンバーに一定以上のスキルが求められます。メンバー編成によっては進捗に深刻な影響が出るおそれがあるため、慎重に編成しなければなりません。特に初心者がいるチームや、途中で離脱者が出たチームなどは、プロジェクトをスムーズに進行できない場合があります。
必要なスキルを不足なく有しているメンバーを集め、最初から最後まで、チームメンバーを変えずに開発するのが望ましいでしょう。離脱したメンバーを補填した際の引き継ぎに時間を割かずに済みます。

• 開発スケジュールの全体像が見えにくい

スクラム開発は仕様変更への柔軟な対応を実現する開発モデルです。一方で、開発の内容が仕様変更の度に変わるため、全体スケジュールが見えにくくなる傾向があります。機能ごとに開発するスプリントの手法も、全体スケジュールの把握を難しくする要因のひとつです。スケジュールを最初に把握できるという点では、ウォーターフォールモデルのほうが秀でています。

• コミュニケーションに負担を感じるメンバーが出るおそれがある

スクラム開発は、日々の業務やミーティングなどメンバー間でコミュニケーションをとる機会が多い点が特徴です。そのため、メンバーにはコミュニケーション能力が求められます。開発スキルが高くてもコミュニケーション能力が低い人材はスクラム開発には不向きです。
メンバーを編成する際はコミュニケーション能力にも注目する必要があります。純粋に開発スキルだけで選ばないように注意が必要です。

スクラム開発で求めるシステムをスピーディーに実現

スクラム開発はチーム主体の開発モデルです。一般的なウォーターフォールモデルとは対照的であり、仕様変更への柔軟な対応を目指しています。また、スプリントを反復させることによるスピーディーな開発や要求を反映させやすい点も魅力です。

一方で、スケジュールが見えなくなりやすい点やメンバー編成に慎重さが求められる点から、適していないプロジェクトもあるでしょう。スクラム開発の特性を理解した上で実施することが大切です。また、開発をアウトソーシングする場合は、こうしたスクラム開発のメリット・デメリットを理解した開発会社が求められます。
スクラム開発を依頼する際は、要件定義時にエンジニアが徹底したヒアリングを行うYAZをご検討ください。