スクラム総合ガイド

スクラムは、チームワーク、責任感、明確に定義された目標への段階的進歩を重視するプロジェクト管理フレームワークである。その出発点は単純な前提である：見えるものや知っているものから始めること。その後、進捗を追跡し、必要に応じて調整する。

スクラムの三本柱

スクラムは経験主義に基づいている。経験から知識が得られ、意思決定は既知の事実に基づくべきであるという主張である。この三本柱がスクラムを統合している。

なぜスクラムなのか？

スクラムは機能を段階的に提供するのに対し、ウォーターフォールはフェーズごとのみ提供する。従来のウォーターフォール開発は、段階的で順次的なプロセスであり、価値はプロジェクトの終了時まで提供されない。スクラムは、大きな将来のリリースに注力するのではなく、通常2〜4週間ごとに新しい機能を提供することで、このモデルを変革する。

スクラムは複雑な作業を扱いやすい部分に分解し、大規模な組織を小さなチームに分けることで、影響力のあるプロジェクトを短期間で完了可能な一連の時間制限付きのスプリント.

反復的かつ段階的な開発を通じて、企業は顧客が本当に必要とする製品やサービスをより迅速かつ効率的に提供できる。スクラムでは、各スプリントの終了時に顧客のフィードバックを受け入れて統合できるため、成果物が仮定ではなく現実の使用状況に基づいて形成される。これにより、顧客や主要ステークホルダーを積極的に関与させやすくなる。

アジャイル vs スクラム

アジャイルは、SDLC全体にわたり開発とテストの継続的な反復を可能にする実践である。アジャイルは製品をより小さく、管理しやすいコンポーネントに分割する。スクラムは、反復的かつ段階的なアジャイルソフトウェア開発プロセスの一つにすぎないであり、最も短い時間でビジネス価値を提供することに集中できる。

スクラムは、プロジェクトの初期段階で変化する可能性がある、または未知の要件を扱うことが多い。スクラムの特徴は次の通りである：

• 軽量
• 理解しやすい
• 習得が難しい

スクラムの利点

スクラムが組織、チーム、製品、個人にもたらす利点は以下の通りである：

1. より高い品質：ビジョンや目標を達成するためのフレームワークがある。スクラムは継続的なフィードバックと可視性を提供し、品質を可能な限り高める。スクラムは、次の実践を通じて品質を確保する：
2. 市場投入までの時間短縮：スクラムは、従来の方法よりもエンドユーザーに価値を提供する速度が30％～40％速いことが実証されている。
3. 投資利益率（ROI）の向上：市場投入までの時間短縮が、スクラムプロジェクトがより高いROIを達成する主な理由である。早期の収益と利益の蓄積は、より高い総収益を意味する。これは、ネット・プレゼント・バリュー（NPV）計算の基本原則に基づいている。
4. チームのモラル向上：満足感があり、関与している人々と働くことは、満足感があり生産的である。自己管理により、通常マネージャーや組織が行う意思決定がスクラムチーム メンバー。
5. より強力なチーム協働：スクラムチームがプロジェクトと製品を所有している場合、優れた成果を達成できます。スクラムチームは、より高い関与とコミュニケーションを通じて協働し、品質とプロジェクトのパフォーマンスを向上させます。

スクラムフレームワーク

スクラムはシンプルです。厳密に結びついた命令の集合ではありません。スクラムはメソドロジーではありません。スクラムは経験主義の科学的方法を体現しています。手続き的でアルゴリズム的なアプローチを、ヒューリスティックな方法に置き換え、人間や自己組織化を尊重することで、予測不可能性に対処し、複雑な問題を解決します。以下の図は、ケン・シュワーバーとジェフ・サザーランドの著書『スクラム：時間の半分で2倍の仕事を達成するアート』で述べられている通り、スクラムの実践を示しており、計画からソフトウェアの提供までのプロセスを描いています。

スクラムプロセスの構成要素

スクラムフレームワーク自体はシンプルです。少数の一般的なガイドラインと少数のルールを定義しています。役割, 成果物、およびイベントしかし、これらの各構成要素は特定の目的において不可欠であり、フレームワークを成功裏に使用する上で必須です。

スクラムフレームワークの主な構成要素は次のとおりです：

• スクラムの役割: スクラムマスター, プロダクトオーナー、およびスクラムチーム
• 成果物: スプリントバックログ, プロダクトバックログ, バーンダウンチャート、ログなど
• スクラムイベント: スプリント計画、スプリントレビュー、デイリースクラム、スプリントリトロスペクティブ、など
• スプリント

以下の図は、スクラムフレームワークの主要な要素を示しています。このプロセスは、スクラムプロセスキャンバスビジュアルパラダイムのアジャイルソフトウェアツールから

スクラムの役割

組織がスクラムを採用する際、まず理解すべきことは、スクラムの役割が従来のプロジェクトマネジメントの役割とどのように異なるかです。スクラムには主に3つの役割しかありませんが、それらが一般的な職務名と自動的に一致するわけではありません。それぞれの役割について簡単に定義を始めましょう：

プロダクトオーナー

プロダクトオーナーは、ビジネスまたはユーザーコミュニティを代表するスクラムの役割です。ユーザーと密接に協力して、製品バックログ内の機能を定義します。主な責任は以下の通りです：

• 製品のビジョンと戦略（短期および長期の目標を含む）を定義すること；
• 製品またはサービスに関する知識を提供または収集すること；
• 顧客のニーズを理解し、開発チームに伝えること；
• 製品またはサービスの要件を収集し、優先順位を付け、管理すること；
• 製品またはサービスの予算管理（収益性を含む）を担当すること；
• 製品またはサービスのリリース日を決定すること；
• 開発チームと毎日質問に答え、意思決定を行うこと；
• スプリントで完了した作業を受け入れたり拒否したりすること；
• 各スプリントの終了時にチームの主要な成果物を提示すること；
• 製品バックログの管理。

スクラムマスター

スクラムマスターはアジャイル開発チームのファシリテーターです。スクラムはアジャイルの原則に基づいて、チームが自己組織化し、迅速に適応できるようにします。スクラムマスターは情報の流れを管理します。主な責任は以下の通りです：

• チームがスクラムの価値観と実践を守れるようにコーチとして支援すること；
• 障害の除去を支援し、チームを外部の干渉から守ること；
• チームとステークホルダーの間の良好な協力を促進すること；
• チーム内での常識と透明性を促進すること；
• チームを組織的な混乱から守ること。

スクラムチーム

スクラムチーム（開発チームとも呼ばれる）は、製品またはサービスを提供するために必要なすべての技術的スキルを collectively 持つ3〜9人のメンバーで構成される。彼らはスクラムマスターの直接的な指導を受けるが、従来の意味での管理は受けない。彼らは自己組織的で、クロスファンクショナルであり、すべての必要な作業を完了する責任を負わなければならない。

開発チームは、各スプリントの終了時に、出荷可能な製品のインクリメントを提供する責任を負う。これには分析、設計、開発、テスト、技術文書作成が含まれる。スクラムチームの重要な特徴には以下が含まれる：

• 自己組織化：すべてのチームメンバーが、割り当てられた作業を完了するために自分の仕事を管理する。アジャイルスクラムでは、チームリーダーやラインマネージャーは存在しない。全員が自らの活動を推進し、チームの成功に貢献するだけのコミットメントが必要である。一人が失敗すれば、全員が失敗する。
• クロスファンクショナル：すべてのチームメンバーが、高品質で出荷可能な製品を提供するために必要なすべての知識とスキルを備えている必要がある。専門家は指導のために招かれることがあるが、その目的はスキルギャップを埋めるためにチームに知識を伝えることのみである。
• プロダクトオーナーにはビジネスビジョンが必要：プロダクトオーナーは顧客の声を代表し、そのニーズをスクラムマスターおよび開発チームのための実行可能な項目に翻訳しなければならない。これは通常、フルタイムの役割である。
• スクラムマスターはラインマネージャーではない：彼らは開発チームのコーチングを助け、進捗を妨げる障害を取り除く。

スクラムアーティファクト

スクラムアーティファクトは、チームに入っている作業および現在進行中の作業を定義するのに役立つ。ユーザー・ストーリー、リリースバックログ、バーンダウンチャートなど、より多くのアーティファクトもあるが、ここではコアとなる3つに焦点を当てる。

プロダクトバックログ

プロダクトバックログは、製品チームが必要とするか期待する機能を表す、優先順位付けされたユーザー・ストーリーのリストである。通常、プロダクトオーナーがこのリストを管理する。

スプリントバックログ

スプリントバックログは、現在のスプリント中に完了する予定の選択された項目のセットを含む。スプリントバックログとプロダクトバックログの関係について注目すべき2つのポイントがある。
1. チームがスプリントに追加する内容を決定する。したがって、チームはこれらの項目の所有権を持ち、それらの提供責任を負う。
2. プロダクトバックログの項目をスプリントバックログに移動する前に、チームはすべて必要な情報を確保していることを確認しなければならない。通常、項目を追加できる前に満たすべき基準のチェックリストをチームが定義する。

プロダクトバックログ vs スプリントバックログ
スプリントバックログは、スプリント中にスクラムチームが完了することを約束するタスクのリストである。スプリント計画会議では、チームは通常、ユーザー・ストーリーの形でいくつかのプロダクトバックログ項目を選択し、それぞれを完了するために必要なタスクを決定する。スプリントバックログは、スクラムチームがスプリント中に完了することを約束するタスクのリストである。スプリント計画会議では、チームは通常、いくつかのプロダクトバックログ項目をユーザー・ストーリーの形で選択し、それぞれを完了するために必要なタスクを決定する。以下に示す通り：

バーンダウンチャート

バーンダウンチャートは、時間経過に伴う残作業のグラフィカルな表現である。残作業（またはバックログ作業）は縦軸に、時間は横軸に表示される。これは残っている作業を追跡するための進行チャートである。すべての作業がいつ完了するかを予測するために使用できる。スクラムのようなアジャイルソフトウェア開発手法でよく使われるが、時間経過に伴う測定可能な進捗があるすべてのプロジェクトに適用可能である。残作業は時間またはストーリーポイント.

スクラムイベント

コミュニケーションが鍵です！スクラムはすべての側面における透明性（スクラムの柱 #1）に依存しています。この基本原則を踏まえて、フレームワークは、他の二つの柱である「検査」と「改善」を確保するために、以下の表に示すように、いくつかの重要なイベントを中心に構築されています。

イベント	検査	改善
スプリント計画	製品バックログ （コミットメント：リトロスペクティブ) （定義：完了)	スプリント目標 予測 スプリントバックログ
デイリースクラム	スプリント目標への進捗	スプリントバックログ デイリープラン
スプリントレビュー	製品インクリメント 製品バックログ（リリース） 市場ビジネス状況	製品バックログ
スプリントリトロスペクティブ	チーム協働 技術的およびエンジニアリング実践 完了の定義	具体的な改善

注記：各スプリントにおいて、スクラムでは以下の通りに5つの重要な会議が存在します。

スプリント計画

すべてのスプリントは計画から始まります。チームは、スプリントの一部として何を提供するかを決定し、コミットする必要があります。可能な項目は常にスプリントバックログから取り出され、以下に示すように行われます。

ここがスクラムマスターが輝く場所です。プロダクトオーナーはビジネス／顧客の観点から何が必要かを定義し、スクラムチームは自分が提供できると信じるものを決定し、スクラムマスターは両者の最適なマッチングを確保します。

デイリースクラムミーティング

チームがスプリントの成果物として何を提供するかをコミットすると、デイリースタンドアップを開催します。主な目的は、すべてのチームメンバー（および観察者もいる場合）が作業の状況と進捗を完全に理解できるようにすることです：

• 昨日は何をしましたか？
• 今日何をしますか？
• 何が私の進捗を妨げていますか？

この毎日の更新はチームに即時のフィードバックを提供します。会議は短時間で、1人あたり3分以内です。

注意：観察者は観察のために存在します。スクラムマスターは外部および内部の干扰を最小限に抑える必要があります。

スプリントレビュー会議

スプリントレビュー（デモ）はスプリントの終了時に開催され、インクリメントの検査を行います。チームは完了定義に基づいてインクリメントをデモし、スプリント目標に焦点を当てます。プロダクトオーナーは提供されたインクリメントをレビューし、受け入れます。

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

スプリントリトロスペクティブは通常、スプリントの最後の活動です。多くのチームはスプリントレビューの直後に実施します。全チームメンバー（スクラムマスターおよびプロダクトオーナーを含む）が参加すべきです。1時間程度のリトロスペクティブで十分です。この会議ではチームが次のように振り返ることができます：

1. 何を始めるべきですか？
2. 何をやめるべきですか？
3. 何を継続すべきですか？

目的は、チームの効率を継続的に向上させることです。

バックログの精査

プロダクトバックログをプロジェクトのロードマップと考えてください。チームが協働する中で、プロジェクトを完了するために必要なすべての項目のリストを作成・更新し、すべての必要な要件が満たされていることを確認します。

スプリント

スクラムフレームワークでは、スクラムプロダクトバックログからの項目を実装するために必要なすべての活動が、スプリント内（「イテレーション」とも呼ばれる）で実施されます。スプリントは常に短いもので、通常2〜4週間です。各スプリントは、以下に示すように明確なプロセスに従います。

前述の通り、プロダクトバックログ内の項目は優先順位付けされ、スプリントバックログに選定されます。スプリントには少数の主要な項目しか含まれません。単一の項目について作業量を過小評価すると、スプリントに大きな影響を及ぼす可能性があります。大きな項目はしばしば見積もりや理解が難しくなるため、スプリント失敗のリスクが高まります。経験豊富なスクラムチームは、複雑または大きな項目（例：ユーザー機能やエピック）を、より小さなユーザー ストーリー（あるいはさらにタスクやサブタスクに分ける）ために時間と労力を費やします。

エピック

エピックは大きな作業量を捉えます。本質的に「大きなユーザー ストーリー」であり、多数の小さなストーリーに分解できます。エピックの完了には複数のスプリントを要する場合があります。したがって、開発でエピックを使用する際には、小さなユーザー ストーリーに分解する必要があります。

エピックはプロジェクトライフサイクルの初期段階で導入されます。高レベルで、ほぼマーケティング志向の機能的ポイントです。

大きなストーリーを「エピック」と呼ぶことで、その規模を伝えることができます。映画を例にすると、もし私が「アクション・アドベンチャー」と言うと、何を期待できるかのイメージが湧きます——たとえば自動車追跡や銃撃戦など。同様に、ストーリーを「エピック」と呼ぶことで、追加の文脈を伝えることもあります。

ユーザー ストーリー

ユーザー ストーリーは、製品要件やビジネスケースの簡潔な記述です。読み手がソフトウェアが何をすべきかを理解できるように、通常は簡単な言葉で書かれます。プロダクトオーナーがストーリーを作成し、その後スクラムチームメンバーがストーリーを1つ以上のスクラムタスクに分割します。

ユーザーストーリーは通常、最終ユーザーが見える機能です。次の形式に従います。「私は[何かをしたい]ので、[目標を達成できる]ようにしたい。」顧客／ユーザーに価値を提供します。これは顧客の製品要件です。

例：「顧客として、来年の予算計画を立てるために、昨年の購入履歴を確認できるようにアカウントを作成したい。」

タスク

一方、タスクはより技術的なものです。タスクはコード、設計、テストデータの作成、自動化などに関わることが多いです。これらは通常、個人の責任です。タスクはユーザーストーリー形式で書かれません。より技術的な内容です。

例：「Material Designを用いてUIの角度を評価する」または「アプリケーションをApp Storeに提出する。」