スクラム開発の進め方/やり方/流れや方法/手法/工程/手順

ソフトウェア開発の現場では、要件が頻繁に変わる・完成イメージが最初から定まらないといった状況が珍しくありません。そうした不確実性の高いプロジェクトで注目を集めているのが「スクラム開発」です。スクラム開発はアジャイル開発の代表的なフレームワークの一つで、1〜4週間という短い期間（スプリント）を繰り返しながら段階的にプロダクトを完成させていく手法です。アメリカのFBI捜査局がウォーターフォール型で5年かけても完成しなかったプロジェクトをスクラムで1年以内に完了させ、コストを10分の1以下に削減した事例は、スクラムの実力を端的に示しています。国内でもメルカリやサイバーエージェントをはじめとした多くの企業が採用し、開発スピードとプロダクト品質の両立に成功しています。

本記事では、スクラム開発の全体像から3つのロール・5つのイベント・3つの成果物といった基本概念、そして実際の進め方や注意点まで体系的に解説します。「スクラムを導入したいがどこから手をつければよいか分からない」「すでに導入しているがうまく機能していない」という方に向けて、現場で即活用できる具体的な情報をお届けします。読み終えたときには、自チームでスクラムを実践するための道筋が明確に見えているはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・スクラム開発の完全ガイド

スクラム開発の全体像

スクラム開発とは、複雑な問題に対して柔軟かつ創造的な解決策を生み出すためのフレームワークです。1990年代にジェフ・サザーランドとケン・シュウェーバーが提唱し、2020年に改訂された「スクラムガイド」が公式定義として世界中で参照されています。スクラムの最大の特徴は、短いスプリントを繰り返すことで早期かつ継続的に価値を届け、変化への対応力を高める点にあります。ウォーターフォール開発のように最初に全仕様を決めてから一気に開発するのではなく、優先度の高い機能から順に作り・試し・改善するサイクルを回すことで、無駄な手戻りを最小化できます。

ウォーターフォール開発は、要件定義→設計→開発→テスト→リリースという工程を順番に進める手法で、各フェーズが完了しなければ次に進めない仕組みです。要件が最初から明確で変更が少ないプロジェクトには適していますが、現代のように市場や顧客ニーズが急速に変わる環境では、リリース時にはすでに仕様が陳腐化しているというリスクを抱えています。それに対してスクラムは、変化を「避けるべき脅威」ではなく「取り込むべき機会」として捉えます。スプリントごとに動くプロダクト（インクリメント）を完成させ、ステークホルダーからフィードバックを受け取り、次のスプリントの計画に反映させるサイクルを繰り返します。この違いは開発スピードにも現れており、スクラムを採用している企業ではウォーターフォールと比べて市場投入までの期間が平均30〜40%短縮されるというデータも報告されています。また、スクラムでは「検査と適応」を重視するため、問題を早期に発見して修正コストを抑えられるという財務的なメリットも大きいといえます。

スクラムガイドでは、スクラムを機能させる3つの経験主義の柱として「透明性」「検査」「適応」を掲げています。透明性とは、スプリントゴールや作業の進捗、プロダクトバックログの状態を全員が可視化できる状態を意味します。検査とは、成果物やプロセスが計画に沿っているかを定期的に確認することで、デイリースクラムやスプリントレビューがその機会として機能します。適応とは、検査の結果に基づいてプロセスや計画を柔軟に変更することです。この3つの柱を支えるのが「コミットメント」「集中」「開放性」「尊重」「勇気」という5つの価値基準です。たとえば「勇気」はチームが困難な問題や複雑な課題に正直に向き合い、正しいことをするための勇気を指します。これらの価値基準が文化として根付いたチームは、スクラムのフォームだけ真似たチームと比べて長期的に高いパフォーマンスを発揮します。スクラムの導入を検討する際には、ツールや手順の整備と同時に、こうした文化的側面への理解も不可欠です。

スクラム開発の3つのロール

スクラム開発では、プロダクトオーナー・スクラムマスター・開発者（開発チーム）という3つのロールが明確に定義されています。それぞれが固有の責任と権限を持ち、相互に補完し合うことでスクラムが機能します。ロールの境界を曖昧にしたまま導入すると責任の所在が不明確になり、意思決定が遅延したりチームのモチベーションが低下したりするため、最初にロールを正確に理解することが成功への第一歩となります。スクラムチームの適切な規模は10名以下とされており、これ以上大きくなると俊敏性が損なわれます。

プロダクトオーナー（PO）は、スクラムチームが開発するプロダクトの価値を最大化することに責任を持つ唯一の人物です。最も重要な職務は「プロダクトバックログの管理」です。プロダクトバックログとは、プロダクトに必要な機能・改善・修正のリストであり、POはそのアイテムに優先順位をつけ、常に最新の状態に保つ責任を負います。「なぜこの機能を作るのか」「どの機能を先に届けることで顧客価値が最大化されるのか」という判断はすべてPOが行います。そのため、POにはビジネス戦略の理解・顧客ニーズの把握・ステークホルダーとの調整能力が求められます。注意すべき点として、POは1人でなければなりません。委員会や複数人の合議でバックログを管理すると、優先順位の決定が遅延しチームが混乱します。また、POとスクラムマスターの兼任はロールの目的が相反するため避けることが推奨されています。国内での一般的な例では、事業部門のプロダクトマネージャーやプロジェクトオーナーがPOを担うケースが多く見られます。

スクラムマスター（SM）は、スクラムチームがスクラムの理論と実践を正しく理解・適用できるよう支援するサーバント型リーダーです。サーバント型リーダーシップとは、指示命令型ではなくチームの障害を取り除き・環境を整えることでチームの自律的な成長を促すリーダーシップスタイルを指します。スクラムマスターの具体的な職務は多岐にわたります。スクラムイベント（スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ）が生産的に進行するようファシリテートすること、チームの妨げになる障害（外部からの割り込み作業・承認フローの遅延・ツールの問題など）を取り除くこと、POがプロダクトバックログを効果的に管理できるようコーチすること、そして組織全体にスクラムを普及させる活動などが挙げられます。スクラムマスターはプロジェクトマネージャーとは根本的に異なり、タスクを「管理」する権限は持ちません。あくまでチームの自己組織化を促し、チームが問題を自分たちで解決できる状態を目指します。スクラムマスターの質がチームのパフォーマンスに与える影響は大きく、優れたスクラムマスターが入ることでチームのベロシティが6ヶ月で3倍になったという事例も報告されています。

スクラムにおける開発者（Developers）は、スプリント内で具体的な作業を行いインクリメントを作成する責任を持ちます。2020年版スクラムガイドでは、かつての「開発チーム」という呼称が「開発者」に変更されており、エンジニアだけでなくデザイナー・QAエンジニア・データアナリストなど、プロダクト開発に関わるすべての専門家を指します。開発者の最大の特徴は「自己組織化」と「クロスファンクショナル」であることです。自己組織化とは、外部から指示されるのではなく自分たちで計画を立て・実行し・改善する能力を指します。クロスファンクショナルとは、設計・開発・テストなどの作業をチーム内で完結できる多様なスキルセットを持つことを意味します。スプリントプランニングではスプリントゴールの達成に向けたタスク計画を自分たちで作り、デイリースクラムでは15分以内に進捗と障害を共有し、スプリント内で動くインクリメントを完成させます。「完成の定義（Definition of Done）」を開発者自身が策定・維持することも重要な責務の一つです。3〜9名程度が理想的なチーム規模とされており、この範囲を超えると意思決定のスピードと一体感が損なわれます。

スクラム開発の進め方：スプリントの流れ

スクラム開発の心臓部は「スプリント」です。スプリントとは1〜4週間の固定された開発サイクルで、この期間内にスプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブという4つのイベントが行われます。スプリントの長さは一度決めたら変えないことが基本で、多くのチームが2週間を採用しています。2週間であれば市場の変化に素早く対応しつつ、チームが集中して成果を出すのに十分な長さを確保できるためです。以下では、スプリントの流れを順を追って詳しく解説します。

スプリントプランニングはスプリントの開始時に行われる計画イベントです。タイムボックスは1週間のスプリントにつき最大2時間が目安で、2週間のスプリントであれば最大4時間となります。スプリントプランニングでは3つのことを決めます。第一は「スプリントゴール」で、このスプリントで達成すべき価値を一文で表現したものです。たとえば「ユーザーが商品をカートに入れて購入完了できる基本購買フローを実装する」といった形で定義します。第二は「スプリントに取り込むプロダクトバックログアイテム（PBI）の選択」です。プロダクトオーナーが優先順位をつけたプロダクトバックログの上位アイテムを、チームのキャパシティ（前スプリントのベロシティを参考に）を考慮しながら選択します。第三は「選択したPBIをどのように実現するかのタスク分解」です。開発者がPBIをより小さなタスクに細分化し、スプリントバックログを作成します。スプリントバックログのタスクはできるだけ1日以内で完了できる粒度に分割することで、デイリースクラムでの進捗確認が容易になります。ストーリーポイントを用いた相対見積もりを採用しているチームでは、プランニングポーカーと呼ばれる合意形成技法でPBIの見積もりを行い、チームの共通認識を形成します。

デイリースクラムはスプリント期間中、毎日同じ時間・同じ場所で開催される15分のイベントです。毎朝定時に開催するチームが多く、立って行うことでダラダラと長引くのを防ぐ「スタンドアップミーティング」の形式を採ることもあります。参加必須なのは開発者のみで、スクラムマスターやプロダクトオーナーはオブザーバーとして参加するのが一般的です。かつてのスクラムガイドでは「昨日やったこと・今日やること・障害」の3点を報告する形式が定番でしたが、2020年版では「スプリントゴールに向けて最善の計画を立てる」という目的に合った形で開発者が自由に形式を選べるようになっています。重要なのは、15分という時間制限を厳守することと、解決策の詳細な議論はデイリースクラムの場ではなく別途「アフターパーティー」として行うことです。デイリースクラムで障害（ブロッカー）が共有された場合、スクラムマスターはその日中に除去に向けて動く姿勢が求められます。毎日15分の短い同期を積み重ねることで、問題の放置による手戻りを防ぎ、スプリントゴール達成率を高める効果があります。実際に、デイリースクラムを導入したチームでは問題発見から解決までの平均時間が従来の3分の1以下に短縮されたという報告もあります。

スプリントレビューはスプリントの最後から2番目に行われるイベントで、スクラムチームとステークホルダーが集まり、完成したインクリメントをデモしながらプロダクトの方向性を検討します。タイムボックスは1ヶ月のスプリントで最大4時間で、2週間であれば2時間が上限の目安です。スプリントレビューはチームの成果発表会でも承認の場でもなく、「インクリメントの検査」と「プロダクトバックログの適応」を目的とした実用的なワーキングセッションです。そのため、PowerPointのスライドを並べた報告会ではなく、実際に動くプロダクトをデモすることが原則です。参加者全員がデモを見ながらフィードバックを提供し、プロダクトオーナーはそのフィードバックをもとにプロダクトバックログを更新します。「この機能は思っていた使い勝手と違う」「競合がこの方向に動いたので優先順位を変えたい」といった声を次のスプリントに反映できるのがスクラムの強みです。スプリントレビューを形骸化させないためには、実際の利用想定ユーザーに近いステークホルダーを招き、率直な意見を引き出す場づくりが重要です。

スプリントレトロスペクティブ（振り返り）はスプリントの最後のイベントで、スクラムチームが自分たちのプロセス・関係性・ツールを振り返り、次のスプリントで改善すべき点を特定します。タイムボックスは1ヶ月のスプリントで最大3時間です。レトロスペクティブでよく使われるフレームワークに「KPT（Keep・Problem・Try）」があります。Keepは続けるべき良い点、Problemは改善が必要な課題、Tryは次のスプリントで試みる新しいアクションを意味します。ほかにも「4Ls（Liked・Learned・Lacked・Longed for）」や「スタート・ストップ・コンティニュー」など、チームの状況に応じたフレームワークを選ぶことが有効です。重要なのは、レトロスペクティブで決まった改善アクションを次のスプリントバックログに組み込み、実際に試みることです。「反省はするが行動は変わらない」というパターンは、レトロスペクティブの効果を台無しにします。心理的安全性の高い環境でメンバーが率直に課題を話せる場を作ることが、スクラムマスターの腕の見せどころとなります。継続的にレトロスペクティブを実施しているチームは、6〜12ヶ月でチームのパフォーマンスが顕著に向上するケースが多く報告されています。

スクラム開発の3つの成果物（アーティファクト）

スクラムには「プロダクトバックログ」「スプリントバックログ」「インクリメント」という3つの成果物（アーティファクト）があります。これらはチームの作業状況と進捗を透明化し、検査と適応を可能にするための情報源です。それぞれの成果物には「コミットメント」と呼ばれる重要な指標が紐付いており、プロダクトバックログには「プロダクトゴール」、スプリントバックログには「スプリントゴール」、インクリメントには「完成の定義」が対応しています。

プロダクトバックログとは、プロダクトの改善に必要なものすべてを順番に並べた動的なリストです。機能要件・非機能要件・バグ修正・技術的な改善など、プロダクトに関するすべての作業候補がここに集約されます。各アイテム（プロダクトバックログアイテム、略称PBI）には説明・順序・サイズ見積もりが含まれ、プロダクトオーナーが継続的に更新・優先順位付けを行います。PBIの記述にはユーザーストーリー形式がよく使われます。「○○のユーザーとして、△△がしたい。なぜなら□□だから」というテンプレートで書くことで、機能を作る目的と価値を明確にできます。たとえば「購買ユーザーとして、購入履歴を確認したい。なぜなら再購入の際に手間を省きたいから」といった形です。プロダクトバックログは常に変化するものであり、新しい情報・ビジネス環境の変化・ステークホルダーのフィードバックを受けてアイテムの追加・修正・削除が繰り返されます。この整理活動を「バックログリファインメント（プロダクトバックログ精緻化）」と呼び、スプリント期間の10%未満の時間を費やすことが推奨されています。

スプリントバックログは、スプリントプランニングで選択されたPBIとその実現方法（タスク）、そしてスプリントゴールで構成されます。スプリントバックログは開発者が所有するものであり、スプリント中に新たな知識が得られた場合は開発者の判断で更新できます。視覚的な管理ツールとしては、「To Do / In Progress / Done」の3列で構成されるかんばんボードが広く使われており、JiraやTrello、Azure DevOpsといったツールがデジタル管理を支援します。インクリメントとはスプリントの成果として生み出された「使用可能な状態の成果物」のことです。インクリメントは「完成の定義（Definition of Done）」を満たす必要があり、この定義はチームが事前に合意して文書化した品質基準です。たとえば「コードレビュー完了・単体テストカバレッジ80%以上・ステージング環境での動作確認済み」といった内容が一般的な完成の定義として設定されます。スプリントの終わりには必ずインクリメントが完成していることがスクラムの大前提で、「80%完成」や「ほぼできた」はインクリメントとして認められません。この厳格さが、スクラムの品質保証の仕組みとして機能しています。ベロシティとは1スプリントで完了したストーリーポイントの合計であり、過去3〜5スプリントの平均ベロシティをもとに次スプリントの計画容量を算出するのが一般的な方法です。

スクラム開発の導入準備と実践ポイント

スクラムの概念を理解したうえで、実際に自組織に導入するには適切な準備と段階的なアプローチが求められます。スクラムは「すべての問題を解決する銀の弾丸」ではありません。スクラムが効果を発揮しやすいのは、要件の不確実性が高い・ビジネス環境の変化が激しい・顧客との継続的なフィードバックループが重要なプロジェクトです。逆に、仕様が明確で変更の少ない製造業の組み込みシステムや法規制に厳格に準拠した開発では、ウォーターフォール型がより適しているケースもあります。ここでは、スクラム導入を成功させるための具体的な準備と実践のポイントを解説します。

スクラム導入の第一歩はチーム編成です。まずプロダクトオーナーを誰にするかを決定します。POはビジネス側と開発側の橋渡し役を担うため、プロダクトに対する意思決定権を持つ人物を選ぶことが不可欠です。開発チームの「誰かPOをやってください」という形での選出は失敗の元になります。次にスクラムマスターを選定します。初めてスクラムを導入するチームでは、スクラムの実践経験を持つ人材を社外から招くか、CSM（認定スクラムマスター）などの資格取得を経た人材に担ってもらうことが理想的です。開発者については、プロジェクトの要件に必要なスキルセット（フロントエンド・バックエンド・インフラ・QAなど）をカバーできるメンバーを揃えます。チームが決まったら、スクラム導入の目的・期待値・基本的なルールについてキックオフセッションを行い、全員の認識を合わせます。この段階でスクラムガイドを全員で読み合わせる「スクラム勉強会」を開催することも有効です。ツール選定も並行して行いましょう。プロダクトバックログとスプリントバックログの管理にはJira Software（中〜大規模チームに適する）、Trello（小規模チームや導入初期に適する）、Notionなどが広く使われています。また、デイリースクラムをオンラインで行う場合はSlackやMicrosoft Teamsとの連携設定も必要です。

第1スプリントは特別な意味を持ちます。チームがスクラムの流れを体で覚えながら、初めてのインクリメントを届けるという二重の課題に挑む場だからです。第1スプリントを成功させるための実践的なポイントをいくつか紹介します。まず、スプリントゴールは達成可能な小さな目標から始めることです。完璧な機能を目指すより「動くものを届けること」を優先し、チームが「やり切った」という達成感を味わうことが次のスプリントへのモチベーションにつながります。プロダクトバックログは第1スプリント前に最低でも2スプリント分のPBIを準備しておきます。作りながら考えるのではなく、先を見越した準備がスプリントのリズムを安定させます。完成の定義（DoD）は最初から完璧を求めず、チームが現実的に守れるシンプルな基準から始めてスプリントを重ねながら改善していきましょう。たとえば最初のDoDとして「コードレビュー完了・テスト合格・ステージング確認済み」の3点だけでも十分です。デイリースクラムは15分の時間制限を徹底することから始めます。最初のうちは脱線して30分以上かかるケースも多いですが、スクラムマスターが積極的にファシリテートして時間を守る習慣を作ることが重要です。スプリント終了後のレトロスペクティブでは「スクラムの進め方自体」を振り返ることを忘れずに実施してください。