Jira徹底活用ガイド：JQLを使い倒す！ビジネスパーソンのためのプロジェクト管理実践JQL [国外事例付]

2025 11/05

2025年11月5日 2025年11月5日

1. JQLは「魔法の呪文」か？なぜビジネスパーソンがJQLを学ぶべきなのか

JQLは開発者だけのものではない：ビジネス活用の幕開け

多くのビジネスパーソンにとって、Jiraは「開発チームがタスクを管理するツール」という認識かもしれません。しかし、Jira Query Language (JQL) は、その認識を根本から覆す可能性を秘めています。JQLは、Jiraに蓄積された膨大なプロジェクトデータから、必要な情報を自在に引き出すための「検索言語」です ¹。

アトラシアンの公式ドキュメントや国外の専門家の間では、JQLは開発者、テスター、アジャイルプロジェクトマネージャー、そして「ビジネスユーザー」のための強力なツールであると明確に位置づけられています ²。本ガイドの目的は、技術的な背景を持たないビジネスパーソンやプロジェクトマネージャーが、Jiraに眠る膨大な「データ」を、実行可能な「インサイト（洞察）」に変えるためのJQLスキルを習得することです。

ビジネス視点：JQLが解決する「3つの問い」

プロジェクト管理の本質とは、突き詰めれば「今、何が問題か？」「誰がボールを持っているか？」「進捗は順調か？」という3つの問いに、迅速かつ正確に答え続けることです。

従来、これらの問いへの答えは、週次の進捗報告会でのヒアリングや、スプレッドシートへの手作業による転記に頼りがちでした。しかし、JQLを活用することで、これらの問いに対して、Jiraの生データから「リアルタイム」で「客観的」な回答を直接引き出すことが可能になります。JQLは、「勘」や「感覚」に頼った旧来の管理スタイルから、データに基づいた（Data-Driven）プロジェクト管理へと移行するための、現代のビジネスパーソンに不可欠なスキルです。

JQLは「ビジネスインテリジェンス（BI）ツール」である

ビジネスユーザーは、Jiraを単なるタスク管理ツールとしてではなく、プロジェクトの「生きたデータベース」として捉え直す必要があります。この観点に立つと、JQLとは、そのデータベースに対して「プロジェクトのKPI（重要業績評価指標）は達成可能か？」「リソース配分は適切か？」 ⁶、「チームのボトルネックはどこにあるか？」 ⁴ といった、高度なビジネス上の質問を投げかけるための、専門知識を必要としない（SQLのような）強力なBIクエリ言語に他なりません。

Jira上の個々のタスク（課題）は、それ自体がデータです。しかし、JQLの真の価値は、個々のタスクを見つけることではなく、それらデータの「集合体」から「傾向（トレンド）」や「パターン（問題）」を抽出することにあります。例えば、「特定のコンポーネントでバグが多発している」や「特定メンバーの作業が滞留している」といった状況を、JQLは即座に可視化します。

組織のアジリティ（俊敏性）はJQLの習熟度で測れる

組織がJQLをどのレベルで活用しているかは、その組織のデータ活用成熟度と、アジャイルな意思決定スピードを測るバロメーターとなります。

レベル1（低）： プロジェクトマネージャー（PM）がチームメンバーに「あのタスク、進捗どう？」と口頭で尋ね、メンバーが後からJiraを手動で更新します。これは報告のための摩擦が非常に大きい「プッシュ型」のレポーティングです ¹⁰。
レベル2（中）： PMはJiraのダッシュボードを眺めます。しかし、自分ではJQLが書けないため、エンジニアに「今週遅れているタスクの一覧が見たい」とフィルターの作成を依頼します。意思決定は他者依存のままです。
レベル3（高）： PM自身がJQLを使いこなし、「レビューで差し戻し（手戻り）が発生したタスク」や「今週に入ってから優先度が変更されたタスク」など、具体的かつ分析的なクエリを自ら実行し、リアルタイムで戦略を修正します ¹¹。これは、PMが必要な情報を自ら取りに行く、低摩擦な「プル型」の分析です。

ビジネスサイドの人間がJQLを使いこなせる組織は、問題の発見から対策の実行までのフィードバックループが圧倒的に短くなります。これにより、真にアジャイルな（俊敏な）プロジェクト運営 ⁴ が可能になります。本ガイドは、読者の皆様をこのレベル3へと導くことを目的としています。

あわせて読みたい

知らなきゃ損する？Jira（ジラ）とは？基本から徹底解説！プロジェクト管理の常識を変えるツール【】「Jira（ジラ）」という言葉を会議や同僚との会話で耳にする機会が増え、「今さら『Jiraって何？』とは聞きづらい…」と感じている方もいらっしゃるかもしれません…

あわせて読みたい

Jiraを上手く活用できない人必見！Jira活用方法10選【2025年最新版・海外事例で徹底解説】【】多くの組織で、プロジェクト管理ツールJiraは強力な機能を持ちながらも、その真価を発揮できずにいるという課題が散見されます。多機能であるがゆえに「複雑すぎる…

2. JQLの「読み方」入門：基本構造を3分で理解する

JQLは、一見すると難解なコードのように見えるかもしれませんが、その構造は非常にシンプルです。基本構造さえ理解すれば、あとは英単語の「辞書」を引くようにJQLを組み立てることができます。

JQLクエリの基本文法：フィールド + 演算子 + 値

JQLの最も基本的なクエリ（「節」と呼ばれます）は、以下の3つの要素で構成されています ¹。

フィールド (Field)： 検索対象の「項目」です。「何について」調べたいかを示します ¹。

例： project （プロジェクト）、 issuetype （課題タイプ）、 status （ステータス）、 assignee （担当者）

演算子 (Operator)： フィールドと値を「どう比較するか」という方法を定義します ¹。

例： = （等しい）、 != （等しくない）、 > （より大きい）、 IN （…のどれか）

値 (Value)： 検索したい「具体的なデータ」です。この値（または関数）を探し出します ¹。

例： “Marketing Campaign” （プロジェクト名）、 “Bug” （課題タイプ）、 “Open” （ステータス）

具体例：

project = “Marketing Campaign”

これは、「project（フィールド）が “Marketing Campaign”（値）と =”（等しい）課題」を検索するという意味になります。

キーワード (Keyword)：検索を「つなげる」糊

より複雑な検索を行うには、これらの「節」を「キーワード」と呼ばれる接続詞でつなげていきます ¹⁴。

AND（かつ）： 両方の条件を満たす課題のみを検索します。

例： project = “Marketing Campaign” AND status = “In Progress”
意味： “Marketing Campaign” プロジェクトに属し、かつステータスが “In Progress” の課題。
OR（または）： どちらか一方（または両方）の条件を満たす課題を検索します。

例： component = “User Interface” OR component = “API” ¹
意味：コンポーネントが “User Interface” であるか、または “API” である課題。

【要注意】JQLが意図通りに動かない最大の落とし穴： AND と OR の優先順位

JQLを使い始めたビジネスユーザーが直面する最大の落とし穴が、AND と OR の処理優先順位です。JQLは、数学の計算と同じように、OR よりも AND を先に処理します。

例えば、「担当者か起票者が自分で、かつ未解決の課題」を検索したいと考え、以下のようなJQLを書いたとします。

悪い例： assignee = currentUser() OR reporter = currentUser() AND status not in (Closed , resolved) ¹⁶

このクエリの意図は「(A or B) and C」です。しかし、JQLは AND を先に解釈するため、実際の動作は「A or (B and C)」となってしまいます 16。

その結果、「(A) 担当者が自分（ステータス問わず）の課題」または「(B) 起票者が自分で、かつ未解決の課題」が検索され、自分が担当者であれば「Closed（完了済み）」の課題まで大量にヒットしてしまうのです。

この問題を回避し、自身の「論理」をJQLに正しく伝えるためには、()（丸括弧）を使います。() で囲われた部分が、ひとつのカタマリとして先に処理されます。

正しい例： (assignee = currentUser() OR reporter = currentUser()) AND status not in (Closed , resolved)

JQLを使いこなすとは、この () を使いこなすことと同義です。OR を使う際は、意図しない検索結果を避けるため、常に () で論理を明示的にグループ化する習慣をつけましょう ¹⁷。

（一般的解説）用語の移行について

アトラシアンは現在、「issue（課題）」という用語を「work item（作業項目）」へと移行中です ¹³。本ガイドでは、JQLの互換性を考慮し、主に「課題」または「作業項目」と併記しますが、JQLクエリ自体は既存のまま（例：issuetype）で問題なく動作します。

あわせて読みたい

SQLインジェクションとは？仕組み、攻撃手法から対策まで一挙解説【】デジタルトランスフォーメーションが加速する現代において、データは企業の最も価値ある資産の一つとなりました。しかし、その価値に比例して、データを狙うサイバ…

3. まずはここから！個人の業務効率を劇的に上げる「マイタスク」JQL

JQLを学ぶ最初のステップは、チーム管理の前に「個人の生産性」を最大化することです。Jiraを開いたときに、自分が今何をすべきかが即座にわかるJQLフィルターを整備しましょう。

1. 「今すぐ自分がやるべきこと」を把握する（My Open Issues）

assignee = currentUser() AND resolution = Unresolved

解説： これはJiraで最も基本的かつ重要なJQLです ¹⁹。

assignee = currentUser()：assignee（担当者）が currentUser()（現在ログインしている自分）である ¹⁸。
resolution = Unresolved：resolution（解決状況）が Unresolved（未解決）である ¹⁹。
ビジネス価値： これにより、「自分が担当者としてアサインされており、まだ完了していない」すべてのタスクが一覧表示されます。これがあなたの「To-Doリスト」の原本となります。

2. 「自分が依頼したタスク」の進捗を追う（Reported by Me）

reporter = currentUser() AND resolution = Unresolved

解説： reporter（起票者）が自分であり、かつ未解決の課題を検索します ¹⁸。
ビジネス価値： 自分が他者に依頼したタスクや、起票したバグ報告などが、対応されないままペンディングになっていないかを一覧で確認できます。
応用： reporter = currentUser() AND assignee!= currentUser() ¹⁸
これは、「自分が起票したが、担当者が自分ではない」タスク、つまり純粋に「他人に依頼した」タスクを絞り込むクエリです。

3. 「自分がウォッチしている」重要課題をリストアップする

watcher = currentUser() AND resolution = Unresolved

解説： watcher（ウォッチャー）が自分である未解決の課題を検索します ¹⁸。
work item in watchedWorkItems() ¹⁸ という関数を使った書き方もありますが、watcher = currentUser() ²³ の方がシンプルで一般的です。
ビジネス価値： 自分は担当者でも起票者でもないが、その動向を注視している（ウォッチしている）重要プロジェクトや、クリティカルな障害の状況を、自分のタスクとは切り離して把握するのに最適です。

currentUser() は「魔法の変数」

上記のクエリで共通して使われている currentUser() ¹⁸ は、単なる「自分」というショートカットではありません。これは、JQLフィルターを「共有可能」かつ「スケーラブル（拡張可能）」にするための鍵です ²⁵。

もし、PMが assignee = “tanaka” というJQLフィルターAを作成した場合、そのフィルターは田中さん以外の人には何の価値もありません。
もし、PMが assignee = currentUser() というJQLフィルターBを作成し、チーム全員に共有した場合 ²⁵、Aさんがそのフィルターを実行すれば「Aさんのタスク」が、Bさんが実行すれば「Bさんのタスク」が表示されます。

つまり、currentUser() を使うことで、JQLは「静的なクエリ」から、実行するユーザーに応じて結果が動的に変わる「テンプレート」へと昇華します。これは、チーム全員が同じダッシュボードを共有しつつ、自分に関係する情報だけを見る、という高度な運用を実現するための最も重要な概念です ²⁰。

ビジネスTips：3つのJQLを「個人用ダッシュボード」に集約する

これら3つのJQL（担当、起票、ウォッチ）を、それぞれJiraの「フィルター」として保存しましょう ¹¹。そして、自分のJiraダッシュボードに「フィルター結果 (Filter Results)」ガジェット ²⁰ を3つ並べ、それぞれに保存したフィルターを設定します。これにより、Jiraを開いた瞬間に自分の関心事をすべて把握できる「個人用コマンドセンター」が完成します。

さらに、これらすべてを1本のJQLにまとめることも可能です ²⁷。

(assignee = currentUser() OR reporter = currentUser() OR watcher = currentUser()) AND resolution = Unresolved ORDER BY updated DESC

この「究極の個人用JQL」は、() を使って（セクション2の教訓です）、自分に関連する（担当、起票、ウォッチ）すべての未解決タスクを、updated DESC（最終更新日の降順）で表示します。

4. PM・リーダー必見：チームとプロジェクトを「見える化」する実践JQL

個人のタスク管理を最適化したら、次はいよいよプロジェクトマネージャー（PM）やチームリーダー ²⁸ として、チーム全体とプロジェクトの状況を「見える化」します。

あわせて読みたい

プロジェクトマネージャー（PM）に向いている人材とは：求められる資質とスキル【】プロジェクトマネージャーの定義と責任プロジェクトマネージャー（以下、PM）とは、特定のプロジェクトにおいて、その開始から完了までの全プロセスに責任を負い…

あわせて読みたい

プロジェクトマネージャーなら絶対に知っておきたい！世界を変えた有名プロジェクト10選【成功と失敗の… 【】プロジェクトマネジメントは、現代のオフィスで生まれた学問ではありません。それは、人類の野心と共に古代から存在し、何世紀にもわたる壮大な試みを通じて磨かれ…

Case 1: チーム全体のタスクを俯瞰する

assignee IN membersOf(“team-dev-A”) AND resolution = Unresolved

解説： membersOf() 関数 ¹⁸ は、Jiraの「グループ」（例：team-dev-A）に所属するメンバー全員をリストアップします。
演算子に = ではなく IN ²⁶ を使うことで、「担当者が team-dev-A グループの誰かに割り当てられている」すべての未解決タスクを検索できます。
ビジネス価値： チームの総作業負荷（ワークロード）を把握し、リソース配分を考えるための基本クエリです。

Case 2: 放置された「担当者未割り当て」の重要タスクを発見する

project = “Customer Support” AND assignee IS EMPTY AND priority >= High

解説： これは、PMが即座に対応すべき「プロセスの穴」を発見するための、非常に重要なJQLです。

assignee IS EMPTY ³⁰ または assignee is empty ³³ で、「担当者が割り当てられていない」課題を検索します。
priority >= High ¹ で、「優先度がHigh（高）以上」のクリティカルな課題に絞り込みます。
JQLは「プロセスの診断ツール」である

このクエリで1件でも課題がヒットした場合、それは単なる「タスク漏れ」ではありません。それは、チームの「トリアージ（優先順位付けとタスク割り当て）プロセス」が機能不全を起こしているという明確な証拠です。
「優先度がHigh（高）以上」 ³⁴ ということは、ビジネス上、即時の対応が求められるはずです。
しかし、「担当者が空」 ³¹ ということは、誰もそのタスクの責任者になっていないことを示します。
この2つの条件が AND で同時に存在する ³² こと自体が、プロジェクト管理上の「矛盾」であり「危険信号」です。
したがって、PM ²⁸ はこのJQLをダッシュボードに常時表示し、ヒット件数が常にゼロであることを監視することで、リソース配分の失敗 ⁶ を未然に防ぐことができます。

Case 3: プロジェクト横断で「期限切れ」のタスクを洗い出す

project IN (“Project A”, “Project B”) AND duedate < now() AND status!= Closed

解説：

project IN (…) で、複数のプロジェクトを横断して検索します。
duedate < now() または due <= now() ²⁶ で、「期限日（duedate）が現在時刻（now()）より前」＝「期限切れ」の課題を抽出します。
status!= Closed で、すでに完了（Closed）しているものを除外します。
ビジネス価値： プロジェクトをまたいで発生している「遅延」を即座に検知するための、PMにとって最も直接的なクエリです。

Case 4: 特定の「コンポーネント」や「バージョン」に関連するバグを追跡する

project = “MobileApp” AND issuetype = Bug AND component = “API” AND fixVersion = latestReleasedVersion()

解説： 複数の条件を AND でつなぎ、情報を絞り込んでいきます。

issuetype = Bug ³¹：課題タイプを「バグ」に限定します。
component = “API” ¹⁵：特定の機能コンポーネント（ここでは “API”）に限定します。
fixVersion = latestReleasedVersion(“MobileApp”) ¹⁸：「MobileApp」プロジェクトの「latestReleasedVersion()（最新のリリース済みバージョン）」 ³⁵ を対象とします。
ビジネス価値： 例えば「最新バージョンをリリースした直後に見つかった、API関連のバグ」をピンポイントで追跡できます。latestReleasedVersion() は動的な関数であるため、リリースごとにJQLを書き換える必要がありません。

Case 5: 「ブロッカー（進捗阻害要因）」となっている課題を特定する

プロジェクトマネージャーが最も知りたいことの一つに、「現在ブロックされている（他の課題に依存していて進められない）タスク」の一覧があります。

しかし、ここでネイティブJQLの「限界」を知っておくことが重要です。驚くべきことに、Jiraの標準JQLには「”is blocked by” のリンクを持つ全ての課題」を直接検索する機能が存在しません ³⁶。

issue in linkedIssues(“PROJ-123”, “blocks”) ³¹ というJQLは存在しますが、これは「特定の課題 PROJ-123 によって ブロックされている」課題を探すものであり、PMが知りたい「（課題を特定せず）ブロックされているものすべて」という要件は満たせません。

現実的な回避策（47より）：

最も一般的で現実的な解決策は、JQLの技術的な限界を、チームの運用ルールでカバーすることです。

チーム内で、「タスクが何らかの要因でブロックされた場合、必ず Priority を Blocker に変更する」または「特定の Labels（例：blocked）を付与する」というルールを徹底します。
このルールに基づき、PMは以下のJQLを使って、ブロッカーを間接的に監視します。

priority = Blocker AND resolution = Unresolved

このアプローチは、JQLの機能の限界を、PMのプロセス設計とチームの規律で補うという、高度なプロジェクト管理の好例と言えます。

5. JQLを「動的」に使いこなす：時間軸で進捗を測る

JQLの真価は、「今、この瞬間」の状態を切り取るだけでなく、「今週」「先月」といった「期間」での検索（²⁶）ができることです。これにより、静的なタスクリストが、動的な進捗レポートへと変わります。

「静的な日付」 vs 「動的な日付」

静的な日付（非推奨）： created >= “2024/10/01”
これでは、レポートを毎週見るたびに日付部分を書き換える必要があり、自動化されたレポートには不向きです。
動的な日付（推奨）： created >= startOfWeek() ³⁸
これなら、JQLが実行された「その時」を基準に、「今週の開始時刻」を自動計算してくれます。一度保存すれば、「常に今週のデータを表示する」生きたレポートになります。

実践クエリ集：時間関数

今週作成されたすべての課題

created >= startOfWeek() ²⁶

先週クローズ（解決）された課題

resolutiondate >= startOfWeek(“-1w”) AND resolutiondate < startOfWeek()
解説： resolutiondate（解決日）が「先週の開始時刻（startOfWeek(“-1w”)）」から「今週の開始時刻（startOfWeek()）」までの間にある課題を検索します ⁴⁰。

今月中に対応すべき課題（期限が今月）

due <= endOfMonth() ¹⁸
解説： endOfMonth() は「今月末の終了時刻」を動的に返します。

過去7日間、全く更新がなかった（放置されている）課題

updated <= “-7d” AND resolution = Unresolved
解説： updated（最終更新日）が「今から7日前」よりも古い（つまり7日間放置されている）未解決の課題を検索します ¹。”-7d” や “-2w”（2週間） ³¹ といった相対指定は、直近の活動がない課題をチェックするのに非常に便利です。

【国外事例】Jiraの「週の開始日」問題と、その解決策

JQLをグローバルスタンダードのSaaS（Jira Cloudなど）で使う際、startOfWeek() ¹⁸ 関数には「文化的な罠」が存在します。多くのアトラシアンのドキュメントやJira Cloudのデフォルト設定では、**週の開始日は「日曜日」**として扱われます ⁴¹。

日本の多くのビジネスパーソンが期待する「月曜日から金曜日」の週次レポート ⁴³ を作成しようとして、月曜日の朝に created >= startOfWeek() を実行すると、意図に反して「日曜日と月曜日のデータ」しか取得できない、という問題が発生します ⁴²。

解決策（26より）：

startOfWeek() 関数には、オフセット（ずらし）指定が可能です。

created >= startOfWeek(1d)

解説： startOfWeek(1d) は、「デフォルトの週の開始日（日曜日）に 1日加算する」という意味になります。結果として、Jiraが内部で何曜日を週の開始日として設定していても、このJQLは常に「月曜日の開始時刻」を指定できます。
この (1d) という記述を知っているかどうかが、正確な週次レポート ³⁸ を作成できるかを左右する、非常に重要なノウハウです。

[表1] ビジネスで多用するJQL関数チートシート

この表は、JQLの「関数」¹⁸ を、ビジネス上の「目的」と「具体的なクエリ例」に紐づけて整理したものです。PMは、左の「目的」から必要な関数を逆引きできます。

関数 (Function)	目的（何をしたいか？）	ビジネス利用例（JQLクエリ）	参照
currentUser()	自分のタスクを見たい	assignee = currentUser()	[18, 26]
membersOf()	チームのタスクを見たい	assignee IN membersOf(“dev-team”)	[18, 26]
now()	今の時刻と比較したい（期限切れなど）	duedate < now() AND status!= Closed	[18, 26]
startOfWeek()	今週の活動を知りたい	resolutiondate >= startOfWeek()	[18, 26]
startOfWeek(1d)	月曜日始まりの今週の活動を知りたい	created >= startOfWeek(1d)	²⁶
startOfMonth()	今月の活動を知りたい	created >= startOfMonth()	¹⁸
endOfMonth()	今月中に期限が来るものを知りたい	due <= endOfMonth()	¹⁸
latestReleasedVersion()	最新リリースに関連するものを知りたい	fixVersion = latestReleasedVersion(PROJ)	¹⁸
startOfDay(“-1d”)	昨日の活動を知りたい	created >= startOfDay(“-1d”) AND created < startOfDay()	[18, 40]

6. JQLマスタークラス：タスクの「変更履歴」を追跡する

Jiraには、課題の「現在」の状態だけでなく、「過去」の変更履歴もすべて蓄積されています。JQLの WAS と CHANGED 演算子 ¹³ は、この「履歴」データにアクセスし、単なるタスク追跡を超えた「プロセス分析」を可能にする、JQLの最強機能です。

注意点： これらの履歴演算子は、Assignee（担当者）、Fix Version、Priority（優先度）、Reporter（起票者）、Resolution（解決状況）、Status（ステータス）といった、限られたフィールドでのみ使用可能です ¹³。例えば、Component（コンポーネント）フィールドでは使用できません ⁴⁴。

1. WAS 演算子：過去の状態を問う

意味： 「今、または過去のある時点で、その状態だった」課題を検索します ¹³。
ビジネス上の問い： 「今週、チームが 少しでも触った タスクは何か？」
JQL： status WAS “In Progress” DURING (startOfWeek(), now())

WAS vs (通常の演算子)：

このクエリの真価は、通常の = 演算子との比較で明らかになります。

status = “In Progress”：
このクエリでは、「今、現在 “In Progress”」のタスクしか見つかりません。例えば、月曜日に “In Progress” になり、水曜日に “Done” になったタスクは、木曜日の検索ではヒットしません。
status WAS “In Progress”… ¹³：
このクエリは、たとえ木曜時点で “Done” になっていたとしても、期間中（今週）に一度でも “In Progress” 状態を経由していれば、そのタスクを検索対象に含めます。

これは、PMが「今週のチームの総活動量（Velocity）¹¹」や「実際に作業したタスクリスト」を正確に把握し、実態に基づいた週次報告 ⁴³ を作成するために不可欠なクエリです。

2. CHANGED 演算子：変更の事実を問う

意味： フィールドの値が「変更された」という「事実（イベント）」そのものを検索します ¹³。

Case A: 「担当者が変更された」タスク（引き継ぎ漏れの防止）

JQL： assignee CHANGED ¹³
活用： assignee CHANGED AFTER startOfWeek()（今週に入ってから担当者が変更された）というJQLで検索し、タスクの引き継ぎが正しく行われているか、PMが定期的に確認できます。

Case B: 「ステータスが差し戻された」タスク（手戻りの分析）

JQL： status CHANGED FROM “Review” TO “In Progress”
解説： CHANGED に FROM と TO ¹³ を加えることで、「レビュー中」から「作業中」にステータスが変更された（＝レビューでNGとなり、差し戻された）タスクをピンポイントで特定できます。
JQLは「プロセス改善」の武器である

この「差し戻し」クエリは、単なる検索ではありません。これは、チームの「手戻り率」という、アジャイル開発 ⁹ における重要な品質・効率メトリクス（KPI）を直接測定するクエリです。
status CHANGED FROM “Review” TO “InG Progress” ⁴⁵ は、「手戻り」の発生を意味します。手戻りが多発している場合、それは「開発の品質が低い」「レビューの基準が曖昧」「最初の要求が不明瞭」のいずれか（または全て）であることを示唆しています。
PM ²⁸ は、このJQLで「手戻り」の件数を定量的（例：… AFTER startOfSprint() でスプリントごと）に測定し ¹¹、その客観的なデータをスプリントの「レトロスペクティブ（振り返り会議）」¹⁰ に持ち込むことができます。これにより、感覚的ではない、データに基づいたプロセス改善 ⁴⁶ の議論をファシリテートすることが可能になります。

Case C: 「特定のユーザーによって優先度が変更された」タスク

JQL： priority CHANGED BY “sato” AFTER startOfWeek()
解説： BY 演算子 ¹³ を使うと、「誰が」変更したかを指定できます。「今週、”sato”さんによって優先度が変更された」タスクを検索し、特定のステークホルダーによるスコープ変更 ⁴⁶ の実態を追跡するのに役立ちます。

[表2] 高度なJQL演算子チートシート（履歴追跡編）

ビジネスパーソンにとって最も強力ですが、混同しやすい履歴演算子を整理します。WAS は「状態」を、CHANGED は「変化」を追跡します。

演算子 (Operator)	目的（何をしたいか？）	ビジネス利用例（JQLクエリ）	参照
IN	複数のどれかに合致するか知りたい	status IN (“In Progress”, “Review”)
WAS	過去にその「状態」だったか知りたい	status WAS “Blocked” DURING (startOfWeek(), now())	¹³
WAS IN	過去にその「状態」（複数）だったか	status WAS IN (“Resolved”, “In Progress”)	¹³
CHANGED	とにかく「変更」があったか知りたい	assignee CHANGED AFTER “-1d” (昨日以降、担当者が変わった)	¹³
CHANGED BY	特定の人が変更したか知りたい	priority CHANGED BY “sato” (satoさんが優先度を変えた)	¹³
CHANGED FROM A TO B	AからBへ「変化」したか知りたい	status CHANGED FROM “Review” TO “In Progress” (差し戻された)	¹³

7. JQLの最終形態：クエリを「生きたKPIダッシュボード」に変える

JQLは「検索して終わり」ではない

ここまでのセクションで、PMが知りたいビジネス上の問いの多くを、JQLに翻訳する方法を学びました。

しかし、JQLの真のゴールは、そのJQLを「使い捨て」にすることではありません。優れたJQLは、「自動化されたレポート」として「仕組み化」すること ¹¹ にこそ価値があります。

黄金のワークフロー：JQL -> フィルター保存 -> ダッシュボードガジェット

Jiraでカスタムレポートを作成する際の、最も重要で基本的な流れがこれです ¹¹。

ステップ1：JQLクエリを作成する

本ガイドで学んだ、ビジネス上の問いを解決するJQLを、Jiraの「高度な検索」画面に入力します。
例： project = “MyProject” AND assignee IS EMPTY AND priority >= High ³²

ステップ2：クエリを「フィルター」として保存する

実行したJQLを「フィルターとして保存」します ¹²。
例：フィルター名「【至急対応】未割り当ての高優先度タスク」
この「保存」こそが、JQLを「使い捨ての検索」から「再利用可能なビジネスロジック」へと昇華させる「魔法のステップ」です ¹¹。

ステップ3：ダッシュボードに「ガジェット」を追加する

Jiraの「ダッシュボード」⁴ に移動し、編集モードにして「ガジェットを追加」を選択します。

ステップ4：ガジェットに保存した「フィルター」を連携する

例えば「フィルター結果 (Filter Results)」²⁰ や「円グラフ (Pie Chart)」、「2次元フィルター統計 (Two Dimensional Filter Statistics)」などのガジェットを選択します。
ガジェットの設定画面で、データソースとしてステップ2で保存した「フィルター」（例：「【至急対応】未割り当ての高優先度タスク」）を選択します。

完成：JQLが「生きたKPIダッシュボード」に変わる瞬間

この4ステップだけで、ダッシュボードには常に「未割り当ての高優先度タスク」のリアルタイムな件数やリストが表示され、件数がゼロでなければ赤く目立つようになります。

PMは、毎日JQLを実行する必要がなくなり、ダッシュボードを眺めるだけで、JQLが裏側で自動的にプロジェクトの健康状態を監視し、異常をアラートしてくれるようになります。

ビジネスTips：PMのための「プロジェクト監視ダッシュボード」レシピ

以下のJQLをフィルターとして保存し、あなたのプロジェクト用ダッシュボードにガジェットとして配置しましょう。これだけで、プロジェクトの「健康診断」ダッシュボードが完成します。

ガジェットの種類	表示内容（フィルター名）	JQL（MY_PROJ と team-name はご自身の環境に置き換えてください）	目的	参照
フィルター結果	緊急：担当者不在の重要タスク	project = MY_PROJ AND assignee IS EMPTY AND priority >= High	プロセスの穴を塞ぐ	[30, 32]
フィルター結果	警告：期限切れタスク	project = MY_PROJ AND duedate < now() AND resolution = Unresolved	遅延の即時検知
2次元フィルター統計	チームの負荷状況（担当者別）	project = MY_PROJ AND assignee IN membersOf(“team-name”) AND resolution = Unresolved	リソース配分の偏りを可視化	[7, 29]
円グラフ	今週の手戻り（差し戻し）	project = MY_PROJ AND status CHANGED FROM “Review” TO “In Progress” AFTER startOfWeek(1d)	プロセスの品質を測定	¹³
フィルター結果	今週完了したタスク	project = MY_PROJ AND resolutiondate >= startOfWeek(1d) AND assignee IN membersOf(“team-name”)	チームの成果（Velocity）を可視化	[11, 38]

8. まとめ：JQLはあなたのビジネスの「羅針盤」である

JQLは、Jiraという広大な「データ」の海から、プロジェクトが向かうべき「進路（インサイト）」を指し示す「羅針盤」です。

JQLをマスターすることは、単にJiraの検索機能に習熟することではありません。それは、Jiraに日々蓄積されていく「過去の事実（データ）」を、チームの「未来のアクション（行動）」に変えるためのスキルを身につけることを意味します。

ビジネスパーソンであるあなたがJQLを習得することで、チームの朝会 ¹⁰ や週次定例 ⁴³ は、進捗を「報告」する場から、リアルタイムのデータを元に「次の打ち手」を議論する、より価値の高い場へと変わるでしょう。

難しく考える必要はありません。まずは、本ガイドのセクション3で紹介した assignee = currentUser() AND resolution = Unresolved ²⁰ をコピーし、Jiraの検索窓に貼り付け、ご自身のダッシュボードに設定することから始めてください。その小さな成功体験が、あなたのプロジェクト管理をデータ駆動型へと変革する、大きな第一歩となります。