Jiraのワークフロー・課題タイプ設計：ステータスと遷移、課題タイプ階層をどう決めるか

ボードより手前に、決めることがある

当サイトの「Jiraのボード運用実務ガイド」は、スクラムボードとカンバンボードのどちらで運用するかという設計を扱った。だが、その記事が前提にしていたのは「列にはワークフロー上のステータスが1つ以上マッピングされる」という仕組みそのものである。列を作る前に、そもそもどんなステータスと遷移（トランジション）を用意するか、そして課題（イシュー）をどの課題タイプの階層で管理するかが決まっていなければ、列の設計は始められない。

この記事は、ボードという表示層の手前にある設定層、つまりワークフロー（ステータスと遷移）の作り方と、課題タイプ（エピック・標準・サブタスクの階層、プロジェクト種別ごとの既定タイプ）の決め方を、Atlassian公式ドキュメントの仕様から整理する。ツールそのものの選定は「プロジェクト管理ツール比較」を参照してほしい。

この記事の編集基準

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

ワークフローとは何か：ステータスと遷移

Atlassian公式ドキュメント「Understand workflows」は、ワークフローを「ステータスと遷移の組み合わせで、課題がその中を移動していくもの」と定義している。組織内のプロセスを表現する仕組みという位置づけである。

ワークフローを構成する要素は2つしかない。ステータスは「チームのプロセスにおける段階であり、作業の状態を説明するもの」。遷移は、課題がステータス間を移動する経路であり、遷移は一方向であるため、AからBへ、Bへ戻すという往復の動きを作るには、それぞれ別の遷移を2本用意する必要がある。ステータスを変えずに画面（トランジション画面）を開いたり、何らかの処理だけを走らせたりするための、同じステータスへ戻るループ遷移も作成できる。

組み込み（デフォルト）のワークフローは編集できないが、コピーして自分たちのワークフローのベースにすることはできる。編集できるのは、コピーして作った独自のワークフロー、またはチーム管理プロジェクトで最初から作られる編集可能なワークフローに限られる。

ワークフロースキーム：会社管理とチーム管理でルートが違う

ワークフローは「特定のプロジェクトと、必要であればワークフロースキームを使って特定の課題タイプとも関連付けられる」。この関連付けの単位がワークフロースキームであり、会社管理プロジェクトではワークフロースキームを通じて、プロジェクトと課題タイプの組み合わせごとに異なるワークフローを割り当てる。編集権限はサイト管理者、またはワークフローの編集権限を持つユーザーに限られる。

チーム管理プロジェクトでは、この間接層を経由しない。プロジェクト名の横の「その他の操作」（•••）から「プロジェクト設定」→「課題タイプ」を選び、編集したい課題タイプを選択して「ワークフローを編集」を開く。既定では「To Do」「進行中」「完了」という3つのステータスが用意され、ステータスカテゴリー（未着手・進行中・完了）によって複数のステータスを1つの区分にまとめられる。複数の課題タイプに、それぞれ別のワークフローを割り当てることも可能である。編集権限はサイト管理者、またはプロジェクト管理者が持つ。

ワークフローが「1つ以上のプロジェクトで現在使用中」の状態はアクティブと呼ばれ、この状態では名前を変更できない。名前を変えたい場合もコピーして作り直す必要がある。

遷移（トランジション）を作る手順

会社管理プロジェクトでワークフローに遷移を追加する手順は次のとおりである。「設定」→「課題」を選び、「ワークフロー」で対象のワークフローの「その他の操作」（•••）から「編集」を開く。表示された図の上部にある「遷移を追加」を選び、遷移元のステータスと遷移先のステータスを指定して名前を付け、「追加」を選ぶ。図の上で2つのステータスの間に直接線をドラッグして遷移を作ることもできる。

繰り返しになるが、遷移は一方向である。ステータスAからBへ移す遷移を作っても、BからAへ戻す遷移は別に用意しなければ、課題を差し戻すことができない。ワークフローの設計段階で、差し戻しの経路が要るステータスの組み合わせを洗い出しておく必要がある。

チーム管理プロジェクトでは、ワークフロー編集画面で変更を加えたあと「ワークフローを更新」を選び、対象の課題タイプを確認してから保存する流れになる。

課題タイプの階層：エピック・標準・サブタスク

Atlassian公式ドキュメント「What are work types?」（現行の英語表記では課題タイプを「work type」、課題を「work item」と呼ぶ。呼び替えについては後述する）は、課題タイプを「異なるカテゴリの作業を区別するもの」と説明し、3つの階層レベルを定義している。

エピックは「Jiraにおける高レベルの取り組みや、より大きな作業のまとまりを表す」課題である。標準課題は「日常的な業務を表す」もので、バグ・ストーリー・タスクといった種類がここに含まれる。サブタスクは「標準課題をより小さな単位に分割する」ために使う課題であり、サブタスクは子にしかなれず、それ自体が親になることはできない。

親子関係には上限がある。1件の親課題に表示できる子課題は最大500件で、公式ドキュメントはこの件数を超えないよう管理することを推奨している。

プロジェクトの種類ごとの既定タイプ

チーム管理プロジェクトでは、プロジェクトの立ち上げ方によって最初に使われる課題タイプが異なる。カンバンプロジェクトとして始めた場合はすべてのタスクが既定で「Task」に分類され、スクラムプロジェクトとして始めた場合は「Story」に分類される。そこから推奨タイプ（Epic・Bug・Task・Story・Subtask）を追加していく形になる。

プロジェクトの種別ごとの既定タイプは次のとおりである。

チーム管理プロジェクトでのカスタム課題タイプ

課題タイプを追加するには、プロジェクト名の横の「その他の操作」（•••）から「プロジェクト設定」→「課題タイプ」を開き、「+ 課題タイプを追加」を選ぶ。Atlassianが提案する課題タイプから選ぶか、独自の課題タイプを作成できる。1プロジェクトに追加できる課題タイプは最大30種類である。

既存の課題タイプは、名前・アイコン・説明・必須フィールドを編集できる。削除する場合、その課題タイプを使っている課題が既にあると警告が出て、削除前に別の課題タイプへ変更するよう求められる。変更しないまま削除を進めると、既存の課題の表示や検索に不具合が起きる。

用語の呼び替えに注意する

Atlassian公式ドキュメントは、2026年8月31日時点で英語表記の用語を置き換えている。旧来の「project」は「space」、「issue」は「work item」、「issue type」は「work type」という表記に変わっている。ページのURL自体は旧来の表記（例：work-with-issue-workflows、what-are-issue-types）のままだが、実際に表示されるページタイトルは「Understand workflows」「What are work types?」のように新しい表記になっている。日本語で定着している「プロジェクト」「課題」「課題タイプ」という言葉と、英語版ドキュメントの最新表記が一致しないことがある点は、公式ドキュメントを直接参照する際に前提として持っておくとよい。

設計の進め方

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

STEP1：課題の階層を決める。エピック・標準課題・サブタスクという3階層の枠組みに、自分たちのプロジェクト種別の既定タイプ（ビジネス／ソフトウェア／サービスマネジメント）を当てはめ、足りない種類だけをチーム管理プロジェクトなら「+ 課題タイプを追加」から補う。

STEP2：ステータスを決める。既定の「To Do」「進行中」「完了」を土台に、チームの現場で実際に使われている状態の呼び方に合わせて増減させる。ステータスカテゴリー（未着手・進行中・完了）の枠内で複数のステータスをまとめることもできる。

STEP3：遷移を洗い出す。あるステータスから別のステータスへ進む遷移だけでなく、差し戻しに使う逆方向の遷移も必要な組み合わせを先に一覧にしておく。遷移は一方向なので、往復させたい経路はそれぞれ別に作る。

STEP4：会社管理プロジェクトかチーム管理プロジェクトかで編集の入り口を確認する。会社管理はワークフロースキーム経由、チーム管理はプロジェクト設定の「課題タイプ」から直接編集という違いがあるため、管理者権限の所在も含めて確認する。

STEP5：ここまでの設定が終わってから、ボードの列を設計する。列はワークフローのステータスを表示するためのものなので、ステータスと遷移が固まっていない段階で列を作ると、後からの列の組み替えが増える。列・WIP制限・累積フロー図の設計手順は「Jiraのボード運用実務ガイド」に譲る。