アジャイルとスクラム、結局なにが違うの? — 開発現場で使える基礎まとめ

はじめに

本記事では、アジャイルとスクラムの関係性を整理しつつ、現場で動くために必要な最小限の知識をまとめます。これからチームに参画する方や、独学で身につけた知識をアップデートしたい方向けです。

アジャイルとは何か

一言でいうと

アジャイル(Agile)は特定の手法ではなく、ソフトウェア開発の「考え方」「価値観」 です。2001年に17人のソフトウェア開発者が集まり発表した「アジャイルソフトウェア開発宣言(Agile Manifesto)」がその起点になっています。

4つの価値観

アジャイル宣言では、左側より右側に価値を置く、と表現されています。

ここで注意したいのは、「左側に価値がない」とは言っていない点です。両方価値があるが、右側により重きを置くというのがアジャイルの姿勢です。

12の原則（抜粋）

宣言の背景には12の原則があります。全部覚える必要はありませんが、特に頻出するものを3つだけ紹介します。

1. 顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供する
2. 要求の変更は開発のどの段階でも歓迎する
3. 動くソフトウェアを2〜3週間から2〜3ヶ月のできるだけ短い間隔でリリースする

「短いサイクルで動くものを出す」「変更を歓迎する」——この2点がアジャイルの核と言ってよいです。

スクラムとは何か

アジャイルとの位置関係

ここがよく混同されるポイント。図にするとこうなります。

アジャイル（考え方・価値観）
├── スクラム（フレームワーク） ← 最も普及
├── XP（エクストリーム・プログラミング）
├── カンバン
└── その他...

つまり、スクラムはアジャイルを実践するための具体的なフレームワークの1つです。アジャイル ≠ スクラムであり、スクラム ⊂ アジャイル と考えるのが正しい関係です。

スクラムの3-5-3

スクラムは「3つの説明責任(Accountabilities)、5つのイベント、3つの作成物」で構成されます。2020年版では旧来の「ロール」という語が「説明責任」に変わり、各作成物にはコミットメントが付加されました（プロダクトバックログ → プロダクトゴール、スプリントバックログ → スプリントゴール、インクリメント → 完成の定義）。

3つの説明責任

• プロダクトオーナー（PO）: プロダクトの価値を最大化する責任者。何を作るかの優先順位を決める。
• スクラムマスター（SM）: スクラムが正しく機能するよう支援する。チームのコーチであり、障害を取り除く人。
• 開発者（Developers）: 実際にプロダクトを作る人たち。エンジニア、デザイナー、QAなど。

5つのイベント

3つの作成物

• プロダクトバックログ: やりたいこと全部の優先順位付きリスト。POが管理。
• スプリントバックログ: 今スプリントでやることのリスト。開発者が管理。
• インクリメント: スプリントで完成した動くプロダクト。

スプリントのサイクル

[プランニング] → [開発 + デイリー × N日] → [レビュー] → [レトロ] → 次スプリントへ

このサイクルを固定の期間で繰り返すのがスクラムの基本リズムです。

具体例で深掘りするスクラム

ここからは、抽象的な説明だけだとピンとこない部分を、架空のプロダクトを題材に踏み込んで見ていきます。

ロールを深掘り

プロダクトオーナー（PO）— 田中さんの1日

POの仕事は「優先順位を決める」と一言で言われがちですが、実際にはもっと泥臭い。FitLogチームのPO・田中さんの典型的な動きはこうです。

• 午前: 直近リリースの利用データを見て、離脱率の高い画面を特定。CSチームから上がってきた要望を整理する
• 午後: ステークホルダー（マーケ、経営層）とミーティングし、Q3の事業目標とプロダクトゴールのすり合わせ
• 合間: 開発者からの「この仕様、こっちの方が実装が軽いけどどうですか？」という相談に即レス
• 週次: バックログをリファインメントし、上位アイテムの受け入れ条件を具体化

ポイントは、POは「ユーザー価値」と「ビジネス価値」の両方を背負っているということ。「機能Aと機能B、どちらを先に作るか？」の判断軸を持つために、ユーザーリサーチもデータ分析も経営会議もこなす必要があります。

スクラムマスター（SM）— 鈴木さんの介入例

SMは「会議のファシリテーター」と思われがちですが、本質はチームの自律を引き出すコーチです。FitLogチームのSM・鈴木さんが実際にやっていることを並べてみます。

• デイリースクラムで開発者Aが毎日「昨日もこのバグ調査してました」と言っているのに気づき、1on1で「困ってる？助けが必要？」と声をかける
• POと開発者の間で「仕様の解釈」が毎回ズレているのを観察し、レトロでこの問題を議題に上げる
• 他部署から「緊急対応お願い！」と直接開発者に依頼が飛んできているのを止めに入り、「依頼はPO経由で」というルールを再徹底する
• チームが慣れてきたタイミングでスクラムイベントの形を見直す提案をする（例: デイリーの形式を変える）

SMは何もしないように見えて、実はチームの環境を整え続けているロールです。「最近SMが暇そうだ」というのは、チームが自律的に回り始めている良い兆候だったりします。

開発者（Developers）— 「自己管理型」とは何か

2020年版スクラムガイドでは、スクラムチーム全体が**自己管理型（self-managing）**とされています。なかでも開発者の自己管理は具体的に次のような形で現れます:

• スプリントで「何を」やるかはPOと相談して決めるが、「どうやって」実装するかは開発者が決める
• タスクを上から割り振られるのではなく、自分たちで取りに行く
• 見積もりは開発者が行う（POや上司ではない）
• 品質基準（完成の定義）を守る責任は開発者にある

iOS担当の佐藤さんが「このAPI、レスポンスが遅くてUXが悪い」と気づいたら、バックエンド担当の山田さんに直接相談して改善する——という横の連携が自然に発生するのが、健全なスクラムチームです。

イベントを深掘り

スプリントプランニング — 実際の進行例

FitLogチームの2週間スプリントのプランニングは、こんな流れで進みます（所要時間約4時間）。

Part 1: なぜこのスプリントは価値があるのか？（スプリントゴールの設定）

PO 田中: 「今スプリントのゴールは『ユーザーが過去30日のトレーニング推移をグラフで確認できる状態にする』にしたいです。先月のリサーチで、継続率の高いユーザーほどグラフ機能を使っているとわかったので」

スプリントゴールは機能リストではなく、達成したい状態で表現するのがコツ。

Part 2: このスプリントで何ができるか？（バックログアイテムの選択）

POが提示した上位アイテムについて、開発者がプランニングポーカーで見積もり、自分たちのキャパシティに収まる量を選ぶ。

Part 3: 選んだ仕事をどう完成させるか？（タスク分解）

選んだバックログアイテムを、開発者が具体的なタスクに分解する。

開発者 佐藤: 「『グラフ表示画面』のアイテムを分解すると、API設計、iOS実装、Android実装、E2Eテスト、の4タスクになります。API設計を先にやらないと並列化できないので、初日は山田さん集中で」

デイリースクラム — Good vs Bad

❌ よくないデイリー（報告会化）

「昨日はAPIの実装をしました。今日はテストを書きます。困ってることはないです」
「私は画面実装を進めました。今日も続きをやります」
……（15分淡々と続く）

これは進捗報告であって、検査と適応になっていません。

✅ 良いデイリー（検査と適応）

開発者 佐藤: 「グラフ描画ライブラリ、想定より動作が重いです。スプリントゴール達成のために、別ライブラリへの切り替えを検討したい。プランニング後の追加調査で2時間欲しいです」
開発者 山田: 「それなら自分のAPI実装を1日前倒ししてサポートに入れます」
開発者 佐藤: 「じゃあ詳細はこの後30分で2人で詰めましょう」

スプリントゴールに対して今日どう動くかを再計画する場、というのが本来の姿です。

スプリントレビュー — デモだけじゃない

レビューでよくある誤解は「動くものをデモして終わり」というもの。本来のレビューはステークホルダーを巻き込んだ対話の場です。

• 開発者が動くインクリメントをデモする
• ステークホルダーが触ってフィードバックする
• 「市場の状況が変わった」「想定ユーザーの反応が違った」など外部情報を共有する
• それを踏まえてプロダクトバックログを次に向けて調整する

つまりレビューは「過去の検査」だけでなく「未来の計画への入力」も兼ねています。

スプリントレトロスペクティブ — 形骸化させないコツ

レトロは「KPT（Keep/Problem/Try）で進めるもの」と思われがちですが、フォーマットは何でもOKです。チームの状況に応じて形式を変えることは有効ですが、それは手段であって目的ではありません。

FitLogチームが試しているバリエーション:

そしてTryを必ず1つに絞り、次スプリントの最初に着手すること。「全部やろう」は何もやらないのと同じです。

作成物を深掘り

プロダクトバックログ — 良いアイテムの粒度

プロダクトバックログアイテム（PBI）は、よくユーザーストーリー形式で書かれます。

As a [どんなユーザーが]
I want to [何をしたい]
So that [なぜそうしたいか]

FitLogの良いPBI例:

タイトル: 過去30日のトレーニング推移グラフ表示

ジョギングを継続しているユーザーとして、過去30日間の走行距離の推移をグラフで見たい。なぜなら、自分の頑張りを可視化することでモチベーションを保ちたいから。

受け入れ条件:

• ホーム画面に「推移」タブが追加されている
• 直近30日の日別走行距離が折れ線グラフで表示される
• データが0件の日はグラフ上で空白になる
• グラフのタップで該当日の詳細画面に遷移する

❌ 悪い PBI 例: 「グラフ機能の実装」← 何のために、誰のためか不明

PBIにはINVEST原則（Independent / Negotiable / Valuable / Estimable / Small / Testable）を満たす粒度が望ましいとされます。

スプリントバックログ — プロダクトゴールとの接続

スプリントバックログは「タスクリスト」ではなく、3つの要素から成る計画です。

1. スプリントゴール（なぜ）: 今スプリントで達成したい状態
2. 選択した PBI（何を）: プロダクトバックログから選んだアイテム
3. 実行計画（どうやって）: タスク分解と進め方

スプリントゴール: 過去30日のトレーニング推移をグラフで確認できる状態にする
├─ PBI 1: 推移グラフ表示画面 [8 pt]
│   ├─ Task: API エンドポイント設計
│   ├─ Task: iOS 実装
│   ├─ Task: Android 実装
│   └─ Task: E2E テスト
├─ PBI 2: グラフタップで詳細遷移 [3 pt]
│   └─ ...
└─ PBI 3: 空データ時の表示改善 [2 pt]
    └─ ...

インクリメント — 「完成の定義（DoD）」

インクリメントは「動くプロダクト」と説明されますが、何をもって完成とするかはチームで明確に定義する必要があります。これが**完成の定義（Definition of Done, DoD）**です。

FitLogチームのDoD例:

• コードレビューで2名以上のApprove
• 単体テストカバレッジ80%以上
• E2Eテストが通る
• アクセシビリティチェック完了（VoiceOver / TalkBack）
• PMが受け入れ条件を確認しOK
• リリースノートのドラフトを作成

DoDを満たさないものは「未完成」として次スプリントに持ち越します。「8割できた機能」を10個積み上げるより、「100%完成した機能」を5個出すのがスクラムの考え方です。

ベロシティ — チームの「速度」を測る

ここまで読んで「あれ、PBIの横にあった [8 pt] って何？」と思った方もいるかもしれません。これがスクラムを実務で運用するうえで重要なベロシティ（Velocity） の話につながります。

定義

ベロシティとは、1スプリントあたりにチームが完了させたバックログアイテムの規模の合計値です。一般には以下のように定義されます。

ベロシティ = そのスプリントで「完成の定義」を満たしたPBIのストーリーポイント合計

ここで重要なのは:

• 完成したPBIだけカウントする（8割できた、は0扱い）
• 単位はストーリーポイント（SP） が一般的（時間ではない）
• スプリント単位で計測し、複数スプリントの移動平均で見ることが多い

ストーリーポイントとは

ストーリーポイントは作業の相対的な大きさを表す単位です。「人日」や「時間」のような絶対値ではなく、「あの基準タスクに比べてどれくらい大きいか」という相対比較で見積もります。

よく使われるのはフィボナッチ数列（1, 2, 3, 5, 8, 13, 21...）です。数字が大きくなるほど間隔が広がるのは、「大きいタスクほど不確実性が高く、細かい区別に意味がない」という考え方を反映しています。

FitLogチームの見積もり基準例:

具体例: FitLogチームのベロシティ推移

FitLogチームの直近6スプリントの実績を見てみましょう。

スプリント1: 18 pt（完成PBI: 5 + 5 + 3 + 3 + 2）
スプリント2: 22 pt（完成PBI: 8 + 5 + 5 + 2 + 2）
スプリント3: 25 pt（完成PBI: 8 + 8 + 5 + 3 + 1）
スプリント4: 23 pt
スプリント5: 26 pt
スプリント6: 24 pt
─────────────────────
直近3スプリント平均: 24.3 pt ← これが現在のベロシティ

このチームは1スプリントあたり約24ポイントこなせる、ということがわかります。

ベロシティの使い道

ベロシティが安定してくると、以下のような使い方ができるようになります。

1. スプリントプランニングのキャパシティ把握

PO 田中: 「次スプリントの候補PBI、合計32ポイントあります」
開発者 佐藤: 「直近の平均が24ポイントなので、上位の26ポイント分（8+8+5+3+2）を引き受けるのが現実的です」

「やる気でなんとかなる」ではなく、実績ベースで合意できるのが大きな価値。

2. リリース計画の予測

プロダクトバックログ全体が180ポイント、ベロシティが24ポイントなら、残り 180 ÷ 24 = 約7.5スプリントで完了する見込み、という予測が立ちます。

これがあれば「だいたいQ3末にリリースできそう」というステークホルダーへの説明が、根拠付きでできるようになります。

3. 見積もり精度の継続的改善

「想定5ポイントだったが、実際は10ポイント分の労力がかかった」というズレが見えると、レトロでの議論材料になります。

よくあるアンチパターン

ベロシティは便利な反面、誤った使い方をするとチームを壊します。

❌ アンチパターン1: ベロシティをKPIにする

「先月より今月の方がベロシティ高くないとダメ」「他チームより低いのは怠けている」——これは最悪の使い方です。

ベロシティはチーム固有の相対値であり、チーム間で比較する意味はゼロです。また「ベロシティを上げろ」とプレッシャーをかけると、チームは見積もりを水増しするだけで、実際の生産性は変わりません（むしろ下がります）。

❌ アンチパターン2: ストーリーポイント = 時間

「1ポイント = 4時間」と固定して使い始めると、ストーリーポイントの意味がなくなります。相対見積もりの利点（不確実性の表現、議論の効率化）が失われ、ただの工数見積もりに退化します。

❌ アンチパターン3: 未完成PBIの部分点をカウント

「8ポイントのPBIが7割完了したから、5.6ポイント分計上」——これはやってはいけません。完成の定義を満たしていないPBIは0ポイントが原則です。

理由: ベロシティは「次スプリントで完成させられる量」を予測するための指標。途中の作業をカウントすると、予測が狂います。

❌ アンチパターン4: チーム編成変更直後の値を信じる

メンバーが増減したり、技術スタックが変わったりすると、ベロシティはリセットされます。新しい体制で3〜4スプリント回してから、改めて平均を取り直すのが鉄則です。

ベロシティを使わない選択肢

近年は「ベロシティを追わない」チームも増えています。代替指標として以下があります:

• スループット: 完了PBI数（ポイントを付けず、PBIの粒度を揃えて数だけ数える）
• サイクルタイム: PBIが着手されてから完了するまでの時間
• リードタイム: PBIが起票されてから完了するまでの時間

特にカンバンと組み合わせる場合や、見積もりコストを下げたい成熟チームでは、これらの指標の方が有効なことも多いです。

押さえておきたい用語集

スクラム/アジャイルには独特の用語が多く、これを押さえているかどうかでチーム内のコミュニケーション効率が大きく変わります。実例とセットで深掘りしていきます。

プランニングポーカー（Planning Poker）

何をするのか

プランニングポーカーは、チーム全員でPBIのストーリーポイントを見積もる手法です。1人の経験豊富なエンジニアが「これは5ポイント」と決めるのではなく、メンバー全員が同時にカードを出して合意形成します。

なぜわざわざ「ポーカー」形式なのか

声が大きい人や経験年数の長い人の意見に引きずられてしまう「アンカリング効果」を防ぐためです。先に「これ8ポイントだよね？」と誰かが言うと、他のメンバーは「いや3だと思う」と反対意見を出しにくくなります。全員同時にカードを出すことで、これを防ぎます。

進め方（FitLogチームの例）

カードはフィボナッチ数列（0, 1, 2, 3, 5, 8, 13, 21, ?, ☕）が一般的です。「?」はわからない、「☕」は休憩を意味します。

ステップ1: PBIの説明

PO 田中: 「次は『プッシュ通知でリマインドを送る』です。ユーザーが設定した時刻に、その日トレーニング記録がなければ通知を送ります」

ステップ2: 質疑応答

開発者 佐藤: 「通知の文面はカスタマイズ可能ですか？」
PO 田中: 「いえ、固定文言で大丈夫です」
開発者 山田: 「サーバー側の通知基盤は既存のものを使う想定ですか？」
PO 田中: 「はい、既存基盤を使う前提です」

ステップ3: 全員一斉にカードを出す

ステップ4: 最高値と最低値の人に説明してもらう

最低の山田: 「BE側は既存通知基盤の呼び出し追加だけなので3です」
最高の渡辺: 「Android側でユーザー設定の保存、定期ジョブ、通知ハンドリング、3つ実装が必要です。前回似たことやった時に苦労したので13つけました」

ステップ5: 議論を踏まえて再投票

議論の結果、全員が「8」前後に収束。最終的に8ポイントで合意。

ポイント

• 早く投票させない: 質疑応答で前提を揃えてから出す
• ズレた人を責めない: ズレているのは情報の差で、それを共有することが目的
• 時間をかけすぎない: 1PBIあたり5〜10分が目安。決まらないPBIはリファインメントに戻す

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

何をするのか

リファインメントは、プロダクトバックログを手入れする継続的な活動です。具体的には:

• 大きすぎるPBIを分割する
• 上位PBIの受け入れ条件を具体化する
• 古くなったPBIを削除する
• 見積もりを行う（プランニングポーカーの場として使われることが多い）

いつやるか

スクラムガイドでは独立したイベントとして定義されていませんが、多くのチームは週1回1〜2時間の専用枠を取っています。スプリントの真ん中あたりに設定するチームが多いです。

Ready の定義（Definition of Ready）

現場では DoDと対比して語られることがある概念として、Definition of Ready（準備完了の定義） があります。リファインメントを通じてPBIがReadyの状態になったらプランニングに持っていける、という考え方です。

FitLogチームのReady定義例:

• ユーザーストーリー形式で書かれている
• 受け入れ条件が3つ以上ある
• チーム全員が内容を理解している
• 8ポイント以下に分割されている
• 外部依存がある場合、依存先と握れている

INVEST原則（深掘り）

良いPBIが満たすべき6つの性質。それぞれ具体例で見ます。

ユーザーストーリーの階層 — テーマ・エピック・ストーリー・タスク

プロダクトバックログは1次元のリストですが、実務では4階層で考えることが多いです。

テーマ（Theme）: ユーザーエンゲージメント向上
└─ エピック（Epic）: トレーニング継続を促進する仕組み
   ├─ ユーザーストーリー: 過去30日の推移をグラフで見られる [8 pt]
   │  ├─ タスク: API実装
   │  ├─ タスク: iOS UI実装
   │  └─ タスク: Android UI実装
   ├─ ユーザーストーリー: リマインド通知を受け取れる [8 pt]
   └─ ユーザーストーリー: 連続記録日数を表示する [3 pt]

PBI（プロダクトバックログアイテム）としてバックログに並ぶのは、主にエピックとユーザーストーリーです。

バーンダウンチャート / バーンアップチャート

バーンダウンチャート

スプリント中の残作業の推移を可視化するグラフ。理想線（均等に減っていく線）に対して実績がどう動いているかを見ます。

残pt
24┤●
22┤  ●
20┤    ●─ 理想線 ────
18┤      ╲╲
16┤        ●（実績、遅れ気味）
14┤          ●
12┤            ╲
 0┤──────────────●
    Day1 Day3 Day5 Day7 Day10

実績が理想線より上にずっといる→スプリントゴール達成が危ないサイン。早めに対応（スコープ削減・支援要請）を検討します。

バーンアップチャート

完了量とスコープを別々の線で表示するもの。スコープ変更が起きたときにバーンダウンより状況が見やすいため、リリース計画の追跡でよく使われます。

MVP と MMP

MVP（Minimum Viable Product）

仮説検証に必要な最小限のプロダクト。Eric Riesの『リーン・スタートアップ』で広まった概念。

FitLogのMVP例: 「ユーザーがアプリを開いて手動で走行距離を記録し、過去の記録を一覧で見られる」だけ。グラフも通知もSNS連携もなし。これで「人々はトレーニング記録アプリにお金を払うか？」という仮説を検証する。

MMP（Minimum Marketable Product）

市場に出して売れる最小限のプロダクト。MVPより一段リッチ。MVPは社内/限定ユーザー向け、MMPは一般公開、というイメージ。

タイムボックス（Timebox）

スクラムイベントには最大時間が決められています。これがタイムボックス。

タイムボックスの効果:

• 議論の発散を防ぐ: 時間が限られているので本質的な話に集中
• 会議の肥大化を防ぐ: 延長を許すと無限に伸びる
• 早く終わるのはOK: 目的が達成されれば短くてよい

スパイク（Spike）

技術調査や不確実性の解消のために行うタイムボックス付きの作業。XPに由来する用語ですがスクラムでも広く使われます。

使うべき場面:

• 「新しいライブラリでこれが実現できるか不明」→ 1日タイムボックスで検証
• 「既存コードのこの部分のリファクタコストが読めない」→ 半日で調査
• 「APIのレスポンス速度が要件を満たすか不明」→ 試作

スパイクの成果物はコードではなく知見です。検証用に書いたコードは基本的に捨てます。

WIP制限（Work In Progress Limit）

同時に進行する作業の数を制限するルール。カンバンに由来しますが、スクラムチームでも採用されることが増えています。

例: 「In Progress 列には同時に3つまで」

効果:

• 完了に集中する: 5個を半端に進めるより、3個を完了させる方が価値が出る
• ボトルネックが見える: 詰まる場所が明確になる
• マルチタスクのコストを減らす: コンテキストスイッチは生産性を大きく下げる

技術的負債（Technical Debt）

将来の保守性を犠牲にして近道で実装した結果、後で利息（追加コスト）を払うことになる状態を借金に例えた概念。Ward Cunninghamが提唱。

種類:

• 意図的な負債: 「期限優先で雑に実装、後でリファクタする」と分かって作る
• 意図せぬ負債: 知識不足や設計ミスで発生
• 環境的な負債: 周辺の技術が古くなって相対的に発生（レガシー化）

その他、サクッと押さえておきたい用語

よくある誤解と落とし穴

「ドキュメントを書かない」は誤り

アジャイル宣言の「包括的なドキュメントよりも動くソフトウェア」を曲解して、ドキュメントゼロで突き進むチームを見かけます。これは動くために必要なドキュメントは書くが正解です。

「計画しない」も誤り

「変化への対応」を盾に計画を放棄するのもNG。スクラムには複数レイヤーの計画（プロダクトゴール、スプリントゴール、デイリーの計画）があります。計画しないのではなく、適応的に計画するのがアジャイルです。

デイリースクラムが「報告会」になっている

PMやマネージャーへの進捗報告会と化したデイリースクラムは、本来の目的を失っています。デイリーは開発者のための、開発者による検査と適応の場です。

スプリントの長さがコロコロ変わる

「今回は忙しいから3週間に」「次は1週間にしよう」と変えると、ベロシティ（チームの速度）が測れなくなります。スプリント長は固定するのが鉄則です。

アジャイル/スクラムが向かないケース

万能ではありません。以下のような状況では、別のアプローチが適している可能性があります。

• 要件が完全に固まっていて変更がほぼ発生しない（例: 法規制対応）
• 安全性が極めて重要で段階的リリースが許されない領域
• チームが極端に大規模で、調整コストの方が高くつく場合

ただし大規模スクラム（LeSS、SAFeなど）のスケーリング手法もあるため、「規模が大きいから無理」と即断するのは早計です。

まとめ

• アジャイルは考え方・価値観。「短いサイクルで動くものを出す」「変化を歓迎する」が核
• スクラムはアジャイルを実践する代表的フレームワーク
• スクラムは「3つの説明責任・5つのイベント・3つの作成物」で構成され、固定期間のスプリントを繰り返す
• 形だけ真似ると形骸化する。価値観の理解が先、フレームワークは後

「スクラムをやること」が目的ではなく、「価値あるプロダクトを継続的に届けること」が目的です。フレームワークはそのための道具と捉えるのが、長く付き合うコツだと思います。

参考文献

• アジャイルソフトウェア開発宣言
• スクラムガイド 2020
• Jeff Sutherland『スクラム — 仕事が4倍速くなる"世界標準"のチーム戦術』