現代は市場の変化が激しく先が読めないVUCA（※）の状況にあると言われます。そんな中で、変化に強いシステム開発方式として大きな注目を集めてきたのが「アジャイル開発（詳しくは『ウォーターフォール、アジャイル、スパイラル……情報システム部門が必ず押さえるべきシステム開発方式の違い』をご覧ください）」です。

この記事で取り上げるのは、アジャイル開発の手法の中でも最もポピュラーな「スクラム開発」です。同手法を開発したケン・シュウェイバー氏／ジェフ・サザーランド氏によりその公式ガイド「スクラムガイド」が邦訳公開されており、2020年11月にリリースされた最新版ではソフトウエア開発を超えた応用可能性も示唆されました。

スクラム開発の基本を学び、その実践イメージをつかみましょう。

※…現代の特性を示す4単語──Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）──の頭文字で表現された造語。

スクラム開発は三つのポジションでアジャイルな開発を進める

スクラム開発という言葉は、そのままラグビーの試合再開前のフォーメーションである「スクラム」を流用して生み出されました。そこから想起される“一丸となって試合を前に進める”イメージがスクラム開発の理解において重要です。

ラグビーに主将が存在し、それぞれのポジションに固有の役割が存在するように、スクラム開発の構成メンバーもそれぞれの役割が与えられます。

スクラム開発の構成メンバーは大きく以下の3種類に分けられます。

1. スクラムマスター：1人
2. プロダクトオーナー：1人
3. 開発者：複数

「1.スクラムマスター」は“スクラムチームが有効に機能する”ことに責任を持つリーダーです。スクラムチームの目的を理解し、スクラム開発において不可欠なプロセスを管理します。もしもほかの業務などでスクラムチームのメンバーの活動に支障が生じていれば、交渉などを通してその問題を解決するのもスクラムマスターの役割です。

「2.プロダクトオーナー」は“スクラムチームが開発するプロダクトの価値を最大化する”ことに責任を持つリーダーです。プロダクトの価値を最大化するためにゴールを定めて共有し、タスク（プロダクトバックログアイテム）の優先順位を策定。必要に応じて入れ替えユーザーといった外部のステークホルダーの目線でプロダクト開発を管理します。

「3.開発者」はスクラムチームのチームメンバーであり、“具体的な作業計画（スプリントバックログ）を、具体的な価値（インクリメント）に変換すること”に取り組みます。「開発者」と名づけられてはいるものの、研究者、アナリストなどプロダクト開発に寄与するすべてのメンバーを包括する概念であることが2020年版「スクラムガイド」には明記されています。

チームの“内部”に寄り添った目線を持つスクラムマスターと、チームの“外部”の目線で開発をリードするプロダクトオーナーの、立場や役割を異にする2人のリーダーが存在することが、スクラム開発のポイントの一つです。従来のウォーターフォール型の開発方式におけるプロジェクトマネージャー（PM）の役割を二つに分割したのがスクラムマスター、プロダクトオーナーであるともいえるでしょう。

これらの役割には、知識・スキルを認定する専門の資格（認定スクラムマスター・認定プロダクトオーナー）も存在します。

スクラム開発の要となる「スプリント」の4ステップ

スクラムチームの構成メンバーの次は、より専門的な用語と手法を押さえましょう。

スクラム開発の肝として「スクラムマスター、プロダクトオーナーという二つの役割」と同等かそれ以上に重視したいのが「スプリント」です。

スクラム開発は、スプリントを積み重ねることでプロダクトゴール（製品の完成）に達成するという手法です。スプリントは1週間・2週間～1カ月の単位で設計され、以下の4ステップで完遂されます。

1. スプリントプランニング
2. デイリースクラム
3. スプリントレビュー
4. スプリントレトロスペクティブ

「1.スプリントプランニング」はその名の通り、スプリントの計画であり、スプリントの方向性や意義を左右する最重要ステップです。ここでスプリントゴールの達成のために必要なタスク（スプリントバックログアイテム）を洗い出し、その優先順位も策定します。

「2.デイリースクラム」は毎日15分、同じ時間、同じ場所で開催する定例ミーティングです。ここでスクラムチームは進捗を共有し、場合によってはスプリントバックログの内容や優先順位を調整します。

「3.スプリントレビュー」「4.スプリントレトロスペクティブ」はいずれもスプリントの振り返りのための時間です。ただし、前者はスプリントインクリメント（成果物）についての振り返り、後者はスクラムチームのあり方についての振り返りを目的とします。そのため前者はプロダクトオーナーが、後者はスクラムマスターがリードすることとなるでしょう。

「プロダクト」と「チーム」を分けた上で等しく評価するスクラム開発の特徴が生かされています。

アジャイルな開発手法はハードウエアにも応用可能

製造業におけるソフトウエアの重要性が高まるにつれて、スクラムをはじめとするアジャイルな開発手法への注目も高まっています。その視線はアプリや組込みソフトウエアだけでなく、ハードウエアの開発におけるスクラム開発にも向けられ始めています。

ソフトウエアのように修正が容易でなく、最初から完成品が求められるハードウエアの開発ではウォーターフォールが適しているという見方が従来支配的でした。しかし、エレキ、メカ、ソフトなどハードウエアの構成を分割し同時並行でアジャイルに進めることで高効率を達成する例も近年は生まれ始めています。また、国内外の自動車メーカーでは、自動運転ソフトウエアの機能をモジュール化し、複数のチームで同時並行的に進める事例も。

もちろん、不適な領域も存在するため、ウォーターフォールとのハイブリッドやドキュメントの詳細化など目的に合わせた工夫は求められますが、アジャイルを取り入れることで開発効率が大きく変わる場合があることは覚えておきましょう。

“スクラム開発”の目指すところや手法はシンプル

最新版スクラムガイドを参照しつつ、その基本的な手法や製造業での応用可能性についてご紹介しました。最初はスプリント、スクラムマスターなど専門用語が多く、“スクラム開発は難しい”と感じられていた方もいたかもしれません。
しかし、本文の内容から分かる通り、その目指すところや手法は非常にシンプルです。ぜひ本記事をスクラム開発実践の足掛かりとしてください。