背景
弊社インサイトではスクラム開発を取り入れているプロジェクトが多く存在します
しかし、私自身そのプロジェクトに一切関わっていないということもあり、スクラム開発について全く知識がありません
そのため、少しでも知識を習得する事によって、外からでもプロジェクトをサポートすることができれば良いなと思い、学習を開始しました
アジャイル開発とは
スクラム開発について説明する前に、大元であるアジャイル開発について学んでいきます
アジャイル開発は短い期間（1週間から1ヶ月）を区切って、その中ですべての手順を踏んで動作する完成品の一部を作る。そしてそれを繰り返す。
分析、設計、実装、テストを短い期間で並列に行い、それを繰り返す。顧客にとって価値の高い機能から開発し、短い間隔で動くソフトウェアを完成させる。
開発を通して顧客やユーザーの意見をフィードバックしながら進める。途中で修正が入るのは普通だし、機能の優先順位も途中で変更される。
引用：アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
このように、細かい間隔で分析、設計、実装、テストの工程を行うことによって、仕様変更などを前提とした開発ができる手法です。
不具合などが発覚しても、ウォーターフォール開発のように、最初に決定した大きな設計・長い計画ではないため、
戻る工数が少ないこともメリットの一つと考えられます
また、機能ごとに短い期間で開発することによって、市場投入のスピードを上げられ、
費用対効果を高めるなど、ビジネスの面からも良い開発手法と言えます
しかし、小さな開発工程を繰り返すことから、スケジュールの感覚を掴みにくいことや、
仕様変更が容易なことから、当初の開発の根本的な仕様から外れてしまうリスクがあります。
以上のことを踏まえると、後々更新していくシステムや、
開発速度と質を重視した製品を作りたいときに適しています
必ずしもウォーターフォールよりアジャイルの方が良いというわけでもなく、
そのプロジェクトに一番合った開発手法を取ることが良さそうですね
スクラム開発とは
前述したアジャイル開発の手法・フレームワークの一つです
アジャイル開発の中でも、コミュニケーションを重視した手法とされています
スクラム開発の流れ
開発の流れは下記の図にまとめました
四角に囲まれたものがスクラム開発での行われる5つのイベントです。
スプリント
2週間～1ヶ月の短い開発期間のことを指します
スクラム開発ではスプリントと呼称しますが、アジャイル開発全体ではイテレーションとも呼びます
これを繰り返すことによって製品を完成に近づけていきます
スプリントプランニング
スプリントの準備のことです
スプリントのゴール（完成させる機能・目標）をチームで定めます
詳細に説明すると、開発するべき製品の機能リストであるプロダクトバックログから、
優先度が高いものから順に1つのスプリントで開発する機能を取り出してリスト化し（スプリントバックログ）、
それをゴールとして設定します
デイリースクラム
スプリント内で行われる定期ミーティングです
スプリントのゴールを達成するために、作業の進捗や作業予定・問題などを共有します
同じ時間、同じ場所で行うことが定められており、短い時間で定期的に行うことによって
アジャイル開発でありがちな計画からの乖離を防ぐことができます
スプリントレビュー
スプリントの終了時に、きちんと動作する成果物（インクリメント）のデモンストレーションを行って関係者にフィードバックを貰うイベントです
フィードバックを踏まえて、プロダクトバックログの優先順位などを整理し、次のスプリントに向けて動き出します
スプリントレトロスペクティブ
スプリントの振り返りです
今回のスプリントの良かった点と改善点を洗い出し、次回以降のスプリントをより良く実施するために行います
また、スプリントのインクリメントの品質を上げることにも効果があります
このように、様々なミーティングイベントを挟みながら開発を進めていくので、コミュニケーションを重視したアジャイル開発と説明されているのも頷けます
スクラム開発で発生する役割
プロダクトオーナー
何を開発するのかを決定する人です
開発において行う投資に対する費用対効果を最大にすることに責任を持ちます
また、プロダクトバックログの順位付けや追加・削除の管理、後述する開発者への機能説明など、
製品をより良いものにしていくために、正しい方向に導く役割を持っています
開発者
文字通り実際に開発する人です
スクラム開発ではプログラマー、テスター、アーキテクトなど明確な区分けを設けません
開発者はプロダクトバックログに入っている項目を完了状態にしていき、製品の価値を高めることに責任を持ちます
スクラムマスター
スクラムが有効に機能するように奉仕するリーダーです
スクラムチーム全体をマネジメントしますが、コントロール型の管理をするわけではなく、
開発者に降りかかる外部からの邪魔の排除や、プロダクトオーナーの製品のスクラムゴールやプロダクトバックログの管理の支援を行ったりします。
指揮命令型のリーダーというよりは、徹底して支援に回る奉仕型のリーダーです
スクラム開発には、明確に指揮命令を出す役割というのは存在せず、
開発に関する決定などはチーム全体で行います
スクラム開発を成功させるためには、自分たちで物事を決めながら動く自己管理型のチームになる必要があります
それがスクラムが生産性を上げていける要因になっているようです
スクラム開発での成果物
プロダクトバックログ
製品へ追加する機能リストです
機能だけでなく、サーバーなどのインフラ整備や製品に必要な技術の習得なども含みます
「ユーザーストーリ」と呼ばれる、機能の詳細についてユーザーにもわかる書き方でこのリストを作成します
優先度順に並べられており、状況の変化や顧客要望などで絶えず変化し続けます
スプリントバックログ
スプリント内で開発する機能リストです
一回のスプリントだけで使用され、プロダクトオーナーの求める優先順位と、チームの見積もる機能の大きさ両方を加味して
プロダクトバックログから抜き出されます
インクリメント
スプリントで完成させる成果物です
スプリントで完了した製品の機能（今回のスプリントとこれまで完成した機能全体）を指します
スプリントの終わりにはインクリメントが完全に機能する状態でなければならず、
それを元にスプリントレビューでフィードバックを行います
インクリメントが積み重なっていくごとに製品の完成に近づいていきます
まとめ
今回はスクラム開発の基本中の基本を学びました
が、どのようにプロダクトバックログを書くか、上記のイベント以外でのチーム内でのコミュニケーションをどうするかなどの実践的な事柄については、
スクラム開発の根本であるアジャイル開発の詳しいプラクティスについてもっと深掘りする必要があると感じました
（誤りがありましたらコメント頂きたいです）