jira.atlassian.com の（歩き方ならぬ）走り方

はじめに

Atlassian では、製品への新機能追加や不具合の修正が以下のポリシーに基づいて実施されており、一つ一つの機能リクエストやバグレポートについては jira.atlassian.com (通称 : JAC) と呼ばれる Jira インスタンス上で管理されている。

• 新機能の実装ポリシー
• アトラシアンのバグ修正ポリシー

JAC はインターネット上に公開されているため、誰でも自由に機能リクエストやバグレポートへアクセスし、その気になればチケット上に思いの丈をコメントとして綴ることも可能である。¹ さらに面白い点としては、機能リクエストに対してはコメントの他に 投票 を行うことも可能であり、リクエストへの投票数も実装される新機能を決める上での判断材料となる。²

このような形で利用されている JAC だが、現職では Atlassian 製品の仕様や不具合についての質問を受けることが多いため、JAC 上に存在する約 24 万件強 ³ のチケットの中から、如何に素早く適切な機能リクエストやバグレポートを見つけられるかが重要になってくる。

Atlassian の技術サポートのエンジニアは、（おそらく）本記事の読者の方々の想像よりもはるかに速いスピードで、狙った JAC 上のチケットを見つけ出すことができる。（と、若干煽ってみる。）ただ、それは製品知識や Atlassian の社内情報のみに頼ったものではなく、誰もが明日から実践できるような些細なテクニックの積み重ね ⁴ によって実現されていることを、本記事でお伝えできればと思う。

目標

本記事では、以下の 2 点を目標としている。

1. JAC 上に存在するチケットの検索スピードの向上
2. JAC に限らない、一般的な Jira チケットの検索スピードの向上

JAC の検索術

これから紹介する話は、どれもが JAC 上に存在するチケットを効率良く検索するための手段となっているが、中には JAC に限らず Jira インスタンス一般に使用できるものも含まれている。もし本記事の読者の所属する企業や団体でも Jira をご使用いただいている場合には、是非そちらでも活用していただければと思う。

① 敢えて Jira の検索機能を使用しない

JAC が Jira インスタンスである以上、Jira 自体の検索機能を使用してチケットを探さなければならないと考えてはいないだろうか？

もちろん、Jira そのものが提供する 検索機能 は非常に強力ではあるが、それはどちらかというと構造化された情報の検索についての話である。 ここで言う構造化された情報とは、Jira のチケットに紐づくプロジェクト情報、チケットの種類、ステータス、担当者、作成日などを指して言っているが、例えばそれらの情報を上手く活用して 「JRASERVER プロジェクトに、2018/10/13 以降に作成された、ステータスが Resolved」 となっているチケットを探す、などといった場合には Jira の検索機能は有用である。

一方で、これらの情報をきちんと活用して JAC 内のチケットを検索することが、一般の製品ユーザーには若干難しいケースも存在する。例えば、使用している Jira アプリケーション上で何らかの不具合を見つけて、それが既知のものかどうかをチェックする目的で JAC 上のバグレポートを検索する場合を考えてみよう。 現状で JAC 上には、Jira に関連するプロジェクトだけで JRASERVER, JRACLOUD, JSWSERVER, JSWCLOUD, JSDSERVER, JSDCLOUD, JPOSERVER, JPOCLOUD, JOPSCLOUD, BON の 10 個ものプロジェクトが存在する。 ⁵ また、不具合が Jira の内部で使用されている特定のプラグインに起因する場合には、更に別のプロジェクトにバグレポートが起票されるケースも存在する。 そういった中で、いきなり JAC の検索機能を使用して、プロジェクトを限定して検索を行ってしまうと、見つけたいバグレポートがそのプロジェクト内に存在しなかった場合に、永遠にそのバグレポートに辿り着けいないリスクが生まれてしまう。

これらの前提情報を知らないユーザーにも、比較的敷居が低いのが フリーテキストでの検索機能 を使用する方法になるかと思うが、ここで問題となるのが 英語 である。

基本的には、JAC 上のチケットは全て英語で記載されているため、テキストで検索する場合にも英語のキーワードを使用する必要がある。そんな中、私も英語ネイティブではないことで若干苦労しているのが、チケット内で使用されている微妙な言い回しの違いである。

過去に私が、Atlassian 製品を日本語で使用する場合に文字化けが発生する不具合を、JAC 上で調査していた時のこと。 当時の私は、「文字化け」 = “garbled” という翻訳は知っていたが、なかなか目的のバグレポートに辿りつくことができなかった。結論から言うと、目的としていたバグレポートの中では文字化けという意味合いで “mangled” という単語が使用されていたため、Jira のテキスト検索にひっかからなかった。

Jira のテキスト検索機能では、形態素解析 により単語の活用の変化 (例 : mangle ↔ mangled, garble ↔ garbled) などは考慮して検索を行ってくれるが、意味レベルで近い単語を類推してくれる程には賢くはない。そういった意味でも、ネイティブではない言語で（もしくはネイティブな言語でも）、Jira のテキスト検索機能を完璧に使いこなすことは、なかなか難しかったりする。

ここで思い出していただきたいのが、JAC は インターネット 上に公開されていて、インターネットの検索にはもちろん Google 検索 が使用できるということだ。 ⁶ 具体的にやることとしては、以下のように Google 検索を行う際に “site:jira.atlassian.com” のキーワードを含めて検索対象のドメインを jira.atlassian.com に絞るだけである。

jira.atlassian.com にドメインを絞った Google 検索

こちらの方法での検索は、Jira 自体が提供するフリーテキスト検索と比べて以下のようなメリットがある。

• 通常の Google 検索同様、キーワードのあいまいさを許容した検索が可能となる
• Google のランキングアルゴリズムの恩恵により、世の中で多く参照されているチケットには、特にたどり着き易い

もちろん、目的とするチケットがすでに Google の検索エンジンにクローリングされているかどうかなども関係してくるため、必ずしもベストな手段だとは言えないが、普段あまり JAC を訪れることの無い方々にとっては、比較的 ROI の高い方法だと考えている。（なお、私自身 JAC 上のチケットを調査する際の最初のステップとして、この手段を利用することが多い。）

② 不要な検索結果を削ぎ落としていくイメージを持つ

① にて JAC 自体の検索機能を使用しない方法の話をしたが、前述した通り、目的とするチケットが Google のインデックスに乗っていない場合には見逃してしまうリスクは存在する。 そういった意味からも、① の方法については、「目的とするチケットが見つかればラッキー」 くらいの感覚で利用してもらえればと考えている。

そこで、次に考えなければいけないのは、如何に検索結果に 漏れがない ように JAC の中を検索するか、ということになる。 この時点で、はじめて Jira の検索機能を使用することになるが、前述したような、JAC 上のプロジェクト情報、チケットの種類、ステータスなどの細かい定義は、単にそれらを知っているかどうかだけの話になってしまうので、ここではもう少し汎用的な話をしようと思う。

Jira 上でチケットを探す際には、おそらく 検索条件 を複数指定した上で、チケットの絞り込みを行うと思う。 ただこの時に最も避けたいのが、比較的早い段階で目的とするチケットが検索結果から漏れてしまうことである。

前述した文字化けの不具合のケースだと、「チケットに “garbled” というキーワードが含まれる」 というある種の 「不確実な検索条件」を検索の序盤から用いて、いきなり目的のチケットを見つけにいってしまっていることが失敗の要因となっている。 今回のケースのように、指定した不確実な検索条件から目的のチケットが漏れてしまった場合、この後どのような検索条件を追加したところで、該当チケットにたどり着くことはできない。（もちろん、OR 検索を使用した場合はこの限りでは無いが。）

目的とするチケットが検索結果から漏れてしまう例

上記のような問題を防ぐためにも、JAC のチケットを検索する際は、初めは「確実な検索条件」から指定していき、不要な検索結果をある程度削ぎ落とした上で、はじめて「不確実な検索条件」を設定するのが望ましいと私は考える。

不要な検索結果を削ぎ落としていくイメージ

ここで言う、「確実な検索条件」としては、以下のようなものが挙げられる。

• サーバー版の Jira Software を使用していて、不具合が Jira Software 特有の機能（ボード機能など）で発生している場合には、バグレポートの存在するプロジェクトについて project = JSWSERVER という条件を指定する ⁷
• 不具合が最新のバージョンでも発生している場合、バグレポートのステータスについて status not in (Resolved, Closed) という条件を指定する ⁸
• 不具合が特定の製品機能に対して発生する場合、text ~ "英語表記の正式な製品機能名称" という条件を指定する
  • 現状では、JAC 上のバグレポートは Atlassian 社員のみが起票する運用となっており ⁹、Atlassian 社員はバグレポート内で正式な製品機能名称を使用するように心がけている

「確実な検索条件」のみを使用して、検索結果が 100 件程度まで絞り込めれば、チケットの要約だけ全件分チェックすることもそこまで難しくはないし、その状態からであれば「不確実な検索条件」を使用しながらの試行錯誤も容易いだろう。

また、テキストでの条件指定にもちょっとしたコツがある。 JAC 上のチケットには以下のようなテキストフィールドが存在している。

• 要約 (summary)
• 説明 (description)
• その他のテキストフィールド（コメントなど）

テキストで条件を指定する際に是非一度考えてみていただきたいのが、「仮に今探しているチケットを自身で起票するとすれば、どのテキストフィールドにどういった粒度の情報を入れるか」 という点についてだ。

例えば 「日本語での利用時に、Jira の ガジェットが、文字化けする」 といった不具合が、既知のものであるかを調査する場合についてを考えてみよう。特に変わったことをしなければ、検索条件は summary ~ "Japanese gadget garbled" や text ~ "Japanese gadget garbled" といった形になるのではないだろうか？

まずはじめに「日本語での利用時」に発生する不具合であることから「要約」フィールドに対していきなり summary ~ "Japanese" という条件を指定するべきか否か。 基本的に日本語での利用で発生する不具合のほとんどは、マルチバイト文字に起因して発生するケースが大半であり、韓国語、中国語、ロシア語での利用時にも同様の問題が発生する可能性が考えられる。そういった場合には、もしその不具合を初めに見つけたのが日本語ネイティブ以外の方であれば、「要約」フィールドには “Korean” や “Chinese” などのキーワードが含まれているかもしれない。 また、仮に私がこの不具合についてのバグレポートを挙げるとすれば、上記のように複数の言語で不具合が再現することをより端的に言い表すために、「要約」フィールドには “Multibyte” のように一般化したキーワードを使用するだろう。 これらを踏まえると、summary ~ "Japanese" は、ある程度「不確実な検索条件」であることがわかるかと思う。

一方で、「Jira の ガジェット」で不具合が発生する、という点についてはどうだろうか？ もしその不具合が Jira のガジェットで発生するとすれば、”gadget” というキーワードは十中八九「要約」フィールドには含まれてくるだろう。そういった意味で summary ~ "gadget" は、「確実な検索条件」だと考えて良いと思う。

ここまででは「要約」フィールドについての話であったが、「説明」フィールドやコメントを含むその他のテキストフィールドはどうだろうか？ 先程の例だと、summary ~ "Japanese" は「不確実な検索条件」に分類されたが、これを description ~ "Japanese" もしくは text ~ "Japanese" とした場合にはどうだろう。

基本的に「説明」フィールドには不具合の詳細な再現手順が記載されるため、もし日本語ネイティブである私がこの不具合のバグレポートを起票したとすれば、ほぼ間違いなく “Japanese” というキーワードを含めるかと思う。 また、もともと韓国語での利用時に発生するものとして起票された不具合でも、後から別の日本人ユーザーが 「この不具合は日本語でも再現する」 といった情報をコメントしている可能性もあるため、コメントに “Japanese” というキーワードが含まれている可能性は更に高い。 文字化けについて言及している部分についても同様で、仮に「要約」フィールドや「説明」フィールドで “mangled” というキーワードが使用されていたとしても、コメントには別のユーザーが “garbled” というキーワードを記載している可能性が考えられる。

一般に、各テキストフィールドが含む情報の抽象度は summary > description > text (コメント等) の順に高くなっていて、情報量は text > description > summary の順に高くなっていると考えて良いかと思う。

一つの検索条件で、より多くの不要な検索結果を振るい落とすためには、抽象度が高く、情報量が少ない テキストフィールドを検索条件に含めた上で 「確実な検索条件」 となるのが望ましい。（例: summary ~ "gadget"）

一方で、「不確実な検索条件」によって本来振い落されてはいけない検索結果が振い落されてしまうことを極力防ぐためには、「不確実な検索条件」 がより 抽象度の低く、情報量の多い テキストフィールドに来るのが良い。（例: text ~ "garbled"）

これらを踏まえると、同じテキストフィールドの検索でも、当初想定していた summary ~ "Japanese gadget garbled" や text ~ "Japanese gadget garbled" などの検索条件よりも、summary ~ "gadget" and description ~ "Japanese" and text ~ "garbled" といった条件の方が、検索効率が良いのがわかるかと思う。 ¹⁰

③ その他のテクニック

その他のちょっとした検索テクニックを紹介する。

ⅰ. 「バージョン」のワイルドカード検索

まだ比較的最近の話ではあるが、Jira 7.9.x にて、ついに「バージョン」のワイルドカード検索がサポートされた。 ¹¹

これまで Atlassian 製品の管理者の方々は、アップグレードを検討する度に JAC にて、アップグレード先のバージョンで解消されている不具合・機能リクエストをリストアップするために、

project = JRASERVER and fixVersion in ("7.6.1", "7.6.2", "7.6.3", "7.6.4", "7.6.5", "7.6.6", "7.6.7", "7.6.8", "7.6.9")

のような途方もない JQL を書いていたかと思うが、現行の JAC はすでにワイルドカード検索に対応したバージョンなので、以下のようなシンプルな JQL で済む。

project = JRASERVER and fixVersion ~ "7.6.*"

ⅱ. ランチャーアプリを使用した Jira 検索

頻繁に Jira の課題の検索を行っていると、検索条件の入力のために一旦「課題ナビゲーター」の画面を開くことすら億劫になってくる。そういった場合には、是非 Alfred などのランチャーアプリを使用して Jira の検索を行っていただくことをオススメする。 Alfred には、Web Search 機能 がデフォルトで備わっていて、予め Jira の課題ナビゲーターの URL を登録しておくと、アプリ上で数コマンド入力するだけで、すぐにアクセスすることが可能となる。 これだけだと、ブラウザのブックマーク機能と大して違いは無いかと感じるかもしれないが、Alfred では アプリからの入力を GET パラメータとして URL へ渡すことが可能である。 Jira では、http(s)://<ベースURL>/issues/?jql=<検索条件> という URL に GET アクセスすることで、直接チケットの検索結果が取得可能であることを利用し、以下のように Alfred 側で設定をしておくことで、アプリ上で入力した JQL にて JAC を検索した結果を即座にブラウザ上に表示することができる。

Alfred から JAC の検索を行うための設定

ランチャーアプリ上での入力 (JQL) が、上記図の Search URL 内の {query} 内に展開された上で、URL へのアクセスが行われる。

Alfred を使用した JAC の検索

この方法は、① で紹介した JAC にドメインを絞った Google 検索でも使用が可能で、上記の URL を https://www.google.co.jp/search?q=site%3Ajira.atlassian.com+{query} に変更するだけで、ランチャーアプリに入力した任意の文字列で JAC 内の Google 検索が可能となる。

私自身は Mac で利用可能な Alfred しか試したことは無いが、Windows にも同様のランチャーアプリは存在しているようだ。alternativeTo というサイトに、それらのアプリがまとまっているようなので、Windows ユーザーの方には是非お試しいただきたい。

おわりに

本記事に記載した内容は、JAC 及び Jira の検索におけるテクニックの一部に過ぎない。 他にも様々なテクニックが存在するだろうし、人によって好き嫌いもあるだろう。 もし本記事の読者が実践している、オススメのテクニックなどがあれば、是非私にも教えていただければと思う。