Jiraとは何か｜何を管理する道具で、どこまでできるか
Jiraとは何か、と聞かれて「開発チームが使うバグ管理の道具」と答える人は多いのですが、実際に触ってみると、その説明では説明しきれない部分がすぐに出てきます。休暇の申請フォームを乗せている会社もあれば、営業の案件を並べている部署もあります。この記事では、公式ドキュメントに出てくる言葉をそのまま使って、この道具が何を数えていて、どこに骨格があるのかを整理します。名前と概念さえ噛み合えば、自分たちの仕事に合うかどうかの判断は、そのあと一気に速くなります。
この道具が数えているのは、作業項目という1件
まず押さえておく単位が、作業項目です。公式ドキュメントには次のように書かれています。
作業項目は Jira の基本構成要素です。作業項目は、ストーリー、バグ、タスク、またはスペースで使用されるその他の作業タイプを表します。 出典: support.atlassian.com
同じページには、ソフトウェアのバグ、プロジェクトのタスク、休暇申請フォームまで、あらゆるものを表せると書かれています。つまりこの道具は、仕事の種類を限定していません。1件として数えられるもの、状態が変わるもの、誰かが担当するもの。この3つが揃っていれば、中身が何であっても乗ります。
ここが理解の入口になります。表計算ソフトで管理していたものを移すとき、「何を1行にしていたか」がそのまま「何を1件の作業項目にするか」になります。行の単位が曖昧なまま移すと、道具を変えても同じ混乱がついてきます。逆にいえば、移す前に行の単位を決め直せば、それだけで整理が半分終わります。
なお、この作業項目という呼び方は、以前は課題と呼ばれていたものにあたります。日本語の公式ドキュメントでは現在、作業項目という表記が使われています。社内に古い資料が残っていると、同じものを別の名前で呼んでいる状態になるので、用語の対応を最初に決めておくと会話が噛み合います。
名前の付き方が、そのまま道具の骨格になっている
作業項目には、必ずキーが付きます。公式ドキュメントによれば、キーはスペースキーと連番の2つで構成されます。たとえばチームのコードネームがあれば、それを短くした英数字をスペースキーにして、そこに1件ごとの番号が続く形です。
この仕組みの効き方は、使い始めてしばらくすると分かります。チャットで「あの件どうなりました」と聞くかわりに、キーを1つ書けば済むようになります。会議のメモにキーを書いておけば、あとから当時の状態を追えます。メールの件名にキーを入れておけば、関連する会話がまとまります。要するに、仕事に住所を与える仕組みです。
住所が付いていない仕事は、探すのに時間がかかります。表計算ソフトで管理しているとき、「先月やりとりした、あの見積もりの修正」を探すには、ファイル名かチャットの検索に頼るしかありません。キーがあれば、その番号ひとつで済みます。この違いは、案件が3件のときは気になりませんが、20件を超えたあたりから毎日の時間に効いてきます。
キーは2文字以上で、大文字で始まる必要があると公式ドキュメントに書かれています。スペースを作るときに自動で提案され、あとから設定で変えることもできます。ただし、途中で変えると過去の記録の見え方が変わるので、最初に決めておくのが無難です。
「プロジェクト」ではなく「スペース」と呼ばれるようになった
もうひとつ、いま調べ始めた人が戸惑いやすいのが、入れ物の呼び名です。現在の公式ドキュメントでは、作業項目を入れる単位をスペースと呼んでいます。以前の資料や、他社が書いた解説記事では、これをプロジェクトと呼んでいることが多く、検索して出てくる情報と画面の表示が食い違います。
呼び名が変わっただけで、役割は同じです。スペースは、ひとまとまりの仕事を入れる箱で、そこにキーが割り当てられ、その中の作業項目に連番が振られます。ひとつの案件でひとつのスペースを作る会社もあれば、部署でひとつにして、案件は中の分類で分ける会社もあります。どちらが正しいという決まりはありません。
決め方の目安は、キーを見たときに誰の仕事か分かるかどうかです。スペースを細かく割りすぎると、キーの種類が増えて覚えられなくなります。反対に大きくまとめすぎると、番号だけでは何の話か分からなくなります。5人から数十人の規模なら、案件ではなくチームや取引先の単位でスペースを作り、その中で分類する形が扱いやすいことが多いです。
スペースには2つの型があり、後から効いてくる
公式ドキュメントには、スペースにはチーム管理対象と企業管理対象の2つがあると書かれています。違いは、誰が設定を持つかです。
チーム管理対象は、チーム内の誰でもセットアップして維持できます。設定が簡単で、管理者の手を借りずに始められます。自分たちのやり方を自分たちで決めたいチームに向いている、と説明されています。企業管理対象は、管理者が画面やスキームを設定する形で、複数のスペースで同じワークフローを共有したいときに向いています。管理者がスキームを変えると、その設定を使っているスペースがすべて連動して変わる、とも書かれています。
この選択は、あとから効いてきます。最初の1つ目を作るときは、早く動かしたいのでチーム管理対象を選びがちです。それ自体は悪くありません。困るのは、2年後にスペースが15個になり、それぞれが少しずつ違うやり方で回っているときです。同じ言葉が別の意味で使われ、部署をまたいだ集計ができなくなります。
とはいえ、最初から企業管理対象で厳密に組むと、設定を待つ時間が発生して、現場が別の場所で仕事を始めてしまいます。現実的なのは、最初の1年はチーム管理対象で回して、やり方が固まった時点で標準にしたい部分だけを企業管理対象へ寄せる、という順番です。公式ドキュメントには、2つの型の間で移行するための手順も用意されています。
6つのビューは、同じデータを別の角度から見ているだけ
料金ページの機能一覧には、バックログ、リスト、ボード、タイムライン、カレンダー、要約というビューが並んでいます。これらは別々の機能ではなく、同じ作業項目を違う並べ方で見せているものです。ここを理解しておくと、「どの画面を使えばよいか」という質問が「いま何を知りたいか」という質問に置き換わります。
ボードは、いま動いているものを列で見る画面です。公式ドキュメントには、ボードの既定の列として、作業前、進行中、完了の3つが用意されていると書かれています。同じページには、タイムラインが週や月や四半期にわたる大きな計画を追うのに向いているのに対し、ボードは通常1週間から2週間先までの、いま実行している作業の状態を見せるものだ、という趣旨の説明があります。
つまり、今週の話をしたいならボード、来期の話をしたいならタイムライン、という使い分けです。会議で画面を出すとき、この使い分けができていないと、細かいカードを見ながら来期の話をすることになり、議論が噛み合いません。
カレンダーは日付の入っているものを暦の上に置く画面、リストは表形式、バックログは着手前のものを並べておく置き場、要約は状況をまとめて見る画面です。すべて同じデータなので、どこかで状態を変えれば全部に反映されます。表計算ソフトを複数人で分けて持っていたときのように、どれが最新かを確かめる作業は不要になります。
ボードには表示の上限があり、設計に効いてくる
公式ドキュメントには、ボードには一度に最大5,000件の作業項目を表示できると書かれています。これを超えると、エラーメッセージが出てフィルターの更新を求められる、とも説明されています。
数字だけ見ると余裕がありそうですが、長く続く仕事では意外と早く届きます。日々の細かい依頼を1件ずつ立てる運用にしていると、月に数百件が積み上がります。3年続けば1万件を超えます。ここで慌てて整理を始めるより、最初から「ボードに出すのは動いているものだけ」という設計にしておくほうが手間がありません。
関連して知っておくとよいのが、完了したカードの扱いです。公式ドキュメントによれば、スプリント機能を使っていない状態では、完了列に置かれた作業項目は14日を過ぎるとボードから自動的に外れます。表示から消えるだけで、記録そのものが失われるわけではありません。この挙動を知らないと、「終わったはずのカードが消えている」と驚くことになります。
開発以外のチームが使うと、何が変わるか
公式の説明にあるとおり、この道具は休暇申請のような事務の手続きも扱えます。実際、マーケティング、法務、人事といった部門向けのテンプレートが用意されていると、スペース作成のドキュメントに書かれています。
ただし、開発以外のチームで使い始めると、たいてい同じところで詰まります。作業の粒度です。開発の仕事は、機能や不具合という形で自然に1件へ分かれますが、事務や営業の仕事は、始まりと終わりの境目が曖昧なことが多く、何を1件にするかで迷います。ここを決めずに始めると、ある人は1日の作業を1件にし、別の人は案件全体を1件にして、同じボードの上に粒度の違うカードが並びます。
もうひとつ詰まるのが、用語です。ストーリーやスプリントといった言葉は、開発の現場から来ています。事務のチームに同じ言葉で説明すると、意味が分からないまま操作だけ覚えることになり、応用が効きません。作業タイプの名前を自分たちの言葉に変えられる部分は変えて、変えられない部分は社内の言い換え表を作っておくと、定着が早くなります。
周りにある製品との関係を、ひとことずつ整理する
料金ページの下部には、同じ会社が出している製品が並んでいます。名前が似ているものが多いので、役割だけ整理しておきます。Jira Service Managementは、社内外からの問い合わせや依頼を受け付ける窓口の側を担う製品です。Jira Alignは、より大きな組織で計画を揃えるための製品です。Confluenceは文書を置く場所、Loomは画面の録画を共有する道具、Bitbucketはソースコードを置く場所、Trelloはカンバンの板です。
Rovoは、これらの上で動くAIの層です。料金ページの機能表には、Rovoのクレジットやインデックス付きオブジェクトの数がプランごとに書かれており、スペースの作成をAIに任せる機能も公式ドキュメントで案内されています。
この構成を知っておくと、比較検討のときに話がずれにくくなります。「問い合わせ対応も一緒にやりたい」という要望が出たとき、それは別の製品の話なのか、同じ製品の中でできるのかで、金額も設定の手間も変わります。最初の相談の段階で、どこまでを1つの道具に載せるつもりなのかを決めておくと、あとから追加の契約が発生しにくくなります。
クラウドで使うか、自社の環境に置くか
現在の料金ページに並んでいる4つのプランは、いずれもクラウドで使う形です。自社の環境に置きたい場合については、料金ページの下部にData Centerという案内があり、厳しい規制要件やセキュリティ要件がある顧客向けのオンプレミス製品で、詳細は問い合わせと書かれています。金額そのものは掲載されておらず、見積もりを取らないと分かりません。
自社の環境に置くかどうかは、機能の話ではなく、社内規程と運用体制の話です。置けば、更新も監視もバックアップも自分たちの仕事になります。数十人のチームで、その運用に人を1人割けるかどうかが判断の分かれ目になります。規程で外部のクラウドが禁じられているのでなければ、まずクラウドで始めて、必要になったときに考えるほうが現実的です。
作業タイプという分類が、階層を作る
作業項目には種類があります。公式ドキュメントでは、ストーリー、バグ、タスクといった作業タイプが例として挙げられており、権限があれば新しい作業タイプを作ることもできると書かれています。同じドキュメントの一覧には、作業項目とサブタスクを作成する、という項目も並んでいます。
種類が分かれていることの意味は、集計にあります。すべてを同じ種類で立てていると、あとから「不具合の対応にどれだけ時間を使ったのか」を出そうとしても、区別が付きません。反対に、種類を細かく作りすぎると、立てるたびにどれを選ぶか迷う時間が生まれます。5人から数十人の規模なら、3つか4つで足りることが多いです。
サブタスクは、1件の中をさらに分ける仕組みです。これも使いすぎると管理が重くなります。目安は、担当者が変わるかどうかです。同じ人が続けてやる工程は、1件の中のチェックリストで十分です。途中で別の人に渡るなら、渡す単位で分けたほうが、誰が持っているかがはっきりします。渡した瞬間に担当が変わることを、画面の上で見えるようにしておくのが目的です。
階層をどこまで作るかは、報告する相手で決まります。役員に見せるのが案件の単位なら、案件の上にもう1階層は要りません。部門をまたぐ計画を揃える必要があるなら、上位の階層が要りますが、その用途は上位プランの機能として整理されています。必要になってから足すほうが、最初から広く作るより扱いやすいです。
列に並ぶ言葉が、そのままチームの合意になる
ボードの列は、作業項目の状態を表しています。公式ドキュメントには、列はチームの作業項目のステータスを表し、ボードは通常チームのプロセスを反映するものだ、と書かれています。既定では、作業前、進行中、完了の3つです。
この3つのままで運用を始めると、たいてい1か月で不満が出ます。「作った人が確認するのを待っている状態」と「進めている状態」が同じ列に入るからです。進行中のカードが10枚並んでいて、そのうち6枚が誰かの返事待ちだと、ボードを見ても誰が動けるのか分かりません。
そこで列を足すことになるのですが、ここで気をつけたいのは、列は多いほど正確になるかわりに、動かす手間が増えるという点です。列が7つあると、1件が完了するまでに6回動かすことになります。動かすのを忘れる人が出ると、板は嘘になります。実務上は、4つか5つが限度です。作業前、進行中、確認待ち、完了。これに、必要なら保留を足す。この形で足りないと感じたら、列を増やす前に、担当と期日の運用を見直したほうが効きます。
列の名前を決める作業は、道具の設定というより、チームの合意を作る作業です。「確認待ち」とは誰の確認なのか、そこに何日置いてよいのか。この2つを決めずに列だけ作ると、確認待ちの列にカードが溜まり続けます。
検索できることが、この道具のいちばん地味な本体
キーの説明のところで触れましたが、この道具の価値がいちばん出るのは、探すときです。公式ドキュメントには、キーが表示される場所として、作業項目そのもの、検索結果と保存済みフィルター、ボードやバックログ上のカード、作業を接続しているリンク、そして作業項目のURLが挙げられています。
保存済みフィルターは、条件を決めて名前を付けて置いておく仕組みです。たとえば「自分が担当で、今週が期日のもの」を保存しておけば、毎朝それを開くだけで済みます。「取引先Aに関するもので、まだ終わっていないもの」を保存しておけば、打ち合わせの前に開けば準備が終わります。
進行をとりまとめる立場でいうと、この保存済みフィルターをいくつ作れるかで、日々の手間が大きく変わります。毎回条件を組み直している人と、5つのフィルターを行き来している人では、同じ情報にたどり着く時間が何倍も違います。導入したあとに定着しない原因の多くは、機能が難しいことではなく、この「自分用の入口」を作らないまま全体の画面だけを見ていることにあります。
もうひとつ、URLに住所があることの効き目も大きいです。1件ごとにURLが決まっているので、議事録にも、メールにも、別の管理表にも貼れます。貼った先から必ず元に戻れる状態を作っておくと、情報が散らばっても迷子になりません。
レポートは、書き込まれた分しか映さない
料金ページの機能一覧には、レポートとダッシュボード、レポートとチームのインサイトという項目が並んでいます。状況を数字やグラフで見るための画面です。
ただし、ここで出てくる数字は、書き込まれた内容をそのまま集計しただけのものです。実際には終わっているのにカードが動かされていなければ、レポートには終わっていないと出ます。逆に、始める前に完了へ動かしてしまう人がいれば、進みが実態より良く見えます。導入して2か月ほど経った頃に「レポートの数字が現場の感覚と合わない」という話が出るのは、機能の問題ではなく、入力の習慣がまだ揃っていないからです。
対処の順番は決まっています。まず、入力する人を増やすこと。とりまとめる人が代わりに打ち込んでいる状態では、いつまでも実態に近づきません。次に、入力の手数を減らすこと。1件を動かすのに3回クリックが要るなら、それは設計の問題です。最後に、見る場面を作ること。週に一度、同じ画面を全員で開く時間があるだけで、その前日に更新が進みます。
この順番を飛ばして、レポートの種類を増やしても意味がありません。映すものが揃っていないのに、映し方だけを増やしている状態になります。
向いている場面と、そうでない場面を先に分けておく
ここまでの内容を、判断に使える形にまとめます。向いているのは、仕事が1件ずつに分かれていて、状態が変わり、誰が持っているかを追いたい場面です。件数が多く、履歴を残す必要があり、後から検索したい場面ほど効きます。
反対に、向いていないというより、この道具でなくてもよい場面もあります。仕事が数十件しかなく、担当が固定されていて、期日も動かないなら、板を1枚持つだけで足ります。設定の自由度が高いということは、決めることが多いということでもあります。決めることを増やしたくない段階では、それが負担になります。
判断に迷ったら、いま管理している表を1枚持ってきて、そのうち何行が「状態が変わるもの」かを数えてみてください。半分以上がそうなら、この形の道具が効きます。ほとんどが記録として置いてあるだけなら、必要なのは台帳ではなく共有の場所です。
使い始めてからの3か月で、順番に起きること
道具そのものの説明とは別に、入れたあとに何が起きるかを知っておくと、慌てずに済みます。よく聞くのは、次のような流れです。
最初の2週間は、たいていうまくいきます。新しい画面が面白いので、全員がカードを立てます。問題は3週目からです。立てたカードが動かなくなり、完了に移されないまま溜まり始めます。この時点で「合わなかった」と判断されることが多いのですが、原因はほとんどが1つで、動かす人がとりまとめ役だけになっているからです。
1か月を過ぎると、別の問題が出ます。カードの粒度がばらつきます。ある人は1日の作業を1件にし、別の人は案件全体を1件にします。並べたときに大きさが揃っていないので、進捗の割合が意味をなさなくなります。ここで一度、粒度の目安を決め直す会話が要ります。目安は「1件が3日以内に終わるか」で十分です。
2か月から3か月にかけては、設定を触りたくなる時期が来ます。項目を足したい、自動化を組みたい、といった要望が出ます。ここで一気に手を入れると、覚えることが増えて、せっかく参加し始めた人が離れます。足すのは、3人以上から同じ要望が出たものだけにしておくと、複雑さが増えすぎません。
3か月を越えて残っているなら、その道具は定着したと考えてよいです。逆に、3か月経っても、とりまとめ役以外が触っていないなら、道具の問題ではなく、板を見る場面が仕事の流れの中に組み込まれていない可能性が高いです。
板の数と人数で区切る、という別の考え方
道具を比べるときは、できることの一覧より、区切り方を見たほうが違いが分かります。機能ごとに段階を作る方式は、必要な機能が上のほうにあると、使わない機能まで一緒に買うことになります。機能で絞らず、区切るのは人数とボードの数だけという考え方なら、選ぶときに数えるのは人数と板の枚数だけで済みます。
カンバンの板を軸にした道具との違いはTrelloとの比較にまとめてあり、仕事の割り当てと期日を中心に据えた道具との違いはAsanaとの比較で扱っています。文書と台帳を同じ場所に置く考え方についてはNotionとの比較、色分けと見た目で状態を追う道具についてはmonday.comとの比較、国内で広く使われている道具についてはBacklogとの比較とJootoとの比較にそれぞれ整理があります。一覧で見たいときは比較の一覧が入口です。
具体的にどこまでできるのかはできることに、費用の区切り方は料金に載せています。いま使っている板から動かす場合の手順はTrelloからの移行に、預けるデータの扱いは安全性の考え方に置いてあります。そこに載っていない疑問はよくある質問で拾えます。
調べ終わったあと、最初にやることは1つだけ
Jiraとは何かを理解したあと、次にやるべきことは、機能の比較ではありません。自分たちの仕事のうち、何を1件として数えるのかを決めることです。ここさえ決まっていれば、どの道具を選んでも形になりますし、決まっていなければ、どんなに高機能な道具を入れても表は嘘になります。
決め方は簡単です。過去1か月のチャットを開いて、「これどうなりました」と聞かれたものを書き出します。それが、数えるべき単位です。聞かれないものは、数えなくても回っています。数えるものが決まったら、そこに住所を与えて、状態を3つか4つに決めます。作業前、進行中、確認待ち、完了。これで十分に動きます。
そのうえで、道具ごとの向き不向きを見ていくと、比較の時間が半分になります。用語や画面の名前が違っても、やっていることは同じです。1件を数えて、状態を変えて、誰が持っているかを分かるようにする。この骨格が見えていれば、どの製品の説明を読んでも迷いません。
もうひとつ、調べる順番として覚えておくとよいことがあります。製品の紹介ページより先に、公式のヘルプを読むほうが実態に近い情報が手に入ります。紹介ページは何ができるかを並べますが、ヘルプには上限や既定値や例外が書かれています。ボードに何件まで並ぶのか、完了したカードが何日で消えるのか、キーが何文字から使えるのか。導入したあとに困るのは、たいていこちら側の情報です。検討の段階で一度ヘルプを開いておくと、稼働してからの驚きが減ります。
Q1. Jiraは開発チーム以外でも使えますか？
使えます。公式ドキュメントには、作業項目はソフトウェアのバグからプロジェクトのタスク、休暇申請フォームまで表せると書かれており、マーケティングや法務や人事の部門向けテンプレートも用意されています。ただし作業の粒度と用語の言い換えを先に決めないと、粒度の違うカードが並んで運用が崩れます。
Q2. プロジェクトとスペースは違うものですか？
現在の公式ドキュメントでは、作業項目を入れる単位をスペースと呼んでいます。以前の資料や他社の解説記事ではプロジェクトと書かれていることが多く、検索結果と画面表示が食い違いますが、指しているものは同じです。社内資料が古い場合は、用語の対応を先に決めておくと会話が噛み合います。
Q3. ボードに表示できる件数に上限はありますか？
公式ドキュメントには、ボードには一度に最大5,000件の作業項目を表示できると書かれています。超えるとエラーが出てフィルターの更新を求められます。また、スプリント機能を使っていない場合、完了列の作業項目は14日後にボードの表示から自動的に外れる仕様です。
Q4. 自社のサーバーに置いて使うことはできますか？
料金ページの下部に、Data Centerという名称で、厳しい規制要件やセキュリティ要件がある顧客向けのオンプレミス製品が案内されています。金額は掲載されておらず問い合わせになるため、公開資料では確認できませんでした。自社環境に置くと更新や監視も自分たちの仕事になる点は先に見積もっておく必要があります。