カンバン運用ガイド¶

関連issue: #91, #136 作成日: 2026-03-10

目次¶

カンバンとは
カンバンの4つの原則
カンバンボードの構成
WIP制限の実践
カンバンのメトリクス
ハンズオン: GitHub Projectsでカンバンを運用する
スクラムとの比較・使い分け
MyLabプロジェクトでの適用例
参考資料

1. カンバンとは¶

起源¶

カンバンはトヨタ自動車の「かんばん方式」が起源。工場の生産ラインで、前工程から後工程への部品供給を「かんばん（看板カード）」で制御する仕組み。

2007年にDavid J. Andersonがソフトウェア開発に適用し、「Kanban（カンバン）メソッド」として体系化した。

核心的なアイデア¶

「仕掛かり作業（WIP: Work In Progress）を制限することで、フロー（流れ）を改善する」

やることを「見える化」する
同時にやる量を制限する
完了を優先する（新しく始めるより、今やっていることを終わらせる）

スローガン: 「始めるのをやめて、終わらせることを始めよう（Stop starting, start finishing）」

2. カンバンの4つの原則¶

原則1: 今やっていることから始める¶

既存のプロセスを大きく変える必要はない。今のワークフローをそのままボードに可視化するところから始める。

原則2: 漸進的・進化的な変化を追求する¶

一気に変革するのではなく、小さな改善を継続的に積み重ねる。

原則3: 現在のプロセス、役割、責任、肩書きを尊重する¶

カンバンはフレームワークではなく「メソッド」。既存の組織構造に上書きするのではなく、重ねて使う。

原則4: あらゆるレベルのリーダーシップ行為を奨励する¶

マネージャーだけでなく、チームの全員が改善提案できる文化を作る。

3. カンバンボードの構成¶

最もシンプルなボード（3列）¶

┌──────────────┬──────────────┬──────────────┐
│   To Do      │ In Progress  │    Done      │
│              │              │              │
│  □ タスクA   │  □ タスクC   │  ☑ タスクE   │
│  □ タスクB   │  □ タスクD   │  ☑ タスクF   │
│  □ タスクG   │              │              │
│              │              │              │
└──────────────┴──────────────┴──────────────┘

まずはこの3列で始める。慣れたら列を増やす。

実践的なボード（5列）¶

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ Backlog  │  To Do   │   In     │  Review  │   Done   │
│          │          │ Progress │          │          │
│          │ WIP: 5   │ WIP: 3   │ WIP: 2   │          │
│          │          │          │          │          │
│ □ タスクA│ □ タスクC│ □ タスクE│ □ タスクG│ ☑ タスクI│
│ □ タスクB│ □ タスクD│ □ タスクF│          │ ☑ タスクJ│
│ □ ...    │          │          │          │          │
└──────────┴──────────┴──────────┴──────────┴──────────┘

列	役割
Backlog	やるべきことの全体リスト。優先順位付け済み
To Do	今週（今スプリント）やること。WIP制限あり
In Progress	今まさに取り組んでいるタスク。WIP制限あり
Review	レビュー待ち。PRレビューやテスト確認など
Done	完了したタスク

列の設計ルール¶

列は「ワークフローの実態」に合わせる（理想ではなく現実を反映）
最初は3列から始め、ボトルネックが見えたら列を追加する
列が多すぎると管理コストが増えるので、5〜7列程度が目安

4. WIP制限の実践¶

WIP制限とは¶

各列に「同時に置けるカードの最大数」を設定すること。カンバンの最も重要な概念。

なぜWIP制限が効くのか¶

人間はマルチタスクが苦手。タスクを切り替えるたびにコンテキストスイッチのコストが発生する。

# WIP制限なし（マルチタスク）
タスクA: ████░░░░████░░░░████  → 完了まで15日
タスクB: ░░░░████░░░░████░░░░████ → 完了まで16日
タスクC: ░░░░░░░░░░░░░░░░░░░░████ → 完了まで20日
（░ = 待ち時間、█ = 作業時間）

# WIP制限あり（シングルタスク）
タスクA: ████████               → 完了まで5日
タスクB:         ████████       → 完了まで10日
タスクC:                 ████████ → 完了まで15日

WIP制限があると、個々のタスクの完了が早くなり、全体のスループット（単位時間あたりの完了数）も向上する。

WIP制限の目安¶

状況	WIP制限の目安
個人（1人）	In Progress: 2〜3
小規模チーム（3〜5人）	In Progress: チーム人数の1〜1.5倍
中規模チーム（6〜10人）	In Progress: チーム人数の1〜2倍

WIP制限の運用ルール¶

WIP制限に達したら、新しいタスクを始めない
代わりに、他の人のタスクを手伝う（ペアプロ、レビュー等）
WIP制限を破る場合は、チームで合意する
「緊急の障害対応」など正当な理由がある場合のみ
定期的にWIP制限を見直す
最初は緩めに設定し、徐々に絞って最適値を見つける
ボトルネックが見えたら調整する

WIP制限を体感するハンズオン¶

準備: 付箋（またはメモ用紙）を10枚用意する

10個の日常タスクを書き出す（洗濯、買い物、勉強、etc.）
WIP制限なしで3日間タスクを管理する（何でも始めてOK）
WIP制限 = 3 で3日間タスクを管理する（In Progressは3枚まで）
両方の期間で「完了したタスクの数」と「各タスクの完了までの時間」を比較する

5. カンバンのメトリクス¶

リードタイム¶

タスクがBacklogに入ってからDoneになるまでの時間。顧客視点の指標。

リードタイム = Done日時 - Backlog登録日時

サイクルタイム¶

タスクがIn Progressに入ってからDoneになるまでの時間。チーム作業の効率を測る指標。

サイクルタイム = Done日時 - In Progress開始日時

スループット¶

一定期間に完了したタスクの数。

スループット = 完了タスク数 / 期間
例: 1週間で10タスク完了 → スループット = 10タスク/週

CFD（累積フロー図）¶

各列のカード枚数の推移を積み上げグラフで表示する。ボトルネックの発見に有効。

カード数
  ^
  |   ____________________  Done
  |  /   _________________  Review
  | /   /  _______________  In Progress
  |/   /  /  _____________  To Do
  |   /  /  /              Backlog
  +-------------------------> 時間

2つの線の間隔が広がっている = その列にタスクが溜まっている = ボトルネック。

6. ハンズオン: GitHub Projectsでカンバンを運用する¶

Step 1: プロジェクトを作成する¶

GitHubリポジトリの「Projects」タブを開く
「New project」をクリック
テンプレートは「Board」を選択（またはBlankから作成）
プロジェクト名を入力して「Create project」

Step 2: 列（ステータス）をカスタマイズする¶

デフォルトでは Todo / In Progress / Done の3列。以下のようにカスタマイズする:

ボードビューで「+」をクリックして列を追加
列名を設定:
Backlog - 全体のタスクプール
Todo - 今週やること
In Progress - 作業中
Review - レビュー待ち
Done - 完了

Step 3: Issueをカードとして追加する¶

列の下部にある「+ Add item」をクリック
既存のIssueを検索して追加、または新しいIssueを直接作成
ドラッグ&ドロップでカードを列間で移動

Step 4: WIP制限を意識して運用する¶

GitHub Projects v2にはWIP制限の組み込み機能はないが、以下の方法で運用できる:

方法1: 列名にWIP制限を明記する

In Progress [WIP: 3]
Review [WIP: 2]

列名を「In Progress [WIP: 3]」のように変更し、チームで合意する。

方法2: 列の説明欄にルールを記載する

列の設定画面で説明欄にWIP制限ルールを書く。

方法3: GitHub Actionsで自動チェック（上級）

WIP制限を超えたときにアラートを出すActionsワークフローを設定できる。

Step 5: 自動化を設定する¶

GitHub Projectsのビルトイン自動化を有効にする:

プロジェクト設定の「Workflows」を開く
以下のワークフローを有効化:

ワークフロー	動作
Item added to project	Issueが追加されたら自動でBacklogに配置
Item closed	IssueがCloseされたら自動でDoneに移動
Pull request merged	PRがマージされたら自動でDoneに移動
Item reopened	Issueが再オープンされたらTodoに移動

Step 6: フィルタービューを作成する¶

特定の条件でカードを絞り込むビューを作成する:

自分のタスクだけ表示: assignee:@me
ラベルで絞り込み: label:bug
今週のタスクだけ: イテレーションフィールドで @current を使用

7. スクラムとの比較・使い分け¶

比較表¶

観点	カンバン	スクラム
イテレーション	なし（継続的フロー）	スプリント（1-4週間固定）
役割	特に定めない	PO, SM, Dev Team
変更	いつでも変更可能	スプリント中は変更しない
WIP制限	列ごとに設定	スプリントバックログで間接的に制限
計画	必要に応じて随時	スプリントプランニング
振り返り	必要に応じて随時	スプリントレトロスペクティブ
向いている場面	保守運用、サポート、個人開発	新規開発、チーム開発

どちらを選ぶか¶

以下に当てはまるならカンバン:
  - 要件が頻繁に変わる
  - 継続的に発生するタスク（保守、サポート等）
  - 1人または少人数で開発している
  - まずシンプルに始めたい

以下に当てはまるならスクラム:
  - 明確なゴールと期限がある
  - 5-9人のチームで開発している
  - 定期的な振り返りとリズムが必要
  - ステークホルダーへの定期的なデモが必要

スクラバン（Scrumban）¶

スクラムとカンバンのハイブリッド。スプリント制を採用しつつ、WIP制限とフロー管理を取り入れる。実務では最も多い運用形態の一つ。

8. MyLabプロジェクトでの適用例¶

個人開発でのカンバン運用¶

MyLabリポジトリは個人開発プロジェクトなので、シンプルなカンバンが最も適している。

推奨ボード構成¶

┌──────────┬──────────┬──────────┬──────────┐
│ Backlog  │  Todo    │   In     │   Done   │
│          │ WIP: 5   │ Progress │          │
│          │          │ WIP: 3   │          │
│          │          │          │          │
│ #134 WBS │ #136 カン│ #91 タスク│ #XX 完了 │
│ #135 ガン│  バン    │  管理    │  済み    │
│ #137 GHP │          │          │          │
└──────────┴──────────┴──────────┴──────────┘

運用ルール（個人開発向け）¶

Backlog: 思いついたタスクはまずここに入れる
Todo: 今週取り組むタスクを5つまで選ぶ（週次で見直し）
In Progress: 今まさにやっているタスクは3つまで
Done: 完了したらIssueをCloseする（自動でDoneに移動）

WIP制限を守るための心構え¶

個人開発では自分がボトルネックになりやすい。特に:

「あれもこれもやりたい」と手を広げがち → WIP制限で抑制
レビュアーがいないのでReview列は不要（個人開発では省略可）
完了の定義を明確にする（「動いたら完了」ではなく「ドキュメントも書いたら完了」等）

GitHub Projectsでの具体的な設定例¶

MyLabリポジトリのGitHub Projectsで以下を設定する:

ボードビュー「カンバン」 を作成
Backlog / Todo / In Progress / Done の4列
自動化ワークフロー を有効化
Issue追加時 → Backlog
Issue Close時 → Done
フィルタービュー を作成
「今週のタスク」: イテレーションフィールドで @current
「学習系タスク」: ラベルで learning を絞り込み

9. 参考資料¶

無料で学べる資料¶

Asana: かんばんとは何か？ - トヨタ発祥の歴史からソフトウェア開発まで
Atlassian: カンバン vs スクラム - 最も網羅的な比較記事
Atlassian: カンバンのWIP制限の実行 - WIP制限の設定方法
スクラムチームのためのカンバンガイド（PDF） - Scrum.org公式
Udemy: Kanban - A Concise Introduction（無料） - 無料で基礎を網羅

書籍（深掘りしたい場合）¶

「リーン開発の現場」Henrik Kniberg - 現場でどうやるかが分かる実体験ベース
「カンバンソフトウェア開発の変革」David J. Anderson - カンバンメソッドの原典
「Personal Kanban」Jim Benson - 個人タスク管理に特化

実務ブログ¶

ToC(制約理論)から理解する「カンバン」の真価（Qiita） - 「なぜWIP制限が効くのか」が腹落ちする
GitHubフル活用でカンバン方式の開発体制構築（Qiita）

次のステップ¶

カンバンの基本を理解したら、次は GitHub Projects v2 ハンズオンガイドで、GitHub上での実践的な運用方法を学ぼう。