はじめに
「私たちはアジャイルに働いています」という言葉を聞いたことがないチームは、ほとんどないでしょう。ところがよく見てみると、毎日集まって進捗を報告する会議が長引き、スプリントはいつまでも終わらず、ふりかえりは形式的に流れている、というケースが少なくありません。アジャイルという言葉は身近でも、その中身であるスクラムとカンバンが何で、どう違うのかを正確に説明できる人は意外と少ないものです。
本記事では、アジャイル宣言と12の原則という根っこから出発し、スクラムとカンバンという二つの代表的フレームワークを実践的な視点で比較します。役割とイベント、成果物、WIP制限、見積もり手法を整理し、よく陥る偽アジャイルのアンチパターンと現実的な導入ガイドまで扱います。ツールや会議の名前を覚えることが目的ではなく、「なぜこう働くのか」を理解することが目標です。
1. アジャイルとは何か
アジャイル宣言
2001年、17名のソフトウェア開発者が米国ユタ州スノーバードに集まり、「アジャイルソフトウェア開発宣言(Agile Manifesto)」を発表しました。重厚な文書と計画中心の従来型開発への反省から生まれたこの宣言は、四つの価値を示しています。
アジャイル宣言の四つの価値
プロセスやツールよりも ──▶ 個人と対話を
包括的な文書よりも ──▶ 動くソフトウェアを
契約交渉よりも ──▶ 顧客との協調を
計画に従うことよりも ──▶ 変化への対応を
「左側にも価値はあるが、
私たちは右側により高い価値を置く。」
ここで最も誤解されやすいのは、左側を捨てよという意味ではない、という点です。文書も必要ですし、計画も必要です。ただ、どちらかを選ばなければならない状況であれば、右側により重きを置く、という優先順位の宣言なのです。
アジャイル12の原則
宣言の後ろには、それを具体化した12の原則が続きます。すべて暗記する必要はありませんが、要点をまとめると次のようになります。
- **顧客満足と価値提供**: 価値あるソフトウェアを早く、継続的に届けて顧客を満足させます。
- **変化の歓迎**: 開発の後半における要求変更も歓迎します。変化は顧客の競争優位を生みます。
- **短い周期での提供**: 数週間から数か月の単位で、短い周期を好み、動くソフトウェアを頻繁に届けます。
- **協働**: ビジネス担当者と開発者がプロジェクトを通じて毎日一緒に働きます。
- **意欲ある人中心**: やる気のある人を中心にチームを作り、必要な環境と支援を与えて信頼します。
- **対面での会話**: 情報伝達の最も効率的な方法は、顔を合わせた会話です。
- **動くソフトウェアが進捗の尺度**: 文書の量ではなく、実際に動く成果物が進み具合を示します。
- **持続可能なペース**: 無理な残業ではなく、一定のペースを無限に維持できることが大切です。
- **技術的卓越性**: 良い設計と技術的優秀さへ、継続的に注意を払います。
- **シンプルさ**: やらなくてよい仕事の量を最大化する技術、すなわちシンプルさが本質です。
- **自己組織化チーム**: 最高のアーキテクチャと設計は、自己組織化するチームから生まれます。
- **定期的なふりかえりと改善**: 一定の周期ごとに、より効果的に働く方法をふりかえり調整します。
これらの原則を一文に圧縮すると、こうなります。「小さな単位で頻繁に届け、素早くフィードバックを得て、改善し続ける。」スクラムとカンバンは、この哲学を実行するための異なる具体的な方法論です。
2. スクラム詳細
スクラムは最も広く使われているアジャイルフレームワークです。決まった長さの反復周期である**スプリント(Sprint)**を中心に、明確な役割とイベント、成果物を定義します。
2.1 スクラムの三つの役割
スクラムチームは三つの責任で構成されます。よく「役割」と呼ばれますが、最新のスクラムガイドではこれを説明責任(accountability)として表現しています。
- **プロダクトオーナー(Product Owner)**: プロダクトの価値を最大化する責任者です。バックログの優先順位を決め、何を作るかを決定します。「何を(What)」と「なぜ(Why)」の主です。
- **スクラムマスター(Scrum Master)**: スクラムが正しく機能するよう助けるサーバントリーダーです。障害を取り除き、チームが自己組織化するようコーチします。管理者ではなく促進者に近い存在です。
- **開発者(Developers)**: 実際にインクリメント(Increment)を作る人々です。開発者、QA、デザイナーなど、成果物を作るすべての人を含みます。「どうやって(How)」を決めます。
理想的なスクラムチームの規模は、通常10名以下です。大きすぎると意思疎通のコストが増え、小さすぎると多様なスキルを備えにくくなります。
2.2 スプリント周期
スプリントは通常1週間から4週間の固定された期間です。一つのスプリントの中で、複数のイベントが決まった順序で起こります。
スプリント周期(2週間の例)
┌──────────────────────────────────────────────────────┐
│ スプリント(2週間) │
│ │
│ スプリントプランニング │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Day 1 ── Day 2 ── ... ── Day 9 ── Day 10 │ │
│ │ │ │ │ │ │ │
│ │ デイリー デイリー デイリー デイリー │ │
│ │ スクラム スクラム スクラム スクラム │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ スプリントレビュー ──▶ スプリントレトロスペクティブ │
└──────────────────────────────────────────────────────┘
│
▼
次のスプリント開始
2.3 スクラムの五つのイベント
スプリント自体も一つのイベントとみなされ、その中に四つのイベントが含まれます。
- **スプリント(Sprint)**: すべての活動を収める器。終わるとすぐに次のスプリントが始まります。
- **スプリントプランニング(Sprint Planning)**: スプリントの始まり。「今回のスプリントで何を、なぜ、どう作るか」を決め、スプリントゴール(Sprint Goal)を立てます。
- **デイリースクラム(Daily Scrum)**: 毎日15分以内で行う開発者たちの短い点検。進捗を同期し、スプリントゴールに向けた計画を調整します。上司への報告ではありません。
- **スプリントレビュー(Sprint Review)**: スプリントの終わりに、完成したインクリメントを関係者に披露しフィードバックを得ます。プロダクトの方向を一緒に点検します。
- **スプリントレトロスペクティブ(Sprint Retrospective)**: 最後のイベント。「人、関係、プロセス、ツール」の観点で、何が良く、何を改善するかをふりかえります。次のスプリントの改善項目を導き出します。
デイリースクラムでよく使われる三つの質問は次のとおりです。
デイリースクラムの伝統的な3つの質問
1) 昨日は何をしたか?
2) 今日は何をするか?
3) スプリントゴールを妨げる障害はないか?
※ 最新のスクラムガイドは形式を強制しません。
核心は「スプリントゴールへの進捗点検と計画調整」です。
2.4 スクラムの三つの成果物
- **プロダクトバックログ(Product Backlog)**: プロダクトに必要なすべての優先順位リスト。プロダクトオーナーが管理し、継続的に洗練(refinement)されます。
- **スプリントバックログ(Sprint Backlog)**: 今回のスプリントで扱う項目とその実行計画。開発者が所有します。
- **インクリメント(Increment)**: スプリントの成果物。これまでのインクリメントに加えられた、潜在的にリリース可能な状態の成果物です。
各成果物には透明性を高める約束(commitment)が結びつきます。プロダクトバックログにはプロダクトゴール(Product Goal)、スプリントバックログにはスプリントゴール(Sprint Goal)、インクリメントには完成の定義(Definition of Done)が結びつきます。
バックログのフロー
アイデア / 要求
│
▼
┌───────────────┐ refinement ┌───────────────┐
│ プロダクト │ ─────────────▶ │ 細かく分割し │
│ バックログ │ 洗練 │ 見積もった項目 │
│ (優先順位順) │ │ │
└───────────────┘ └───────────────┘
│
│ プランニングで上位項目を選ぶ
▼
┌───────────────┐ ┌───────────────┐
│ スプリント │ ───────────▶ │ インクリメント │
│ バックログ │ 開発/統合 │ (リリース可能) │
│ (今回の作業) │ │ │
└───────────────┘ └───────────────┘
2.5 完成の定義(Definition of Done)
完成の定義は、「この仕事が終わった」と言える共通の基準です。コードを書けば終わりではなく、テスト通過、コードレビュー、文書化、デプロイ可能な状態までを合意しておきます。完成の定義が曖昧だと、「ほぼできています」という言葉が毎スプリント繰り返され、インクリメントの品質を信頼できなくなります。
完成の定義の例
[ ] 機能要求を満たす
[ ] ユニットテスト作成と通過
[ ] コードレビュー承認 1件以上
[ ] リント/フォーマット検査の通過
[ ] 文書の更新
[ ] ステージング環境へのデプロイ確認
3. カンバン詳細
カンバンは、トヨタ生産方式から生まれたフロー(flow)管理の方法です。日本語で「看板」や「合図のカード」を意味し、ソフトウェア開発では作業の流れを可視化し、進行中の仕事の量を制限する方法として使われます。
スクラムが決まった周期で区切って働くのに対し、カンバンは途切れのない連続的な流れを追求します。決まった役割も、固定された反復周期も強制しません。
3.1 カンバンの中心的なプラクティス
カンバンには変化を扱う原則とプラクティスがあります。プラクティスの核心は次のとおりです。
- **作業の可視化(Visualize the workflow)**: すべての仕事をボード上のカードにして、流れを目に見えるようにします。
- **進行中作業の制限(Limit WIP)**: 各段階で同時に進められる作業数に上限を設けます。
- **フローの管理(Manage flow)**: 作業が段階の間をなめらかに流れるよう測定し改善します。
- **方針の明示化(Make policies explicit)**: 各段階の開始/完了基準を明確に書いておきます。
- **フィードバックループの運用(Feedback loops)**: 定期的に流れを点検する会議を設けます。
- **協働的な改善(Improve collaboratively)**: データを根拠に、段階的に改善します。
3.2 カンバンボード
カンバンボードは作業の流れを列(column)で表します。最もシンプルな形は次のとおりです。
カンバンボード(WIP制限あり)
┌──────────┬──────────┬──────────────┬──────────┬──────────┐
│ Backlog │ To Do │ In Progress │ Review │ Done │
│ │ (WIP 3) │ (WIP 2) │ (WIP 2) │ │
├──────────┼──────────┼──────────────┼──────────┼──────────┤
│ [ #12 ] │ [ #08 ] │ [ #05 ] │ [ #03 ] │ [ #01 ] │
│ [ #13 ] │ [ #09 ] │ [ #06 ] │ │ [ #02 ] │
│ [ #14 ] │ [ #10 ] │ │ │ │
│ [ #15 ] │ │ │ │ │
└──────────┴──────────┴──────────────┴──────────┴──────────┘
│ │
└─ 引き取り ─┘
(前の段階が空けば次のカードを引き取る = Pull システム)
ここで In Progress 列の「WIP 2」は、同時に二つまでしか進められないという意味です。三つ目の作業を始めたくても、まず進行中の一つを Review に渡して枠を空ける必要があります。
3.3 WIP制限が重要な理由
進行中作業(Work In Progress)を制限することは、カンバンの心臓です。直感に反して、同時にもっと多くの仕事を抱えると、処理量が増えるどころか、むしろ減ります。
- **コンテキストスイッチのコスト**: 複数の作業を行き来すると、毎回頭の中を入れ替える必要があります。切り替えコストが累積します。
- **ボトルネックの可視化**: WIP制限に阻まれて作業が止まると、その地点こそがボトルネックです。問題が目に見えるようになります。
- **早い完了**: 少ない数の作業に集中すると、各作業がより早く終わります。始めた仕事を終わらせる文化が生まれます。
リトルの法則(Little's Law)は、この直感に数学的な根拠を与えます。平均処理時間は、進行中作業の数を処理率で割った値に比例します。つまり、同じ処理率でも進行中作業が多いほど、各作業が終わるまでにかかる時間が長くなります。
リトルの法則(概念)
平均リードタイム = 進行中作業の数 / 平均処理率
進行中作業が多いほど → リードタイムが長くなる
WIPを減らせば → 個々の作業がより早く終わる
3.4 カンバンの測定指標
カンバンはデータに基づく改善を重視します。よく使われる指標は次のとおりです。
- **リードタイム(Lead Time)**: 作業が要求された時点から完了までにかかった全体の時間。
- **サイクルタイム(Cycle Time)**: 実際に作業を始めた時点から完了までにかかった時間。
- **スループット(Throughput)**: 一定期間に完了した作業の数。
- **累積フロー図(CFD)**: 各段階に積まれた作業量の変化を時間軸で見たグラフ。ボトルネックと滞留を一目で示します。
4. スクラム vs カンバン 比較
二つのフレームワークは同じアジャイル哲学を共有しますが、強調点が異なります。どちらが優れているかではなく、チームの働き方と業務の性質によって適合度が分かれます。
| 区分 | スクラム | カンバン |
| --- | --- | --- |
| リズム | 固定長スプリントの反復 | 途切れのない連続フロー |
| 役割 | PO、スクラムマスター、開発者を定義 | 役割の強制なし |
| 変更時点 | スプリント中の範囲変更は避ける | いつでも優先順位を調整可能 |
| 主要指標 | ベロシティ、バーンダウン | リード/サイクルタイム、スループット |
| WIP管理 | スプリント単位で暗黙的に制限 | 列ごとに明示的なWIP制限 |
| イベント | プランニング、デイリー、レビュー、レトロ | 強制会議なし |
| 成果物 | プロダクト/スプリントバックログ、インクリメント | ボード、方針、フロー指標 |
| 適した状況 | 計画可能な機能開発 | 運用、支援、流入が不規則な業務 |
| 変化の強度 | 働き方を新たに導入 | 既存プロセスの上に段階的に適用 |
実務では、両者を混ぜた**スクラムバン(Scrumban)**もよく使われます。スクラムのリズムとふりかえりを保ちながら、ボードにWIP制限を加える形です。フレームワークは目的のための手段にすぎないので、教条的に片方だけに固執する必要はありません。
選択ガイド(おおまかな直感)
仕事が事前に計画可能で、周期的なリリースが合う
└──▶ スクラム
仕事が外部から不規則に入り(運用/支援)、フローが重要
└──▶ カンバン
既存プロセスを刷新するのが負担
└──▶ カンバンで始めて段階的に改善
チームが自律とリズムの両方を望む
└──▶ スクラムバン
5. 見積もり(Estimation)
アジャイルにおいて「この仕事はどれくらいかかるか」を扱う方法は、従来型とは異なります。時間を正確に当てることが目的ではなく、相対的な大きさと複雑さについての共通理解を作ることが目的です。
5.1 ストーリーポイント
ストーリーポイントは作業の大きさを、時間ではなく相対的な数値で表します。「この仕事はあの仕事より二倍ほど複雑だ」といった比較です。通常、次の三つを合わせて考えます。
- **複雑さ(Complexity)**: 技術的にどれだけ難しいか。
- **作業量(Effort)**: 手間がどれだけかかるか。
- **不確実性(Uncertainty)**: わからない部分、リスクがどれだけ大きいか。
時間の代わりにポイントを使う理由は、人によって作業の速さが異なり、「3日」という絶対的な見積もりがよく外れるからです。相対的な大きさは比較的一貫して合意されます。複数のスプリントが積み重なると、チームの平均処理量である**ベロシティ(Velocity)**が見えてきて、それをもとに今後の計画を立てられます。
5.2 プランニングポーカー
プランニングポーカーは、ストーリーポイントを一緒に見積もる代表的な技法です。よくフィボナッチ数列を変形したカードを使います。
プランニングポーカーのカード(変形フィボナッチ)
0 1 2 3 5 8 13 20 40 100 ? (コーヒー)
数字が大きくなるほど間隔が広がる
→ 大きな作業ほど不確実性が大きく、精密な見積もりが無意味なことを反映
→ 「?」 はわからないという合図、「コーヒー」 は少し休もうという合図
進め方はシンプルです。
プランニングポーカーの進行
1) POがバックログ項目を説明する
2) メンバー各自がカードを同時に公開する
3) 数字が大きく割れたら、最も高い/低い人が理由を話す
4) 議論の後、再び見積もる
5) 合意に近づくまで繰り返す
核心は「正解」ではなく「理解のそろえ」
値が割れること自体が価値ある合図です。誰かが5を、誰かが13を出したなら、その差はたいてい要求への理解の差から来ます。その隔たりを埋める対話こそが、見積もりの本当の目的です。
5.3 バーンダウンチャート
バーンダウンチャートは、スプリントの間に残りの作業量が減っていく推移を示します。理想の直線と実際の推移を比べて、進捗とリスクを見積もります。
スプリントバーンダウン(概念)
残り
作業量
│＼
│ ＼ ＼ 理想線(均等な減少)
│ ● ＼
│ ＼● ＼
│ ＼ ● ＼
│ ＼ ● ＼
│ ＼ ●● ＼
│ ＼ ● ＼
└────────────────────────────────▶ 時間
開始 終了
実際の線が理想線の上にとどまると → 遅延リスクの合図
バーンダウンは監視の道具ではなく、対話の道具として使うべきです。「なぜ遅れたのか」を追及するのに使えば、チームは見積もりを水増しし始め、指標は意味を失います。
6. アンチパターン — 偽アジャイル
アジャイルの形式だけをまね、精神を取りこぼした状態を、よく「偽アジャイル(Fake Agile)」または「ダークスクラム(Dark Scrum)」と呼びます。会議の名前とツールはそろっていても、実際には統制と圧力の道具に変質してしまった場合です。
よく見られるアンチパターン
- **デイリースクラムが報告会議に変質**: 開発者同士が計画を調整する場ではなく、管理者に進捗を報告する時間になります。15分が30分、1時間へと伸びます。
- **ベロシティを人事評価に使用**: ベロシティは計画用の指標なのに、これをチーム間の比較や評価に使うと、ポイントのインフレが起こります。皆が見積もりを水増しします。
- **ふりかえりが形式的、または省略される**: 改善のエンジンであるふりかえりを「時間がない」と飛ばすと、同じ問題が毎スプリント繰り返されます。
- **固定された範囲 + 固定された日程 + 固定された人員**: 三つすべてを固定してアジャイルと呼びます。変化対応の余地のないウォーターフォールを、スプリントに細かく刻んだだけです。
- **完成の定義の欠如**: 「ほぼできています」が毎回繰り返され、インクリメントの品質を信頼できません。
- **WIP制限の無視**: カンバンボードは描いたが制限を設けず、すべてのカードが In Progress に積み重なります。フローではなく滞留だけが見えます。
- **スクラムマスターがすなわち管理者**: 促進者ではなく、仕事を割り振り統制する上司になり、自己組織化が消えます。
本物のアジャイル vs 偽アジャイル
本物 偽物
───────────────── ─────────────────
目標(なぜ)に集中 vs 儀式(手順)に集中
自己組織化チーム vs 上から統制するチーム
変化を歓迎 vs 変化を封じる
指標で学ぶ vs 指標で罰する
ふりかえりで改善 vs ふりかえりを省略
完成 = リリース可能 vs 完成 = 「ほぼ完了」
偽アジャイルの共通の根は「統制したい欲求」です。アジャイルは本質的に、チームへの信頼を前提とします。信頼なしに形式だけを導入すると、すべてのイベントが監視の道具に変質します。
7. 導入ガイド
新しいチームにアジャイルを導入するときは、本に書いてあるすべてを一度に適用しようとする欲を捨てるのが賢明です。小さく始めて段階的に洗練していくこと自体が、アジャイルなやり方です。
段階的なアプローチ
段階的導入ロードマップ
ステップ1 現在の流れを可視化
└ どう仕事をしているかをボードにそのまま描く
│
ステップ2 小さなルールを一つ追加
└ ふりかえりを隔週で導入 / または一列にWIP制限を適用
│
ステップ3 測定を開始
└ サイクルタイム、スループットなど一つ二つの指標だけ追う
│
ステップ4 ふりかえりで調整
└ データを根拠にルールを足したり引いたりする
│
ステップ5 反復
└ チームに合う形に収束するまで改善
フレームワーク選択の基準
- **業務の流入が不規則か**: 運用、顧客支援、バグ対応のように仕事が予測なく入るなら、カンバンがよく合います。
- **計画可能なプロダクト開発か**: ロードマップがあり、周期的なリリースが合うなら、スクラムが効果的です。
- **変化への組織の耐性は**: 既存プロセスを大きく変えにくいなら、上に重ねる方式であるカンバンで始めるほうが抵抗が少なくなります。
- **チームの成熟度は**: 自律性がまだ低いチームなら、スクラムの明確な構造が学びの足場になることもあります。
導入時によくある落とし穴
- ツールから買うこと: ボードツールを導入したからといってアジャイルにはなりません。働き方と信頼が先です。
- 一度にすべて変えること: すべてのイベントと役割を同時に強制すると、チームが消化しきれません。
- 指標を武器にすること: 測定は学びのためのものであり、罰のためのものではありません。
- ふりかえりを真っ先に捨てること: 忙しいという理由でふりかえりを省くと、改善の原動力が失われます。ふりかえりだけは最後まで守ってください。
おわりに
アジャイルは特定の会議やツールの集合ではなく、「小さく作り、頻繁にフィードバックを得て、絶えず改善する」という考え方です。スクラムは決まったリズムと役割でこの考え方を構造化し、カンバンはフローとWIP制限で同じ目標に近づきます。どちらにせよ大切なのは形式ではなく、その中に込められた精神、すなわちチームへの信頼と継続的な改善です。
最も警戒すべきは、儀式だけをまねる偽アジャイルです。デイリースクラムが報告会議になり、ベロシティが評価の道具になり、ふりかえりが消える瞬間、フレームワークは抜け殻だけが残ります。小さく始め、データで学び、ふりかえりで調整してください。チームに合わせて収束していくその過程自体が、最もアジャイルな実践です。
参考資料
- [Agile Manifesto (原文と12の原則)](https://agilemanifesto.org/)
- [The Scrum Guide — scrum.org](https://www.scrum.org/resources/scrum-guide)
- [Kanban University](https://kanban.university/)
- [Atlassian Agile Coach](https://www.atlassian.com/agile)
- [Atlassian — Scrum](https://www.atlassian.com/agile/scrum)
- [Atlassian — Kanban](https://www.atlassian.com/agile/kanban)
현재 단락 (1/241)
「私たちはアジャイルに働いています」という言葉を聞いたことがないチームは、ほとんどないでしょう。ところがよく見てみると、毎日集まって進捗を報告する会議が長引き、スプリントはいつまでも終わらず、ふりかえ...