スクラム開発ガイド

スクラムとは？

スクラムは、複雑な問題に対して価値の高いプロダクトを創造的・適応的に届けるための軽量フレームワークです。

スクラムの3つの柱は、透明性（Transparency：作業状況・進捗をチーム全体で見える化する）、検査（Inspection：成果物・プロセスを定期的に確認・評価する）、適応（Adaptation：問題を発見したら素早く改善・軌道修正する）です。

短いサイクル（スプリント）を繰り返すことで継続的に学習・改善します。ウォーターフォール（従来型）との大きな違いは、スプリント内で「要求 → 設計 → 実装 → テスト」をすべて行い、毎回「動くもの」を作る点です。1スプリントは1〜4週間とし、延長しません。

開発は、スプリント1・スプリント2…と繰り返しながら、それぞれのスプリントの終わりに「インクリメント」（動く成果物）を積み上げていく流れになります。

スクラムの3つの役割（ロール）

スクラムチームは以下の3つの役割で構成されます。これらをまとめて「スクラムチーム」と呼びます。

プロダクトオーナー（Product Owner / PO）― 「何を作るか」を決める人

・プロダクトの価値を最大化することに責任を持つ

・プロダクトバックログ（機能の優先リスト）を管理・優先順位付けする

・開発者に機能の内容を説明し、理解してもらう責任がある

・ステークホルダー（顧客・社内関係者）と調整・交渉・ヒアリングを行う

開発者へ：POの説明に不明点があれば必ず確認する。自分で仕様を推測して進めない、という点が重要です。

スクラムマスター（Scrum Master / SM）― 「どう進めるか」を支援する人

・スクラムが正しく実践されるようにサポートする

・チームの障害（作業を妨げる問題）を取り除く

・会議のファシリテーター（進行役）を担う

・チームに細かい指示を出すのではなく、チームが自律的に動けるよう気づきを与える役割

開発者（Developers）― 「どう作るか」を決めて実装する人々

・設計・実装・テストを担当する

・スクラムでは「プログラマー」「テスター」などの厳密な区分けはなく、1人が複数の役割を担う（多能工）

・スプリントバックログのタスクを完了させ、プロダクトの価値を高めることに責任を持つ

・プロジェクト管理（計画・見積もり・品質管理・進捗管理）もチームで自律的に行う

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

プロダクトバックログ（全体の要求リスト）から選択してスプリントバックログ（今回やること）を作り、それを完成させることでインクリメント（動く成果物）になる、という流れです。

プロダクトバックログ（Product Backlog）は、プロダクトに必要なすべての機能・改善・修正を優先順位順に並べたリストです。プロダクトオーナーが管理します。ストーリー（機能要求）はユーザーにとっての価値がわかる言葉で書きます。開発が続く間、常に更新・維持される「生きたリスト」です。

スプリントバックログ（Sprint Backlog）は、今のスプリントで実施するタスクのリスト（スプリントプランニングで作成）です。プロダクトバックログから選んだアイテムをタスクに分割したもので、タスクは通常2〜8時間程度で見積もれる単位に分解します。ユーザー観点と開発者観点の両方でタスクを切り出します。

インクリメント（Increment）は、1スプリントで完成した動作するプロダクトの成果物です。スプリント終了時点で「リリース判断可能」な状態でなければなりません。各スプリントのインクリメントは積み上げられ、プロダクトが成長していきます。

スプリントの流れ（1回の開発サイクル）

スプリント（1〜4週間）の中では、①スプリントプランニング → ②開発作業（③デイリースクラムを毎日実施）→ ④スプリントレビュー → ⑤レトロスペクティブ、という流れを繰り返します。⑥バックログリファインメントはスプリント中に随時実施します。

各イベントの詳細

① スプリントプランニング（Sprint Planning）の目的は今スプリントのゴールとタスクをチームで決めることです。参加者はスクラムチーム全員、時間はスプリントが1週間なら最大2時間、1ヶ月なら最大8時間です。成果物はスプリントゴールとスプリントバックログです。

手順は次の通りです。①POが優先順位に従ってプロダクトバックログアイテムを提示する ②チーム全体でアイテムを合意する ③開発者が見積もりを行い、今スプリントに入れる範囲を決める ④開発者がタスクに分割し、スプリントバックログを作成する。

② 開発作業（スプリント内の開発）では、優先順位が高いタスクから順番に「動くもの」を仕上げていきます。設計→製造→テストという工程ごとの区切りではなく、1つの機能を最初から最後まで完成させます。完了したタスクは既存コードと結合し続け、常に動く状態を保ちます。

③ デイリースクラム（Daily Scrum）の目的はチーム全員が状況を共有し、障害を取り除くことです。参加者は開発者（SMも参加可）、時間は毎日15分、形式は立ったまま（スタンドアップミーティング、朝会とも呼ぶ）で行います。

各自が共有する3つのことは、①昨日やったこと（スプリントゴールに貢献したか）②今日やること（スプリントゴールに向けて何をするか）③障害・ブロッカー（作業を妨げていることはあるか）です。

ポイント：小さな問題でも一人で抱え込まず、必ずデイリースクラムで共有することが重要です。

④ スプリントレビュー（Sprint Review）の目的は完成した成果物をPOとステークホルダーに見せてフィードバックを得ることです。参加者はスクラムチーム＋ステークホルダー、時間はスプリントが1ヶ月の場合、最大4時間です。

動くプロダクトのデモンストレーションを行い、対等な立場で話し合い、フィードバックを相互に受けます。プロダクトゴールに対する進捗の確認や今後の方向性を話し合います。

⑤ スプリントレトロスペクティブ／振り返り（Retrospective）の目的はチームのプロセスを振り返り、次スプリントの改善策を決めることです。参加者はスクラムチーム全員、時間はスプリントが1ヶ月の場合、最大3時間です。

話し合う3つのこと（KPT形式）は、Keep（うまくいったこと → 次も続ける）、Problem（うまくいかなかったこと → 解決策を考える）、Try（次のスプリントで試すこと）です。

重要：レトロスペクティブで決めた改善策は必ず次スプリントで実行します。話し合って終わりにしないことがポイントです。

⑥ バックログリファインメント（Backlog Refinement）は、プロダクトバックログの内容を詳細化・見積もり・優先順位変更する継続的な作業です。POと開発者が協力して行い、スプリント中に随時実施します（独立したイベントではなく継続的な活動です）。

スプリントの中の開発作業

タスクボード（かんばんボード）の活用として、GitHub Projects のイシューで管理する場合の状態遷移は、To Do（未着手）→ In Progress（作業中）→ In Review（レビュー中）→ Done（完了）です。各メンバーが自分のタスクの状態を毎日更新し、デイリースクラムの際にボードを見ながら状況を共有します。

タスクの分解ルールは次の通りです。

・1タスク = 1〜2日以内 … 大きすぎるタスクは必ず分割してから着手する

・完了基準を明確に … 「完了」とは何かをタスク作成時に定義する

・技術調査は別タスク … 技術的に不確かな部分は「調査タスク」として分離する

完了の定義（Definition of Done）

「タスクが完了した」と判断するための共通基準です。チーム全員がこの基準に合意し、常に認識できる状態にしておく必要があります。

DoDチェックリストの例：

・コードレビューが完了している（別の開発者が確認済み）

・ユニットテストを作成し、すべてパスしている

・機能テストが完了し、要件通りに動作することを確認した

・既存機能を壊すバグが発生していないことを確認した

・READMEや関連ドキュメントを更新した

・プロダクトオーナーが確認・承認した

「コードを書いた」だけでは完了ではありません。DoDの全項目を満たして初めて「完了」です。

オフショアチームへの重要なポイント

コミュニケーションでは、毎日デイリースクラムに参加し、進捗と障害を必ず共有すること、小さな疑問でもすぐに聞くこと（「たぶん合っている」で進めない）、問題を一人で抱え込まず早めにエスカレーションすることが大切です。

タスク管理では、タスクは必ず1〜2日以内で完了できる単位に分解し、タスクの状態を毎日GitHub Issuesで更新し、着手前に完了基準（DoD）を確認します。

仕様・設計の扱いでは、仕様が不明な点は絶対に自分で推測・決定せず、不明点はGitHub Issuesのコメントまたはデイリースクラムで必ず確認し、確認した仕様はイシューのコメントに記録しておきます（口頭のみにしない）。

完了の基準では、DoDを全て満たしてからイシューをクローズし、「動いているように見える」は完了ではなくテストで確認し、スプリント終了直前に大量のタスクを完了にしない（品質が下がる）ようにします。

振り返りと改善では、レトロスペクティブで出た改善点は次スプリントで必ず実行し、同じ問題を繰り返さないよう根本原因まで考え、改善は大きくなくてよく小さな改善を毎スプリント積み重ねます。

参考：ウォーターフォールとスクラムの違い

開発サイクルは、ウォーターフォールが長期間（数ヶ月〜年単位）、スクラムが短期間（1〜4週間）です。要求の変更は、ウォーターフォールが困難（後工程での変更はコスト大）、スクラムが柔軟に対応可能です。成果物の確認は、ウォーターフォールが最後にまとめて確認、スクラムが毎スプリント確認です。役割分担は、ウォーターフォールが厳密（SE/PG/テスターなど）、スクラムが柔軟（多能工）です。問題の発見は、ウォーターフォールが後工程で発覚しやすい、スクラムが早期に発見・対処です。PM的作業は、ウォーターフォールがプロジェクトマネージャーが集中管理、スクラムがチーム全員で自律的に管理です。

重要な考え方：スクラムでは「完璧なものを一度に作る」のではなく、「小さく作って早くフィードバックを得て改善する」を繰り返します。