この記事はDee Ann Pizzicaによるゲスト投稿です。
さて、あなたはアジャイルソフトウェア開発チームにいて、会社は作業を追跡するツールとしてJiraを選択しました。Jiraはすばらしいツールです。大幅なカスタマイズが可能です。十分に機能します。けれど誰もが単にJiraに我慢しているだけで、気に入っている人は誰もいないようです。
Jiraを使っているチームにいたことがあるなら、おそらく誰でも、不満や、あるいははっきりと嫌いだという意見を聞いたことがあるでしょう。QAスタッフは例外かもしれませんが、それは単に慣れているからというだけかもしれません。
どうすればJiraを嫌う人たちの不満を鎮め、チームのエクスペリエンスを高めることができるでしょうか？
詳細に移る前に、いくつか覚えておくべき重要なことがあります。
Jiraは目標の達成を助け、プロセスをサポートするツールであることを忘れないでください。Jiraは（アジャイルであれそれ以外であれ）プロセス自体ではありません。どんなプロセスに従うと決めた場合でも、Jiraは役に立ちますが、結局のところはツールにすぎません。チームのあらゆる問題を魔法のように解決してくれるツールなどありません。
もう1つ、覚えておくべき大事なことは、チームに必要なのは興味を引く情報ではなく、アクション可能な情報だということです。環境をセットアップしたら、吟味してください。なぜ情報が欲しいのかを自問自答してください。たとえば、スプリントで記録されたバグの数をJiraで追跡することは可能です。記録されたバグの数を知るのは興味深いことかもしれませんが、その知識はプロセスに関する意思決定の参考になるでしょうか？そのデータがあることはポジティブな変化を促すでしょうか？
ありとあらゆる種類の興味深い作業アイテムが記録され、傾向を観察できます。アクションを起こすことができないデータにとらわれるのはやめましょう。先へ進み、Jiraを中心としてあらゆるものを記録しましょう。ただし、なんでも過度にありがたがるのはやめましょう。そんな時間はありません。
明確にしておくと、この記事では、Jiraに記録されるものはなんでも「作業アイテム」、「課題」、「チケット」と呼びます。エピック、ユーザーストーリー、バグ、タスク、サブタスクなど、標準的に使われるカテゴリがいろいろあります。すべてにルールや制約を課し、異なるフィールドを使うことができます。非常に複雑になる可能性もあります。しかし、根本的には、ツールに入力したものはすべて、あなたか他のメンバーが対処することになります。誰かに作業をしてもらいたい場合、作業内容が明確で、具体的で、取り組みやすく、検索可能でなければなりません。これを達成できれば、作業が行われる可能性が高まります。そして、作業が完了することこそが目標なのではありませんか？
そこで、これから説明する、チームがJiraに抱くいくつかの大きな不満と、それにどうやって対処するかが重要になるのです。
検索
「Jiraでは何も見つけられない！」
チームのあらゆるバグ、あらゆるすばらしいアイデアがJiraのどこかに記録されますが、どうやってそれを見つけられるか、誰にもわかりません。これはもっともな不満です。スプリントボード、バックログ、プロジェクト、エピック等、作業アイテムが隠れられる場所はたくさんあります。しかし、ある程度の解決策はあります。
Jiraでの作業アイテム探しはJiraの外で始まる
ステップ 1: 共通の用語と語法を確立する
行う作業を記述するのに使う単語について合意する必要があります。あなたは新しい機能を「オンボーディング ウィジェット」と呼び、私は「新規ユーザー フロー」と呼んだとして、どちらも適切であるかもしれません。しかし、異なる用語を使用するのは非効率であり、チームはおそらく混乱するでしょう。共通の用語はプロジェクト全体を通じた明確さにつながり、コミュニケーションを改善します。
ステップ 2: プロジェクトおよびフィーチャーのキーワードをピックアップする
検索可能な用語が必要です。たとえば「フロー」はいくつかの場所で使われている可能性がありますが、「オンボーディング」は後で検索するときにより簡潔なキーワードになるでしょう。
ステップ 3: 作業アイテムのタイトルにキーワードを使用する
記録するすべてのアイテムの名前をチーム全体が了解しているキー用語で始めるようにします。この用語は特定の機能またはコードの領域を表します。これにより、チームにとって意味のある用語のセットに基づいて検索やソートを行うことができます。
チームの他のメンバーがあなたの助けなしに情報にアクセスできる必要があることを忘れないでください。もし、あなただけに意味がある用語を使った場合、他の誰も効果的に検索することができないため、あなたの作業は見失われる可能性があります。他の誰かが検索したとき、まとめてグループにする必要のある作業が漏れてしまうかもしれません。見つけられるのがあなたしかいないため、あなたがボトルネックになります。
たっぷりとラベルする
すべての作業のための意味のある用語とカテゴリーのセットが確立されたら、あらゆるものにラベルを付けます。1つのチケットに好きなだけラベルを使うことができます。いくつか保存すると、入力を始めたときに表示されるようになるので、再利用が容易です。
ラベルは製品に関連するものでも、エンジニアリングを目的としたものでもかまいません。私のチームでは、チケットに「購入フロー」、「料金」、「注文履歴」、「顧客からレポート」などのラベルが付けられています。漠然としているように見えるかもしれませんが、各用語はチームにとって意味があり、特定のページ、機能、可視性などを指し示しています。
あらゆるものにラベルを付けると、より効果的なクエリーを作成できます。すべての「購入フロー」チケットを検索し、そのリストに「顧客からレポート」を追加することもできます。
チームの誰もがアクセスできるスプレッドシートでラベルを管理し、用語の意味を記載しています。誰もが関わっているため、皆が合意した同一の用語を使用して作業を記述できます。この種のドキュメントは、特にチームの新規メンバーにはとっつきにくく思われるかもしれません。オンボーディングチェックリストにチームのJiraの使い方や皆が使用する共通用語の場所を案内することという注意事項を追加しましょう。
チケットのグループ化
「バックログがめちゃくちゃだ！」
いとも簡単に乱雑なチケットの山ができ、永遠に終わりそうにないバックログの問題につながります。なにかを終わらせるのが難しくなり、その時点でシステムは崩壊に向かいます。対策は、バックログのアイテムをフィルターし、ソートし、焦点を絞るためのプロセスをあらかじめ決めておくことです。
エピック
エピックは整頓に役立ちます。バックログにエピックタグを表示するよう設定できます。すると、互いに関連があるアイテムをすばやく把握するのに役立ちます。計画してプロジェクトのバックログに何百ものアイテムを積みあげるチームはありませんが、そうなってしまうのは不可避です。エピックを作成すると、まとめて評価できる可能性があるチケットをチームメンバーが見つけるのに役立ちます。
もう1つエピックの便利な機能は、リンクされたすべての課題が大きなリストに表示されることです。リストをざっとみて、あらゆるもののステータスを確認することができます。チケットのグループの目標と目的の説明を追加することもできます。
スプリント
スプリントは作業をフィルターし、チームが集中できるようにするもう1つの仕組みです。作業をスプリントに追加すると、Jiraの「アジャイルモード」が有効になります。チケットをスプリントボードでカスタム列とともに見ることができ、進捗も表示されるようになります。Jiraを利用しているアジャイルチームの場合、おそらくチームがメインで利用するビューはこれでしょう。
しかし、他にも試せることがあります。通常のスプリント用にスプリントを作成するだけでなく、タイムフレームとはかかわりなくひとまとまりで追跡したいチケットのグループ用にもスプリントを作成します。たとえば、カスタマーサポートチームであれば、顧客からレポートされたオープン中の問題に関する更新を把握するためにチケットをまとめます。チケットがバックログに散らばっていると、現在の新規フィーチャーの作業の中でチケットを検索し、優先順位をつけるのが難しくなる場合があります。まとまりとして扱われるよう、スプリントを作成しましょう。修正が行われることになった場合、グルーミング時にそれらのチケットを新しいスプリントに割り当てることができます。
(スプリントボードを含め)Jiraでなにも見つけられないというすべての人に、おまけのヒントがあります。チームに現在のプロジェクト専用のSlackチャネルがあれば、チャネルトピックをJiraスプリントボードへのリンクとして設定しましょう。
パーミッションの付与
「そのフィールドを変更できません！」
ツールをセットアップする際に管理者が行う判断で最も難しいのが、それぞれのユーザーにどんな権限を与えるかです。Jiraにはきめ細かいパーミッションやアクセスのオプションがあります。広く信頼し、すべてをできるだけオープンにすることも、ロールに必要な権限だけに制限することもできます。
あまりにも多くのものにアクセスできると気が散り、危険である可能性もあることはわかります。しかし、協調的なチームで作業するには、訓練と信頼が必要です。Jiraの管理者はあらゆる手段を使って仕事を容易にできるのに、自分にはそれができないというのは不満がたまるものです。
管理者は特定のオプションをチームに開放し、Jiraの作業を容易にする機能を活用できるようにするべきです。
一括更新
一括更新は、チームによっては制限していることもある強力な機能です。誰かが誤って大量のチケットを更新してしまったことや、開発者やテスターはチケットを操作するたびに必ずコメントを追加して何らかの情報を提供するべきだという考えから、この機能を制限したくなるかもしれません。しかし、どんなに細かいチームでも、ショートカットを必要とする場合はあります。
ステータスは、チームの誰もが更新する必要がある一般的な更新です。ステージング環境にデプロイされ、テストの準備ができたチケットが大量にあるかもしれません。既存のエピックを分割したり、複数のチケットに新しいラベルを追加したい場合もあるかもしれません。理由はなんであれ、すばやく作業できる必要があります。管理作業が必要になればなるほど、ツールへの不満も増えるでしょう。
課題の移動
チームのだれもがすばやく課題を移動できる必要があります。Jiraでは、これはターゲットプロジェクトまたは課題タイプを変更することを意味します。プロジェクトや課題のタイプによってワークフローや機能が異なる場合があるため、記録済みの課題を要求される作業に合わせて変更できる柔軟性をチームに提供する必要があります。
よくある例は、ユーザーストーリーでサブタスクを作成する場合です。開発者がサブタスクを掘り下げると、作業についてより多くのことがわかります。ときには単純なタスクに見えたものが、当初の想定よりも複雑になることもあります。そのような場合、タスクを分割して独立したストーリーにするのが適切かもしれません。
作業を追跡してスプリント終了時にストーリーをクローズさせたい場合、簡単にチケットを修正できるようにしなければなりません。ある問題への対処として情報をコピー&ペーストした場合、その作業を追跡できなくなることがよくあります。
ステータスワークフロー
Jiraの課題のステータスは、どの作業が完了しており、どの作業を次に行うべきかを理解するうえで非常に役に立つことがあります。
To Do、In Progress、Code Review、Testing、Ready for Deploy、Doneなどの通常のステータスを使用する基本的なワークフローを作成します。環境によってステータスは異なる場合がありますが、たいていのチケットはあらかじめ決められた道筋でこれらのステージを通過します。ツールがフローの次のステップを提案できるほど利口であれば理想的です。
問題は、設計されたワークフローにうまくはまらないようなことをしたいと考えたときに発生します。ありとあらゆるケースが考えられます。たとえばチケットの更新が遅れている開発者がいるかもしれません。チケットはすでに完了してコードレビューに入っているのにTo Doステータスのままです。チケットが各ステップをいちいち通らなければならない場合、最新の状態を保つための作業負荷が増加します。
特定のフローに従うよう強制することでは、プロセスやコミュニケーションの問題は解決されません。作業が完了することと、ボードが最新であることと、どちらのほうが重要か自分に尋ねてみましょう。ボードに適切なステータスが表示されることが重要だと皆が同意するなら、なぜだか話し合ってみましょう。
ときには作業を始めたあとで変更が入ることがあります。必要だと考えた手順が、結局は作業を完了するのに必須ではないとわかることもあります。3つのストーリーが必要だと思われたものが1つに収まったと思ったら、今度は1つのチケットの進捗のために3つのチケットを進めることになったりします。
次のステップを提案するようJiraを設定するのもよいですが、いっぽうで1つか2つのステップをスキップする必要がある場合に備えて、ユーザーが任意のステータスを選べるようにします。
データの取得
提案される情報のテンプレートを提供するか、カスタムフィールドを作成して、必要なすべてのデータを捕捉します。必要なものすべてを要求します。ただし、ごく基本的なもの以外は要求しないようにしましょう。必須にする基本的なフィールドには、プロジェクト、課題タイプ、タイトル、説明などがあります。多くの場合、これだけでは足りませんが、手始めとしては十分です。
通常、チームメンバーは何か別のことをしている最中に発見した問題についてメモを記録しています。思い付きをすばやく簡単に記録し、後で時間ができたときに戻ってこられるようにします。なお、記録されるすべての作業アイテムにあなたが欲しいと思うフィールドが必要だとはかぎりません。
プロセスやメンバーの問題により、特定のフィールドやワークフローの特定の部分を必須にしたいという誘惑に駆られるかもしれません。アイテムに十分な情報を提供しないメンバーがいるとして、単にフィールドを追加したりテンプレートを提供するだけでは、状況は変わらないでしょう。なぜその情報が必要なのか、どのようにチームの役に立つのかを該当メンバーに説明するほうが、情報を要求するワークフローに従うよう強制するより、はるかに効果的でしょう。
ツールはチームのコミュニケーション能力を改善しません。バグ修正のために原因情報を提供するよう開発者に要求することは可能です。品質チームはバグが修正されたことをテストするためにその情報を必要とします。しかし、ツールは開発者に品質の高い情報を入力するよう強制はできません。ツールはまだ作業中の作業がどれくらいあるかを明確にしますが、何が進捗を妨げているかについては教えてくれません。
究極的には、ツールはチームのコミュニケーションを支援するためにあります。Jiraはスタンドアップミーティングや、質問や、ディスカッションや、建設的なフィードバックの代わりにはなりません。
聖域はない
積極的に変化しましょう。積極的に削除し手放しましょう。何かがJiraに長くとどまるほど、それがずっと妥当である可能性は少なくなります。物事を動かすのに抵抗を持たないようにする必要があります。
バックログのあらゆるものを修正する時間が与えられることはけっしてありません。ときには断念する必要があります。チケットを削除したくないのであれば、単にクローズすることもできます。何もかも作業することはできないため、何がチームの目標に適うのかについて現実的になりましょう。チームが対処すると計画したものだけを保存し、単に興味を引くだけのものは手放しましょう。
統合
「なぜ同じ情報をこんなにたくさんの場所にポストしなければいけないの？」
Jiraと統合するツールを日常的に使っているのであれば、統合を検討しましょう。統合を利用すれば、さまざまなシステムからの情報を接続できるので、あらゆるものをあらゆる場所で更新する必要がなくなります。Jiraとともに利用できるツールの例として、以下のようなものがあります。
Slack
Slackには優れたJiraとの統合機能があります。さまざまなプロジェクトチャネルを更新するようプロジェクトを設定できます。そうすると、誰かがチケット番号を入力すると、該当するJiraへのリンクが続きます。この機能を利用すると、チケットに関して他のメンバーと容易にコラボレートできるので、課題を見つけて調査を行い、Slackのディスカッションにすることができます。
GitLab
GitLabとの統合も可能です。コードリポジトリとの統合を検討しましょう。統合することで、開発者がコミット時にJiraの課題についてコメントすると、チケットにリンクが自動的にポストされます。これで、少なくともアイテムに関する作業が終わったことがわかります。理想的なケースでは、リンクによって変更に関するさらなるコンテキストがわかります。
Zendesk
カスタマーサービスチームがZendeskを使用してサポートの問題を追跡している場合、Jiraとの統合をセットアップできます。顧客からレポートされた問題によって開発チームによる変更が必要になる場合があります。Zendeskのチケットを関連するJiraアイテムにリンクできます。すると、エンジニアリングチームは、どれだけ多くのチケットがリンクされているかに基づいて、より正確に影響を判断することができます。また、サポートチームがリンク先を見てJiraチケットのコメントやステータスを確認し、修正の進捗を見守ることを可能にします。
TestRail
TestRailにもJiraとの統合が用意されています。TestRailと統合すると、テスト結果からバグレポートを作成できます。テストに対応するJiraレポートにリンクすることもできます。
ソフトウェアの開発は複数のツールに依存しています。情報をできるだけ見つけやすくするためには、ツールをリンクし、相互参照するべきです。
コミュニケーションをわかりやすく、全員に力を与える
Jiraに関する私たちの目標は、作業を完遂するためにアクション可能な情報を得ることです。
チームで共通の用語を策定し、Jiraに記録するあらゆるものに対して使います。そのような用語を使用すると、より強力な検索を行うことができます。どんなものでも、チームにとって意味のあるまとまりで作業をグループ化します。作業がたどる道を変えることができるようにしましょう。できるだけ他のツールと統合して重複作業を減らします。
このようなアドバイスに従うことで、ツールとしてのJiraに関する不満を鎮め、より良く情報を追跡できるようにし、共有する必要がある重要な情報を共有するための役に立つヒントをチームに提供できます。情報と同じように、最も価値のあるものに確実に時間をかけられるようにするとよいでしょう。
常に自分自身に次のように尋ねてください。これは興味を引くだけか、それともアクション可能か？必要なくなったものは手放しましょう。ツールにプロセスを修正する仕事をやらせないようにしましょう。
Dee Annは熱心で好奇心にあふれたソフトウェアテスターです。15年以上にわたって、さまざまな業界の顧客向けに、小規模からエンタープライズ規模まで、きわめて複雑なビジネスロジックを持つカスタムモバイルおよびWebアプリケーションをサポートしてきた経験があります。現在、Dee AnnはBRDのDirector of Engineeringとして勤務し、iOSおよびAndroid向け暗号通貨ウォレットに取り組む才能あるチームとコラボレートしています。
（この記事は、開発元Gurock社の Blog 「Solutions to Your Common Problems with Jira」2020年5月7日の翻訳記事です。）