都元ダイスケ IT-PRESS このページをアンテナに追加 RSSフィード Twitter

最近は会社ブログしか書いてません。

2011-12-05

[]JIRAの課題検索とフィルターを使いこなそう

JIRA Advent Calendarってのに巻き込まれました。巻き込まれサイコーw

昨日は@oota_ken氏のJIRAのスキーマーをastahのクラス図で書いてみる ユーザー編 | ソーシャルゲームでもTDDするお!でした。確かに、JIRAのデータ構造って、ぶっちゃけ理解するの大変ですよね…。なんちゃらスキーム苦手ですw

で。@yusukeyサンからの「オマエのJIRAへの愛を語れ」っていう振りは完全スルーして、普通に活用Tips書きますw

自分はJiemamyプロジェクトにOSSライセンスを頂いて以来、随分長いことJIRAユーザをしています。なので、もうちっとディープな話もできなくもないかなぁとは思ったのですが、周囲を見ていると、玄人向けの難しい機能を紹介するよりも「願わくば全てのJIRAユーザが活用して欲しい、けどもなかなかこれを活用している人はいないんですよね」的な機能の紹介をしたほうがウケがいいよね、と思ってそんなネタを書きます。

JIRA Advent Calendarに参加するような人たちは既知のお話だと思いますが、活用歴が浅めのユーザさんに向けて。

まず課題検索を理解する

f:id:daisuke-m:20111205210334p:image:right

JIRA上には様々なチケットが蓄積されていきます。まず、そのチケットを「探す」ことにフォーカスを当ててみましょう。

検索と言えば、まずは普通にキーワード検索が浮かぶと思います。また、チケットID*1でチケットを探すこともあると思います。このような検索は、通常画面の右上にある「クイック検索」を利用します。

とりあえず、Jiemamy ProjectのJIRAに行ってみて、右上のクイック検索欄に「FileNotFoundException」とか入力してみましょう。この記事の執筆時点では ISM-18 とCORE-128 という2つのチケットが引っかかるはずです。続いて、同じくクイック検索に「ECL-100」と入力してみると、該当チケットに直接ジャンプします。って、普通ですね。

ここまでは敢えて説明するまでもない、普通の検索です。しかしこの「クイック検索」ボックスは、実は恐るべき機能を備えています。例えばここに「ECL unresolved」と入力してみましょう。そうすると「スマート クエリが起動しました。」というメッセージと共に「未解決で、かつECLプロジェクトに属するチケット」が表示されます。そう、unresolvedなど、いくつかの単語は普通にキーワード検索されるのではなく、特殊な意味として解釈されるのです。

f:id:daisuke-m:20111205210335p:image

その他、「CORE bug created:-10w」(COREプロジェクトで過去10週間以内に作成されたバグチケット)など、色々な検索を手軽にできるんですが、その中でも私が一番使うのは「my unresolved (プロジェクト名)」(ex: my unresolved ECL)ですかね。このスマートクエリは、是非知っておきたい機能です。

あわせて読みたいログイン - Atlassian Japan Confluence

色々なフィルターを紹介

クイック検索を使って、簡単にチケットを検索できることがわかりました。しかし、前述のような何度も使う簡単な検索条件は、覚えてしまえば良いのですが、覚えるのには向かない程度に複雑であるものの、よく使う検索条件、というのも存在します。そういったものは「検索条件を保存」しておいて、必要な時に呼び出せば良いのです。このように「よく使う検索条件を保存したもの」のことを「フィルター」って呼びます。

f:id:daisuke-m:20111205210336p:image:w100:right

f:id:daisuke-m:20111205210337p:image:w150:left

少し話が飛びますが、検索には「簡易検索」と「高度な検索」というものがあります。前者はフォームに検索条件を細かく指定するタイプ(右図)の検索なのですが、私はほぼこれを使いません。まどっろっこしい! まぁ多分、エンジニアだからでしょうけどw フィルターに保存するくらいの複雑さを持つ検索条件は、「高度な検索」を使うと良いと思います。というわけで、これを高度な検索に切り替えてみましょう。

まず、クイック検索で適当に「my unresolved」等と検索してみましょう。その上で、検索結果の左側にあるエリアの上方「高度な検索に切り替える」をクリック(左図)します。そうすると、検索結果の上に「クエリ」というテキストエリアが表示され、ここに検索条件を「式として」記述できるようになります。この条件式の記述言語はSQLに似た形になっており、「JQL (JIRA Query Language)」と呼ばれています。JQLを活用すれば、簡易検索では表現できない複雑な検索条件を記述できるようになります。

f:id:daisuke-m:20111205210339p:image

で、JQLの細かい書き方はドキュメントに任せることにして、ここでは私が普段使っているフィルターを、成り立ちと共に具体的に紹介したいと思います。(エンジニアの方は普通にJQLを読めると思います)

報告者にアサインして解決確認を依頼すべき担当課題

JIRAのチケットは、特にカスタマイズしていない状態では、「オープン→対応中→解決済み→クローズ」というライフサイクルを辿ります。ただ、私の経験上、デフォルトのままのJIRAを運用すると、解決済みのステータスで止まってしまってクローズに至らないチケットがあまりにも多いのです。しかしこれはある意味当然の事。実施者が満足して解決済みとしたタスクは、多くの場合特に問題はなく、完全に終わったタスクだとみなされてしまいます。従って、それ以上、そのチケットに対してアクションをする必要はない、と考えてしまうのです。そもそも「クローズ」という状態の存在さえ忘れてしまう。だって、解決したんだから良いでしょう? という気持ちです。

ただ、より一層厳密に仕事を進めるために、対応者が行った仕事の結果を報告者*2に見てもらい、チケットを作った意図通りの結果になっているかどうか最終確認をしてもらう、というプロセスを踏んだ方がトラブルが少ないでしょう。従って、まずチーム内で「対応者が満足して解決済みにしたチケットは、報告者にアサインを返し*3、クローズを依頼する」というルールを作り、コンセンサスを得ます。(このルールを厳密化するために、私が管理するJIRAでは「報告者でなければチケットをクローズできない」ように設定しています。この方法は今回の話から脱線するので、また別の機会にでも。)

しかし、人間というのは基本的にミスをする生き物です。前述のルールでは、対応者がチケットを「解決済み」にする際に、報告者にアサインバックすべきなのですが、担当者の変更を忘れてそのままにしてしまう、というミスが頻発します。こんなエントリを書いている私でさえ、よくやります。このようにアサインバックを忘れられたチケット*4は、ダッシュボードの「自分の担当課題」には表示されなくなるため、ほぼ確実に "忘れ去られた存在" になります。

そこで効果を発揮するのがこのフィルター。

status = Resolved AND assignee = currentUser() AND reporter != currentUser()

「ステータスが解決済み かつ 担当者が自分 かつ 報告者が自分ではない」チケットですね。この条件に引っかかるチケットは、前述の「アサインバック忘れ」ですので、見つけ次第、報告者にアサインを返す操作をしましょう。

解決を確認の上クローズすべき担当課題

次に、上記のシナリオでアサインバックされた側の話。このような経緯でアサインバックされたチケットは既に「解決済み」のチケットです。従って、このチケットも「自分の担当課題」には挙ってこないんですね。というわけで、確認しなければならない立場の人にとっても同様、"忘れ去られて然るべき存在" なのです。同じように、フィルターで検出してあげましょう。

status = Resolved AND assignee = currentUser() AND reporter = currentUser()

解決済みで、担当者と報告者がどちらも自分のもの、というフィルターです。この条件に引っかかるチケットは、対応内容を確認して、問題が無ければクローズ、問題があれば再オープンして対応者に差し戻す必要があります。

期限超過の担当課題

JIRAのチケットには「期限」という項目があります。が、別に期限を過ぎたからって、デフォルトのJIRAは何をしてくれる訳でもありません。でも、期限をオーバーしてしまったチケットには早めに気づきたいですよね。そこでコレ。

resolution = Unresolved AND assignee = currentUser() AND due <= now() ORDER BY due

このように、期限の値が現在より小さい(つまり過去)で、解決されていない自分担当のチケットを検出します。この条件に引っかかったら、早急に対応するか、または期限の見直しをすべきでしょう。

長期放置の担当課題

とは言え、チケットの期限設定というのは意外と難しいものです。チケットを作る人が勝手に期限を設定したとしても、実際の対応者が対応しきれなければ全く無意味です。対応者の忙しさを度外視して、チケット作成者の都合だけを押し付けた期限を設定しても印象悪いだけですしw 従って、よほど明確なデッドラインがあるチケットでなければ、基本的に期限を付けずにチケット発行することが多いようです。経験的に。

しかし、期限がないままチケットをアサインすると、そのチケットをそのまま握り続けられてしまう場合があります。期限がないので「期限超過の担当課題」にも引っかかりません。他にもっと優先度が高いチケットがある、という錦の御旗の下、黙殺されるチケットになってしまうのです。

しかし私は、そういった優先度の低いチケットであっても、定期的にレビューし、放置されている状態が適切かどうかを考える必要があると考えています。もしかしたら状況が変わっていて、もっと優先度が上がっているかもしれません。GTDでも、定期的にタスクをレビューしますよね。

というわけで、長期に渡って放置されている課題をフィルターで検出します。

updated < -14d AND status != Closed AND assignee = currentUser()

ここでは「長期」を「14日間」としていますが、まぁここは各自調整してみてください。この条件に引っかかるチケットは、引き続き放置することが適切であるかをレビューしましょう。放置してはいけないと判断した場合はチケットを編集して優先度を上げましょう。編集すればupdatedの値が更新されるのでこのフィルターには引っかからなくなります。また、引き続き放置する場合は、一言コメントしましょう。コメント操作でもupdatedの値が更新されます。

フィルターを購読する

と、まぁ私が普段使っているフィルターを色々紹介してきましたが、フィルターを作るだけではあまり効果がありません。このフィルターは「フィルターの結果」ウィジェットを使ってダッシュボードに常設しておくと良いでしょう。ウィジェットの追加方法は、説明し出すとまた長くなるので、@Sean_SFさんのブログ JIRAで、ある条件に当てはまる課題を常にダッシュボードに表示する方法 - Sean Osawa - Atlassian Japan Confluence を参照してください(逃)

ここではもう一つ。定期的にフィルターの条件を満たすチケットが無いかをチェックし、条件にhitするチケットが検出されたらメールを送る、という技です。

JRIAの課題メニューの一番下に「フィルターの管理」という項目がありますので、このページに飛んでください。作ったフィルターが列挙されているはずです。そのそれぞれのフィルターの右方に「配信登録」というリンクがあるはずです。これをクリックし、適当なスケジュール(例えば毎朝9時など)で配信登録してみましょう。これで、フィルターに引っかかった課題リストを毎日メールしてくれるようになります。

朝出社したら、このメールを見ながらチケットを整理することによって、クリーンな状態で仕事を始めることができますね。

番外編:今週解決した課題

resolution = Fixed AND resolutiondate >= startOfWeek() AND resolutiondate <= endOfWeek()

私が最近作ったフィルターです。週の頭には1つも引っかかりませんが、週末になるに連れて課題が増えていきます。あー、ウチのチームは今週これだけの仕事を進めたんだなぁ、って眺めながらニヤニヤする用のフィルターです。

実は私はもう一工夫して「自分が今週解決した課題」として、より一層ニヤニヤしているのですが。ただしこの場合、単に assignee = currentUser() ではダメなんですね。というのも、前述のルールでは、自分が解決したとしても報告者にアサインバックしてしまうから。そこで「 lastResolutionUser = currentuser() 」っていう条件(最後に「解決済み」にしたユーザ、つまりほとんどの場合「タスクの実施担当者・対応者」を表す)を使っています。しかしこの lastResolutionUser っていうのはJIRAの標準機能ではありません。Jira Enhancer Pluginというプラグインインストールし、設定しています。頑張れる人は各自頑張ってみてください。


さて JIRA Advent Calendar 4日目は以上です! みなさんも、便利なフィルター条件があったら教えてください。明日はエロ元上司 @j5ik2o (id:j5ik2o)…かと思いきや、どうやら@yusukeyの無茶振りに対してバックレを決め込んでいるようです。俺はそんな上司に育てた覚えはないぞっ!!w 観念してエントリーするように。

というわけで、明日は @inda_re 氏のエントリーです。お楽しみに!

*1:正確にはキーって呼ぶみたいですね

*2:チケットを作った人=仕事を振った人

*3:担当者をチケット作成者に割り当てる

*4:つまり「ステータスが解決済み かつ 担当者が自分」のチケット