compare
Jiraでタスク管理を始める前に｜開発以外のチームで起きること
Jiraでタスク管理をしたいという相談は、2つの立場から来ます。1つは開発のチームで使っていて、その仕組みを他の部署にも広げたい立場。もう1つは開発ではないチームで、評判を聞いて検討している立場です。同じ製品でも、この2つでは判断の材料がまったく違います。
先に結論を書きます。開発の現場で使われている仕組みをそのまま他の部署に広げると、用語と設定の壁で止まります。逆に、その壁を越える手当てを先に用意すれば、道具そのものは問題なく使えます。この記事では、この製品が前提にしている仕事の形、10ユーザーまで無料という料金の数え方、開発以外のチームでつまずく場所、そして浸透にかかる時間を縮める手を順に扱います。
この製品が前提にしている仕事の形
最初に押さえたいのは、タスクを何と呼ぶかです。この製品では、仕事の1件を課題として登録し、進み具合をステータスで管理します。紹介記事では次のように説明されています。
Jira Cloudは、タスクひとつひとつを「課題」として登録し、進捗状況を「ステータス」で管理します。どのタスク（課題）がどの進捗状況になっているのかを、当事者だけでなく、チームメンバーからも可視化できます。 出典: ricksoft.jp
課題という言葉は、開発の現場では自然に受け取られます。不具合、要望、調査といったものを1件ずつ登録して追いかける文化が先にあるからです。一方、営業や総務や制作の現場では、日々の仕事を課題と呼ぶ習慣がありません。「課題を登録してください」と案内した時点で、何を登録すべきか分からないという反応が返ってきます。
これは名前だけの問題に見えて、実際には運用の問題になります。仕事の1件をどこまで細かく分けて登録するのか、その判断の基準が言葉に含まれているからです。不具合の1件は明確ですが、「来月の展示会の準備」は1件なのか10件なのかが分かりません。開発以外のチームに広げるときは、何を1件と数えるかを決めて、言葉も自分たちの呼び方に置き換えてください。
規模の面では、広く使われている製品です。導入の実績について、次のような紹介があります。
「Jira（ジラ）」は、プロジェクト管理の効率化を図るために、世界約30万社が企業が導入しているITツールです。 出典: ricksoft.jp
広く使われていることは、情報が多いという利点になります。設定の方法や困ったときの対処が、日本語の記事としても多く公開されています。導入を任された人が調べれば答えが見つかる状態は、社内に詳しい人がいない場合に効きます。
無料の範囲は10ユーザーまで。料金の数え方
料金の条件は、日本向けの料金ページで確かめられます。2026年9月27日時点では、無料のプランが10ユーザーまで無期限で無料と書かれています。有料のStandardは1ユーザーあたり月額1,085円、Premiumは1ユーザーあたり月額1,987円です（消費税は別で、ユーザー数によって額が変わる形です）。
10人までが無料という線は、試す段階では十分です。1つのチームで始めるなら、費用の判断を後回しにできます。稟議を通す前に数週間動かして、続けるかどうかを決められるのは大きな利点です。
数え方で注意したいのは、11人目が入ったときです。人数で区切る形なので、11人目が入った時点で全員分が有料になります。5人から10人のあいだで運用している場合は、いつ11人目が入るのかを見ておいてください。人が増える予定があるなら、増えた月からの金額を先に計算しておくと、急な稟議になりません。
また、見るだけの人を人数に数えるかどうかは、製品によって扱いが違います。報告を見るだけの管理職を何人入れるかによって、合計が変わります。この条件は料金ページと利用の条件に書かれているので、申し込む前に確かめてください。
もう1つ、関連する製品を併せて使う場合の費用も確かめておきます。文書の共有や社内の問い合わせ管理を同じ会社の別の製品で行う構成にすると、それぞれに費用がかかります。全部をまとめた場合の月々の合計を出してから判断してください。
開発以外のチームでつまずく4つの場所
導入が止まる場所は、だいたい決まっています。
1つめは、用語です。課題、ステータス、ワークフローといった言葉が、日常の仕事の言葉と結び付きません。最初の案内で、自分たちの言葉に言い換えた対応表を配ると、この壁は下がります。
2つめは、設定の自由度です。状態の並びや入力の項目を細かく決められるため、決める作業が先に発生します。開発のチームには決める習慣がありますが、他の部署では、決めること自体が新しい仕事になります。
3つめは、最初の画面で何をすればよいか分からないことです。使い始めたときに、登録する場所と見る場所が同じ画面に無いと、操作の順番を覚えるまで時間がかかります。実際に、浸透までに時間がかかったという声があります。
高度なタスク管理作成が可能ですが、初見ではどのようにしたら必要な作業ができるかなどの使いづらさがあり、他メンバーにこのツールの使用を浸透させるまでに時間がかかりました。 出典: stock-app.info
この声は、機能が足りないという話ではありません。できることが多い道具で、最初にどこを触ればよいかが分かりにくいという話です。導入を任された人が、最初の3つの操作だけを画面の写真つきで案内すると、浸透の速さが変わります。
4つめは、権限です。誰がどの案件を見られるかを細かく設定できる分、設定を間違えたときに見えるべきものが見えない状態になります。社外の協力者を入れる場合は、先に見せる範囲を決めてから招いてください。
開発の現場で育った設定を、そのまま持ち込まない
すでに社内の開発チームで使われている場合、その設定をそのまま複製したくなります。作る手間が省けるように見えますが、ここは分けて考えたほうが安全です。
開発の設定には、その現場の事情が積み重なっています。状態が細かく分かれているのは、確認や検証の工程が実際にあるからです。入力の項目が多いのは、後から集計するときに必要だからです。事情を共有していないチームに同じものを渡すと、埋める理由が分からない項目と、使わない状態が並びます。
参考にするなら、設定そのものではなく、決め方を参考にしてください。状態をどういう基準で分けたのか、どの項目を必須にしたのか。その基準を聞いて、自分たちの仕事に当てはめ直す形です。この作業に半日かけておくと、あとの数か月が軽くなります。
もう1つ、開発チームの運用の速さを基準にしないことです。毎日画面を開く習慣があるチームと、週に2回しか開かないチームでは、同じ仕組みでも動き方が変わります。週に2回しか開かないなら、通知と週1回の場で補う設計にしてください。
社内に詳しい人がいることは利点です。ただ、頼る範囲は決めておいてください。設定を全部任せると、困ったときに毎回その人を呼ぶことになり、自分たちで直せなくなります。
浸透にかかる時間を縮める3つの手
新しい道具が定着するかどうかは、最初の2週間で決まります。縮めるための手は3つです。
1つめは、登録する項目を最初は3つに絞ることです。仕事の名前、担当、締切だけで始めます。細かい項目は、運用が続いてから、足りないと声が出たものだけを追加してください。項目が多いと、1件の登録に時間がかかり、登録されない仕事が出ます。
2つめは、状態の数を4つに抑えることです。未着手、進行中、確認中、完了で足ります。開発の現場では状態が6つや8つに分かれていることがありますが、そのまま他の部署に持ち込むと、どの状態に置くべきか迷う仕事が出ます。迷ったカードは動かされないまま残ります。
3つめは、週に1回15分、全員で画面を開く場を作ることです。この場で、状態が古くなっているものをその場で直します。場があると入力は習慣になり、無いと忙しい週に止まります。この時間は、進捗を聞いて回っていた時間から出てくるので、新しい負担にはなりません。
加えて、質問の受け先を1人決めておいてください。誰に聞けばよいか分からないと、質問が出ないまま使われなくなります。受けた質問と答えをそのまま残せば、次の人への案内になります。
開発と開発以外で、道具を分けるか同じにするか
判断が分かれるのはここです。同じ道具にする利点と、分ける利点の両方があります。
同じ道具にする利点は、開発への依頼が直接つながることです。制作や営業から開発への依頼が多い職場では、依頼を課題として登録すれば、その後の進み具合を依頼した側からも追えます。間に人が入って転記する作業が消えます。管理する側も、権限と請求を1か所で見られます。
分ける利点は、それぞれの仕事に合った形で使えることです。開発の仕事は、状態が細かく分かれていて、分岐も多くなります。一方、他の部署の仕事は、締切と担当が決まっていて状態が少ない形が多くなります。片方に合わせると、もう片方が使いにくくなります。
判断の目安は、部署をまたぐ依頼の件数です。月に20件を超えるなら同じ道具にしたほうが転記が減り、それ以下なら分けたほうが、それぞれの使い勝手を優先できます。分ける場合は、依頼の受け渡しだけをどうつなぐかを決めてください。
もう1つの考え方として、依頼を受け付ける入口だけを共通にして、その後の管理は部署ごとの道具で行う形もあります。入口を1か所にすると、依頼の抜けが無くなり、それぞれの部署は使いやすい道具を使えます。
仕事の1件を、どこまで細かく分けるか
課題として登録する単位を決めないまま始めると、人によって粒度が変わり、件数が意味を持たなくなります。分ける基準は2つです。
1つめは、担当が変わるところで切ることです。同じ人が続けてやる作業は1件にまとめ、渡す相手が変わるなら分けます。制作から確認に回す、確認から発送に回すといった受け渡しの点で切ると、止まっている場所が誰の手元なのかが見えます。
2つめは、日付が変わるところで切ることです。同じ日に終わる作業は1件で足ります。1つの作業が3日を超えるなら分けてください。3日を超える作業は、遅れに気づくのが遅くなります。逆に半日を切る作業を分けると、登録する時間のほうが長くなります。
この基準で切ると、「来月の展示会の準備」は、会場との連絡、配布物の手配、当日の担当決め、搬入の手配といった形に分かれます。分けた結果が10件を超えるなら、上に1つの枠を作って、その下に並べる形にしてください。一覧に並んだときに、どの枠の作業かが分かる状態にしておくのが目的です。
粒度を決めたら、1行で書いて全員が見える場所に残します。書いていないと、3か月後に入った人が別の粒度で登録し始めます。粒度がそろっていない一覧は、件数で状況を判断できなくなります。
依頼を受け付ける入口を、1か所にする
開発以外のチームでタスク管理を始めると、最初に効くのは依頼の受け付けです。チャットで来る依頼、口頭で来る依頼、メールで来る依頼が混ざっていると、受けた本人しか知らない仕事ができます。
入口を1か所にするとは、依頼を受ける場所を決めて、そこ以外で受けた依頼も必ずその場所に登録することです。チャットで依頼が来たら、その場でカードを作って、カードのリンクを返す。この動作を習慣にすると、どの依頼がどこまで進んでいるかを依頼した側からも見られるようになります。
入口を1か所にすると、聞き返しが減ります。依頼した側は、状況を尋ねる前に自分で見られます。受けた側は、同じ説明を何度もしなくなります。この効果は、依頼の件数が多い部署ほど大きくなります。
決めておくのは、依頼に何を書いてもらうかです。依頼の内容、希望する期限、優先したい理由の3つで足ります。項目を増やすと、依頼する側が入口を使わなくなり、またチャットに戻ります。依頼する人の手間を最小にすることが、入口を守る条件です。
そして、入口に来た依頼を誰が受けるかを決めてください。受ける人が決まっていないと、依頼は入口に溜まります。当番を週ごとに回す形にすると、1人に集中しません。
移すときに、データをどう運ぶか
すでに別の道具で管理している場合、移行の作業が発生します。ここで判断するのは、何を運び、何を運ばないかです。
運ぶのは、進行中の仕事だけにしてください。過去の完了した仕事を運ぶ作業は時間がかかり、運んだあとに見られることはほとんどありません。過去の分は元の道具を参照専用にして残すか、書き出したファイルを保存場所に残すのが現実的です。
運ぶときに落ちやすいのは、コメントの履歴と添付ファイルです。仕事の一覧だけを移して、経緯が残らないと、移した直後に「この件の経緯はどこ」という質問が出ます。経緯が必要な仕事が数件あるなら、その数件だけは手で写してください。全部を機械で運ぼうとすると、対応していない項目の扱いで時間がかかります。
移行の期間は、1週間以内に収めてください。2つの道具が並行して動く期間が長いと、どちらに登録すべきか分からない仕事が出ます。移す日を決めて、その日以降の新しい仕事は新しい道具だけに登録する形にすると、混ざりません。
移し終わったら、元の道具は編集できない状態にしてください。両方が更新できる状態を残すと、両方が古くなります。
導入は1つのチームから始める
広げ方にも順番があります。全社に一斉に入れると、質問が同時に来て、答える人が足りません。
第1のステップは、1つのチームで始めることです。人数は5人前後が扱いやすく、無料の範囲にも収まります。このチームで2週間から1か月動かして、運用の形を固めます。
第2のステップは、その形を手順書にすることです。作った手順書は、次のチームに渡すものになります。手順書は、画面の写真と、最初にする3つの操作だけで足ります。網羅的な説明書を作ると、読まれません。
第3のステップは、2つめのチームに広げることです。ここで、最初のチームで決めた形が他の仕事にも合うかを確かめます。合わない部分が出たら、共通にする部分と、チームごとに変える部分を分けてください。全部を共通にしようとすると、どのチームにも合わない形になります。
第4のステップで、人数と費用を確定させます。10人を超える時点で有料になるため、その前に、続けるかどうかの判断を済ませておきます。判断の材料は、聞いて回る時間が減ったか、抜けが減ったかの2つです。
締切の重なりと、人ごとの偏りをどこで見るか
タスクの一覧が整うと、次に必要になるのは2つの画面です。1つは締切の重なりを見る画面、もう1つは誰に仕事が寄っているかを見る画面です。
締切の重なりは、工程表かカレンダーで見ます。一覧では、同じ週に締切が4件あることに気づけません。工程表なら横棒の重なりとして見え、カレンダーなら1日のマスに並ぶ件数として見えます。どちらを使うかは、期間の長さで決めてください。数週間の案件は工程表、日ごとの締切が多い仕事はカレンダーが読みやすくなります。
人ごとの偏りは、人を縦に、日付を横に並べた画面で見ます。担当で絞り込んだ一覧を1人ずつ開いて数える方法でも分かりますが、5人を超えると時間がかかります。並べた画面があれば、列が長くなっている人が一目で分かります。
この2つの画面が、いま使っている道具で最初から使えるかを確かめてください。上位のプランに含まれている場合、試す段階では見られないことになります。見られないまま導入を決めると、運用を始めてから追加の費用の判断が必要になります。
そして、この2つの画面を別の道具で持たないことです。同じ仕事を2か所に記録することになり、片方が必ず古くなります。同じカードを角度を変えて見る形になっていれば、記録は1か所で済みます。
続いているかを確かめる4つの目印
入れた道具が生きているかは、件数で数えると分かります。
1つめは、締切が入っていない仕事の数です。増えているなら、登録だけされて放置されている仕事が溜まっています。締切の無いものは誰の視界にも入らないため、忘れられます。
2つめは、7日以上動いていない仕事の数です。進行中のまま1週間動いていないものは、終わっているか、止まっているか、忘れられているかのどれかです。週に1回の場で、この絞り込みだけを見る運用にすれば、確認の対象が数件に絞られます。
3つめは、状態を動かした人の数です。とりまとめる人だけが動かしている状態なら、他の人は画面を開いていません。権限か使い勝手のどちらかに原因があります。
4つめは、別の場所に同じ情報が書かれていないかです。表計算の新しいファイルが共有フォルダに増えていたら、この道具で足りない何かがあります。そのファイルの列を見れば、足りないものが分かります。多いのは、締切の一覧と、人ごとの割り当てです。
この4つを月に1回見るだけで、直すべき場所が具体的になります。感覚で議論すると、道具の好き嫌いの話になります。
社外の協力者を入れるときに決めること
制作や編集の仕事では、業務委託の相手や協力会社が案件に入ります。社内だけの運用とは別に、決めることが3つあります。
1つめは、見せる範囲です。案件ごとに場所を分けて、その案件の中身しか見えないようにするのが基本です。全部の案件が見える場所に招くと、他社の案件名が見えてしまいます。場所を分けられるか、権限で項目を隠せるかを、招く前に確かめてください。
2つめは、入力を頼む範囲です。相手にとっては別の会社の道具にログインする作業なので、頼む範囲が広いと続きません。状態の更新だけを頼み、細かい記録は求めない形が現実的です。複数の取引先の道具を使い分けている相手なら、ログインの手間そのものが負担になります。
3つめは、人数の数え方です。社外の人を人数に数える製品では、協力者が増えるたびに費用が増えます。見るだけの人を数えない製品もあるため、条件を確かめてから招いてください。
なお、作業の進め方をどこまで指示してよいかは契約の形によって扱いが変わります。線引きは所管の窓口や専門家に確かめてから運用を決めてください。道具の設定で解決する話ではありません。
何を1つにまとめ、何を分けるか
最後に、道具の役割の話に戻ります。開発の管理に必要な細かさと、他の部署に必要な分かりやすさは、両立させるのが難しい要求です。1つの道具で両方をやるなら、設定を分けて運用することになり、設定を決める人が必要になります。
開発以外のチームだけを別の道具にする場合、確かめるのは3つです。設定を決めずに使い始められるか、工程表と人ごとの割り当てが最初から使えるか、そして社外の協力者を入れられるか。
同じカードを、カンバンでも工程表でもカレンダーでも人ごとの割り当てでも見られる作りについてはできることに一覧があります。ボードを作るときに種類を選ぶ形なので、状態の並びや項目の設計を先に決める作業が要りません。開発ではないチームで、決める作業そのものを省きたい場合に向いた形です。
費用の形も比べてください。機能で絞らず、区切るのは人数とボードの数だけという形なら、工程表もチャットも無料の範囲で確かめられます。5人までとボード10個までが無期限で無料、6人目からは1人あたり月額500円（税抜。年払いなら1人あたり月額400円）という線は料金に公開されています。見るだけのゲストを人数に数えるかや、ボードの数え方の条件はよくある質問に並んでいるので、人数が増える前に確かめておくと差し戻しが減ります。
候補を横に並べたいなら比較の一覧が出発点になります。課題の管理と工程表の組み合わせで考えているならBacklogとの比較、案件の下に作業を並べて依頼として回す形ならAsanaとの比較が近い位置にあります。社外の協力者を入れる前提なら、操作ログとログイン履歴の残り方を安全性の考え方で確かめてください。
開発の現場で実績のある道具を他の部署に広げるときに必要なのは、機能の比較ではなく、決める作業を誰が引き受けるかの整理です。引き受ける人がいるなら1つにまとめられます。いないなら、決めなくても使える道具を選ぶほうが、運用は続きます。
Q1. Jiraは無料でどこまで使えますか？
2026年9月27日時点の日本向けの料金ページでは、無料のプランが10ユーザーまで無期限で無料と書かれています。有料のStandardは1ユーザーあたり月額1,085円、Premiumは1ユーザーあたり月額1,987円です（消費税は別で、ユーザー数によって額が変わります）。11人目が入ると全員分が有料になるため、人が増える予定を先に確かめてください。
Q2. 開発ではないチームでも使えますか？
使えますが、用語と設定の手当てが先に必要です。仕事の1件を課題と呼ぶ文化が無い職場では、何を登録すべきか分からないという反応が出ます。自分たちの言葉に言い換えた対応表を配り、登録する項目を3つ、状態を4つに絞って始めると、最初の壁は下がります。
Q3. 浸透までにどのくらいかかりますか？
最初の2週間で決まります。実際の利用者の声として、初めて見たときに何をすればよいか分かりにくく、他のメンバーに広げるまでに時間がかかったという記述があります。最初にする3つの操作だけを画面の写真つきで案内し、質問の受け先を1人決めておくと、この時間は短くなります。
Q4. 開発チームと同じ道具にすべきですか？
部署をまたぐ依頼の件数で決めてください。月に20件を超えるなら同じ道具にしたほうが転記が減ります。それ以下なら分けて、それぞれの仕事に合った形を優先したほうが使い勝手がよくなります。分ける場合は、依頼の受け付けの入口だけを共通にする方法もあります。