小さなチームで開発を進めていると、「タスク管理をもう少しきちんとしたい」と感じる時期が来ます。
そこで候補に挙がるのが、スクラムとカンバンです。
どちらもアジャイル開発でよく使われる進め方ですが、仕組みの考え方は大きく異なります。
この記事では、両者の違いを整理し、3〜5人程度の小規模チームでどちらを選ぶかの判断基準と、導入時の落とし穴を解説します。
スクラムの基本
スクラムは、一定の長さの期間（スプリント）を区切り、その期間ごとに計画・開発・確認・改善を繰り返す枠組みです。
公式の説明である「スクラムガイド」に、役割・イベント・成果物が定められています。
スプリントの長さは1か月以内で、チームが決めた長さに固定します。
実務では、1週間や2週間がよく選ばれます。
スクラムチームには、次の3つの責任があります。
- プロダクトオーナーは、何を作るかの優先順位を決める。
- スクラムマスターは、スクラムが正しく機能するように、チームを支援する。
- 開発者は、スプリントごとに使える成果物（インクリメント）を作る。
1回のスプリントの中では、次のイベントを行います。
| イベント | 内容 |
|---|---|
| スプリントプランニング | スプリントのゴールと、取り組む項目を決める |
| デイリースクラム | 開発者が毎日15分以内で、ゴールへの進み具合を確認する |
| スプリントレビュー | できた成果物を関係者に見せ、次に何をするかを話し合う |
| スプリントレトロスペクティブ | 仕事の進め方を見直し、改善点を決める |
スプリントの途中では、スプリントのゴールを危うくする変更はしません。
新しい要望は、原則として次のスプリントの計画で扱います。
カンバンの基本
カンバンは、作業の流れ（ワークフロー）を見える化し、同時に進める作業の量を制限して、流れを改善していく方法です。
スクラムのような決まった役割や、固定の期間はありません。
今のチームの進め方をそのまま出発点にできます。
中心となる道具は、作業の状態を列にしたボードです。
| 未着手 | 開発中（上限3） | レビュー待ち（上限2） | 完了 |
|---|---|---|---|
| 検索機能の追加 | ログイン画面の修正 | CSV出力 | 問い合わせフォーム |
| メール通知 | 管理画面の一覧 |
列に付けた「上限」が、仕掛かり中の作業（WIP）の制限です。
上限に達した列には、新しい作業を入れません。
その代わりに、詰まっている作業を先に片付けます。
たとえば「レビュー待ち」が上限の2件に達したら、開発者は新しい実装を始める前に、レビューを手伝います。
カンバンでは、作業が着手から完了までにかかった時間（サイクルタイム）や、一定期間に完了した件数（スループット）を見て、流れの詰まりを見つけます。
たとえば、サイクルタイムが前の月より延びていたら、どの列でカードが長く止まっているかをボードで確かめます。
違いを比べる
| 観点 | スクラム | カンバン |
|---|---|---|
| 期間の区切り | スプリント（1か月以内の固定の長さ） | なし。作業は随時流れる |
| 役割 | プロダクトオーナー、スクラムマスター、開発者 | 決まった役割はない |
| 作業量の制御 | スプリントで取り組む量を、計画時に決める | 列ごとのWIP制限で、同時に進める量を絞る |
| 途中の変更 | スプリント中は、ゴールを崩す変更をしない | 優先順位は随時入れ替えられる |
| 改善のきっかけ | スプリントごとのレトロスペクティブ | 指標やボードの詰まりを見て、随時行う |
| 導入の負担 | 役割とイベントをそろえる必要がある | 今の進め方に、ボードとWIP制限を足せば始められる |
大まかに言うと、スクラムは「期間で区切って、計画どおりに届ける」仕組みです。
カンバンは「流れを止めずに、詰まりを減らす」仕組みです。
小規模チームでの選び方
どちらが優れているかではなく、チームの仕事の性質で選びます。
判断の目安を挙げます。
スクラムが向いている場合
次のような仕事が中心なら、期間で区切って届けるスクラムが合います。
- 新しいサービスや機能を、まとまった単位で作っている。
- 2週間ごとなど、定期的に依頼者へ成果を見せる必要がある。
- 依頼者の要望が多く、優先順位を決める人（プロダクトオーナー）を立てられる。
たとえば、受託で新規のWebアプリを作る場合です。
2週間ごとにスプリントレビューで画面を見せると、依頼者との認識のずれを早く見つけられます。
カンバンが向いている場合
次のような状況では、期間で区切るより、作業の流れを管理するほうが合います。
- 問い合わせ対応や不具合の修正など、作業が予定外に入ってくる。
- 1件ごとの作業が小さく、大きさもばらばらである。
- 複数の案件や、運用と開発を、同じ人が並行して担当している。
たとえば、公開済みのサービスの保守を担当するチームです。
障害の対応を「次のスプリントまで待つ」わけにはいかないため、優先順位を随時入れ替えられるカンバンのほうが合います。
3〜5人のチームでの注意
スクラムを3人のチームで行うと、スクラムマスターやプロダクトオーナーを、開発者が兼ねることになりがちです。
兼務自体は珍しくありませんが、優先順位を決める人と作る人が同じだと、依頼者の視点が抜けやすくなります。
プロダクトオーナーだけは、依頼者側の担当者にお願いするなど、役割を分ける工夫をします。
迷う場合は、カンバンのボードとWIP制限から始めるのが手軽です。
今の進め方を変えずに始められ、あとから定期的なレビューやふりかえりを足すこともできます。
導入でつまずきやすい点
会議だけを取り入れる
スクラムのイベントだけを行い、スプリントのゴールを決めないと、毎日の朝会が進捗報告の場になります。
ゴールがあるから、デイリースクラムで「ゴールに間に合うか」を話せます。
まず、スプリントごとに1文でゴールを書くところから始めます。
WIP制限を設けないカンバン
ボードに列を作っただけでは、作業の状態を並べた一覧にすぎません。
WIP制限がないと、着手中の作業ばかりが増え、完了する件数は増えません。
上限は、最初は「開発中の列は人数と同じ数」のように単純に決め、詰まり具合を見て調整します。
ボードと実際の作業がずれる
ボードの更新が後回しになると、誰も見なくなります。
作業の状態を変えたら、その場でカードを動かすことをチームの決まりにします。
GitHub Projects のように、プルリクエストの状態と連動できる道具を使うと、更新の手間を減らせます。
改善の時間を取らない
どちらの方法も、進め方を見直す時間がなければ効果が出ません。
カンバンには決まったふりかえりの場がないため、2週間に1回など、見直しの時間を予定に入れておきます。
ふりかえりの進め方は、KPTで進めるふりかえりで解説しています。
まとめ
スクラムとカンバンの選び方は、次のように整理できます。
- まとまった機能を定期的に届けるなら、スプリントで区切るスクラムを選ぶ。
- 予定外の作業が多く、優先順位が頻繁に変わるなら、カンバンを選ぶ。
- 迷ったら、ボードとWIP制限から始め、必要に応じて定期的なレビューとふりかえりを足す。
どちらを選んでも、最初の形のまま固定する必要はありません。
数週間ごとに進め方を見直し、チームに合う形へ調整していきます。
