本記事の目的

スクラムは、Webアプリやネイティブアプリの開発現場では多くのプロジェクトで導入されている、プロダクトを生産的に開発するための手法です。ファンタラクティブもWebアプリ開発をスクラムで進めています。

本記事は、スクラムの概要とスクラムの核である「スプリント」の進め方をご紹介し、読者にサービス開発においてスクラムを採用する際の助けとなることを目的にしています。

スクラムはアジャイル開発の代表的な手法

アプリケーションの開発には、 ①設計 ②開発 ③テスト ④リリース という4段階のフェーズが必要です。 この4つのフェーズを1セットにまとめ反復する開発手法が「アジャイル開発」です。 設計・開発・テスト・リリースの1セットをアジャイル開発では「イテレーション」と呼び、スクラムでは「スプリント」と呼びます。なのでスクラムにおいてイテレーションとスプリントは同じものを指すと考えて頂いて問題ありません。 「アジャイル開発」とよく比較される手法に「ウォーターフォール開発」があります。ウォーターフォール開発は各フェーズの期間を長く設定し1度ずつ行う開発手法です。

アジャイル開発とウォーターフォール開発という大きな2つの開発手法があり、スクラムはアジャイル開発の代表的な開発手法、という位置づけになります。

スクラムチームとスプリント

ここからはスクラムの具体的な手法について解説していきます。

スクラムチーム

スクラムを行うチームには3つの役割分担が存在します。それぞれの名称と役割をご紹介します。

プロダクトオーナー

プロダクトの価値を最大化することに責任を持つ人です。プロダクトオーナーは1人です。 プロダクトバックログの管理、つまり「何を」「どの順番で」「いつまでに」開発するかの最終責任を持ちます。

開発チーム

デザイナーやエンジニアなど実際に手を動かすチームです。 スケジュールに合わせてプロダクトを開発し、リリースクオリティを守る責任を持ちます。

スクラムマスター

スクラムの理論をチーム全員に理解、そして実践してもらうことに責任を持つ人です。 スプリントが適切に運用されるためには全員の協力が必要なので、スクラムマスターはプロダクトオーナーや開発チームをサポートしながらチームの価値を最大化します。

スプリントのタイムボックス

スクラムではスプリントを繰り返してプロダクトを開発していきます。1スプリントの期間のことを「タイムボックス」と呼びます。 1スプリントの期間は1週間や2週間など、1週間の倍数かつ4週間以内で設定するのが望ましいです。 リリースや定例の打ち合わせなどは曜日が固定されていた方がわかりやすいためです。 スプリントのタイムボックスを何週間に設定するかはプロジェクトやフェーズによって適切に選択する必要があります。 タイムボックスを短くしたほうがリリース回数が増えてユーザーからの要望をより早くプロダクトに反映することができます。ただ、タイムボックスを短くするとまとまった開発時間を取ることができず品質が下がってしまう可能性もあります。

弊社では2週間のタイムボックスを設定することが最も多く、時折1週間スプリントのプロジェクトもあります。

スプリントの中でやること

具体的にスプリントの中でやること、そしてスプリントの流れをご紹介します。

スプリントプランニング

「何を」「どの順番で」「いつまでに」開発するか、つまりスプリントのゴールをチーム全員で決めます。大きすぎるゴールでは見積もりもしづらく解釈にブレが出てくるので、ゴールに向けてタスクを分割し優先順位を決めます。スプリントプランニングでタスクを決めきることで、全てを終わらせれば自然とゴールにたどり着くことが保証されますし、開発チームはタスクを1つずつ完了することに集中することができます。

デイリースクラム

開発チームが毎日行うイベントです。必要な時間は15分程度。 前日までのタスクの進捗を確認し、今日の作業計画をチームメンバーに共有します。一方的にメンバーの進捗を確認するだけではなく、困っていることがあれば共有し質問できる場でもあります。

開発作業

開発チームがデザインや実装を実際に行う時間です。プロダクトのリリースも開発チームが行います。

スプリントレビュー

スプリントの終了時にチーム全員で行います。 開発チームはこのスプリントでリリースされるプロダクトのデモを行い、成果を共有します。 また、プロダクトオーナーは既存のプロダクトや市場の分析結果を共有し、次のスプリントで何を行いそれがどういう影響を与えるかの予測を共有します。

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

スプリントレビュー完了後に行います。レトロスペクティブという単語は馴染みが無い方も多いと思いますが「回顧」「振り返り」という意味です。 スプリントレビューがどちらかというとプロダクトやタスクを議題とするものであったのに対して、スプリントレトロスペクティブはチームやコミュニケーション、プロセスに重きを置いた振り返りです。 いくら綿密な計画を定めたからと言って機械がそれをこなして完了するわけではなく、チームは人間の集まりです。スプリントレトロスペクティブで個々の不安やアイデアを共有して次のスプリントに向けて改善を図って行きましょう。

なぜスクラムを採用するのか

ユーザーに早く価値を届けるため

サービス開発はいくら良い企画を練ってもリリースしなければそれがユーザーに届くことはありません。もちろん売上にも貢献しません。リリースサイクルを短く反復して設けることで、常に最短でユーザーに価値を届ける体制を維持できます。

ユーザーからのフィードバックを素早く吸い上げ活用するため

リリースを早くすると、もう一つ良いことがあります。それはユーザーからのフィードバックを受けられることです。ユーザーの動きを予測し、仮説を立てた上で施策を練ることはもちろん重要ですが、その結果を100%確実に予測することは誰にもできません。そのため仮説を温めておくよりも、出来るだけ早くユーザーに使ってもらい、フィードバックを受け次の改善に活かす方が、結果としてサービスの成長は早くなります。

チームに規律をもたらすため

サービス開発にとっては「最速が善」です。ただしサービス開発はチームで行うものです。「最速」の定義は人によって異なるものですし、各自がそれぞれに最速を目指して要件定義やテストを十分に行わずにリリースを繰り返すと、クオリティの担保であったり一貫性のあるサービス提供というのは出来なくなります。 そのためには、スプリントという形でスケジュールを明確にし、最速でありながらチームメンバーが自分の今やるべきことを理解し集中できる環境を用意することが大切になります。

開発効率を可視化し、見積もりを正確にするため

スプリントの特長として期間を一定にすることが大切と書きました。期間を一定にすること自体開発の初期は効果が無いのですが、それを繰り返していくことでデータが溜まっていきチームの基準値を明確にすることができます。 最も分かりやすいのは実装フェーズで、タスクの実工数を記録していくことで「開発チームが1スプリントでどのくらいのボリュームの開発ができるのか」ということを以前のスプリントと比較しながら想定することができます。「1スプリントでどのくらいのボリュームの開発ができるのか」の指標を速度を表す単語である「ベロシティ」と呼ぶこともあります。

まとめ

本記事ではアジャイル開発の代表的手法であるスクラムを噛み砕いてご説明し、最後に私なりにスクラムを採用する理由を書かせていただきました。スクラムに対する理解が少しでも深まったと感じていただければ幸いです。 実際の現場でスクラムを運用する際は、プロジェクトに合わせてもう少しルールをチューニングする必要があります。追って記事を公開しますのでまたお読みいただけれと思います。

ファンタラクティブではサービス開発についてのお悩み相談を無料で受け付けています。自社のサービス開発にてスクラムを採用すべきか、スクラムで開発しているけれどうまくいかない、など課題をお持ちであればこちらからぜひお気軽にご相談ください。

TIPS

スクラムの手法は「スクラムガイド」に定義されており、IPA（情報処理推進機構）の提供する「アジャイル開発の進め方」にも詳しい記載があります。自社の開発にスクラムを取り入れたい方はこの2つの資料を読まれておいた方が良いでしょう。