見出し画像

【ソフトウェアの開発プロセス】スクラムとは

対象の読者

・これからソフトウェアを開発しようと考えている人
・ソフトウェア開発について基礎的な勉強したい人
・アジャイルソフトウェア開発に興味がある人

このチャンネルを初めてご覧の方は以下の記事を一読いただけると幸いです。

はじめに

スクラムとはソフトウェア開発のプロセスモデルである『アジャイルソフトウェア開発』の中に含まれる開発手法の一つです。

アジャイルソフトウェア開発について、概要を知りたい方は、こちらをぜひ参照ください。

アジャイルソフトウェア開発の中でスクラムは非常に人気があります。
理由は、いくつかありますが個人的にはそのシンプルさではないかと思います。

ソフトウェア開発のプロセスモデルはいくつもありますが、いずれも専門的な内容が含まれていたり、工程が多かったり、と初めての人には少し取り組みにくい内容が多いと感じます。

その点、スクラムは最低限の決められた役割やルールが非常にシンプルに作られており、内容を把握するだけであれば1,2時間もあれば理解することが可能です。

専門性的な内容が少なく、全容を理解しやすいというのがスクラムの導入が増えている理由だと思います。

スクラムの概要

はじめに、スクラムのルールを簡単に説明します。

スクラムでは、いくつかの『役割(ロール)』を分担したチームで作業を行います。
後ほど説明しますが、この役割はプログラマーやデザイナーなど職域を表すものではありません。スクラムというフレームワークの中での役割を指します。

画像2

チームは、一つの開発ゴールに対して『スプリント』という決められた期間で作業します。
スプリントの期間は、1ヶ月以内で固定されていて、このスプリントを繰り返し回して開発プロジェクトを進めていくことになります。
たとえば、2週間のスプリントと決めたら変更があるまで、2週間固定のサイクルでプロジェクトを進めていきます。

画像2

スプリント期間中には、いくつかのスクラムで用意された『イベント』を実施します。
各イベントでは、目的とタイムボックス(イベントで使える最大時間)が設定されており、イベントに沿ってスプリントを進めることで開発に必要なコミュニケーションが完了するようになっています。

またスクラムは、『作成物(成果物)』についても重要な定義づけがされています、スプリントを進めるなかで作成物を適切に評価することで、品質を安定させた開発ができるようが仕組みが設けられています。

スクラムで決められているルールはざっくり以上です。

このようにスクラムのルールは非常にシンプルになっていて、詳細についてはプロダクトに委ねられています。
基本のルールがシンプルで自由度が高い分、実際に実行するには難易度が高いモデルであるという見方もできます。

スクラムのチーム

スクラムでは、各メンバーにロール(役割)が与えられています。

■ 開発者

各スプリントにおいて、実際に作業を行なうメンバーを指します。
ここでいう開発者は、プログラマーに限らず、デザイナー、ディレクターなど様々な職域の人間を全て含めます
実際にスプリントの中で成果物を作り上げる人たちが『開発者』です。

■ プロダクトオーナー

プロダクトオーナーは『開発チームから生み出されるプロダクトの価値を最大化することに責任を持つ』役割の人を指します。
基本的に一つのチームに一人です。

具体的な役割としては、

・プロダクトに関するゴールをチームに伝える
・プロダクトが開発すべき機能や体験を制作する
・プロダクトが開発すべき機能や体験の優先度を決める


などがあります。

重要なのは、これらの作業は「他のメンバーに委譲することもできる」という点です。
プロダクトオーナーは、基本的にプロダクトに関する意思決定を行なう人ですが、全ての権限を持つ独裁者のような立ち位置ではなく、チームを先導する舵取りのようなイメージです。

■ スクラムマスター

スクラムマスターは、『スクラムがチームで上手く運用されることの結果に責任を持つ』役割の人を指します。

スクラムマスターの主な役割は、スクラムの理論やプラクティスをチーム全員に理解してもらうように務めることです。

具体的には、

・スクラムの導入をコーチする
・チームの進捗を妨げる障害物を排除するように働きかける
・プロダクトの計画の策定を支援する


などがあります。

スクラムマスターは、俯瞰的にチームをみて、チームの問題を見つけ出し改善を働きかける必要があります。
自らが動くのではなく、チームの自律的な行動を引き出だし、チームの成長に貢献する非常に重要な役割です。

スクラムの人数

スクラムは10人までが適正と言われています。
スプリント内で効果的な作業を行なうのに十分な人数がいて、かつ円滑にコミュニケーションできる人数が10人程度までというのが理由です。

それ以上人数がいるの大規模なプロジェクトについては、別のアジャイル開発のフレームワークを検討するか、スクラムのチームを複数ツリー構造に連結するなどの方法があります。

しかし、これらの方法はプロジェクト難易度としては高いものとなるため、一度スモールなチームでスクラムを運用して知見を得たあとで慎重に検討するとよいでしょう。

スクラムのイベント

スクラムでは予め決められたイベント(会議体)が用意されています。
スクラムのイベントは、一つのスプリントで1回ずつ定期的に実施されることになっています。

このようなサイクルを作ることで、決められたイベント以外の会議を極力減らし、予測できない遅延やトラブルを最小限に抑えることを目的とされています。

■ スプリント

スプリントは、前述の通り開発作業を行なうための決められた期間です。
基本的に最大1ヶ月を1スプリントとして、一度決めた期間を繰り返します。
(スプリント①が完了後スプリント②が始まる)

スプリントでは、予め計画されたプランをもとにゴールが設計されます。
そのゴールに向かって開発者は開発作業を進めていきます。

スプリントが計画どおりに進まなくなってしまったときは、プロジェクトオーナーがスプリントを中止することができます。

■ スプリントプランニング

スプリントが始める前にスプリントで実施するタスクを開発者、プロダクトオーナー、スクラムマスターのチーム全員でプランニングします。

スプリントで目指すべきゴールとそのスプリントで行なう内容をプロダクトオーナーと一緒に話し合い決定し詳細なタスクとして分解していきます。

■ デイリースクラム

実際にスプリントが始まると、毎日行われる15分のイベントです。
基本的に毎日同じ時間に、同じ場所で行います。(朝会や夕会といったイメージです)

デイリースクラムの目的は、チーム内のコミュニケーションを改善し、開発の障害物を取り除くことです。

作業の中で困っていることや、共有しておきたい内容をメンバーに相談します。
15分のタイムボックスに収まらない固有の問題については、別の会議体で担当者のみで話し合い解決します。

■ スプリントレビュー

スプリントの完了前にスプリントの成果を検査するためのイベントが『スプリントレビュー』です。

実際の成果物をメンバーや外部のステークホルダーとともにレビューし、今後の方針などを話し合い次の開発へ反映します。

スプリントレビューでは、実際に動くものをデモでプレゼンするなど目に見える形で発表します

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

スプリントレトロスペクティブは、スプリントの最後に行なうイベントです。

スプリントレトロスペクティブの目的は、今回のスプリントがどのように進んだのかを検査することです。

スプリントの運用の問題や、個人の問題などチームで発生した問題を話し合い次のスプリントの改善へとつなげます。

スプリントの適切な期間

スプリントの適切な期間は、チームの熟練度や状況により異なります。

基本的にスプリントが長いほど、運営は行いやすくなりますが、フィードバックのサイクルも長くなるため、改善もしにくくなります。
逆に短いと、フィードバックのサイクルは短くなり、より早く改善のサイクルも回せますが、運営の難易度が高くなる傾向にあります。


例えば、一週間のスプリントで、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントを繰り返すのはサイクルが早くタイトのため、初めてのスクラムチームでは難易度が高くなります。

また、「イベントのタイムボックスはスプリントの期間に比例して長くなる」というのもポイントの一つです。

スプリントが1ヶ月の場合、スプリントプランニングの最大時間は「8時間」になります。
長時間の会議に慣れていないチームにとって8時間集中してプランニングを行なうことは非常に難易度が高いでしょう。

そのため、一般的には1ヶ月の間をとって「2週間」を1スプリントとするようなプロジェクトが多いようです。

画像3

スクラムで重要なこと

スクラムは、『経験主義』と『リーン思考』という考え方を基に作られています。

経験主義とは「実際に行動して体験したことから学習し、知識の源泉にする」という考え方です。

スクラムでは、小さなサイクルを繰り返し回すことで、リスクを減らし多くの経験を積むことを大事にしています。

スクラムを導入してすぐに結果が出ることを期待してはいけません。
多くのスプリントを回すことで、徐々に適切な意思決定と開発を行なうことができるようになるのです。

ルール自体は少ないですが、実際にスクラムを進める中で多くの問題や疑問点が発生します。
これらをチームで話し合い、一つ一つの経験から学習することがスクラムでは重要です。

スクラムの学習のしかた(入門書籍)

■ スクラムガイド

スクラムで定義された最小限のルールは、スクラムガイドという20ページほどの小さなドキュメントとして公式にまとめられています。
まずはこのガイドをよく読んで概要を理解してください。

スクラムガイドは定期的にアップデートされていくので、導入後も定期的にチェックするとよいでしょう。

■ SCRUM BOOT CAMP

スクラムについて挿絵を使ってわかりやすく説明されている書籍です。

初心者向けのわかりやすさだけでなく、スクラムガイドには記載されていない具体的な事例や運用方法も詳しく記載されており実践的な書籍です。

まずはどんなものか知りたいと思っているひとは読んでみると良いと思います。

まとめ

スクラムは、導入しやすく、汎用性も高い非常に優れたフレームワークですが、運用には経験が必要です。

すぐに効果が期待できるものではないですが、将来的にはスクラムを導入することで成果物の品質向上や開発工程の最適化など多くのプロジェクト改善を期待できます。

これからアジャイルなソフトウェア開発を検討しているチームは、ぜひ一度勉強してみてください。

アンケートのお願い

このチャンネルでは、これから提供していくコンテンツやサポートの内容を改善していくために、アンケートをお願いしています。
ぜひアンケートにご協力ください。

アンケートはこちらから


この記事が参加している募集

この記事が気に入ったらサポートをしてみませんか?