エンジニア全般
ソフトウェア開発の世界では、市場の変化に素早く対応し、高品質な製品を提供するために、様々な開発手法が用いられています。
その中でも、近年特に注目を集めているのが、アジャイル開発です。
アジャイル開発とは、短期間での開発サイクルを繰り返すことで、柔軟かつ適応性の高いソフトウェア開発を実現するための手法です。
本記事では、スプリントの基本から実践手順、メリット／デメリットまでを詳しく解説します。
これからアジャイル開発を始める方や、すでにアジャイル開発に取り組んでいる方は、ぜひ最後までお読みください。
プログラマー兼ネットワークエンジニア。 24歳でエンジニアの世界に飛び込むも、いきなり大手企業機器の検証担当に。 その後も検証をこなしていく中で、自動的にできないものかと試行錯誤しているといつの間にかプログラマーへとステップアップ。 現在はプログラミングの方が好き。
アジャイル開発におけるスプリントとは？
アジャイル開発におけるスプリントとは、短期間で繰り返し行う作業サイクルを意味します。
スプリントは、プロジェクトを小さな単位に分割して進行管理をしやすくするための重要な要素です。
ここでは、スプリントとアジャイル開発の関係やスプリント途中で行われるスクラムについて詳しく解説します。
スプリントとアジャイル開発の関係
アジャイル開発におけるスプリントは、1週間から4週間の短期間で設定された開発サイクルの基本単位であり、目標達成のための期限として機能します。
スプリントを通じて、開発の進捗状況が可視化され、クライアントからのフィードバックを受けることが可能です。
また、要件変更や優先順位の見直しに柔軟に対応するための仕組みでもあります。
スプリントは、チームの自己組織化と協調を促進し、継続的な改善のサイクルを回すこともできます。
つまり、スプリントは、アジャイル開発において、開発サイクルの管理、目標達成、柔軟な対応、チームの協調、継続的な改善を促進する重要な存在です。
スプリント途中で行われる「スクラム」とは
スクラムは、アジャイル開発手法の一つで、スプリント中に毎日行われる短いミーティングです。
チームメンバーの進捗状況を共有し、障害や問題を早期に発見して解決策を検討することを目的としています。
スクラムは毎日同じ時間・場所で開催され、各メンバーは、昨日の成果、今日の予定、障害の有無について報告します。
スクラムにより、開発状況が可視化され、スムーズな情報共有が可能です。問題に早期に対応できるため、スプリントの目標達成に貢献します。
また、スクラムはイテレーションと同義で使われる場合もあり、小さな開発サイクルを繰り返すという意味合いです。
つまり、スクラムは、スプリント中の進捗共有とコミュニケーションを促進する重要な会議です。
スプリントのスクラムイベントとタイムボックス
スクラムガイドでは、下記を「スクラムイベント」と定義しています。
- スプリントプランニング（目標や開発方法を計画）
- デイリースクラム（チームメンバーとミーティング）
- スプリントレビュー（結果を振り返る会議）
- スプリントレトロスペクティブ（チームの動きやプロセスを振り返る会議）
各スクラムイベントには、推奨のタイムボックス（時間枠）が割り当てられています。スプリント期間の長さによって、イベントの長さが決定される流れです。
そして、それぞれの時間枠がタイムボックスとして割り当てられています。
| イベント名 | 1週間 | 2週間 | 3週間 | 4週間 |
| スプリントプランニング | 2h | 4h | 6h | 8h |
| デイリースクラム | 0.25 | 0.25 | 0.25 | 0.25 |
| スプリントレビュー | 1h | 2h | 3h | 4h |
| スプリントレトロスペクティブ | 45min | 1h 30min | 2h 15mini | 3h |
上記の時間を参考に、スクラムイベントを進めましょう。
スプリントの体制
スプリントを実施するには、主に以下の役割を設ける必要があります。
- プロダクトオーナー
- 開発チーム
- スクラムマスター
これらの役割が連携し、スプリントの目標達成に向けて協力することが、スクラムの成功には不可欠です。適切な体制を整え、スプリントを通じて継続的な価値提供を実現するようにしましょう。
プロダクトオーナー
プロダクトオーナーは開発の責任者として、プロダクトの価値を最大化するための意思決定を行います。
プロダクトやバックログを管理し、優先順位を決定し、開発チームが結果を出せるように方向を見定めることが大切です。プロジェクトのスケジュールやアウトプットのレビューなども実施します。
開発チーム
開発チームは、文字通りプロダクトを開発するメンバーです。
ゴールの達成に向けて自己組織化されたチームとして機能します。チームメンバーは、それぞれの専門性を生かしながら協力し合い、高品質なプロダクトを提供することに注力します。
スクラムマスター
スクラムマスターの役割は、スクラムプロセスが正しく実践されるようにサポートすることです。開発チームの障害を取り除き、生産性を高めるための支援を行います。
また、スクラムの価値や原則を組織全体に広め、アジャイル文化の醸成に貢献しなければなりません。
スプリントのメリット
スプリントには、以下のメリットがあります。
- 課題をすぐに解決できる
- 仕様変更など柔軟な対応が可能
- テストやフィードバックが容易
- 目標が明確化する
- チーム内コミュニケーションの活性化
課題をすぐに解決できる
スプリントは短期間のサイクルで進められるため、開発中に発生した課題をすぐに解決できます。
デイリースクラムで日々の進捗を共有すると、問題が発生した場合にも早期に対応することが可能です。
また、スプリントレビューでは、開発したプロダクトのデモを行い、クライアントからのフィードバックを受けやすくなります。
その結果、課題を次のスプリントに持ち越すことなく、その場で解決策を検討し、改善につなげられます。
仕様変更など柔軟な対応が可能
仕様変更は開発につきもので、必ず発生すると言っても過言ではありません。
従来のウォーターフォールでは、仕様が変更されたら手戻りが起きて、前やった工程をもう一度やらなければなりませんでした。これはときどき、無視できない工数の増加となり、開発者を疲弊させていました。
アジャイル開発では、スプリントがあることで、仕様変更が発生したら次期以降のスプリントで新しい仕様に修正をすれば問題ありません。
スプリントは一つの閉じた開発サイクルのため可能です。
もちろん、ソフトウェア全体の作りを柔軟に仕様変更に対応できる作りにしておく必然性はあります。そのためにマイクロサービスアーキテクチャなどが用いられます。
テストやフィードバックが容易
1つのスプリントで作りこむ機能は、そのスプリント内で完結する機能です。したがって、テストは狭い範囲で済みます。
また、追加された機能に対してのフィードバックを顧客なりチームメンバーなりから受ければ、フィードバックの範囲も広くなりません。
結果として、テストに関する修正、フィードバックに関する修正も少なくなります。
ウォーターフォールでは、まとめてテストやフィードバックをしていたために、修正項目が膨大になりがちでしたが、スプリントがあることで、手戻りが最小限で済むのです。
全体的な工数の低下もさることながら、チームメンバーのモチベーションの維持にもスプリントは大変効果があります。遠くの見えにくい計画より、近くの見やすい計画の方が人間は気が楽になるものです。
目標が明確化する
1つのスプリントで作りこむ機能は、計画を立てるときに決まり小規模で済むことから、開発の目標が明確になります。
遠大な目標を立てて、それをトップダウンしていって微細なWBSに落とすのがウォーターフォールのプランニングの手法ですが、そんな計画を立てても多くの場合、遅延します。
計画は小さい方が、修正が効きやすいものです。
このことは、チームメンバーそれぞれが各自の目標を持ちやすいということですし、経験が多くなくても目標を具体的な行動に落とし込めるケースもあります。
アジャイル開発のチームメンバーには自走能力が求められますが、自走しやすい仕組みがスプリントにはあります。
チーム内コミュニケーションの活性化
スクラムがあることにより、スプリントに参加しているチームメンバー間は、自然にコミュニケーションの密度が濃くなります。
あなたも新人の頃、仕事で分からないことがあっても先輩に話しかけるきっかけがなくて困ったことはないでしょうか？
アジャイル開発では、スクラムの導入により、話しかけるきっかけがないということを無くします。
リモートワークをしているとコミュニケーションが希薄になるのはよくある話ですが、アジャイル開発を導入している開発現場ではそのようなことは起きにくいようです。
伝達ミスのようなものも減ります。リモートワークについては、以下の記事も参考にしてください。
スプリントのデメリット
メリットの多いスプリントですが、以下のデメリットも把握する必要があります。
- 初期の準備に時間がかかる
- 頻繁な変更がプロジェクトの混乱を招く
- コミュニケーションが密になりすぎ過負荷となる
それぞれ具体的に見てみましょう。
初期の準備に時間がかかる
スプリントを開始する際、チームメンバーの準備に時間がかかることが課題です。
プロジェクト開始当初、メンバーは製品の概要やアジャイル開発自体に不慣れな場合があり、チームとして自走できる状態に達するまでには困難が伴います。
新しいメンバーの参入には、当人だけでなく、コーチ役やメンターの負担も大きくなります。
スクラムマスターは、プロジェクトを隅々まで把握していないと、スクラムの司会進行ができません。
また、メンバーも他のメンバーの相談に乗るためには、プロジェクトについての深い理解が必要です。
昨今の開発現場では、メンバーの入れ替わりが頻繁に起こるため、この問題はより顕著になっています。チームが自走できるようになるまでには、様々な困難が伴うのが現実です。
初期の準備に時間がかかることは、スプリントを円滑に進める上での大きな課題と言えます。
管理が煩雑になる恐れがある
いくらスプリントの途中で要件は変わらないとはいえ、スプリントの度ごとに要件が変わっていたらどうでしょうか。コードのどこを修正したのか容易に分からなくなり、プロジェクトが混乱することは目に見えています。
その結果、コードを管理しているコードマスターの業務が果てしなく煩雑になります。
また、会社であればプロジェクトを管理する人は存在して当然ですが、誰が何をやっているのか把握しきれていない状態になりがちです。指令が一か所から出るのではなく、各自が手を挙げて作業する方式だからです。
上役がメンバーを把握できなければ、適正な評価ができなくなります。
オープンソースプロジェクトならともかく、営利目的の組織でそれは許されることではありません。
コミュニケーションの過負荷
スプリントには、コミュニケーションが密になる代償として、人によってはコミュニケーションが過負荷になるデメリットもあります。
アジャイル開発では、些細な変更であってもチームメンバー全員に報告する必要があり、業務時間外に対応する場合もあります。
また、苦手な人とのコミュニケーションも半ば強制されるため、メンバーにとって苦痛となるケースも少なくありません。
ウォーターフォール開発では、プロジェクトマネージャーに報告すればよかった変更も、アジャイル開発ではチームメンバー全員に共有しなければなりません。
家でゆっくりしているときに、仕事のメッセージを進んで確認したい人は少ないのではないしょうか。
アジャイル開発ではコミュニケーションが重要視されるため、苦手な人とのコミュニケーションも避けられません。
アジャイル開発でのスプリントの流れ
アジャイル開発のスプリントでは、下記の流れで進めていきます。
- 1.スプリント計画の設計
- 2.デイリースクラム
- 3.スプリントの開始
- 4.スプリントレビュー
- 5.スプリントレトロスペクティブ
詳細は下記の通りです。
1.スプリント計画の設計
スプリント計画の立て方は前述した通り、スプリントプランニングという会議を開催することが通例です。
スプリントプランニングでは、ユーザーストーリーを全員で共有し、今の課題の中から各自が手を挙げて自分の次のスプリントにおけるタスクを決めます。
そのタスクにどれだけの工数がかかるかは、チームメンバー全員で見積もります。
なぜなら、一人で見積もるより誤差が少なくなるからです。経験が浅くても、経験豊かなメンバーがメンターとしてつくなら自分で思っているより早く完成する場合があります。
逆に、根拠のない自信で過小に見積もって結局終わらないという事態も避けられます。
アジャイル開発では、スプリント計画はプロジェクトマネージャーが一人ではなく、チームメンバー全員で立てるものです。
2.デイリースクラム
デイリースクラムもお伝えした通り、30分といった時間を定めることが大切です。
時間を定めると、優先順位をつけやすくなります。デイリースクラムの時間内に終わらない議論があったら、別途MTGの機会を設けて1on1で話し合います。
また、デイリースクラムは、単なる進捗報告の場ではありません。昨日何を達成したかを報告し、その日に何を達成するかを宣言する場です。
スプリントにおいては宣言が重要視され、具体的に、何をどうやってどうするかを伝える必要があります。
メンターがいる場合、デイリースクラムとは別にメンタリングの時間を1on1で設けるケースも多く、ささいな悩みごとを相談することが可能です。
3.スプリントの開始
デイリースクラムで宣言したことを実行するのがその日の業務となりますが、一人で行うのではありません。
ソフトウェア開発は、その特性上どうしても一人での作業が多くなります。分からないことがあったら最初は調べるのが鉄則ですが、そのプロジェクト固有の情報や、調べ方さえも分からない場合、他のチームメンバーのサポートを仰ぎます。
全員がすべてのタスクを知っているため、誰もがサポートできる、というのがアジャイル開発の理想形です。
ただ、実際にはそのコミュニケーションが過負荷となるメンバーもいることは前述した通りです。
そのため、微妙なさじ加減が必要となるのも現実ですが、少なくとも投げられっぱなしにはならないでしょう。
4.スプリントレビュー
スプリントレビューでは、スプリント計画に対してできたことを互いに確認しあいます。プロダクトオーナーもスプリントレビューには参加します。
このとき大事なのは、できなかったメンバーを責めてはいけない、ということです。
それはモチベーションの低下につながり、全員参加のアジャイル開発を破綻させかねません。
それよりも、できた点を評価しましょう。評価するのはスクラムマスターやプロダクトオーナーだけではありません。チームメンバー全員がチームメンバー全員を評価します。
レビューのときには、次のスプリントへの積み残しもしっかり確認します。
この点は、漏れが発生しやすいので気を付けたいところです。タスク管理ツールを上手く活用すると良いでしょう。
5.スプリントレトロスペクティブ
スプリントレビュー後に、30分～1時間程度でスプリントレトロスペクティブが行われることが多いです。
これは打ち上げみたいなもので、下記の点を全員で共有します。
- 達成できたこと
- よかったこと
- 成長できたこと
スプリントレトロスペクティブは共有の機会であると同時に、チームメンバーのプロジェクトへの関心を高める機会でもあります。
プロダクトオーナーは、スプリントレトロスペクティブの機会を上手く利用して、プロジェクトの求心力を高めていきましょう。
効果的なスプリント計画の立て方
次はスプリント計画の立て方を見ていきましょう。
- 1.目標の設定方法
- 2.タスクの分割と優先順位付け
- 3.チームメンバーの役割分担決め
- 4.リスク管理計画
効果的なスプリント計画の立て方と、計画を立てる段階での重要なポイントを解説します。
1.目標の設定方法
スプリントの目標を立てると言っても、ゼロから目標が出てくるわけではありません。
アジャイル開発には、最終的にユーザーに届けたい機能を網羅したユーザーストーリーというプロジェクトの青写真が存在します。
ユーザーストーリーには、ユーザーに体験してほしい状態が網羅されています。機能／非機能両面に渡って書いてあります。
ユーザーストーリーの中から、今回のスプリントで実現させたい機能を抽出し、スプリントの目標とするのです。
もちろん前のスプリントからのフィードバックや、バグの修正も目標に入るでしょう。
大がかりな機能追加の時は、その機能を更に分割して、一つのスプリントで実現可能な単位にまで細分化します。
決して、過大な目標を一つのスプリントに盛り込まないでください。
2.タスクの分割と優先順位付け
目標が決まったら、次にタスクの分割です。
前述した大がかりな機能追加のときタスクを分割しますが、何人かで同時並行できる機能追加の場合は複数人で並行するための分割をします。
技術的な話をすると、フロントエンドとバックエンドを同時に進行する、モックやスタブを作って各自で開発してから本番同士で結合するなどです。
そして、立てた目標が多すぎてスプリント内に完結できそうになかったら、ボトルネックの箇所の解消など優先順位の高いタスクからこなしていきます。
優先順位の高いタスクが先に終わっていることで、全体としては進捗を進めやすい状態になります。
3.チームメンバーの役割分担決め
アジャイル開発ではチームメンバーの自走が大切ですが、そうは言っても、経験の差、得意不得意などはあります。
そこで、スプリント計画の中で自分が取り組めそうなものをチームメンバーに自分から手を挙げてもらいます。
もしそのメンバーには荷が重いかなと（経験豊かなメンバーなどが）感じた場合、メンターをそのメンバーにつけます。
メンターは、自分が担当したメンバーがより自走できるようにサポートし、チームメンバーの成長を促します。
役割の固定化はあまり好まれません。理想的な状態は全員がどのタスクでもこなせるように進めていきましょう。
4.リスク管理計画
優先順位付けもリスク管理の一端です。というよりも、アジャイル開発自体が巨大なリスク管理のプロセスです。
とはいえ、メンバーの思わぬ病気などで、穴が開くこともあるでしょう。
役割を固定化した組織では、その時組織全体の業務がストップします。これを属人化の罠と呼びます。
そうならないように、全員がどのタスクでもこなせるように常に目指すことで、思わぬリスクへの対処の強度を高めるのがスプリントの目的です。
また、昨今の開発では途中でチームメンバーの出入りがあるのが当たり前です。
教育の手間は、前述したようにやはりかかってしまいますが、教育する側が一人ではない、というのがアジャイル開発の強みです。
プロダクトバックログとスプリントバックログの違い
プロダクトバックログとスプリントバックログは、アジャイル開発における重要な要素です。
プロダクトバックログはプロジェクト全体のタスクを一覧にしたものであり、スプリントバックログはスプリント期間内に達成するタスクを選定したものです。
ここでは、それぞれの役割や特徴について詳しく説明します。
プロダクトバックログの役割
プロダクトバックログとは、プロジェクト全体のタスクや機能を一覧にまとめたリストのことです。
プロダクトバックログの主な役割は以下の通りです。
- プロジェクトの進行状況や未完了タスクを把握しやすくする。
- 重要度に応じてタスクを整理し、開発チームが効率的に作業を進める。
- 新しい要求や変更が発生した際に迅速に対応。
これにより、プロジェクトの透明性が高まり、チーム全体が共通の目標に向かって効率的に作業できます。
スプリントバックログの特徴
スプリントバックログは、スプリント期間中に完了するための具体的なタスクや作業項目をまとめたリストです。
主な特徴は以下の通りです。
- スプリント期間中に達成可能なタスクが含まれる。
- 各タスクは詳細に記述され、担当者や期限が明確。
- スプリントプランニングミーティングでチーム全体が共有する内容。
- タスクの進行状況を視覚的に把握しやすい。
これらの特徴により、スプリント期間中の目標達成が明確になり、効率的なプロジェクト進行が可能となります。
まとめ
アジャイル開発のスプリントについて説明してきました。
最後にスプリントのメリットについておさらいしておきましょう。
- 課題をすぐに解決できる
- 仕様変更など柔軟な対応が可能
- テストやフィードバックが容易
- 目標が明確化する
- チーム内コミュニケーションの活性化
これらのメリットを活かすことで、アジャイル開発が効率的に進めることができます。
しかし、この記事を読んで「なかなか難しそうだな…」そう思われた方もいらっしゃるのではないでしょうか？
実際にアジャイル開発を導入には障壁は高かったりします。
自社での導入が難しい、しかしこのソフトウェアの開発はウォーターフォール開発よりアジャイル開発の方が適してそうだ、そう考えたら、アジャイル開発が得意なシステム開発会社に開発をお任せすることも考えてはいかがでしょうか？
株式会社Jiteraでは、アジャイル開発の経験豊富なスタッフが、貴社のソフトウェア開発を承っております。
最適なリソースを配分してソフトウェアを開発するのが世界の潮流です。
スプリントに興味がある方は、株式会社Jiteraにお問い合わせください。スプリントも含め最新の開発手法を取り入れたサービスを提供しています。ご質問やご要望など、お気軽にご連絡ください。
