compare
Jiraのワークフローを作り込みすぎたとき｜状態の数を減らす
Jiraのワークフローを調べている段階では、たいてい作る側で困っています。テンプレートのままでは実際の手順と合わない、あるいは合わせて作り込んだ結果、誰も正しく状態を動かせなくなっている。どちらも同じ原因から来ています。
先に結論を書きます。ワークフローの品質は、表現できる細かさではなく、状態の数の少なさで決まります。状態が7つある設計は、5つに減らすと運用が続きます。増やすときに考えるべきなのは「この状態を誰が見て、何を判断するか」の1点で、判断する人がいない状態は、記録の役に立たず入力の手間だけを増やします。
だけど、テンプレートに出てくるワークフロースキームは、実際の作業のワークフローと近いけど手順がちょっと違うクマね～。例えば、「ブログ」のテンプレートには、うちの部門の場合公開前に「コーディング」というワークフローがもう一つ必要クマ。 出典: ricksoft.jp
この記事では、ワークフローの構成要素の定義から始めて、テンプレートとの付き合い方、作り込みすぎたときに起きること、状態の数を減らす手順、条件とバリデーターと事後操作の使いどころ、編集するときの制約、そして道具を選ぶときの見方までを順に扱います。
ワークフローはステータスとトランジションの2つでできている
用語を先に固めます。公式のドキュメントでは、Jiraのワークフローは課題がライフサイクルの間に通過する一連のステータスとトランジションであり、通常は組織内のプロセスを表すもの、と説明されています。
ステータスは、ある時点の課題の状態です。「進行中」のような呼び方をします。公式のドキュメントには、課題に与えられるステータスは常に1つだけ、と明記されています。ここが重要な点で、「実装は終わったがレビュー待ちで、同時にテスト待ち」という状態を1つの課題で表すことはできません。
トランジションは、2つのステータスを繋ぐ道です。公式のドキュメントでは、2つのステータス間で課題を移動するにはトランジションが存在する必要があり、トランジションは一方向性のリンクだと説明されています。つまり、「レビュー中」から「進行中」へ戻す必要があるなら、行きと戻りで2本のトランジションを作ることになります。
この2つの関係が、設計の難しさの本体です。ステータスを1つ増やすと、そこへ入る道と出る道が必要になります。戻る道も要るなら、トランジションは一気に増えます。ステータスが5つのときにトランジションが8本だったものが、ステータスを7つにすると15本を超えることがあります。
さらに、ワークフローをプロジェクトや課題タイプに結び付けるのがワークフロースキームです。公式のドキュメントでは、ワークフロースキームを利用することで、特定のプロジェクトや、必要に応じて特定の課題タイプにワークフローを関連付けられると説明されています。1つのワークフローを複数のプロジェクトで共有できるので、変更の影響範囲を把握しておく必要があります。
つまり、ワークフローを設計する作業は、状態の名前を決める作業ではありません。状態と状態の間にどの道を通すかを決める作業です。名前を増やすのは簡単で、道を正しく引くのが難しい、という非対称があります。
テンプレートは出発点として使い、そのまま使わない
Jiraにはワークフローのテンプレートが用意されています。これをどう扱うかで、その後の手間が変わります。
これはアトラシアン社が様々な業態やタスクや業務フローを調査して、「新入社員オンボーディング」や「調達」など、王道のワークフローをテンプレート化したものです。 出典: ricksoft.jp
テンプレートの価値は、抜けている状態を教えてくれることです。自分たちで一から考えると、「差し戻し」や「保留」のような状態を忘れます。テンプレートを見ると、そういう状態が必要になる場面があることに気づけます。
一方で、テンプレートをそのまま使うと合いません。合わない理由は、その組織の手順に固有の工程が1つか2つあるからです。公開の前に確認の工程が入る、納品の前に検収の工程が入る、といった違いです。この1つか2つを足す作業が、実際の設計作業になります。
ここで注意が要ります。公式のドキュメントでは、既定の組み込みワークフローは編集できないが、コピーして使えば独自のワークフローを作れる、と説明されています。つまり、いきなり既定のものを直そうとしても進みません。コピーを作ってから触ることになります。
足すときの原則は、1つずつ足して1週間運用することです。まとめて3つ足すと、どれが合わなかったのかが分かりません。1つ足して、その状態に実際にカードが入るかを確かめます。1週間でその状態を1件も通らなかったなら、その状態は不要です。
逆に、テンプレートから減らす作業も必要になります。テンプレートに入っている状態のうち、自分たちが使わないものは最初に消します。残しておくと、誰かが誤ってそこへ移動させて、以降その課題が忘れられます。使わない状態は、存在するだけで事故の原因になります。
作り込みすぎたワークフローで起きる3つのこと
状態とトランジションを増やしていくと、順に3つのことが起きます。
1つめは、入力する人が状態を選べなくなることです。状態が7つあると、いま自分の作業がどれに当たるのかを考える必要が出ます。「確認待ち」と「レビュー中」と「承認待ち」が並んでいると、どれを選ぶべきかが人によって変わります。結果として、同じ作業が別の状態に入り、集計が合わなくなります。
2つめは、動かせない場所が生まれることです。トランジションは一方向なので、戻る道を引き忘れると、間違えて進めた課題を戻せなくなります。戻せないと分かった人は、課題を1つ作り直します。作り直された課題は履歴が切れているので、経緯を辿れなくなります。
3つめは、直せる人が1人になることです。ワークフローを管理するには権限が必要です。公式のドキュメントでは、ワークフローにアクセスして管理するにはJira管理者のグローバル権限を持つユーザーとしてログインする必要があり、プロジェクト管理者の権限では新しいワークフローを作成できず、編集できるのは既定以外で他のプロジェクトと共有されていないワークフローだけ、と説明されています。作り込むほど、直すのに管理者を呼ぶ回数が増えます。
この3つが重なると、運用の形が変わります。担当者が状態を動かさなくなり、とりまとめる人が全員に聞いて回って代わりに動かす、という形に落ちます。この状態になると、ワークフローは実態の記録ではなく、報告のための書類になります。
進行をとりまとめる立場の人にとって重いのは、ここの復旧です。状態を減らす作業は、すでに動いている課題を別の状態へ移す作業を伴います。500件の課題が動いているプロジェクトで状態を2つ減らすと、その2つに入っている課題を全部移すことになります。だから、増やす前に考えるほうが圧倒的に安く済みます。
状態の数を減らす手順
減らすときの手順は4つです。数える、見る人を確かめる、統合する、道を引き直す。
最初に数えます。各状態に、直近3か月で何件の課題が入ったかを数えます。件数がゼロか、10件未満の状態は削除の候補です。使われていない状態は、設計上の理想として作られただけで、実際の手順には存在しません。
次に、その状態を見て判断する人がいるかを確かめます。「レビュー中」を見て動く人がいるなら残します。誰も見ていないなら、その状態は記録にしかなっていません。記録が必要なら、状態ではなくコメントやラベルで残せます。状態は、次に動く人を決めるためのものです。
3つめに統合します。「確認待ち」と「承認待ち」が別の人の作業を指しているなら残しますが、同じ人が同じ行動をするなら1つにまとめます。まとめるときは、残す側の名前を決めて、消す側に入っている課題を一括で移します。
最後に道を引き直します。状態を1つ消すと、そこを経由していた道が2本消え、代わりに1本引く必要が出ます。引き忘れると、前の状態から次の状態へ進めなくなります。減らす作業で事故が起きるのは、ほぼこの引き忘れです。
移すときの実務も見積もっておく価値があります。500件の課題が動いているプロジェクトで状態を2つ統合すると、一覧で絞り込んで一括更新する操作が2回必要になります。この操作で通知が全員に飛ぶ設定になっていると、500件分の通知が一度に届きます。作業の前に通知の設定を確かめて、必要なら一時的に止めるほうが混乱が少なくなります。
減らしたあとの目安は、状態が5つ以内、トランジションが10本以内です。この規模だと、新しく入った人が1回説明を聞くだけで覚えられます。覚えられる設計にすることが、正しく運用される条件です。
実務で残す価値がある5つの状態
減らしたあとに何を残すかは、業種が違っても似た形になります。多くのチームで機能するのは次の5つです。
1つめは「未着手」です。作られたが誰も手を付けていない課題を溜める場所です。この状態に入っている件数が、そのチームの積み残しの量になります。ここが増え続けているなら、引き受ける量が処理できる量を超えています。
2つめは「進行中」です。いま誰かが手を動かしている課題です。この状態の件数を1人あたり2件までに保つのが、進行を早くする最も単純な方法です。5件並行している人は、どれも終わりません。
3つめは「確認待ち」です。担当者の作業は終わり、別の人の判断を待っている状態です。この状態が最も渋滞します。渋滞するのは、確認する人が1人に集中しているからです。件数が10件を超えたら、確認できる人を増やす話になります。
4つめは「差し戻し」です。確認で止まって、担当者に戻った課題です。この状態を「進行中」に混ぜると、初めから作っているものと直しているものが区別できなくなります。分けておくと、確認で落ちる割合が見えます。落ちる割合が高いなら、作り始める前の合意が足りていません。
5つめは「完了」です。終わった課題です。ここに入った課題を後から動かさない約束にしておくと、集計が安定します。動かす必要が出た場合は、新しい課題を作って前の課題からリンクを張ります。
この5つの外側で必要になりやすいのが「保留」です。外部の返事を待っていて、自分たちでは動かせない課題を入れます。ただし、保留は溜まる一方になりやすいので、入れるときに「いつまで待つか」を書く決まりを付けます。日付を書かない保留は、忘れられます。
逆に、作らないほうがよい状態もあります。「レビュー中」と「承認待ち」の両方、「テスト中」と「検証中」の両方のように、同じ人が同じ行動をする状態を2つ並べるのは避けます。細かく分けたい気持ちは、状態ではなく担当者やラベルで満たせます。
条件とバリデーターと事後操作を使う場所
Jiraのトランジションには、動きを細かく制御する仕組みが用意されています。公式のドキュメントでは、Jira管理者が制御できる側面として、トリガー、条件、バリデーター、事後操作、プロパティが挙げられています。
条件は、そのトランジションをユーザーが実行してよいかを検査します。公式のドキュメントでは、報告者にのみ実行を許可する、特定の権限を持つユーザーにのみ実行を許可する、といった例が示されています。条件が満たされない場合、トランジションのボタンが表示されず実行できないとも説明されています。
バリデーターは、トランジションの実行前に入力が有効かどうかを検査します。公式のドキュメントでは、トランジション画面でユーザーから収集した入力も対象になり、検証が失敗した場合は目的のステータスに進まず、事後操作も実行されないと説明されています。条件は入力パラメーターを検証できないため、それを行うにはバリデーターを使う必要があるとも明記されています。
事後操作は、トランジションのあとに追加の処理を行います。公式のドキュメントでは、課題フィールドの更新、変更履歴の生成、コメントの追加、メール通知を起こすイベントの生成が例として挙げられています。
使いどころの原則は、1つのワークフローで使うのを2つまでに抑えることです。多くのトランジションに条件とバリデーターを付けると、ボタンが表示されない理由が誰にも分からなくなります。「動かせません」という相談が来たとき、条件が3階層に入れ子になっていると、原因を探すのに時間がかかります。
特に気を付けるべきなのは、条件のグループ化です。公式のドキュメントでは、条件をグループ化し入れ子にすることで複雑な条件を作れると説明されています。作れることと、あとで読めることは別です。入れ子を使うのは、承認の手順が法令や契約で決まっている場合だけに限るほうが安全です。
開発ツールからの自動遷移を使うかどうか
Jiraのワークフローには、外部の出来事で状態を動かす仕組みもあります。公式のドキュメントでは、リンク済みの開発ツール内のイベントに応答するトリガーをワークフローに設定できると説明されていて、開発者がブランチを作って課題に対して作業を始めると、課題が自動的に「オープン」から「進行中」へ遷移する例が挙げられています。
この仕組みが効くのは、状態の更新を人が忘れる場合です。作業を始めたのに状態が「未着手」のまま残っている課題は、進行の把握を狂わせます。ブランチを作った時点で自動的に動くなら、忘れる余地がなくなります。
一方で、注意すべき点が2つあります。1つめは、自動で動いた状態が現実と合わない場合です。試しにブランチを作っただけで「進行中」になると、実際には手を付けていない課題が進行中として数えられます。2つめは、自動で動いたことに気づかない人が出ることです。自分が動かしていない課題の状態が変わっていると、誰が変えたのかを探す手間が生まれます。
使い方の原則は、開始だけを自動にして、完了は人が動かすことです。完了の判定には人の判断が要るので、自動化すると誤りが混ざります。開始は誤っても影響が小さいので、自動でよいです。
また、トリガーを設定するには権限が必要です。公式のドキュメントでは、トリガーを追加するにはJira管理者のグローバル権限を持つユーザーとしてログインし、管理の課題からワークフローを選んで編集する手順が示されています。日々の運用の中で気軽に変えられる設定ではないので、最初に決めておくほうがよいです。
編集するときの制約を先に知っておく
ワークフローを直す作業には、稼働中かどうかで違う制約がかかります。
公式のドキュメントでは、非アクティブなワークフローは現在プロジェクトで使用されていないもので、トランジション中の課題が存在しないためステップやトランジションを直接編集でき、変更は自動で保存されると説明されています。手動で保存や公開をする必要はないとも書かれています。
一方、アクティブなワークフローは1つ以上のプロジェクトで使われているもので、編集すると下書きが作成されます。編集が完了したら下書きを公開し、元のワークフローを非アクティブなバックアップとして保存できると説明されています。制限として、ワークフローがアクティブな場合は名前を編集できず、編集できるのは説明のみとも明記されています。
この違いが実務で効くのは、試す場所を作れるかどうかです。稼働中のワークフローを直接いじると、公開した瞬間に全員の画面が変わります。先にコピーを作って、新しいプロジェクトに割り当てて、そこで試してから本番へ持っていく手順を踏むほうが安全です。
もう1つの制約が、共有の範囲です。ワークフロースキームで複数のプロジェクトに同じワークフローを割り当てている場合、1つを直すと全部に反映されます。あるプロジェクトのために状態を1つ足したことが、別のプロジェクトの画面にも現れます。共有しているかどうかを、直す前に確かめる必要があります。
ここが、ワークフローを作り込む設計の隠れたコストです。1つのプロジェクトの都合で足した状態が、他のプロジェクトの運用を乱します。だから、プロジェクトごとに違う手順があるなら、ワークフローを共有しないほうがよい場合もあります。ただし共有しないと、管理するワークフローの数が増えます。どちらを取るかは、プロジェクトの数と手順の違いの大きさで決めます。
運用が始まってから効いてくる3つの観測点
設計が終わったあと、その設計が機能しているかを測る方法があります。見るのは3つです。
1つめは、状態ごとの滞留時間です。課題が「確認待ち」に平均何日いるかを見ます。ここが長いなら、状態の設計ではなく人の配置の問題です。確認できる人を増やすか、確認の基準を軽くするかのどちらかになります。滞留時間を状態の数のせいにすると、状態を減らしても改善しません。
2つめは、飛ばされている状態です。トランジションが引かれているのに、実際にはほとんど通らない状態があります。「未着手」から直接「確認待ち」へ飛ぶ経路が多用されているなら、その間の状態は実務では存在しません。飛ばされる状態は消す候補です。
3つめは、戻る回数です。「差し戻し」を通る割合が全体の3割を超えているなら、作り始める前の合意が足りていません。ワークフローを細かくしても、この割合は下がりません。下げるには、着手前に確認する項目を決める必要があります。道具の設計ではなく、仕事の順番の問題です。
この3つを月1回見るだけで、ワークフローの手入れが必要かどうかが分かります。逆に、この3つを見ないまま状態を増やしていくと、増やしたことが良かったのか悪かったのかを判定できません。判定できない変更を重ねると、最後には誰も全体像を説明できなくなります。
観測の手間も考えどころです。滞留時間を毎月集計するには、状態の変更履歴を取り出す必要があります。この集計を人が手で行うと、月に1時間以上かかります。1時間かけて集計しても、改善の打ち手が出ないなら続きません。集計が自動で出る仕組みがあるかどうかは、道具を選ぶときに確かめる価値があります。
プランによって何が変わるか
ワークフローそのものは無料の範囲でも使えます。2026年9月時点の公式の料金ページでは、カスタマイズ可能なワークフローがFreeプランから使える機能として示されています。
Freeプランの上限は、最大10ユーザーが永久に無料、ストレージが2GB、自動化のステップが1サブスクリプションあたり月150、サポートはコミュニティ、と案内されています。Standardは1ユーザーあたり月額1,085円で、ストレージ250GB、自動化は1ユーザーあたり月400ステップ、1サイトあたり最大100,000ユーザーです。Premiumは1ユーザーあたり月額1,987円で、ストレージ無制限、自動化は1ユーザーあたり月750ステップ、99.9%のアップタイムSLAが付きます。Enterpriseは問い合わせになっていて、自動化は1ユーザーあたり月1,000ステップ、複数サイトが最大150、99.95%のSLAと案内されています。
ここで見るべきなのは、自動化のステップ数です。トランジションの事後操作で処理を自動化していくと、この上限に当たります。Freeプランの月150ステップは、10人のチームで課題が毎日数件動く程度なら足りますが、通知やフィールドの更新を細かく自動化すると足りません。
つまり、ワークフローを作り込む方向へ進むと、自動化の枠も一緒に必要になります。状態を減らす設計は、この費用も一緒に減らします。状態が5つで済むワークフローは、自動化する場所も少なくなります。
金額と上限は変わるので、契約の前に公式のページで確かめてください。ここに書いた内容は2026年9月時点のものです。
状態の数と道具の形は繋がっている
ここまでの内容を、道具を選ぶ視点で整理します。
ワークフローを細かく作り込める道具は、細かく作り込むことを促します。作り込めるという理由だけで状態が増えるので、設計を我慢する力が要ります。逆に、状態の表現が素朴な道具では、そもそも作り込めないので、この問題が起きません。
どちらが向いているかは、手順が外から決まっているかどうかで分かれます。監査や契約で承認の経路が決まっているなら、条件とバリデーターで縛る道具が必要です。手順が自分たちで決められるなら、列をドラッグで動かすだけの素朴な形のほうが運用が続きます。
素朴な形の代表がカンバンです。列が状態に相当し、カードをドラッグで移します。トランジションという概念がないので、どの列からどの列へでも動かせます。戻す道を引き忘れる事故が起きません。できることのページでは、列は自由に作れて仕事の流れがそのまま画面になる形として説明されていて、同じカードをガントやカレンダーでも見られるとされています。
ただし、素朴な形には弱点もあります。誰でもどこへでも動かせるので、承認の経路を強制できません。「上司の承認を経ずに完了へ動かす」ことを機械で止められない、という性質です。承認を止める必要がある業務では、この弱さが問題になります。
自動化と外部連携で比べるなら、Jiraのような道具のほうが選択肢が多いです。Jootoとの比較やBacklogとの比較のページには、自動化と外部連携では勝負しない、リポジトリの機能は無いという制約が自分から示されています。開発の作業とワークフローの制御を1か所で扱いたいなら、いまの道具を続けるほうが正しい判断です。
移す場合に確かめるべきなのは、無料で試せる範囲です。料金のページでは、5人までは期限なしで無料、ボードは10個までで、カスタムフィールドと権限ロールも無料の範囲から使える形が示されています。機能で絞らず、区切るのは人数とボードの数だけという区切り方なので、状態を5つに減らした運用が自分たちに合うかどうかを、課金の前に1つのボードで確かめられます。
他の系統も含めて見るなら、7社を横に並べた比較の一覧から入るのが早いです。付箋型で始めやすいものはTrelloとの比較にまとまっています。移行の手間が気になる場合は、Trelloからの移行のページで、ボードとリストの構成、カードの説明、ラベル、チェックリスト、添付ファイル、コメントが運ばれる範囲を確かめられます。
最後に、道具を替えても状態の数の問題は解決しません。7つの状態を7つの列として作り直せば、同じ混乱が起きます。先に状態を5つに減らして、それでも制御の仕組みが足りないなら道具を見直す。この順番で進めるほうが、無駄な移行が減ります。
Q1. Jiraのワークフローで状態はいくつまで作るべきですか？
5つ以内、トランジションは10本以内を目安にしてください。状態が7つあると、入力する人がどれを選ぶべきか迷い、同じ作業が別の状態に入って集計が合わなくなります。増やすかどうかの判断は、その状態を見て動く人がいるかどうかで決めます。誰も見ない状態は、入力の手間だけを増やします。
Q2. テンプレートのワークフローはそのまま使えますか？
抜けている状態を教えてくれる出発点としては役に立ちますが、そのままでは合いません。公開前の確認や納品前の検収のように、その組織に固有の工程が1つか2つあるためです。公式のドキュメントでは、既定の組み込みワークフローは編集できず、コピーして使えば独自のものを作れると説明されています。
Q3. 一度作ったワークフローを直すときに気を付けることは何ですか？
稼働中かどうかで制約が違います。公式のドキュメントでは、アクティブなワークフローを編集すると下書きが作られ、公開が必要で、アクティブな間は名前を編集できないと説明されています。ワークフロースキームで複数のプロジェクトに割り当てている場合、1つの変更が全部に反映されるので、共有の範囲を先に確かめてください。
Q4. 条件やバリデーターはどこまで使ってよいですか？
1つのワークフローで2つまでに抑えるのが安全です。多くのトランジションに付けると、ボタンが表示されない理由が誰にも分からなくなります。条件のグループ化と入れ子は作れますが、あとから読むのが難しくなるため、承認の手順が法令や契約で決まっている場合に限るのが現実的です。