こんにちは

前の記事には、アジャイルとウォーターフォールの開発モデルの概要や徹底について理解していました。これらの開発モデルがオフショアプロジェクトを開発する際によく適用されている有名なモデルであります。但し、近年IT技術が進化し並びにビジネスのスピードが加速されるため、スクラム開発という他の開発手法がオフショア開発会社においてよく適用されている状態です。

それでは、スクラム開発とはどんな開発モデルのか、他の開発方法とどのように違うのかわからないという方もいるのではないでしょうか。本記事ではスクラム開発の特徴やメリットをわかりやすく解説していきます。

スクラム開発とは

スクラム開発は、1990年代に米国の技術者によって生み出され、「スクラムガイド」で定義されています。その中、「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである」と定義しています。

すなわち、スクラム開発（Srum)とはアジャイル手法の1つで、少人数のチームに分かれ短期間の開発サイクルを繰り返し行うフレームワークです。

スクラム開発はチームを組んで役割やタスクを分散させつつ、コミュニケーションを重視するため、チームのコラボレーション向上を促し、インパクトの大きな仕事の達成をサポートする手法として人気があります。

スクラム開発の特徴

スクラムは「経験主義」と「リーン思考」に基づいています。その中、経験主義が知識や経験から生まれ、意思決定が観察によってなされます。リーン思考で、ムダを省き本質に集中します。スクラムが機能するのは3つの本柱を実現しています。詳細は以下となります。

スクラムの3つ本柱

透明性

透明性とは作業状況がわかるようになることです。作業内容及びよい事実も悪い事実もどちらともの状況はチームメンバーやその作業結果を検収する人に見えるようにしておくということです。透明性が欠けた状態では誤解を招き、無駄なものとなる恐れがあります。

検査

チームメンバーが進捗状況やプロセスなどに問題発生がないかどうかを確認するということです。検査は透明性の上に成り立ち、望ましくない状況や問題に気づくために積極的に行う必要があります。

適応

適応は検査の結果に基づき、プロセスやプロダクトの修正を行うということです。検査結果への対応はもちろん、作業中にも手法やプロセスの見直しが必要です。チーム全員が、前回より良くなっているかを問いかけながら、プロセスの改善やプロダクトの軌道修正をできるだけ早く行っています。　

それでは、スクラム開発モデルには具体的なステップが何でしょうか？チームメンバーは何をしますか？スクラム開発プロセスは、以下のように進行します。

スクラム開発のプロセス

• バックログを管理する

スクラムスプリントを始めるには、チームリーダーがやるべき仕事を決定し、バックログという一か所で文章化して、管理します。

• スプリントスプリント計画セッションを開く

スプリント計画セッションでは、そのスプリントでバックログのどの仕事に注力するのかを決定します。

• スプリントを開始する

スプリント期間中、チームはスプリント計画セッションでチームリーダーがまとめたバックログの内容に取り組みます。通常、1 つのスプリントは 2 週間続きます。ただし、チームに合わせてこれより短くまた長くする場合があります。

• デイリーミーティングを開催する

デイリーミーティングに進捗情報を共有し、予想外の障害があれば優先度を調整します。

• スプリントレビューで作業内容を報告する

スプリントレビューでは、スクラムチームのメンバーが完了した仕事を報告し、関係者の承認を受けます。

• スプリントの振り返りで共有、反省を行う

スプリントが終わったら、その感想を共有し、次回以降どういった点が改善できるかについて話し合います。この振り返りはレトロスペクティブと呼ばれます。

スクラム開発におけるルールは、「3つの役割」「５つのイベント」「3つの作成物」といわれています。具合を説明していきます。

スクラム開発で重要な3つの役割

スクラム開発には、「プロジェクトリーダー」がいることなく、スクラムチームに所属するメンバーは大きく３つ役割にわかれています。

プロダクトオーナー（Product Owner）

プロダクトオーナーは「何を開発するか決める人」と定義されています。ユーザーの要望を把握し、ユーザーの体験談を開発チームに伝えることに重点を置きます。設計やコーディング、テストなどの開発作業には直接関わりませんが、進捗状況は把握します。

プリントプランニングの際には、POの方が必要な機能を選択し、機能優先順位を付けて、チームのメンバーに説明、共有するようにします。

スクラムマスター（Scrum Master）

スクラムがうまく回るように全体を調整するチームリーダーの役割があります。おもな仕事はスクラムのルールや進め方を決め、開発チームが開発期間内に全てのタスクを終わらせることができるように進捗を管理し、開発チームが解決できない課題に取り組み、スクラムの仕組みや進め方を改善するのことです。

開発メンバー（Development Member）

開発者は、スクラムチーム内で、開発作業直接関わるメンバーのことです。プロダクトの開発どのものを専用的に担う役割です。開発者はお互いに支援をする、毎日進捗を共有するという責任を持ちます。チーム構成は通常10人以下で、人数が少ないほど生産性が高い傾向にあるといわれています。

スクラム開発の５つイベント

スクラムイベント（Event）とは、スクラム開発を実践する上で必要なミーティングです。プロダクトの検査と適応の機会として設けられていて、スクラムに必要な透明性が実現できるようになっています。クラムイベントを実施することは、規則性を生み、スクラムで定義されていない不要な会議を最小限に抑えることができます。すべてのスクラムイベントは、単純に運用できるように、同じ時間、同じ場所で開催されることが必要です。

スプリント（Spint）とは、アウトプットを出すまでの期間のことです。スクラムチームでスプリントの期間を決めて、スプリント内のスクラムイベントを通して、検査と適応を行います。スプリント期間が長すぎると、検査と適応を小まめに実施できないので、リスクが高まります。スプリント期間を短くすると、より多くの学習サイクルが生まれ、リスクが大きくなる前に潰せます。ただ、スプリントは一ヶ月以内の期間で終了します。

スプリントプランニング（Sprint Planning）

スプリントプランニングとは、スプリントのゴールを達成するために必要な作業を計画するイベントです。スプリントプラニングの中に、アウトプットまでの期間に何をするのかをチームで話し合います。プリントバックログ（スプリント期間中にチームが取り組む作業アイテムを明確にするための手段）を作成し、アイテムの洗い出しをしておきます。

デイリースクラム（Daily Scrum）

デイリースクラムとは、スプリントゴールが達成できるか検査するためのイベントです。デイリースクラムには、スプリントゴールへの進捗状況を確認し、問題点、解決したことなどを共有し、必要に応じてスプリントバックログを修正し、今後の予定作業を調整します。

リファインメント（Refinement）  （任意）

リファインメントとは、プロダクトバックログアイテムをより詳細にするイベントです。プロダクトバックログアイテムは開発チームが目標を達成するために、必要となるアイテムやタスクに優先順位をつけてリスト化した一覧に登録されているタスクのことです。POと開発メンバーはプロダクトバックログアイテムの内容や見積もり、優先準備などの内容を確認し、詳細化します。

スプリントレビュー（Sprint Review）

スプリントレビューとは、スプリントの成果を確認し、フィードバックを得るイベントです。スプリントの成果(インクリメント)をデモすることで、フィードバックを引き出します。フィードバックを元に、プロダクトバックログの項目追加や優先順位の変更を検討して、今後に向けた改善策を見つけていきます。

レトロスペクティブ（Retrospective）

スプリント中のチームの活動やプロセスを振り返るイベントです。チーム全員が参加し、問題を改善し、良かった点や反省点を共有し、次回に生かしていきます。スクラムイベントの一番最後に実施し、レトロスペクティブが完了を持って１つのスプリントが完了します。

３つの作成物

プロダクトバックログ（Product Backlog）

プロダクトの開発や改善に必要なタスクを優先度順に並べた一覧です。この一覧がチームのメンバー全員に共有され、作業内容を確認でき、ゴールを共通認識できるためです。

スプリントバックログ（Sprint Backlog）

スプリントで実施するプロダクトバックログの項目を実行可能なタスクレベルにまで詳細化したものです。プロダクトバックログが開発メンバーより日々確認されて、ゴールが達成できるかを検査し、リスクに適応するように計画を立てていくためです。

インクリメント（Increment）

インクリメントとは、スプリントの終わりに納品される、開発者が作成する成果物のことです。新製品や機能、改善、バグ修正など、チームによって異なります。スクラムの関係者がそのインクリメントについて考え、「完了」かどうかを判断します。

開発プロジェクトでよく使われるスクラム開発ですが、万能ではありません。スクラム開発はどんなチームにでも合うものではありません。但し、スクラム開発のメリットを活用しながら継続的な改善を利用しては大きな仕事を成し遂げることができます。これからスクラム開発のメリットやデメリットについてご紹介します。

スクラム開発のメリット

• 各スプリントは短期間であるため、正確な見積もりを立てやすい。
• 仕様変更には柔軟に、不具合の修正には迅速に対応可能。
• 目標が明確であることから、各メンバーが主導的に仕事を進めていく、生産性の向上が期待、個々のスキルが最大限に発揮可能
• デイリースクラムが継続的に行われるため、問題点を早期発見しやすい、素早く改善・軌道修正が可能

スクラム開発のデメリット

1. 少数のチームで進めるため、技術者のスキルにより品質が左右されやすい
2. 仕様変更が相次ぐことにより、プロジェクトの範囲が肥大化しやすい
3. 毎日に多くのミーティングが開催され、仕事の効率に影響を与える恐れがあり

まとめ、スクラム開発は柔軟性高いをもち、継続的に更新が必要となりそうなシステムに適すると言われる、優れた開発手法の一つです。ただし、すべてのプロジェクトはスクラム開発が向いているわけではありません。そのため、スクラム開発の特徴をしっかりと、より良い開発の実現に相談します。