Jira で担当者ごとの WIP 制限を設定する方法
Kayabyte 著 · 更新日 2026年11月2日
結論: Jira の標準設定ではできません。ボードの列の制約は、1 つのボードの列にある作業項目をすべて数えて警告を表示するだけなので、1 人が抱える作業の量は制限できません。JQL とダッシュボードを使えば担当者ごとの仕掛中の作業を確認でき、自動化を使えば移動後に警告を出せます。担当者が上限に達しているときに作業の開始そのものを止めたい場合は、スクリプトによるワークフロー バリデーターか、Personal WIP Limits: Work in Progress per Person for Jira (英語) のようなアプリが必要です。
ボードの列の制約は、1 つの列に作業が溜まりすぎるのを防ぐものです。1 人が列の大半を抱え込むことは防げません。「誰も同時に 3 件を超えて進行中にしない」という運用にしたい場合、Jira Cloud だけでどこまで実現できるのか、各方法の限界とあわせて順に説明します。フロー理論 (リトルの法則や、列ごとの制限では足りない理由) については、Kanban WIP limit per person in Jira (英語) を参照してください。
列の制約でできること、できないこと
ボードの設定の 列 では、列ごとに作業項目の最小数と最大数を設定できます。上限を超えると、Jira が列に色を付けます。
- 制約は、担当者に関係なく、列にあるすべての作業項目を数えます。
- あくまで警告です。満杯の列にも作業を移動できます。
- 対象は 1 つのボードだけです。3 つのチームのボードで作業しているユーザーは、どの列の制約も下回ったまま、10 件を同時に進行中にすることもあり得ます。
つまり、列の制約はチームがボトルネックを把握するのには役立ちますが、1 人ひとりに上限を設けることはできません。
上限超過を確認する: フィルターとダッシュボード
少なくとも、誰の進行中の作業が多すぎるのかは確認できます。
次の JQL でフィルターを作成し、たとえば「担当者別の進行中」という名前で保存します。
statusCategory = "In Progress" AND assignee is not EMPTY ORDER BY assigneeこのフィルターを使って、フィルター結果 ガジェット、または 二次元フィルター統計 ガジェットをダッシュボードに追加し、片方の軸を 担当者 にします。
各ユーザーの件数が、そのユーザーが進行中にしている作業項目の数になります。
これは問題を可視化するだけで、誰かを止めるものではなく、確認する人も必要です。
事後に対応する: Jira の自動化
自動化を使うと、上限を超えたときに警告を出せます。
- トリガー: 作業項目の遷移時。遷移先は、進行中のステータスにします。
- アクション: 作業項目を検索 で、
assignee = {{issue.assignee.accountId}} AND statusCategory = "In Progress"のような JQL を実行します。 - 条件:
{{lookupIssues.size}}が上限より大きい。 - アクション: コメントを追加する、チーム リーダーに通知する、または作業項目を元に戻す。
注意点として、自動化は移動の後に実行されます。作業項目はすでに開始されており、あとで取り消される移動についても通知が届きます。また、2 件の移動がまったく同時に起きた場合、件数がずれることもあります。これは注意を促す仕組みであり、制限ではありません。
件数の集計はスクリプトで行いたい場合は、atlassian-admin-scripts (英語) の jira-wip-per-person スクリプトが利用できます。上限を超えているユーザーを一覧にし、スケジュール実行も可能です。無料で MIT ライセンスのスクリプトで、公開されている REST API を使用します。報告するだけで、作業の開始を止めることはなく、結果は実行した時点の状態を反映します。
移動を止める: ワークフロー ルール
担当者が上限に達しているときに作業項目の開始を止めるには、移動が行われる前に、トランジション自体でチェックを実行する必要があります。Jira の標準のバリデーターでは、ユーザーがすでに進行中にしている作業項目の数を数えられないため、スクリプトによるバリデーターかアプリが必要になります。
どちらの方法を使う場合も、先に次の点を決めておいてください。
- すべてのプロジェクトを対象にするか、プロジェクトごとにするか。 個人の作業全体に 1 つの上限を設けるのか、意図的に時間を分けて働くユーザーのためにプロジェクトごとの上限を設けるのか。
- 何を「作業の開始」とみなすか。 To Do から進行中への移動は数えるべきですが、進行中からレビュー中への移動は数えるべきではありません。
- 誰を対象外にするか。 オンコールやサポートのローテーションでは、緊急の作業を上限に関係なく引き受ける必要があることが多くあります。
- チェックが失敗したときにどうするか。 Jira の動作が遅いときにユーザーの作業をブロックする制限は、役に立つどころか害になります。その場合は、移動を許可してください。
Personal WIP Limits: Work in Progress per Person for Jira
Personal WIP Limits: Work in Progress per Person for Jira (英語) は、この課題のために弊社が開発しているアプリです。作業を開始するトランジションに設定するワークフロー ルールを追加します。企業管理対象とチーム管理対象 (team-managed) のどちらのワークフローにも対応しています。
- 担当者が上限に達している場合、Jira に「Alex has reached the limit of 3 work items in progress」と表示され、作業項目はその場にとどまります。
- すべてのプロジェクトを通算するか、プロジェクトごとに数えるかを選べます。プロジェクトごとに独自の上限を設定することも、オフにすることもでき、グループを対象外にすることもできます。
- 進行中のステータス間の移動と、担当者が未設定の作業はブロックされません。アプリがチェックできない場合は、移動が許可されます。
- 保存するのは設定だけで、Atlassian の外部への通信は行いません。
Atlassian Marketplace で入手できます。
よくある質問
Jira の列の制約で、満杯の列への作業の移動を止められますか? いいえ。上限を超えると Jira は列に色を付けますが、作業はそのまま移動できます。
Jira の自動化で、担当者ごとの WIP 制限を強制できますか? コメントの追加、通知、作業項目を元に戻すことは可能ですが、実行されるのは移動の後です。作業はすでに開始されているため、注意を促す仕組みであって、制限ではありません。
担当者ごとの進行中の作業を表示する JQL は何ですか? statusCategory = "In Progress" AND assignee is not EMPTY ORDER BY assignee です。ダッシュボード ガジェットで、片方の軸を担当者にして使用します。
Personal WIP Limits は、進行中のステータス間の移動もブロックしますか? いいえ。進行中のステータス間の移動と、担当者が未設定の作業はブロックされません。アプリがチェックできない場合も、移動は許可されます。
Jira および Atlassian は Atlassian の商標です。Kayabyte は独立した開発者であり、Atlassian と提携しておらず、Atlassian による承認も受けていません。