「スクラム」とは、アジャイル開発における代表的な管理フレームワークです。少数精鋭のチームを構成し、短期間で開発サイクルを繰り返すことによって開発をおこないます。
スクラムは、主にアプリやソフトウェア開発などのIT分野で活用される手法ですが、人事やマーケティング、デザインなど、さまざまな職種でチームワークを構築する際に役立てることができるでしょう。
この記事では、スクラムによって実現できることやスクラムチームの構成メンバー、スクラムのスプリントに含まれるイベントなどを解説します。
スクラムとは
スクラム (Scrum) とは簡単にいうと、アプリやソフトウェア開発で用いられる開発手法の1つです。10名程度の少人数のチームを結成して短期間の開発サイクルを進行するフレームワークであり、役割の異なる複数のメンバーがチームを組み、1つのゴールを目指してコミュニケーションを取りながら開発を進行します。ラグビーの「スクラム」にちなんで名づけられました。
スクラムの創設者であるKen SchwaberとJeff Sutherlandによる「スクラムガイド（Scrum guides）」によれば、スクラムの定義は次のようなものです。
「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。」*1
つまりスクラムは、チームが経験から学び、柔軟に変化へ適応することを可能にする自律的な開発手法です。変化のスピードが早く、未来が予測しにくいといわれる現代において、生産性や仕様変更への適応力が向上するほか、工数見積もりの精度が高まるなどの実務的なメリットを享受することができるでしょう。
スプリントとは
スクラムには、イベントと呼ばれる成果物の作成とその検査と適応を目的として実施される機会が複数存在します。正式なスクラムイベントとしては4つが定義されており、そのサイクルを「スプリント（Sprint）」と呼びます。スクラムの基本的な作業単位と言い換えることができます。
プロダクトの開発では、短期間で開発・実践投入・学習・適応を繰り返す必要があります。スプリントは1か月以内の決まった期間に区切られます。特定の目標を設定し、開発からリリースまでの工程を反復的に繰り返します。
この短期間のサイクルを繰り返すことにより、不確定な状況に対する予測可能性を高めることで要求の変化に合わせた柔軟な対応が可能になります。プロダクトを開発するうえでリスクや複雑性を低減させることができます。
アジャイル開発との違い
アジャイル開発は、ソフトウェア開発において開発の設計・実装・テストをフィードバックを得ながら素早く反復していく開発手法の概念で、その中の1つが「スクラム」です。
アジャイル開発手法は、スクラム以外に「カンバン」「XP」「動的システム開発手法（DSDM）」などさまざまな種類があります。いずれも基本方針は「決められた短期間で開発・実装をおこない、それを何度も繰り返していく」ことです。
アジャイル開発のメリットは、システムを実際に動かしながら確認できる点にあります。ユーザーからのフィードバックを即座に受けることができるため、変化するニーズを満たすシステムを完成させます。ウォーターフォール開発などと比べて、仕様変更への対応がおこないやすいともいわれています。
スクラムは何を実現するのか
スクラムの理論は「経験主義」と「リーン思考」に基づいています。
経験主義はフランシス・ベーコンやジョン・ロックなどによって提唱されたもので、「知識は経験に由来し、意思決定は観察に基づく」という考え方です。リーン思考はアメリカの企業家であるエリック・リース氏によって提唱されたもので、「無駄を省いて顧客への価値提供に注力する」という考え方です。*2
これらの2つの考え方を踏まえ、透明性、検査、適応という「スクラムの3本柱」が定義されています。
透明性
透明性（transparency）の柱では、「創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人の双方に見える必要がある」と考えます。
スクラムにおける重要な意思決定をおこなうためには、作成物を正確に認知することが不可欠です。透明性の低い作業は、作業実行者と作業を受け取る人との間で齟齬が生まれる可能性があり、リスクの高い意思決定を引き起こしてしまう可能性もあります。透明性を高めることによって、適切に検査をおこなうことが可能になります。
検査
検査（inspection）の柱では、「スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査されなければならない」と考えます。
スクラムの作成物に対する検査が必要なのは、潜在的に望ましくない変化や問題を検知するためです。検査とは現状把握、すなわち目標と現状の比較・評価ということができます。目標が示されていないと比較対象が存在しないため、十分な検査をおこなうことができないでしょう。しっかりと検査がおこなえることによって、この後の「適応」が可能になります。
適応
適応（adaptation）の柱では、「プロセスのいずれかの側面が許容範囲を逸脱していたり、プロダクトが受け入れられない場合、出来るだけ早く軌道修正を図る必要がある」と考えます。
検査結果を元に、適応まで導く体制が整っていなければ、スピード感のある開発をおこなうことが困難になってしまいます。よってスクラムチームには、検査によって問題を発見した際に、軌道修正や改善ができるような体制を整えることが期待されています。
スクラム開発の方向性を示す価値基準
スクラム開発は、次のような価値基準を実践できているかどうかで評価されます。これらはスクラムチームの行動指針とも言い換えることができます。
確約
確約（commitment）とは、「スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する」ことです。
開発ではチーム全体で同じ目標に向かって作業をおこない、成果を出さなければなりません。そのために確約をおこない、開発作業を滞りなく進めていく必要があります。
確約する内容としては、「ビジネス価値を創出し続けること」「高い品質を保ち続けること」「透明性に挑み続けること」などです。
集中
集中（focus）とは、「スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する」ことです。
ほかの仕事を同時進行で担いながら開発に携わる場合、スクラムのような反復的で漸進的なアプローチでは目標が達成できず、全体で生み出す成果の価値が下がってしまうかもしれません。
時間管理手法である「タイムボックス」などを活用することにより、集中できる体制を整えましょう。もっとも重要なことに集中し、作業を終わらせることだけを考えます。
公開
公開（openness）とは、「スクラムチームとステークホルダーは、作業や課題を公開する」という内容です。
スクラムでは、透明性を確保するための公開が必要とされます。開発チームは予測不可能ななかで動いています。手さぐりで作業を進めるなかで作業工程やステークホルダーの持つ課題を隠したまま開発を進めてしまうと、開発の途中や最終段階で仕様の変更やトラブルの発生につながるかもしれません。
開発を効率的かつ正確に進めるためにも、スクラムチームは作業工程や進捗、課題を公開しあって意見を述べ、フィードバックを共有することが求められます。
尊敬
尊敬（respect）とは、「スクラムチームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同様に尊敬される」ということです。
開発はチームが一丸となっておこなうため、メンバー同士の関係性を良好に保つことが非常に重要です。このためチーム内のメンバーには、お互いに常に敬意をもって接することが求められます。
それぞれの能力や経験、バックグラウンド、専門知識、洞察力などを認め合うことで作業を円滑に進めることができるでしょう。
勇気
勇気（courage）とは、「スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ」というものです。スクラムチームのメンバーには、どんな局面においても勇気をもって立ち向かうことのできる人間力が問われます。
たとえば、正しいことを選択するための勇気や難しい課題に挑戦して解決するための勇気、未来が不確実なものだと認める勇気、自らの間違いを認める勇気など、求められる場面はさまざまです。
スクラムチームを構築するメンバーと役割
スクラムチームは、スクラムの基本単位となる10名程度のチームとなります。高い専門性をもつ各メンバーが一丸となり、1つのゴールを目指して横並びとなってプロダクトゴールを目指さなければなりません。このスクラムチームには、「開発者」「プロダクトオーナー」「スクラムマスター」という3つの役割とそれぞれの責任が定義されています。
開発者
「開発者（Developer）」は、スクラムチームが行う各段階において必要な作成（インクリメント）を確約する役割です。
一般的に、開発チームの規模が大きくなるとコミュニケーションが取りづらくなり、早く正確に行動することも困難になるため、ある程度規模を抑えることが望ましいとされています。
このため開発チームは通常、ライターやアナリスト、デザイナー、プログラマーを含む3〜9人で構成され、スクラムの各段階で日々それぞれの作業をおこないます。チームとして製品の機能を設計してコードを書き、テストをおこない、品質の高い製品を生産してリリースする役割を担います。
製品の成否に関する責任は個人ではなくチームが負うと考えられているため、開発チームのメンバーは個人の肩書きをもちません。スクラムマスターの指導のもと、開発チームは日々の活動の中でスクラムバリューを実践していきます。スクラムのプロジェクト管理において、開発チームは次のような責任を負っています。
- 各作業の目的や目標に基づいてプロダクトバックログを作成し、その項目からタスクを選択する
- 各作業の進捗を監視し、必要に応じて日次計画を調整する
- 各作業の完成の定義を忠実に守り、品質を作り込む
- 各作業のレビューや反省会に参加して製品やプロセスを検証し、日々ゴールに向けて最適化する
プロダクトオーナー
「プロダクトオーナー（Product Owner）」は製品の総責任者です。プロダクトの管理をおこない、プロダクトの価値を最大化する役割を担います。また、チーム内やクライアントなど外部の利害関係者との仲介役にもなります。
プロダクトオーナーが指揮を取ることで、市場動向や顧客の期待などプロダクトが目指す総合的な目標を理解しやすくなります。このためプロダクトオーナーは、製品のビジョンを設定したうえでビジネスの視点からプロジェクトに問題がないことをしっかりとチェックしなければなりません。
スクラムにおけるプロダクトオーナーの役割としては、次のようなものが挙げられます。
- プロダクトのビジョンや要件定義、優先順位の決定などプロダクトに関する戦略を立案する
- プロダクトのビジョンをチームと共有し、価値の最大化を目指す
- プロダクトの方向性を定め、進捗を管理する
スクラムマスター
「スクラムマスター（Scrum Master）」は、チームがスクラムの原則に沿って機能しスクラムの価値を活用して問題を解決できるよう促す役割を担います。
このためスクラムの原則を理解して実践し、問題が発生したときに着実に解決に導く手腕が求められます。チーム間のコミュニケーションを促進することも大切です。スクラムマスターはチームが成功するために指導する役割を果たし、プロジェクト全体を通じて問題解決をサポートします。
スクラムマスターに割り当てられる具体的なタスクは、組織や担当するチームのニーズによって異なります。一般的には、スクラムに関連して次のような役割が求められます。
- 各作業の進行と指導をおこなう
- チームが抱えるプロダクト残案件を認識し、各作業内で提供できる以上のタスクがワークフローに追加されないよう調整する
- 協働とパフォーマンスを向上させるために、チームメンバーの自己管理と部門間の連携を促進・指導する
※スクラムマスターの関連資格について気になる方はぜひ以下記事もご覧ください。
スクラム開発における作成物
スクラム開発における作成物としては、「プロダクトバックログ」「スプリントバックログ」「インクリメント」の3つが定義されています。
プロダクトバックログ
プロダクトバックログとは、プロダクトが目指す将来の姿とそれを実現するために必要な要素の一覧です。
プロダクトバックログは「プロダクトゴール」と「プロダクトバックログアイテム」から構成されます。プロダクトゴールとは価値を提供する手段としてのプロダクトが目指す将来の状態であり、スクラムチームの長期的な目標です。プロダクトバックログアイテムとはプロダクトゴールを達成するために必要な要素をいいます。
それぞれのプロダクトバックログアイテムについてコストと顧客価値を見積り、優先順位をつけていきます。プロダクトに対する要求は、市場からのフィードバックやビジネス要求、環境の変化、技術の登場などにより常に変化し続けるでしょう。その変化にプロダクトバックログは「適応」するため、プロダクトバックログを更新していくことで製品が常に市場で競争力をもつものになります。
スプリントバックログ
スプリントバックログをひとことでいうと、開発者による開発者のための計画です。スプリングバックログは、そのスプリントの目的である「スプリントゴール」（why）と、そのスプリントで対応する「プロダクトバックログアイテム」（what）、成果物を作成するための具体的な作業計画（how）によって構成されます。
スプリングバックログはプロダクトバックログと同様に、ゴールとそれを達成するために必要な要素が含まれています。スプリントバックログはスプリントプランニングにおいて作成され、開発チームの学習や日々の進捗、状況の変化などを通じてリアルタイムで更新されていきます。スプリントバックログには、デイリースクラムで進捗を検査できるような詳細な内容が求められます。
インクリメント
インクリメントとは、プロダクトゴールを達成するために作成する完成の定義を満たした具体的な成果物です。アイデアを、実際に価値あるプロダクトに落とし込んだものということができます。
新しいインクリメントは過去に作成されたインクリメントに追加される形で1つひとつ積み重ねられ、最終的にプロダクトゴールを満たすプロダクトが完成します。インクリメントはすべてのインクリメントが連携して正しく機能することを保証するために、徹底的に検証しなければなりません。
スクラムのスプリントに含まれるイベント4つ
プロダクトゴールを達成するためにスプリント内で行われるスクラムのイベントは、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの4つです。それぞれ詳しくみていきましょう。
スプリントプランニング
「スプリントプランニング」はスプリントの最初におこなうイベントで、スプリントで実行する作業の計画を立てます。
この計画は、スクラムチーム全体の共同作業によって作成されます。タイムボックスは、スプリント期間が1か月の場合は最大8時間、スプリント期間が2週間の場合は最大4時間となります。スプリントプランニングでおこなうことは、主に以下の3つです。
- スプリントゴールの設定
- 対応するプロダクトバックログアイテムの選定
- スプリントバックログの作成
スプリントゴールの設定
プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案します。次にスクラムチーム全体が協力し合い、そのスプリントになぜ価値があるのかをステークホルダーに伝えるためのスプリントゴールを定義します。
対応するプロダクトバックログアイテムの選定
開発者は、プロダクトオーナーとの話し合いを通じてプロダクトに必要な要素からアイテムを選択し、スプリントに導入していきます。
スクラムチームは、必要に応じてこのプロセスのなかでプロダクトに必要な要素の変更や修正をおこなう場合があります。開発者が過去の自分たちのパフォーマンスやキャパシティ、完成の定義に対する理解を深めていくことができれば、スプリントの予測に自信をもって取り組めるようになるでしょう。
スプリントバックログの作成
開発者は、プロダクトに必要な要素ごとに完成の定義を満たすインクリメントを作成するために必要な作業を計画します。計画の際は、プロダクトバックログアイテムを1日以内の小さな作業アイテムに分解しながら考えていきます。
スプリントゴールやスプリント向けに選択したプロダクトバックログアイテム、およびこれらを提供するための計画をまとめて「スプリントバックログ」と呼びます。
デイリースクラム（デイリースタンドアップ）
デイリースクラムは、開発チームのメンバーがそれぞれの作業進捗について報告・共有する場です。毎日15分程度のイベントで、スプリント期間中に基本的には同じ時間、同じ場所でおこないます。
デイリースクラムの目的は、スプリントゴールに対する進捗を検査して必要な場合にスプリントバックログを適応させることです。そのために開発者それぞれの進捗状況や課題を共有し、状況に応じてスケジュールの調整やプロダクト開発に必要な要素の見直しもおこないます。
デイリースクラムでは、必要に応じてスクラムマスターがファシリテートを担当します。プロダクトオーナーの参加は必須とされていません。 開発者は、デイリースクラムにおいて1日の作業の実行可能な計画を作成したり、実行にあたって必要なものを選択したりできます。
全員が立ったままの状態でミーティングを終えられるくらいの短さが想定されているため、デイリースタンドアップとも呼ばれます。
スプリントレビュー
スプリントレビューはステークホルダーに成果物を提示する場で、スクラムチームのメンバーとステークホルダーが参加します。1か月のスプリントの場合は最大4時間、2週間のスプリントの場合は最大2時間のタイムボックスが割り当てられます。
スクラムチームは、主要なステークホルダーに作業の結果を提示します。またスクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューします。ステークホルダーからあらためてフィードバックを得ることで、プロダクトゴールに対する進捗状況を再確認することができるでしょう。
それを元にプロダクトバックログの項目変更や追加、削除などの調整をおこない、次回の計画の見通しを立てます。スプリントレビューでは建設的な討論をおこなうことが重要となるため、ステークホルダーに対するプレゼンテーションだけに限定しないようにしましょう。
スプリントレトロスペクティブ
スプリントレトロスペクティブは、スプリントの最後におこなわれるイベントです。スプリントの成果を確認し、スクラムチームでスプリント全体の振り返りをおこないます。
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することです。スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義について今回のスプリントがどのように進んだかを検査しましょう。検査する要素は、作業領域によって異なります。
課題や問題点に対する具体的な改善案を出すのはもちろん、順調に進んでいて今後も継続したい作業を明確にすることも大切です。スプリントレトロスペクティブをもってスプリントは終了となりますが、プロダクトゴールに達していない場合は次のスプリントがスタートすることになります。
スクラム開発のメリット・デメリットは？
効率的にプロジェクトを進めやすくなる軽量級フレームワークのスクラム開発ですが、メリットもあればデメリットもあります。
スクラムのルールブックであるスクラムガイドは20ページ程度のボリュームで非常にシンプルです。そのため理解がしやすく、状況やプロダクトに応じてアレンジしやすいといえます。世界で多く採用されているフレームワークなので、情報収集もしやすいでしょう。
スクラム開発のメリットは、短期間で開発工程を繰り返しフィードバックを得ながら修正・改善を重ねるため、仕様変更に柔軟に対応することができる点にあります。ミーティングを頻繁に実施し密なコミュニケーションを図るため、問題を早期に発見しやすくプロジェクトもスムーズに進みやすいでしょう。チームメンバーが協力し合いながらそれぞれの役割やタスクを果たすことから、作業を効率的に進められる点も特徴です。
さらにスクラム開発では、スプリントごとに工数見積もりをおこなうため高い精度の見積もりを知ることが可能です。工数を正確に把握できると、現在どこまで進んでいるのかも認識しやすくなります。
スクラム開発のデメリットは、短期間に少人数で開発をおこなう必要があるため、スキルが高いエンジニアを複数集める必要がある点です。チームメンバーのスキルレベルやコミュニケーション力がばらばらだと、プロジェクトがスムーズに進まないこともあるかもしれません。
また柔軟な仕様変更に対応できる反面、頻繁な変更によって全体的なスケジュールが把握しづらくなることもあります。プロジェクトの範囲がどんどん拡大してしまい、予算やリソースを圧迫するケースがある点に注意しましょう。
スクラムの理解を深めるためにおすすめの本
スクラム開発の全体像を把握して学習を深めるには、本を読んで学ぶのがおすすめです。ここでは、スクラムの理解を深めるためにおすすめの本を紹介します。
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
スクラムを実際の開発現場にどう適用すればよいのかをわかりやすく解説しています。
増補改訂では、初版以降のスクラムのルールの変更を踏まえて用語や説明の変更、最近の開発現場に向けた追補など、全面的な見直しがおこなわれました。
基礎編と実践編に分かれていて、基礎編ではスクラムの全体像と決められているルールについて説明されています。実践編では、架空の開発現場を題材に、開発が始まる段階から時系列を追ってスクラムではどう進めていくのかが説明されています。
アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
ソフトウェア開発手法「アジャイル」とその手法の1つである「スクラム」の体系的な解説書です。この第2版では、ビジネスで広く存在感を示すようになったアジャイルの新しい知見を盛り込み、内容がアップデートされています。
アジャイルとスクラムの全体像や野中郁次郎の知識創造プロセスとの関係など、初版での核心部分はそのままに、アジャイルを組織内で大規模化するためのスケールフレームワークなど新たな観点からの解説が追加されました。
国内を代表する著者陣による提言は、ITエンジニアはもちろんさまざまな業界のビジネスリーダーにおすすめの内容です。
スクラムはチームを1つにまとめる開発手法
この記事では、スクラムによって実現できるものやスクラムチームの構成メンバー、スクラムのスプリントに含まれるイベントなどについて解説しました。
スクラム開発はアジャイルのフレームワークとして世界で最も採用されている手法で、開発チームを1つにまとめコミュニケーションを図るために非常に有効です。
チームメンバーが各プロダクトゴールをビジョンとしてもち、それぞれの役割を遂行しつつ開発を進行させるフレームワークなので、よりよい製品やプロダクトの開発を実現することができるでしょう。
スクラム開発には、それぞれのメンバーが高いスキルを有していることが不可欠です。女性向けキャリアスクールのSHElikes（シーライクス）では、プログラミング入門やデザインなどさまざまなスキルを高めることができます。興味のある方は、ぜひ無料体験レッスンに参加してみてください。
女性向けキャリアスクールSHElikes無料体験レッスンはこちら
引用
*1 「スクラムのガイド スクラム公式ガイド：ゲームのルール」スクラムの定義 より
*2「スクラムのガイド スクラム公式ガイド：ゲームのルール」スクラムの理論 より
