ScrumとKanbanの違い：それぞれをいつ使うべきか

どちらもアジャイルです。どちらもボードを使います。しかし、ScrumとKanbanを混同したチームは、継続的なフローが必要なところにSprintの硬直性を持ち込んだり、構造化された計画が必要なところにKanbanの自由度を当てはめたりしてしまいます。核心となる違いはケイデンスにあります。一方はタイムボックス化されており、もう一方は川のように流れます。

ScrumとKanbanの違いとは

Scrumはタイムボックス型です。作業は固定されたSprintで進みます（通常1〜4週間）。定義された役割と必須の計画ケイデンスがあります。Kanbanは継続的フロー型です。作業はハードリセットなしにボードを流れます。時間ではなく、各列のWork in Progress（WIP）制限によって制約されます。

どちらのフレームワークもアジャイルとリーン思考から生まれています。しかし目標は異なります。Scrumは、チームが構造化されたフィードバックループを必要とする予測困難な探索重視のプロダクト作業のために設計されました。Kanbanは、1940年代のトヨタ生産方式（TPS）にルーツを持ち、Sprint Velocityではなく安定したスループットとボトルネック最小化を目標とするフロー最適化のために設計されました。

重要なポイント

• Scrum Guideは1995年にJeff SutherlandとKen Schwaberによって最初に体系化され、直近では2020年に改訂されました。2020年の改訂ではフレームワークが簡素化され、「Development Team」が「Developers」に置き換えられました。
• 知識作業向けのKanbanは、David J. Andersonの2010年の著書「Kanban: Successful Evolutionary Change for Your Technology Business」（Blue Hole Press）で正式に体系化されましたが、製造業のルーツは1940年代の大野耐一のトヨタ生産方式に遡ります。
• 第17回年次State of Agileレポート（2023年）によると、回答者の87%がScrumまたはScrumハイブリッドを主要な手法として使用しており、56%がKanbanを、9%がScrumbanを使用しています。多くのチームが複数のアプローチを使用していると報告しています。

一目でわかる：10の主な違い

2つのフレームワークがどのように異なるかを最も素早く把握できる一覧です。

ケイデンスと計画

ScrumのSprintは交渉の余地がありません。チームはゴールに合意し、BacklogからアイテムのセットをPullし、Sprint中にそのスコープを変更しません。これは強制機能を生み出します。1〜4週間ごとにチームは何かをリリースし、ステークホルダーとともにレビューし、方向を調整します。計画を立てやすいリズムです。

KanbanにはSprintがありません。作業が届き、優先順位が付けられ、キャパシティが生まれるにつれてボードを流れます。計画は軽量です。キューの先頭を補充するための補充ミーティングがあります。「今週何を完了するか」という約束はありません。約束は個々の項目レベルで行われ、サイクルタイム（1つの項目が開始から完了まで何日かかるか）で追跡されます。

実際には、Scrumチームは「Sprint演劇」に悩まされることが多いです。セレモニーは行われるがSprintゴールは架空のものになるケースです。Kanbanチームはその逆に悩まされます。すべてが進行中になり、WIP制限が無視され、ボードが駐車場になります。どちらの問題も規律の問題であり、フレームワークの問題ではありません。

役割とセレモニー

Scrumには3つの役割と5つのイベントがあります。

役割：Product Owner（Backlogを管理し、優先順位を定義する）・Scrum Master（プロセスをコーチし、ブロッカーを取り除く）・Developers（実際に作る人）。設計通りにScrumを機能させるには3つすべてが必要です。

イベント：Sprintプランニング・Daily Scrum（15分のスタンドアップ）・Sprintレビュー・Sprintレトロスペクティブ・そしてSprintそのもの。これらは任意ではありませんが、チームはレトロスペクティブを省略しようとすることがよくあります。

Kanbanは役割を一切必要としません。Kanban Masterも、仕様上のProduct Owner相当の役割もありません。チームは実際にフローマネージャーやサービスデリバリーマネージャーを設ける場合がありますが、それは組織的な選択であり、フレームワークの要件ではありません。任意のケイデンスとして補充ミーティング（キューの補充）・デリバリー計画・サービスデリバリーレビュー・レトロスペクティブがあります。いずれも必須ではありません。

これがKanbanを既存のチームに導入しやすい理由です。役職名を変えることを求めません。ワークフローを可視化し、WIP制限を追加するだけです。

指標：Velocityとサイクルタイム

ScrumはVelocityを測定します。チームはSprintあたりに何Story Point（または同様の単位）を完了するか？ VelocityはSprintプランニングとざっくりしたキャパシティ予測に役立ちます。ただし、特定の項目がいつリリースされるかの予測には役立ちません。

Kanbanはサイクルタイム（「開始」から「完了」まで項目にどれくらいかかるか）とスループット（チームが単位時間あたりに何項目を完了するか）を測定します。これらは個々の成果物に対してより予測的です。平均サイクルタイムが3日でばらつきが少なければ、「この項目はおそらく木曜日までに完了します」とステークホルダーに確信を持って伝えられます。

累積フロー図はKanbanを特徴付けるチャートです。時間の経過とともに各段階の作業量を示し、幅が広がるバンドとしてボトルネックを可視化します。ScrumのバーンダウンチャートはSprint内の残作業を示します。どちらも有用ですが、異なるものを測定しています。

ScrumかKanbanかの判断フロー

率直に言えば、どちらのフレームワークが格好よく聞こえるかではなく、実際の作業がどのように届くかに基づいて選んでください。

Scrumを使うべきとき：

• 作業に、構造化された探索サイクルから恩恵を受けるプロダクトゴールがある場合。
• チームが「緊急事態」を理由にすることなくSprintスコープにコミットできる場合。
• 学習ループが重要な場合：何かをリリースし、そこから学び、さらに作る前に方向を修正する。
• ステークホルダーが定期的で予測可能なレビューチェックポイントから恩恵を受ける場合。
• チケットキューを処理しているのではなく、Roadmapを持つプロダクトを作っている場合。

Kanbanを使うべきとき：

• 作業が予測不可能に届く場合：サポートチケット・運用依頼・保守作業。
• Sprint VelocityよりスループットMaximizationが重要な場合。
• 割り込みが仕事の一部であるため、固定スコープにコミットできない場合。
• セレモニーが少ない形で構造化されたワークフロー管理を始めたい場合。
• 新しいプロダクトを探索するのではなく、既存のプロセスを改善している場合。

Scrumbanを使うべきとき：

• Scrumの硬直性を超えたが、何らかの計画リズムはまだ欲しい場合。
• 同じチームに計画済みのプロダクト作業と予定外のサポート作業が混在している場合。
• Sprintが毎回同じチケットの名前を変えているだけで、レトロスペクティブで何も変わらない場合。

実用的なヒューリスティック：チームの作業分解構成図を合理的な確信を持って2週間前に定義できるなら、Scrumが適します。できないなら、Kanbanの方が合います。スコープが変わり続けてGanttチャートがほぼフィクションになっているなら、どちらかにコミットする前にGanttチャートが何のためにあるかを確認してみてください。

よくある誤解

チームは実際の状況ではなく誤解に対応して間違ったフレームワークを採用することが多いです。

• 「Kanbanにはルールがない」。 セレモニーは少ないですが、ルールは実在します。WIP制限は提案ではありません。WIP制限を破ることは、削除ではなく解決が必要な体系的な問題を示しています。
• 「Scrumの方が成熟している、またはプロフェッショナルだ」。 成熟度は無関係です。NetflixはKanbanに影響されたフロー管理で動いています。AmazonのソフトウェアプロダクトチームはSprintベースのアプローチを使っています。適切なツールは作業に依存しており、威信には依存しません。
• 「混ぜることはできない」。 Scrumbanはまさに、両方の要素を組み合わせることに価値を見出したチームのために存在します。フレームワークは宗教ではありません。
• 「KanbanボードはScrumボードだ」。 ボードは単なる可視化ツールです。ScrumボードはSprintごとにリセットされ、Sprint状態を示します。KanbanボードはPersisteしており、ワークフローの段階を示し、WIP制限を適用します。同じ家具、異なる部屋です。
• 「デイリースタンドアップはKanbanだ」。 Daily ScrumはScrumのセレモニーです。Kanbanはデイリースタンドアップを必要としませんが、多くのKanbanチームが採用しています。セレモニーとフレームワークを混同しないでください。
• 「Scrumはハードウェアに使える」。 使えますが、ハードウェアには真の連続依存関係があるため、クリティカルパス法やPERTチャートの方がハードウェア開発に適していることが多いです。Sprintリセットによってその依存関係は変わりません。

Scrumban：両方を組み合わせる

Corey Ladasは2008年の論文でScrumbanをScrumからKanbanへチームを移行する方法として描写しました。実際には、独自のハイブリッドとして進化しました。チームはSprintのような計画ケイデンスを一部維持しながら（Backlogが閾値を下回ったときに発火する「トリガー」）、ボード上ではKanbanのWIP制限とフロー指標を使います。

プロダクト開発とサポートが半々のチームに特に有用です。プロダクト作業はSprintゴールとレビューサイクルから恩恵を受けます。サポート作業はSprintの境界まで待てません。ScrumbanはSprintコミットメントを崩さずに緊急項目を処理できます。

リスクもあります。Scrumbanはどちらのフレームワークにおいても規律を避ける言い訳になることがあります。WIP制限が常に10で、Sprintゴールが常に「今週来たもの」であるならば、ScrumでもKanbanでもありません。ラベルを貼った白板です。

よくある質問

KanbanはMethodologyですか、それともツールですか？

Methodologyです。「Kanbanボード」はKanban手法の一つの成果物ですが、Kanban自体はフローを管理・改善するための一連の実践です。作業を可視化し、WIPを制限し、フローを管理し、プロセスポリシーを明示し、フィードバックループを実装し、協働的に改善する。ボードは最も目に見える部分ですが、WIP制限とフロー指標こそが、単なるスティッキーノートの習慣ではなく、Methodologyたらしめているものです。

チームはプロジェクト途中でScrumからKanbanに切り替えられますか？

はい、ただし意図的に行ってください。最も一般的な移行は、チームがSprintサイクルに価値がないと合意したチームのレトロスペクティブ中に行われます。実際の手順は：Sprintの計画を止める。既存のボードにWIP制限を明示する。Velocityではなくサイクルタイムのトラッキングを開始する。Sprintレビューではなくフローレビューを実施する。移行中にScrumとKanbanを同時に行わないでください。日付を決めて切り替えてください。

KanbanにScrum Masterは必要ですか？

必要ありません。Kanbanには必須の役割がありません。一部の組織では補充ミーティングの運営とWIP制限の保護のために「フローマネージャー」または「サービスデリバリーマネージャー」を置きますが、Kanban手法ではこれは義務付けられていません。ScrumからKanbanに移行するチームは、Scrum Masterをコーチングの役割として維持することが多く、それで問題ありません。その役割が必須ではなく任意になったことを明確にするだけです。

どちらから始めやすいですか：ScrumとKanban？

ほとんどのチームにとってKanbanの方が始めやすいです。役割の再編成や新しいセレモニーカレンダーへのコミットメントが不要だからです。既存のワークフローをボードで可視化し、WIP制限に合意するだけでKanbanを導入できます。Scrumは役割の明確化（Product Ownerは誰か？）とセレモニーへのコミットメント（2週間ごとにSprintプランニングを行う）が、設計通りに機能するために必要です。ただし、Scrumの構造化されたケイデンスは定期的にリリースするための強制機能を必要とするチームには強みになります。チームに「準備ができたときにリリースする」という慣習がある場合、ScrumのSprintプレッシャーがまさに必要なものかもしれません。

---

ほとんどのチームは、どちらのフレームワークが「より優れているか」を議論することに時間を使いますが、実際に問うべきは「どちらが実際の作業の届き方に合っているか」です。Scrumは1〜4週間ごとに構造化されたフィードバックループを提供します。Kanbanは個々の項目レベルでフローの透明性と予測可能性を提供します。どちらも、共有スプレッドシートと感覚だけで進める方法より優れています。まず作業パターンに合う方から始め、誠実に測定し、そこから改善していきましょう。

アジャイル作業と並行して構造化されたプロジェクト計画を立てるチームには、RACIマトリクスがSprintチーム間の意思決定の責任を明確にするのに役立ちます。また、ウォーターフォール手法の経験が連続した計画に引き寄せているなら、Kanbanの継続的フローに直接ジャンプするより、Scrumのスプリント構造の方が良い橋渡しになります。