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