Jiraのボード運用実務ガイド：スクラムボードとカンバンボードの使い分けを設計する

ツールを選んだ後に、もう一段の設計が要る

当サイトの「プロジェクト管理ツール比較」では、Jiraを「ソフトウェア開発をアジャイルで進め、ワークフローを細かく定義したい組織」向けの第一候補として整理した。だが実際にJiraを選んだPMが次にぶつかるのは、機能一覧の理解ではなく「自分たちのチームはスクラムボードとカンバンボードのどちらで運用するのか」という設計の問いである。

この2つは画面の見た目が似ているため、深く考えずにどちらかを選び、数か月後にスプリントの区切りが実態に合わない、あるいはバックログが際限なく積み上がるといった形で運用のひずみが表面化することが多い。この記事は、Atlassian公式ドキュメントに明記されている機能の違いから、どちらを選ぶべきかの判断軸と、選んだ後の列・WIP制限・監視方法までを設計する。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。価格や機能の記述は、Atlassian公式のサポートドキュメント（support.atlassian.com）で確認できた範囲に限定している。

ボードの基本設計：どちらの型も土台は同じ

Atlassian公式ドキュメントは、ボードを「チームの作業をカードとして表示し、列の間を移動させられるもの」と定義している。既定では「To Do（未着手）」「In Progress（進行中）」「Done（完了）」の3列が用意され、各列にはワークフロー上のステータスが1つ以上マッピングされる。複数のステータスを1つの列にまとめて表示することもできる。

公式ドキュメントはボードの役割を「より戦術的」なものと位置づけている。数週間から数か月先までを見るタイムライン（ロードマップ）に対し、ボードは「次の1〜2週間程度、チームが今まさに進めている作業の状況を示す」ためのものだとされている。表示できる作業項目は最大5,000件で、完了した項目はスプリント機能が有効な場合は保持され、無効な場合は14日後に自動的に列から外れる。

この基本設計はスクラムボードとカンバンボードで共通している。違いが生まれるのは、この上に「バックログをどう扱うか」「区切り（スプリント）を置くかどうか」という運用ルールを重ねたときである。

スクラムボード：区切りを作り、区切りの中で完了させる

スクラムボードの中心はバックログタブである。作業項目の作成、優先順位づけ（ドラッグ＆ドロップによるランク付け）、スプリントへの割り当てをここで行う。バックログに表示される項目には条件があり、サブタスクではないこと、ボードのフィルター条件に合致していること、ステータスがいずれかの列にマッピングされていることが必要で、最右列には少なくとも1つのステータスがマッピングされている必要がある。

スプリントの運用は、スプリントを作成し、対象の作業項目をドラッグ＆ドロップで追加し、準備が整った段階で「スプリント開始」を選ぶという流れになる。既定では同時に進められるアクティブなスプリントは1つに制限されるが、並行スプリント機能を有効化すれば複数のスプリントを同時に走らせることもできる。

この設計が向くのは、プロダクトバックログがあり、一定の周期でコミットメントを区切って成果を確認したいチームである。何をこのスプリントで終わらせるかを事前に合意する運用と、スクラムボードの「バックログ→スプリント」という構造は噛み合っている。

カンバンボード：区切りを置かず、流れを絶やさない

カンバンボードにもバックログ機能はあるが、既定では無効になっており、Jira管理者またはボード管理者が有効化する必要がある。有効化すると、作業項目は「Backlog」と「Selected for Development」という2つのセクションに分かれ、着手候補をこの2つの間でドラッグして絞り込む。表示条件はスクラムと同じく、ボードのフィルターに合致しステータスが列にマッピングされている項目に限られる。

カンバンバックログが役に立つのは、バックログの件数が増えてきた場面だと公式ドキュメントは説明している。ボードの最初の列に未着手の項目をすべて置いたままにすると、件数が増えるほどスクロールが煩雑になるため、専用のバックログビューに切り出す設計になっている。

スクラムとの決定的な違いは、スプリントという単位を持たないことである。カンバンは継続的なフローを前提としており、問い合わせ対応・保守運用・PMOへの依頼受付のように、作業が随時流れ込み、かつ一定周期でのコミットメントに区切る意味が薄い業務に向いている。

どちらを選ぶか：作業の入り方で決める

機能の多さでは選べない。分岐点は「自分たちの作業が、区切って計画できるものか、随時流れ込むものか」である。

列とWIP制限を設計する

ボード名の横にある「その他の操作」（•••）から「ボード設定」を開き、「レイアウト」の「列」で列の追加・名前変更・削除・並べ替えができる。1つの列に複数のワークフローステータスをまとめて割り当てることも可能で、チームの現場の言葉に合わせて列名を整えられる。

運用の質を左右するのはWIP制限（列の制約）である。公式ドキュメントは「各ワークフローの状態に制約を設けることは、カンバンの重要な要素である」と明記している。設定は列ごとの制約から行い、対象を「すべての作業項目」で数えるか、「サブタスクを除いた作業項目」で数えるかを選べる。スクラムでは後者（サブタスク除外）が推奨されている。上限を設定すれば、超過時に列ヘッダーが赤くなり、下限を下回れば黄色になるという視覚的なフィードバックが得られる。

この制約はカンバンボードに限らず、スクラムボードでも設定できる。スプリント内で複数の作業項目に同時に着手して手が止まる状態を避けたいなら、スクラムボードにもWIP制限を置く価値がある。アジャイルの教科書的な区分（スクラム＝WIP制限なし、カンバン＝WIP制限あり）を機械的に当てはめず、自分たちのボトルネックに合わせて設定するのが実務的である。

累積フロー図でボトルネックの列を見つける

運用を始めてから2〜4週間ほど経ったら、累積フロー図（Cumulative Flow Diagram）を確認する。これは横軸に時間、縦軸に作業項目数（カード数）を取り、各色の領域がボードの列（ワークフローステータス）に対応するエリアチャートである。

見るべきは、時間の経過とともに垂直方向に広がっていく領域である。公式ドキュメントは「その広がっている領域に対応する列が、通常はボトルネックになっている」と説明している。累積フロー図からは、作業項目が「進行中」の状態を通過して着手可能になるまでの所要時間（サイクルタイム）、同時に手をつけている作業項目数（仕掛かり量）も読み取れる。スクラムチームであれば、スプリントごとにどれだけの作業をコミットしたかというスコープの推移も見える。

ボトルネックの列が特定できたら、その列のWIP制限を下げて流入を絞るか、その工程の担当を増やすかを検討する。列を増やす、名前を変えるといった表面的な調整だけでは、蓄積の原因は解消しない。

設計の進め方

ここまでを、導入直後に踏む順序として並べ直す。