Jiraの使い方と基本機能｜作業項目・エピック・ボードを実務目線で解説

Jiraは、Atlassianが提供するプロジェクト・課題管理ツールです。ただし2024年から2025年にかけて、製品構成も画面上の用語も入れ替わりました。「Jira Software」という製品名はなくなり、長年使われた「課題（Issue）」という呼び名も「作業項目」に変わっています。古い解説記事のとおりに操作しようとすると、そもそもメニューの名前が見つかりません。ここでは現在のJiraを前提に、初期設定から作業項目の階層、ボード、JQL、自動化までを実務で使う順に整理します。

まとめ

いま押さえるべき要点は5つです。第一に、Jira SoftwareとJira Work Managementは2024年5月に統合され、製品名は単に「Jira」になりました。第二に、Server版は2024年2月15日にサポートが終了し、選択肢はCloudかData Centerの二択です。第三に、2025年の用語変更で「課題」は「作業項目（work item）」になりましたが、REST APIとJQLはissueのまま動きます。第四に、エピック・ストーリー・タスク・サブタスクの階層を最初に決めておかないと、ボードもレポートも意味のある数字を出しません。第五に、Jiraが使いにくいと感じる原因の大半は機能の多さではなく、チーム管理型とカンパニー管理型のどちらのプロジェクトを選んだかにあります。以下、それぞれを操作手順と数値で見ていきます。

2024年から2025年に変わったJiraの前提

Jiraの解説で最初につまずくのは、記事の中の名前と画面の中の名前が一致しないことです。ここ2年で起きた3つの変更を先に押さえておくと、公式ドキュメントも読み違えずに済みます。

Jiraとは：作業項目を単位にしたプロジェクト管理ツール

Jiraは、追跡したい仕事を「作業項目（旧称：課題）」という単位に分解し、担当者・状態・期限を紐づけて管理するツールです。バグ1件、機能1つ、申請1件がそれぞれ作業項目になり、それらをボードに並べて状態を動かし、JQLで検索し、ダッシュボードに集計します。ExcelやスプレッドシートとJiraの本質的な違いは、行が「状態を持ち、状態の変化が履歴として残る」ことです。誰がいつ何をレビュー待ちにしたかを後から追える点が、リードタイム分析や自動化の土台になります。

製品統合：Jira SoftwareとJira Work Managementの一本化

Atlassianは2024年5月1日、開発チーム向けのJira Softwareと、非開発部門向けのJira Work Managementを統合すると発表しました。以降、両者は「Jira」という単一製品として提供され、Jira Work Managementの既存契約は2025年初頭にJiraの契約へ自動的に切り替えられています。開発チームはスプリントやバックログを、マーケティングや人事のチームはリストやカレンダーを、同じプロジェクトの中で使えます。「Jira Softwareとは」という書き出しの解説を読んでいたら、それは統合前の情報です。

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

提供形態：Server版は終了し、CloudかData Centerの二択

「オンプレミス版のJira Server」を検討対象に挙げる記事がまだ残っていますが、Server製品のサポートは2024年2月15日に終了しました。技術サポート、セキュリティ更新、不具合修正のいずれも提供されません。脆弱性が見つかっても修正が配布されないため、いま新規に選ぶ形態ではありません。

現在の選択肢はAtlassianがホストするCloudか、自社インフラで動かすData Centerです。Data Centerは大規模構成や、データを自社管理下に置く要件がある場合の受け皿として残っていますが、新機能はCloudから先に入ります。特別な制約がなければCloudが既定の選択になります。

用語変更：「課題」は「作業項目」へ

Jiraはもともとバグ管理ツールとして生まれたため、追跡対象を「issue（課題）」と呼んできました。この呼称が2025年に「work item（作業項目）」へ変更されています。FreeプランとStandardプランから順次適用され、PremiumとEnterpriseは2025年4月14日以降、バンドル・リリーストラックの利用者は2025年7月10日に切り替わりました。管理者が別の言葉に変えることはできず、サイト全体で一律に置き換わります。

実装への影響は限定的です。既存のREST APIはissueという語のまま動作し、新設のAPIからwork item系の名称になります。JQLのissuetypeやissuekeyといった句、保存済みフィルターも後方互換が保たれるため、既存の自動化やダッシュボードを書き換える必要はありません。変わったのは画面表示の言葉であって、データモデルではない、と理解しておけば十分です。本記事では画面の表示に合わせて「作業項目」と書きますが、API・JQLの文脈ではissueのままである点に注意してください。

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

Cloud版は4プランです。無料で始められますが、人数とストレージに明確な線があります。

人数の線引きはFreeの10ユーザーです。スクラムチーム1つならぎりぎり収まりますが、11人目を招待する時点でStandardへの移行が必要になります（Standard以上の上限は公式ドキュメント内で35,000と100,000の記載が併存するため、大規模導入時は契約前に確認してください）。監査ログや高度な権限設定はStandard以上、サンドボックス環境と後述するプラン機能はPremium以上です。単価は2026年7月時点でStandardが1ユーザー月7.91ドル、Premiumが14.54ドル（いずれも年額請求時の目安）ですが、為替と改定で動くため、金額は必ず公式の料金ページで確認してください。

Jiraの使い方：登録から日次運用までの最短ルート

最初にやることは多くありません。テンプレートを選び、作業項目を登録し、ボードで動かす。この3つが回れば運用は始まります。

サイト作成とプロジェクトテンプレートの選択

使い始めるまでの工程は5つです。

• 1. Atlassianアカウントを作り、Cloudサイト（自社名.atlassian.net）を発行する
• 2. プロジェクトのテンプレート（スクラム／カンバン／ビジネス系）を選ぶ
• 3. チーム管理型かカンパニー管理型かを決める
• 4. メンバーを招待し、作業項目を登録する
• 5. ボードでステータスを動かして日次運用に入る

テンプレートは、反復開発で見積もりとベロシティを扱うならスクラム、流量を制御して継続的に流すならカンバン、開発以外の業務（申請処理や制作進行）ならビジネス系を選びます。

テンプレート選択より重要なのが、その次に出る「チーム管理型（team-managed）」と「カンパニー管理型（company-managed）」の選択です。チーム管理型はプロジェクト管理者が自分で設定を変えられる代わりに、設定はそのプロジェクトの中で閉じます。カンパニー管理型はワークフローや画面がJira管理者の管理する共有スキームになり、複数プロジェクトで統一できます。10人程度で1プロジェクトならチーム管理型、部門横断で数十プロジェクトを標準化するならカンパニー管理型。ここを取り違えると、後述する「使いにくい」の大半が発生します。

作業項目の登録と必須項目の決め方

作業項目の作成時に埋める欄は、要約、種類、担当者、優先度、期限、説明です。運用が破綻するのは、この中の「どれを必須にするか」を決めないまま人数を増やしたときです。最低限、要約・種類・担当者の3つは全員が入れる約束にしておきます。期限は入れる文化がないなら空欄のままでも構いません。空の期限フィールドが並ぶより、スプリントやボードの列で締切を表現するほうが実態に合います。

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

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

日々の操作はボード上でカードをドラッグしてステータスを変え、進捗の判断材料をコメントに残す、この2つに集約されます。コメントに書くのは「作業ログ」ではなく「判断と依頼」です。「調査中です」という進捗報告はステータスが示しているので不要で、「Aの方式で進めます、理由はB」「Cの確認をお願いします」といった、後から読んで意思決定を追える情報を残します。この使い分けができているチームは、後からJQLで過去の判断を掘り返せます。

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

「エピックとは何か」はJiraの検索で常に上位に来る疑問です。階層の定義があいまいなままだと、ロードマップもバーンダウンも数字が合わなくなります。

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

標準構成の階層は、上からエピック、その下にストーリー／タスク／バグ、さらに下にサブタスクです。エピックは複数スプリントにまたがる大きな塊で、「決済機能の刷新」のような、単体ではリリース単位にならない粒度を指します。ストーリーはユーザーから見た価値の単位（「利用者がクレジットカードを登録できる」）、タスクは価値には直結しないがやらねばならない作業（「決済APIのキー発行」）です。

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

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

下位の構造を表す手段が複数あり、ここも混同されがちです。サブタスクは親の作業項目に従属し、単独ではスプリントに積めません。リンク（blocks / relates to など）は対等な作業項目どうしの関係で、依存関係の可視化に使います。ラベルは誰でも自由に付けられるタグ、コンポーネントはJira管理者が定義する構成要素（「認証基盤」「決済」など）で、既定の担当者を紐づけられます。

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

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

ボードは作業項目を並べる画面ですが、スクラムとカンバンでは前提が違います。違いはスプリントの有無です。

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

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

カンバンボードにはスプリントがなく、作業は入り口から出口へ連続的に流れます。制御に使うのがWIP制限です。列ごとに「同時に置ける枚数」の上限を設定し、「進行中」に5枚まで、と決めれば、6枚目を入れようとした時点で列が赤くなる。新しい作業を始める前に滞留を片付けることが強制される仕組みです。リリース日を約束する運用に向くのがスクラム、割り込みが多い運用保守に向くのがカンバンです。開発手法そのものの違いはウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分けで整理しています。

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

スクラムボードではバーンダウンチャート（残作業の推移）とベロシティチャート（スプリントごとの完了量）が自動生成されます。バーンダウンが理想線どおりに落ちることはまずないので、傾きそのものより「スプリント終盤まで水平で、最終日に垂直に落ちる」形になっていないかを見ます。この形は、作業が終盤にまとめて完了扱いされている、つまりステータスがリアルタイムに更新されていないサインです。数字を美しくするために更新タイミングを操作した瞬間、レポートは意味を失います。

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

ロードマップとタイムライン：Jiraで計画を引く2つの機能

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

タイムライン：プロジェクト単位のロードマップ（全プラン）

タイムラインは、エピックを行、期間を横軸に表示するビューで、Freeプランでも使えます。エピックの開始日と期限を入れ、依存関係を線で結べば、遅延が後続に波及する様子が見えます。ロードマップとして最初に触れるのはこの画面です。

プラン機能（旧Advanced Roadmaps）：複数チーム横断の計画（Premium以上）

複数プロジェクト・複数チームをまたいで計画するプラン機能（旧称Advanced Roadmaps）は、PremiumプランとEnterpriseプランでのみ利用できます。容量（チームごとの供給量）を入れてスケジュールを自動算出したり、シナリオを複数作って比較したりできますが、Standardプランでは選択肢に現れません。「Jiraでロードマップが引ける」と紹介されている機能の多くはこちらを指しているため、契約プランを確認してから設計してください。

JQLとダッシュボード：検索を定型レポートにする

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

project = ABC AND status != 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

実務で効くのは3つ目のような履歴条件です。CHANGED TOやWASを使うと「今どうなっているか」ではなく「いつ状態が変わったか」を検索できます。着手から完了までの時間を追う、放置されたレビュー待ちを洗い出す、といった分析はこの構文なしには書けません。

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

自動化（Automation）：実行回数の上限を起点にしたルール設計

Jiraの自動化は、トリガー（作業項目が作成された、ステータスが変わった等）、条件、アクション（担当者を設定する、Slackに通知する等）をノーコードで組み合わせるものです。設計する前に知っておくべきなのは、実行回数に上限があることです。

2023年11月1日の体系変更以降、Jira製品ごとの月間実行回数はFreeが100回、Standardが1,700回、Premiumは有料ユーザー1人あたり1,000回で、Enterpriseは無制限です。カウント単位はルールの実行回数で、1回の実行で10個のアクションが動いても1回として数えます。未使用分の翌月繰り越しはありません。

この上限は、設計方針を左右します。「作業項目が更新されるたびに走る」ルールを作ると、コメント1件で1回消費するため、Standardの1,700回はチーム数十人の組織で数日で溶けます。回数を食うのは、頻繁に起きるイベントをトリガーにした通知系ルールです。逆に、スケジュールトリガー（毎朝1回、期限超過を検出して担当者に通知）は月20〜30回程度で収まり、費用対効果が高くなります。まず消費の大きいルールを1本だけ作り、使用量画面で実測してから増やすのが安全です。

「Jiraは使いにくい」と言われる本当の理由

「jira 使いにくい」「jira 使いづらい」という検索が一定数あります。原因を機能の多さに求める解説が多いのですが、実際に現場で詰まる箇所はもっと限定的です。断言すると、原因の大半は次の3つで、いずれも設定で解消できます。

1つ目は、前述したチーム管理型とカンパニー管理型の取り違えです。カンパニー管理型ではワークフローや画面が共有スキームで管理されるため、プロジェクト管理者の権限では列ひとつ追加できません。「ステータスを増やしたいだけなのにJira管理者への申請が要る」という不満は、10人のチームがカンパニー管理型を選んだことに起因します。逆に、全社で運用ルールを揃えたいのにチーム管理型を配ると、プロジェクトごとにワークフローが乱立して集計できなくなります。

2つ目は通知過多です。既定のままだと、自分がウォッチしている作業項目のあらゆる変更でメールが飛びます。通知が日次で3桁に達すると実質的に読まれなくなり、本当に必要な依頼が埋もれる。対処は通知スキームを絞ることです。Slack連携に寄せて「自分が担当者になったとき」「メンションされたとき」だけ届くようにすれば、受信箱の様相は変わります。

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

逆に、Jiraを使うべきでない場面もあります。作業項目が週に数件しか発生しない少人数チーム、ワークフローが1本道でステータスが2つしかない業務、成果物の議論が文書中心で作業の状態遷移に意味がない仕事。これらはスプレッドシートやConfluenceのようなドキュメントツールで足りており、Jiraを入れると管理コストだけが増えます。ツールを入れれば進行が改善するわけではないという点は、アジャイル開発はなぜ失敗するのか？で挙げられている失敗パターンとも重なります。

よくある質問（FAQ）

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

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

Jiraは無料で使えますか？

Freeプランで最大10ユーザーまで無料で使えます。ストレージは2GBまで、サポートはコミュニティのみで、監査ログや高度な権限設定は含まれません。11人目を招待する時点でStandard以上への移行が必要です。

「課題」が「作業項目」に変わったのはなぜですか？既存のJQLは動きますか？

Jiraはバグ管理ツール出身のため「課題（issue）」という語を使ってきましたが、開発以外のチームにとって実態と合わないため、2025年に「作業項目（work item）」へ統一されました。既存のREST APIはissueのまま動作し、JQLの句や保存済みフィルターも後方互換が保たれるため、書き換えは不要です。

エピック・ストーリー・タスク・サブタスクはどう使い分けますか？

1スプリントに収まらない大きな塊がエピック、収まるものがストーリーまたはタスクです。ストーリーは利用者から見た価値の単位、タスクは価値に直結しない必要作業を指します。サブタスクは親に従属し、単独ではスプリントに積めません。担当者は1作業項目につき1名なので、複数人で分担する作業はサブタスクに割るのが基本です。

ウォーターフォール型のプロジェクトでもJiraは使えますか？

使えます。カンバンボードでフェーズを列に見立てるか、スクラム機能を使わずタイムラインで工程を管理する運用が現実的です。ただしバーンダウンやベロシティは反復開発を前提としたレポートなので、ウォーターフォールでは指標として機能しません。工程表の詳細さを求めるなら、専用のガントチャートツールとの併用も検討対象になります。

関連記事

• ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け
• スクラム開発のメリットとデメリットを徹底解説
• アジャイル開発はなぜ失敗するのか？
• Confluenceの検索方法と検索機能の活用方法を徹底解説