公開2025.07.24更新2026.10.24 開発

Jiraの使い方｜スペース作成・エピックの使い分けと「使いにくい」の解消法【2026年10月】

Jiraは、Atlassianが提供するプロジェクト管理ツールです。2024年から2025年にかけて製品構成と画面の用語が大きく変わり、Cloud版ではJira SoftwareとJira Work Managementが「Jira」に統合され、「課題」は「作業項目」に、「プロジェクト」は「スペース」に改称されました。数年前の解説記事どおりに操作しようとすると、メニューの名前がそもそも見つかりません。

この記事では2026年10月時点のJira Cloudを前提に、スペースの作成から作業項目の階層、ボード、JQL、自動化までを、実務で詰まる順に説明します。「Jiraは使いにくい」と感じている人向けに、原因と設定での直し方も1章にまとめました。

まとめ：2026年のJiraで押さえる要点

2026年10月時点で押さえる要点は次のとおりです。

Cloud版では、Jira SoftwareとJira Work Managementが2024年に「Jira」へ統合されました。
Freeは10ユーザーまで無料です。有料の一覧価格は2026年10月13日に上がり、1〜100ユーザー帯でStandardが月9.70ドル、Premiumが月19.60ドルです。
自動化は実行回数ではなく「ステップ数」を組織全体で数える方式に変わり、2026年12月3日から超過分が課金されます。Standardは1ユーザーあたり月400ステップです。
画面の用語は「作業項目（旧：課題）」と「スペース（旧：プロジェクト）」です。JQLとREST APIは旧来の書き方のまま動きます。
Server版は2024年2月15日にサポートが終わり、Data Centerも2026年3月30日に新規販売を終えました。これから導入するならCloudの一択です。
使い始めで最も重いのは「チーム管理対象スペース」と「企業管理対象スペース」の選択です。10人前後の1チームなら前者、部門をまたいで運用を揃えるなら後者を選びます。
「使いにくい」と感じたら、スペースタイプ・通知量・必須フィールドを確認します。通知と入力項目は設定を見直し、スペースタイプが合わなければ別スペースへの移行も検討します。

Jiraとは：2024〜2025年に変わった製品と用語

Jiraは、追跡したい仕事を「作業項目」という単位に分け、担当者・状態・期限を紐づけて管理するツールです。バグ1件、機能1つ、申請1件がそれぞれ作業項目になり、ボードで状態を動かし、JQLで検索し、ダッシュボードに集計します。ExcelとJiraの違いは、行が状態を持ち、状態の変化が履歴として残ることです。誰がいつレビュー待ちにしたかを後から追えるため、リードタイムの測定や停滞の発見ができます。

解説記事と画面の名前が一致しないのは、ここ2年で次の変更が重なったためです。

Jira SoftwareとJira Work Managementの製品統合

Atlassianは2024年5月に、開発チーム向けのJira Softwareと、非開発部門向けのJira Work Managementを1つの「Jira」に統合しました（Atlassianの発表）。開発チームはスプリントやバックログを、マーケティングや人事のチームはリストやカレンダーを、同じ製品の中で使います。

サービスデスク用途のJira Service Managementと、アイデア管理のJira Product Discoveryは別製品のまま残っています。統合されたのはJira SoftwareとJira Work Managementの2つだけです。

提供形態：Server終了とData Centerの販売終了日程

Server製品のサポートは2024年2月15日に終了し、セキュリティ更新も不具合修正も配布されていません。Data Centerでも、2026年10月公表のAtlassian 脆弱性CVE-2026-21589のように修正版への更新が必要な脆弱性が出ています。さらにAtlassianは自社ホスト型のData Centerにも終了日程を出しています（Atlassianの移行案内）。

日付	Data Centerで起きること
2026年3月30日	新規顧客への販売終了
2028年3月30日	既存顧客の新規契約・追加購入・アップグレード終了（更新は継続）
2029年3月28日	サポート終了・ライセンス失効

2029年3月28日を過ぎると、Data Centerの製品は読み取り専用になります。更新契約もこの日を越えて延ばせず、日割りで打ち切られます。いまData Centerを使っている組織は、2028年3月までにCloudへの移行計画を固める必要があります。新規に導入する組織にはCloud以外の選択肢がありません。

用語の変更：「課題」は作業項目、「プロジェクト」はスペース

Jiraはバグ管理ツールとして生まれたため、追跡対象を「issue（課題）」と呼んできました。この呼称は2025年に「work item（作業項目）」へ変わりました。PremiumとEnterpriseは2025年4月14日から順次展開され、バンドル・リリーストラックの利用者には2025年7月10日に反映されると告知されました（Atlassian Communityの告知）。

続いて2025年9月1日から、作業項目を入れる箱である「project（プロジェクト）」が「space（スペース）」に改称されました。FreeとStandardが先に切り替わり、PremiumとEnterpriseは2025年10月20日から、リリーストラック利用者を除く全プランへの展開は2025年11月10日、リリーストラック利用者への反映は2025年12月9日の予定でした（Atlassian Communityの展開日程）。目標や期日を束ねる別機能「Atlassian Projects」と名前を区別するための変更で、告知は「名前だけの変更で、機能・動作・範囲は変わらない」と明記しています（Atlassian Communityの告知）。Data Centerにはこの改称を入れる予定はないとされているため、Data Centerの画面は「プロジェクト」のままです。

実装への影響は小さく済みます。既存のREST APIはissueのまま動き、JQLの project や issuetype といったフィールドも、保存済みフィルターもそのまま使えます。この記事では画面の表示に合わせて「作業項目」「スペース」と書き、JQLとAPIの文脈では元の英語のまま書きます。

料金プランと無料枠の上限

Cloud版のプランは4つです。Freeは10ユーザーまで無料で使え、11人目を招待する時点で有料プランへの移行が必要になります。

プラン	月額（1〜100ユーザー帯）	ユーザー数	ストレージ	稼働率SLA
Free	0ドル	10まで	2GB	なし
Standard	9.70ドル	100,000まで	250GB	なし
Premium	19.60ドル	100,000まで	無制限	99.9%
Enterprise	見積もり	801〜100,000	無制限	99.95%

月額は2026年10月13日に改定された一覧価格で、改定前はStandardが9.05ドル、Premiumが18.30ドルでした（Atlassianのクラウド価格表）。月払いは人数帯ごとに単価が下がる累進制で、Standardは101〜250人目が8.20ドル、251〜1,000人目が6.85ドルです。300人で平均すると1ユーザーあたり約8.48ドルです。Jiraの料金ページで人数に応じた見積もりを確認できます。表示額は選択した人数や請求周期によって異なるため、計算機の条件も確認してください。ストレージとSLAはJira Cloudのプラン比較によります。サンドボックスと後述のプラン機能はPremium以上です。

Jiraの使い方：スペース作成から日次運用までの6手順

最初にやることは多くありません。使い始めるまでの流れは次の6手順です。

Atlassianアカウントを作り、Cloudサイト（自社名.atlassian.net）を発行する
スペースのテンプレート（スクラム／カンバン／バグ追跡など）を選ぶ
スペースタイプ（チーム管理対象か企業管理対象か）を決める
ボードの列を、チームの実際の作業の流れに合わせる
メンバーを招待し、作業項目を登録する
ボードでステータスを動かし、日次運用に入る

手順の詳細と画面は公式の「Jira の使い方：概要」にあります。ここでは、テンプレートとスペースタイプの選択、列の設計、入力項目の決め方を説明します。

テンプレートとスペースタイプの選び方

テンプレートは、反復開発で見積もりとベロシティを扱うならスクラム、割り込みを流しながら滞留を抑えるならカンバン、ボードより一覧で不具合を管理するならバグ追跡を選びます。

テンプレートより重いのが、その次に出るスペースタイプの選択です。チーム管理対象スペースは、スペースの管理者が自分で列やフィールドを変えられる代わりに、設定がそのスペースの中で閉じます。企業管理対象スペースは、ワークフローや画面をJira管理者が共有スキームとして管理し、複数のスペースで揃えられます。10人前後で1スペースならチーム管理対象、部門をまたいで数十のスペースを同じルールで運用するなら企業管理対象です。スペースタイプは作成後に切り替えられず、変えるには新しいスペースを作って作業項目を移すことになるため、最初の選択で決めておきます。

ボードの列とワークフローの対応設定

ボードの列は、作業が完了へ向かう段階（ワークフロー）をそのまま表します。テンプレートの初期値は「To Do／進行中／完了」の3列ですが、レビューやテストの待ちが発生するチームなら「レビュー待ち」「検証中」を足します。列が実態と合っていないと、カードが「進行中」に溜まったまま本当の詰まりが見えません。

列を増やしすぎるのも逆効果です。「設計中」「設計レビュー中」「設計完了」のように1人の作業を細かく刻むと、ステータスの更新が手間になり誰も動かさなくなります。未着手・進行中・完了を基本に、滞留を把握したい「レビュー待ち」などの列を追加します。担当者の引き継ぎや判断に使わない細分化は避けます。

作業項目の登録と必須フィールドの決め方

作業項目の作成時に埋める欄は、要約、作業タイプ、担当者、優先度、期限、説明です。運用が崩れるのは、どれを必須にするか決めないまま人数を増やしたときです。最低限、要約・作業タイプ・担当者の3つは全員が入れる約束にします。期限を入れる文化がないなら空欄のままで構いません。期限欄を使わない場合も、完了を目指す時期はスプリントの終了日などで明示します。ボードの列は作業の状態を表すもので、締切日の代わりにはなりません。

担当者は1つの作業項目に1名しか設定できません。複数人で進める作業は、サブタスクに分けて個々に担当者を付けるか、レビュー担当をカスタムフィールドで持たせます。Excelの管理表から移ってきたチームが最初に戸惑うのがこの点です。

日次の更新とコメント運用

日々の操作では、たとえばカードを「進行中」から「レビュー待ち」へ移し、コメントに「決済APIのエラー処理を変更したため、再試行条件の確認をお願いします」と判断理由と依頼内容を残します。コメントに書くのは作業ログではなく判断と依頼です。「調査中です」はステータスが示しているので要りません。後から読んで、なぜその方式にしたのかを追える情報だけを残します。

作業項目の階層：エピック・ストーリー・タスク・サブタスクの使い分け

エピックは、大きな仕事を複数のストーリーやタスクに分けて管理するための作業タイプです。階層の定義があいまいなままだと、タイムラインもバーンダウンも数字が合わなくなります。

エピック・ストーリー・タスクの境界

標準の階層は、上からエピック、その下にストーリー／タスク／バグ、さらに下にサブタスクです。エピックは「決済機能の刷新」のように複数のストーリーへ分割する大きな作業のまとまりで、複数スプリントにまたがることが一般的です。リリースとの対応はチームの計画によって決まります。ストーリーは利用者から見た価値の単位（「利用者がクレジットカードを登録できる」）、タスクは価値には直結しないが必要な作業（「決済APIのキー発行」）です。

判断基準は「1スプリントで終わるか」です。終わらないならエピックに上げ、終わるならストーリーかタスクに置きます。ストーリーとタスクの違いで悩む時間は成果を生まないので、迷ったら「利用者に説明できる価値か」だけで振り分け、チーム内の定義を1行書き残しておけば足ります。

ストーリーをエピックに紐づける欄は、以前の「エピックリンク」から「親」フィールドに一本化されています。古い手順で「Epic Link」欄を探しても見つからないのはこのためです。PremiumとEnterpriseでは、エピックより上の階層（「イニシアチブ」など）を追加できます。

サブタスク・リンク・ラベル・コンポーネントの違い

サブタスクは親の作業項目に従属し、単独ではスプリントに積めません。リンク（blocks／relates to など）は対等な作業項目どうしの関係で、依存関係を見せるために使います。ラベルは誰でも自由に付けられるタグ、Jiraコンポーネントは企業管理対象スペースで利用できる分類で、スペース管理者が「認証基盤」「決済」などを定義し、既定の担当者を紐づけられます。チーム管理対象スペースでは利用できません。

恒久的な分類はコンポーネント、一時的な横串はラベル、と分けます。「2026年上期対応」のような期間限定の括りをコンポーネントで作ると、半年後に不要な選択肢として残り続けます。逆に、担当チームが決まっている領域をラベルで運用すると、表記ゆれ（authとAuth）で集計が割れます。

スクラムボードとカンバンボードの選び方

2つのボードの違いはスプリントの有無です。手法そのものの比較はウォーターフォールとアジャイル・スクラムの違い｜比較表と使い分け・契約形態の選び方に、スクラムの役割とイベントはスクラム開発とは？進め方・3つの役割・5つのイベントとメリット・デメリットをスクラムガイドで解説にまとめています。

スプリント運用（スクラム）とWIP制限（カンバン）

スクラムボードにはバックログ画面があり、作業項目をスプリントに積んでから開始します。1〜2週間程度の期間を区切り、その中で完了させる運用です。ベロシティ（スプリントごとの完了ポイント）が溜まると、次のスプリントに積める量が読めるようになります。

カンバンボードにはスプリントがなく、作業は入口から出口へ連続して流れます。制御に使うのがWIP制限で、列ごとに同時に置ける枚数の上限を決めます。「進行中」を5枚までにすれば、6枚目を入れた時点で列の表示が警告に変わり、新しい作業を始める前に滞留を片付けることになります。スプリントごとに目標と作業量を調整する開発にはスクラム、割り込みを受けながら仕掛かり量を制御する運用にはカンバンを選びます。リリース日の有無だけでは選び分けません。WIP制限とリードタイムの測り方はカンバン方式のタスク管理とは？ボードの作り方とWIP制限・リードタイムの測り方で詳しく扱っています。

バーンダウンチャートとベロシティの読み方

スクラムボードでは、バーンダウンチャート（残作業の推移）とベロシティチャート（スプリントごとの完了量）が自動で作られます。バーンダウンが理想線どおりに落ちることはまずないので、傾きより「終盤まで水平で、最終日に垂直に落ちる」形になっていないかを見ます。この形では、完了が終盤に集中した理由を確認します。途中のステータスを毎日更新していても、完了判定が最後に集中すれば同じ形になるため、更新漏れとは断定できません。

ベロシティは他チームとの比較に使えません。ストーリーポイントの基準はチームごとに違うので、並べても優劣は測れません。自チームの過去数スプリントの平均と比べる用途に限ります。

タイムラインとプラン機能の用途・契約条件

「Jiraでガントチャートのような計画表を作りたい」という要望には2つの機能が対応し、契約プランによって使えるものが分かれます。

タイムラインは、エピックを行、期間を横軸に並べるビューで、Freeプランでも使えます。エピックの開始日と期限を入れ、依存関係を線で結べば、遅れが後続に波及する様子が見えます。

複数のスペース・複数のチームをまたいで計画するプラン機能（旧称Advanced Roadmaps）は、PremiumとEnterpriseでだけ使えます。チームごとの容量を入れてスケジュールを算出したり、シナリオを複数作って比べたりできますが、Standardでは選択肢に出てきません。「Jiraでロードマップが引ける」と紹介される機能の多くはこちらなので、契約プランを確かめてから設計してください。WBSやガントチャートとの役割分担はプロジェクト管理とタスク管理の違い｜PMBOKの定義とWBSでのつなぎ方・ツールの階層で整理で整理しています。

JQLとダッシュボードによる定型レポートの作成

JQL（Jira Query Language）は作業項目を絞り込むクエリ言語です。画面の用語が変わった後も、フィールド名は project や issuetype のままです。

project = ABC AND statusCategory != Done AND assignee = currentUser() ORDER BY priority DESC
project = ABC AND issuetype = Bug AND created >= -14d
project = ABC AND status CHANGED TO "In Progress" AFTER -7d
project = ABC AND status = "In Review" AND updated <= -3d

各行は別々に実行する検索例です。ABCは自分のスペースキーに、作業タイプ名とステータス名は実際の設定値に置き換えます。1行目は自分の未完了作業、2行目は直近14日間に作成されたBug、3行目は直近7日間にIn Progressへ遷移した作業、4行目はIn Reviewで最終更新が3日以上前の作業です。実務で効くのは3行目と4行目のような時間条件です。CHANGED TO や WAS を使うと「今どうなっているか」ではなく「いつ状態が変わったか」で検索できます。構文の一覧はAtlassianのJQLドキュメントにあります。

書いたJQLは保存済みフィルターにして、ダッシュボードのガジェットに割り当てます。フィルター結果、円グラフ、スプリントの健全性といったガジェットを1画面に並べれば、朝会で開く定型レポートになります。ダッシュボードは共有先を特定のグループに絞れるので、管理職向けと開発チーム向けを分けて作るのが定石です。フィルターの購読を使えば、結果を定期的にメールで届けることもできます。

自動化フローのステップ上限と消費量の見積もり

Jiraの自動化は、トリガー（作業項目の作成、ステータスの変更など）、条件、アクション（担当者の設定、Slackへの通知など）をノーコードで組み合わせる機能です。以前の「ルール」は、いまの画面とドキュメントでは「フロー」と呼ばれています。設計の前に知っておくべきなのは、使える量に月ごとの上限があり、その数え方が2026年に変わったことです。

以前は製品ごとにフローの実行回数で数えていました（Standardは月1,700回、Enterpriseは無制限）。現在は、フローの中で動いたトリガー・条件・アクション・分岐・ループの1つずつを「ステップ」として数え、組織全体で合算する方式です（Atlassianの使用量の計算方法）。Jiraに含まれる月間のステップ数は次のとおりです。

プラン	Jiraの月間ステップ数	10ユーザーの組織なら
Free	150（サブスクリプションごと）	150
Standard	400×ユーザー数	4,000
Premium	750×ユーザー数	7,500
Enterprise	1,000×ユーザー数	なし（801ユーザー以上で契約）

ConfluenceやJira Service Managementを契約していれば、その分のステップも同じ枠に足されます。超過分は2026年12月3日から1,000ステップあたり0.50ドルで課金され、超過の利用を無効にしている組織では、枠を使い切った時点で全フローが次の請求日まで止まります。Rovoのエージェントを呼ぶアクションはステップではなく、Rovoのクレジットで別に数えます。

この数え方が設計を左右します。トリガーが条件に合わず先へ進まなかった場合でも、トリガーの1ステップは消費されます。「作業項目が更新されるたびに走る」フローは、コメント1件でも最低1ステップを使い、条件と通知のアクションが続けば1回で3ステップになります。10人のStandardなら月4,000ステップなので、1日に数百回更新される現場では月の途中で尽きます。スケジュールトリガーを毎朝1回実行しても、検索で見つかった作業項目ごとに通知すれば、その件数に応じてステップ数が増えます。月間消費量は起動回数だけでなく、対象件数と各項目に実行する処理数から見積もります。まずスケジュール型で組み、Atlassian Administrationの「インサイト」から「プラットフォームの使用状況」で消費を確かめてから、イベント型を足す順にしてください。GitHubのコミットやプルリクエストから作業項目を動かす連携はJiraとGitHubを連携する方法｜GitHub for Jiraで課題キー・スマートコミット設定で扱っています。

「Jiraは使いにくい」の原因と設定での解消法

「jira 使いにくい」「jira 使いづらい」は一定数検索されています。原因を機能の多さに求める解説が多いのですが、現場で詰まる箇所はもっと限られます。確認するのはスペースタイプ・通知量・必須フィールドの3点です。通知と入力項目は設定で見直せますが、スペースタイプが合わない場合は別スペースへの移行が必要です。

1つ目はスペースタイプの取り違えです。企業管理対象スペースでも、スペース管理者やボード管理者は列を追加できます。ただし、列に対応する新しいステータスの追加は、ワークフローの設定によってはJira管理者の操作が必要です。「ステータスを増やしたいだけなのにJira管理者への申請が要る」という不満は、共有ワークフローの変更にJira管理者の対応が必要な場合に生まれます。10人前後の1チームで設定を自分たちで変えたいなら、チーム管理対象のほうが合います。逆に、全社でルールを揃えたいのにチーム管理対象を配ると、スペースごとにワークフローがばらばらになり、同じ基準で横断集計するためにステータスやフィールドの対応整理が必要になります。

2つ目は通知の出しすぎです。既定のままだと、ウォッチしている作業項目のあらゆる変更でメールが届きます。通知が日に3桁届くようになると誰も読まなくなり、本当に必要な依頼が埋もれます。通知スキームを絞り、Slack連携で「自分が担当者になったとき」「メンションされたとき」だけ届くようにすると、受信箱の量は大きく減ります。

3つ目は必須フィールドの入れすぎです。「あとで分析したいから」と必須項目を10個作ると、作業項目の登録が苦行になり、誰も登録しなくなります。データが集まらないので分析もできません。フィールドは「今すぐ集計に使う」ものに絞り、必要になった時点で足すほうが、最終的に集まるデータは多くなります。

Jiraを使うべきでない場面もあります。作業項目が週に数件しか発生しない少人数のチーム、ステータスが2つしかない一本道の業務、成果物の議論が文書中心で状態の遷移に意味がない仕事です。これらはスプレッドシートやConfluenceのようなドキュメントツールで足り、Jiraを入れると管理の手間だけが増えます。中小規模でツールを選び直すなら、費用と定着の判断軸を中小企業のプロジェクト管理ツールの選び方｜コスト・機能過不足・定着で外さない判断軸に、JetBrainsの代替製品はYouTrackとは？料金・無料プランの範囲とJiraとの違い、使い方を解説【2026年9月】にまとめています。スペース設計や運用ルールづくりを外部に任せたい場合は、一創の要件定義・RFP作成・PMO支援でプロジェクト管理の立ち上げから支援しています。

よくある質問

Jiraとは何ができるツールですか？

作業項目を単位に、タスクの登録、担当者の割り当て、ステータス管理、進捗の可視化を行うツールです。スクラムとカンバンのボード、スプリント管理、JQLによる検索、ダッシュボードでのレポート、自動化ルールまでを1つの製品で扱います。2024年にJira SoftwareとJira Work Managementが統合されたため、開発以外のチームの業務管理にも同じ製品を使えます。