「スクラム」を同僚に伝えるためにまとめたもの

はじめに

私は、開発者の役割でスクラムの経験は2.5年ほどあります。スクラムマスターの経験はありませんが、チーム開発におけるスクラムの価値を実感してきました。

この記事では、同僚にスクラムの基本的な概念を伝えるために、私なりに整理した内容をまとめています。

スクラムとは？

スクラムとは、アジャイル開発のフレームワークの1つです。ラグビーのスクラムのようにチーム全体が一つの目標に向かって連携します。
もともとはソフトウェア開発のために考案されましたが、近年ではハードウェア開発や新規事業開発など別の業界でも使われています。

スクラムガイド

スクラムには「スクラムガイド」という原典的な文書があり、よくこれを参照します。数年おきに改定され、スクラムの標準的な定義を提供しています。

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

スクラムの歴史

1986年：野中郁次郎氏と竹内弘高氏が論文「The New New Product Development Game」を発表。効果的な製品開発チームを「スクラム」として表現しました。

1990年代前半：ジェフ・サザーランド氏とケン・シュエイバー氏が、野中・竹内論文の考え方をソフトウェア開発に適用し、スクラムフレームワークを開発しました。

2001年：アジャイルソフトウェア開発宣言が発表され、スクラムはアジャイル開発手法の一つとして位置づけられました。

2010年：最初の「スクラムガイド」が公開され、スクラムの標準的な定義が確立されました。

現在：ソフトウェア開発だけでなく、ハードウェア開発、マーケティング、教育など様々な分野で活用されています。

スクラムの3つの柱

スクラムは3つの柱によって支えられています。

透明性（Transparency）

作業の進行状況や課題、プロセスが関係者全員に見えている状態のことです。プロダクトバックログや進捗状況が明確に共有され、課題がオープンに議論されます。透明性がないと、正しい判断や効果的な改善ができません。

検査（Inspection）

スクラムの成果物やプロセスを定期的に確認することです。スプリントレビューでのプロダクト検査、デイリースクラムでの進捗確認、レトロスペクティブでのプロセス検査などを通じて、変更の必要性を特定します。

適応（Adaptation）

検査の結果として必要な調整や変更を行うことです。フィードバックを受けてプロダクトバックログを調整したり、レトロスペクティブで特定した改善点をプロセスに反映します。

透明性→検査→適応のサイクルを回し続けることで、より良いプロダクトとプロセスを実現します。

スクラムの5つの価値基準

スクラムチームが効果的に機能するためには、以下の5つの価値基準を共有することが重要です。

確約（Commitment）

チームとしてスプリントゴールの達成と、お互いをサポートすることにコミットします。個人の責任ではなく、チーム全体での確約が重要です。

集中（Focus）

今のスプリントと目の前の重要な作業に集中します。スプリント中は計画を変更せず、優先度の高いタスクから取り組み、マルチタスクを避けます。

公開（Openness）

作業や課題をオープンに共有し、さまざまなものに対するオープンマインドを持ちます。進捗状況を隠さず、問題を議論し、新しいアイデアや失敗から学ぶ姿勢を大切にします。

尊敬（Respect）

お互いを能力のある独立した個人として尊敬し合います。異なる意見や専門性を認め、チームメンバーの自律性を尊重し、建設的なフィードバックを行います。

勇気（Courage）

正しいことをし、困難な問題に取り組む勇気を持ちます。技術的課題への挑戦、問題を声に出すこと、既存のやり方を変える提案をすることが含まれます。

以下、スクラムの戦術的な話になっていきますが、あくまで型であり、必ずしも完全に従う必要はないです。スクラムは変化を受け入れる手法なので、プロジェクトやチームの状況によって柔軟に変えていくことも大切です。

スクラムチームにおける3つの役割

スクラムチームのメンバーの役割は3つあります。

• 開発者
• プロダクトオーナー
• スクラムマスター

特に上下関係ではなく、対等な存在です。

スクラムガイド的にはそれぞれ専任で別々の人が役割を担いますが、実務では兼任していることもあります。スクラムマスター兼開発者はよくある組み合わせです。

開発者（Developer）

開発者は、プロダクトインクリメントを作成する責任を持つ人々です。プログラマーだけでなく、デザイナー、テスター、アナリストなど、プロダクト作成に関わる全ての人が含まれます。

開発者の責任

• スプリントバックログの作成と管理

  • スプリントプランニングでタスクを見積もり、計画する
  • スプリント中にスプリントバックログを更新し続ける

• 品質の確保

  • Done（完成）の定義に従って作業を完了させる
  • 継続的にプロダクトの品質を向上させる

• 計画の調整

  • デイリースクラムで進捗を共有し、必要に応じて計画を調整する
  • スプリントゴール達成のために協力し合う

• 自己組織化

  • チーム内で作業を分担し、協力して進める
  • 技術的な判断を自律的に行う

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

プロダクトオーナーは、プロダクトバックログの管理とプロダクト価値の最大化に責任を持つ役割です。

プロダクトオーナーの責任

• プロダクトバックログの管理

  • プロダクトバックログアイテムを作成し、優先順位を決める
  • 要求事項を明確に表現し、開発チームに伝える
  • プロダクトバックログアイテムの受け入れ基準を定める

• ステークホルダーとの調整

  • ビジネス要求を理解し、開発チームに伝える
  • ステークホルダーからのフィードバックを収集し、プロダクトに反映する

• プロダクト価値の最大化

  • ビジネス価値の高い機能を優先する
  • 市場やユーザーのニーズを継続的に調査し、プロダクト戦略に反映する

• 意思決定

  • プロダクトに関する最終的な意思決定を行う
  • スプリントレビューで完成したインクリメントを受け入れるかどうかを判断する

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

スクラムマスターは、スクラムフレームワークが効果的に実施されるよう支援する役割です。サーバントリーダーとして、チームとプロダクトオーナーをサポートします。

スクラムマスターの責任

• スクラムの普及と改善

  • スクラムの理論、実践、ルール、価値を組織に広める
  • スクラムの実装を継続的に改善する
  • チームがスクラムを正しく理解し実践できるよう支援する

• 開発者のサポート

  • 自己組織化されたチームになるよう支援する
  • 障害や阻害要因を取り除く
  • スクラムイベントの進行を支援する

• プロダクトオーナーのサポート

  • 効果的なプロダクトバックログ管理の技法を見つけるのを支援する
  • プロダクトゴールやプロダクトバックログアイテムの理解をチームに促進する

• 組織のサポート

  • スクラムの導入をサポートする
  • 組織内でのスクラム実装を計画し、助言する
  • ステークホルダーとスクラムチームの協力関係を築く支援をする

スクラムマスターが「しない」こと

• チームメンバーに作業を指示すること（チームは自己組織化される）
• プロジェクトマネージャーとしてプロジェクトを管理すること
• チームの成果に対して個人的な責任を負うこと

5（+1）つのスクラムイベント

スクラムでは、決められた5つのイベント（会議体）を通じて、透明性・検査・適応のサイクルを実現します。これらのイベントは必須であり、それぞれに明確な目的があります。

さらに、正式なイベントではありませんが、実際のスクラム運用では「バックログリファインメント」という重要な活動も行われます。

スプリント（Sprint）

スプリントは他の全てのイベントを含む、最も重要なイベントです。固定された期間（通常1〜4週間）内で、動作するプロダクトインクリメントを作成します。

スプリントの特徴

• 固定長：開始前に期間を決めて、途中で変更しない
• 連続性：1つのスプリントが終わったらすぐに次のスプリントが始まる
• 保護された時間：スプリント中は目標を変更せず、集中して作業する
• 成果物志向：必ず動作するインクリメントを完成させる

スプリント中に起こること

• デイリースクラムによる毎日の調整
• 開発作業とテスト
• プロダクトオーナーとの継続的なコミュニケーション
• 必要に応じたスプリントバックログの調整

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

スプリントの開始時に行う計画会議です。「何を作るか」と「どのように作るか」を決めます。

話し合う内容

Part 1: 何を作るか（What）

• プロダクトバックログから今スプリントで取り組むアイテムを選択
• スプリントゴールを設定
• チームの能力（ベロシティ）を考慮した現実的な計画

Part 2: どのように作るか（How）

• 選択したアイテムを具体的なタスクに分解
• 各タスクの見積もりと担当の検討
• 技術的なアプローチの決定

参加者と時間

• 参加者：開発者、プロダクトオーナー、スクラムマスター
• 時間：2週間スプリントの場合、最大4時間

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

毎日同じ時間・同じ場所で行う短い会議です。開発者同士の情報共有と調整のために行います。

話し合う内容

各開発者が以下について共有：

• 昨日やったこと：スプリントゴールに向けて完了した作業
• 今日やること：スプリントゴールに向けて予定している作業
• 障害・課題：進捗を妨げている問題や助けが必要なこと

デイリースクラムのルール

• 時間：15分以内
• 参加者：開発者（必須）、その他は任意
• 目的：進捗報告ではなく、チームの調整
• フォロー：詳細な議論は会議後に別途実施

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

スプリント終了時に、完成したプロダクトインクリメントをステークホルダーに披露し、フィードバックを得る会議です。

実施内容

• デモンストレーション：動作するインクリメントの実演
• フィードバック収集：ステークホルダーからの意見・要望
• プロダクトバックログの調整：フィードバックを反映した優先順位の見直し
• 今後の計画：次のスプリントや将来のリリースについての議論

参加者と時間

• 参加者：スクラムチーム全員 + ステークホルダー
• 時間：2週間スプリントの場合、最大2時間
• 形式：フォーマルなプレゼンテーションではなく、協働的な作業会議

スプリントレトロスペクティブ（Sprint Retrospective）

スプリントレビューの後に行う、チームの振り返り会議です。プロセスやチームワークの改善に焦点を当てます。

話し合う内容

• うまくいったこと：今後も継続したい取り組みや効果的だった方法
• 改善が必要なこと：うまくいかなかった点や課題となった事項
• 次のスプリントでの改善案：具体的な改善策や新しく試したいアプローチ

レトロスペクティブの成果

• 改善アクション：次のスプリントで実施する具体的な改善策
• チームビルディング：メンバー同士の理解と信頼の向上
• 継続的改善：定期的にプロセスを見直す習慣の確立

参加者と時間

• 参加者：スクラムチーム（開発者、プロダクトオーナー、スクラムマスター）
• 時間：2週間スプリントの場合、最大1.5時間
• 重要性：スクラムの「適応」を実現する最も重要な機会

よく使われる手法

• KPT（Keep, Problem, Try）
• Good & New
• スタート・ストップ・コンティニュー
• 4Ls（Liked, Learned, Lacked, Longed for）
• Celebration Grid

これらの5つのイベントは、スクラムの「透明性・検査・適応」のサイクルを実現するための仕組みです。形式的に実施するのではなく、それぞれの目的を理解して効果的に活用することが大切です。

バックログリファインメント（Backlog Refinement）

バックログリファインメントは正式なスクラムイベントではありませんが、効果的なスクラム運用には欠かせない重要な活動です。プロダクトバックログアイテムの詳細化と見積もりを行います。

実施内容と目的

• アイテムの詳細化：曖昧な要求を具体的に定義し、実装可能なサイズに分割
• 見積もり：ストーリーポイントを使った相対的な工数評価
• 受け入れ基準の明確化：完成の条件を具体的に定義

実施方法

• 頻度・時間：スプリント中に週1〜2回、スプリント時間の約10%
• 参加者：開発者、プロダクトオーナー、必要に応じてスクラムマスター
• 対象：次のスプリント以降で取り組む予定のアイテム

メリット

• スプリントプランニングの効率化と見積もり精度の向上
• 技術的課題の早期発見とチーム理解の統一

バックログリファインメントは、スプリントプランニングを円滑に進めるための準備活動です。適切なタイミングと範囲で実施することが重要です。

スクラムの3つの成果物

スクラムでは、3つの成果物（アーティファクト）を通じて作業の透明性を確保し、検査と適応の機会を提供します。これらの成果物にはそれぞれ「確約」が関連付けられています。

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

プロダクトに必要な要求や機能を優先順位順に並べたリストです。プロダクトの「何を作るか」を定義する唯一の情報源となります。

特徴

• 動的：常に変化し続ける生きた文書
• 順序付け：ビジネス価値に基づいて優先順位が決められている
• 詳細度の違い：上位のアイテムほど詳細で、下位のアイテムは大まかな内容

プロダクトゴール（確約）

プロダクトの将来の状態を表す長期的な目標で、チームの方向性を提供し、意思決定の基準となります。

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

スプリント期間中に実装するプロダクトバックログアイテムと、それらを実現するための具体的な作業計画です。

構成要素と管理

• 選択されたPBI、スプリントゴール、作業計画で構成
• 開発者が作成・管理し、必要に応じて随時更新
• スプリントゴールを変えない範囲で調整可能

スプリントゴール（確約）

そのスプリントで達成すべき目標で、チームの統一と優先順位の指針となります。

インクリメント（Increment）

スプリント中に完成したプロダクトバックログアイテムの合計で、動作可能なプロダクトの一部分です。

特徴と価値

• 動作可能・統合済み・テスト済み・リリース可能な状態
• 早期フィードバック、リスク軽減、価値の早期提供を実現

Done（完成）の定義（確約）

インクリメントが完成したと判断するための共通基準です。

例：コードレビュー完了、テスト完了、ドキュメント更新、プロダクトオーナーの承認など

これら3つの成果物とそれに関連する確約は、スクラムチームが共通の理解を持ち、透明性を保ちながら価値のあるプロダクトを作るための基盤となります。

その他のスクラムのキーワード

スクラムを実践する上で知っておくと役に立つ、その他の重要なキーワードをまとめました。

ユーザーストーリー（User Story）

ユーザーの視点から書かれた機能要求のことです。「誰が、何を、なぜ必要とするのか」を明確にします。

基本的な形式：

[ユーザー/役割]として、
[目標/機能]が欲しい、
[理由/価値]のために。

例：

オンラインショッピングの顧客として、
商品を検索する機能が欲しい、
欲しい商品を素早く見つけるために。

ストーリーポイント（Story Point）

プロダクトバックログアイテムの相対的な大きさや複雑さを表す単位です。時間ではなく、難易度や労力を相対的に評価します。

特徴：

• 相対的な見積もり（絶対的な時間ではない）
• チーム固有の基準
• フィボナッチ数列（1,2,3,5,8,13...）を使うことが多い
• プランニングポーカーで決めることが多い

ベロシティ（Velocity）

チームがスプリントで完成させることができるプロダクトバックログアイテムの量を表す指標です。過去のスプリントの実績から計算します。

使い方：

• 将来のスプリント計画の参考にする
• リリース計画を立てる際の基準にする
• チーム間の比較には使わない（重要）

受け入れ基準（Acceptance Criteria）

プロダクトバックログアイテムが「完成」したと判断するための具体的な条件です。ユーザーストーリーごとに定義されます。

例：

• ユーザーが商品名で検索できること
• 検索結果が価格順で並び替えられること
• 検索結果が5秒以内に表示されること

ステークホルダー（Stakeholder）

プロダクトに関心を持ち、その結果に影響を受ける、または影響を与える可能性のある関係者のことです。

主なステークホルダー：

• 顧客・ユーザー：実際にプロダクトを使用する人々
• 経営陣：プロダクトの戦略的方向性を決定する立場の人
• 営業・マーケティング：プロダクトを販売・宣伝する部門
• サポート部門：プロダクトのサポートを提供する部門
• 法務・コンプライアンス：法的要件や規制に関わる部門

スクラムにおける関わり：

• スプリントレビューに参加してフィードバックを提供
• プロダクトオーナーを通じて要求や優先順位を伝える
• プロダクトの価値と方向性について継続的に対話

参考文献

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

https://monstar-lab.com/dx/solution/about-scrum/