Jiraが使いにくいと感じる理由｜自分たちに合わない部分を切り分ける
「jira 使いにくい」で検索する人の状況は、だいたい2つに分かれます。自分が使う側で、毎日開くのが億劫になっている場合と、導入や運用を任されていて、チームから「使いにくい」と言われて困っている場合です。どちらの立場でも、まず必要なのは「使いにくい」の中身を分解することです。設計思想の問題なのか、設定の問題なのか、そもそも自分たちの仕事に合っていないのか。この記事では、その切り分け方を整理したうえで、そのまま使い続けたほうがよい場合と、道具の形を見直す価値がある場合を分けて扱います。
「使いにくい」という言葉の中身を分ける
同じ「使いにくい」でも、指しているものはまるで違います。よく聞くのは次の5つです。
・画面の項目が多く、どこに何を入力すればよいのか分からない ・課題を1件作るのに手数が多く、思いついたことをすぐ書けない ・自分に関係のない通知が大量に届く ・欲しい一覧を出すのに、検索の書き方を覚える必要がある ・設定を変えたいが、どこを触れば変わるのか分からない
この5つは、原因も対処もそれぞれ違います。1つ目と2つ目は、入力必須の項目が多すぎることが原因であることが多く、設定を減らせば改善します。3つ目は通知の購読設定の問題で、これも設定で直ります。4つ目は道具の設計思想そのもので、慣れるか、別の入口を用意するかしかありません。5つ目は、管理する側の話で、利用する側の使いにくさとは別の問題です。
とりまとめる立場の人が最初にやるべきなのは、チームから出てきた「使いにくい」がこのどれなのかを聞き取ることです。「使いにくいから別のツールにしよう」と即断すると、次の道具でも同じ場所で詰まります。項目が多すぎて入力できない、というのが本当の理由なら、道具を替えても項目を減らさない限り同じ結果になります。
逆に、聞き取った結果が「そもそも自分たちの仕事の形と合っていない」であれば、設定をいくら詰めても解決しません。この場合だけが、道具の形を見直す理由になります。
もうひとつ、「使いにくい」が実は「習っていない」であることも少なくありません。導入時に説明したつもりでも、あとから入った人には誰も教えていない、という状態はよく起きます。この場合は、道具でも設定でもなく、案内の不足が原因です。よく使う操作を5つだけ書いた1枚の手順を用意するだけで、声が止まることがあります。試す価値のある、いちばん安い対処です。
設計思想の違いから生まれるつまずき
Jiraは、ソフトウェア開発の現場で使われることを前提に設計が積み上がってきた道具です。課題(イシュー)を単位として、種類を分け、状態の遷移を定義し、誰がどの状態に動かせるかを制御する。この考え方は、開発の工程を厳密に管理するうえで理にかなっています。
一方で、この考え方が前提としているのは、工程が繰り返し発生し、同じ形で処理されるという状況です。要件を書き、設計し、実装し、テストし、リリースする。この流れが何十回も回るなら、それを型として定義しておく価値があります。定義する手間は、繰り返しの回数で割り戻されるからです。
問題は、この前提が成り立たない仕事に持ち込んだときに起きます。制作会社の案件、社内の総務や人事の業務、営業の提案準備といった仕事は、案件ごとに工程が違います。型を定義しようとしても、次の案件では当てはまりません。それでも型を作ると、実態と合わない項目を毎回埋めることになり、入力が形骸化します。
ここで起きるのは、道具が悪いという話ではなく、道具の設計が想定している状況と、実際の状況がずれているという話です。ずれの大きさは、次の3つで測れます。
・同じ形の作業が、月に何回発生するか。数回なら型を作る意味は薄い ・状態の遷移に、承認や差し戻しが必要か。不要なら状態は3つか4つで足りる ・入力した情報を、あとから集計して使うか。使わないなら項目は最小でよい
3つとも「いいえ」に近いなら、開発向けに作られた仕組みは重すぎる可能性が高くなります。逆に1つでも「はい」があるなら、設定を詰めれば十分に使えます。
管理者と利用者で「使いにくさ」が別物になる
導入した人と、日々使う人とで、感じる使いにくさはまったく違います。ここを混ぜると議論が噛み合いません。
管理する側の使いにくさは、設定の深さから来ます。プロジェクトの種類、課題タイプ、画面の構成、フィールドの設定、ワークフロー、権限スキーム、通知スキーム。これらが別々の場所で管理されていて、1つを変えるために複数の設定を触る必要があります。柔軟である裏返しとして、覚えることが多くなります。
使う側の使いにくさは、逆に「選択肢が多いこと」から来ます。課題を作る画面に項目が15個並んでいれば、どれを埋めるべきか分かりません。必須でない項目まで真面目に埋めようとする人と、必須以外を全部飛ばす人が混在し、データの質がばらつきます。
この2つのうち、実は直しやすいのは使う側の使いにくさです。作成画面に出す項目を減らし、必須を3つ以内にすれば、多くの不満は消えます。導入した人が「せっかくだから情報を集めたい」と項目を増やしていることが原因であるケースは、現場でしばしば見かけます。まずは自分が作った設定を疑ってください。
行政が公開している資料にも、道具を作る側が持つべき視点として、次のような整理があります。
「誰一人取り残されない」デジタル化を進めていく上では、デジタル機器・サービスが操作しやすいだけではなく、これらの機器・サービスを通じ、利用者の利便性の向上や課題の解決、目的の達成が図られることが大切です。 出典: digital.go.jp
道具を選ぶ側にも同じことが言えます。操作しやすいかどうかだけでなく、その道具を通じて自分たちの目的が達成できるかどうかで判断する必要があります。機能が豊富であることと、目的が達成しやすいことは、必ずしも一致しません。
チームの規模で「使いにくい」の意味が変わる
同じ道具でも、チームの人数によって困る場所が変わります。ここを分けておくと、対処の順番を間違えません。
3人から5人のチームでは、そもそも管理の仕組みがあまり要りません。誰が何をしているかは会話で分かるので、道具に求めるのは「忘れないための置き場所」です。この規模で厳密な状態遷移を定義すると、定義した本人以外は使わなくなります。使いにくいという声の中身は、たいてい「そこまで要らない」です。
10人から30人になると、会話だけでは把握できなくなります。誰かが休んだときに、その人が何を抱えていたのかが見えない。この規模で初めて、状態や担当者を記録する意味が出てきます。ただし、この規模でも必要な状態は4つ程度で、承認の流れを厳密に制御する必要はまだ出てきません。使いにくいという声の中身は「入力が面倒」であることが多く、項目を減らせば収まります。
50人を超え、複数のチームが同じ仕組みを共有するようになると、話が変わります。チームごとに違う運用をされると全体が見えなくなるので、型を決めて守らせる必要が出ます。ここで初めて、細かい設定ができることが利点になります。この規模で「使いにくい」と言われた場合、それは統制のために意図的に不自由にしている部分であることが多く、単純に緩めるわけにはいきません。
自分たちがどの段階にいるかを見誤ると、判断がずれます。10人のチームが50人向けの型を使えば重く感じますし、50人の組織が10人向けの緩い道具に移れば、半年後に統制が効かなくなって困ります。人数と、必要な厳密さは連動しています。
課題の粒度をどう決めるか
使いにくさの原因が、道具ではなく粒度にあることもよくあります。細かすぎる単位で登録すると、登録と更新の手間だけが増えて、見返りがありません。
目安として、1件の課題は半日から3日で終わる大きさにします。1時間で終わる作業を1件ずつ登録すると、1日に何件も作ることになり、一覧が埋まって全体が見えなくなります。そういう細かい作業は、親となる課題の中にチェックリストとして持たせてください。
逆に、1件で2週間以上かかる課題は、途中の状況が見えません。進行中のまま2週間動かない行があっても、それが順調なのか止まっているのか判断できないからです。長いものは、途中に区切りを入れて分割します。
粒度を揃えると、一覧を見たときの読みやすさが大きく変わります。同じ画面に「メールを1通送る」と「新システムを構築する」が並んでいると、どれが重いのかが分かりません。粒度が揃っていれば、件数がそのまま作業量の目安になります。
粒度の基準は、チームで1度だけ話し合って決めてください。決めずに運用すると、人によって粒度がばらつき、集計しても意味のない数字になります。この話し合いは30分もあれば終わりますが、やっているチームは多くありません。
設定で直せる範囲を先に試す
道具を替える前に、設定で直せることは全部試してください。替える判断は、それからでも遅くありません。試す価値があるのは次の4つです。
第一に、作成画面の項目を減らします。必須項目を3つ以内にし、それ以外は作成後に追加する形にします。思いついたことをすぐ書ける状態を作るのが目的です。入り口が重いと、そもそも課題が登録されなくなり、道具の外で仕事が進むようになります。
第二に、状態の数を減らします。開発の型をそのまま使うと状態が7つや8つになりますが、多くのチームは未着手、進行中、確認待ち、完了の4つで足ります。状態が多いほど、どこに動かせばよいか迷う場面が増えます。
第三に、通知の設定を見直します。全部の変更が通知される設定のままだと、1日に数十通が届き、やがて全員が通知を無視するようになります。自分が担当か、自分がウォッチしているものだけに絞ってください。
第四に、よく使う一覧を保存します。検索の書き方を毎回覚える必要がある、という不満は、よく使う条件を保存して共有すれば大部分が消えます。「今週の自分の担当」「期限切れ」の2つを用意しておくだけで、日常の使い勝手はかなり変わります。
この4つを試して、それでも重いと感じるなら、設定ではなく形の問題である可能性が高くなります。試すときは、変更を1つずつ入れて、1週間ずつ様子を見てください。4つを同時に変えると、何が効いたのかが分からなくなり、次に困ったときの手がかりが残りません。
もうひとつ、設定を減らすときに管理する側が抵抗を感じる点にも触れておきます。項目を減らすと、集めたい情報が集まらなくなるように思えます。しかし、実際には項目が多い状態でも情報は集まっていません。適当に埋められた項目が並んでいるだけです。埋まらない項目を残すより、本当に使う3つを確実に埋めてもらうほうが、集計に使えるデータになります。
そのまま使い続けたほうがよい場合
道具を替えないほうがよいケースは、はっきりしています。次のどれかに当てはまるなら、乗り換えのコストが利益を上回ります。
・ソフトウェア開発が主な仕事で、リリースの単位で課題を束ねている ・課題の履歴を、監査や品質管理のために長期間残す必要がある ・ソースコードの管理や継続的インテグレーションと連携させている ・すでに数千件の課題が蓄積されていて、それを日常的に検索している ・社内に設定を理解している担当者がいて、必要に応じて調整できる
とくに3つ目と4つ目が効きます。開発の周辺の道具とつながっている状態で乗り換えると、つながりを作り直す作業が発生します。この作業は、工程表を移すよりはるかに重くなります。蓄積した課題の検索が業務に組み込まれている場合も同様です。
また、「一部のメンバーが使いにくいと言っている」だけであれば、乗り換えではなく、そのメンバー向けの入口を用意するほうが早いことがあります。開発チームは今の道具を使い続け、開発以外のチームは別の道具を使い、必要な情報だけを共有する。この形が現実的な落としどころになることは珍しくありません。
公開されている料金ページで確かめられること
判断材料として、公開情報を並べておきます。プランの内容は変わるので、2026年9月4日時点の日本語の料金ページの記載であることを添えます。
プランはFree、Standard、Premium、Enterpriseの4つです。Freeについては「10ユーザーまで常に無料」「2 GBのファイル・ストレージ」「コミュニティ サポート」という記載があります。10ユーザーを超える場合、またはより多くのサポートやストレージが必要な場合は、StandardプランまたはPremiumプランへ、という案内が続きます。
無料プランの制約として、メール通知が1日100件までで、それを超えると送信が翌日まで保留されるという記載もあります。人数が上限に近づくと、この制約が先に効いてくる場合があります。また、1つのサイトに追加できるユーザー数の上限は100,000ユーザーとされています。
自動化のステップ数もプランごとに定められています。Freeは1か月1サブスクリプションあたり150ステップ、Standardは1か月1ユーザーあたり400ステップ、Premiumは750ステップ、Enterpriseは1,000ステップという記載です。自動化を業務の中心に据えるかどうかで、必要なプランが変わることになります。
金額そのものは、ページ上で人数と支払い周期を入力して計算する形式になっており、静的な数字としては掲載されていません。見積もりを取る際は、公式のページで実際の人数を入れて確認してください。
変えるなら、何を変えるのか
設定で直らず、形が合っていないと判断した場合、選択肢は2つあります。運用のルールを変えるか、道具を変えるかです。
運用で変えられることは意外に多くあります。たとえば、課題を作るのは決まった人だけにして、他のメンバーはチャットで依頼する。作成の手数が問題なら、これで解決します。あるいは、細かい作業は課題にせず、大きな単位だけを登録する。粒度の問題であれば、これで軽くなります。
道具を変える場合は、何を捨てるかを先に決めてください。開発向けの厳密な状態管理を捨てるのか、外部サービスとの連携を捨てるのか、履歴の長期保存を捨てるのか。何も捨てずに軽い道具に移ろうとすると、移った先で「あれができない」という話になり、結局戻ることになります。
多くのチームにとって、捨ててよいのは「厳密な状態遷移の制御」です。誰がどの状態に動かせるかを制御しなくても、実務ではほとんど困りません。逆に捨てにくいのは「検索して一覧を出せること」と「経緯が残ること」です。この2つが弱い道具に移ると、しばらくして不満が出ます。
道具を分けるという選択肢
すべてを1つの道具に統一しなければならない、という前提を外すと、選択肢が増えます。実際、開発チームと開発以外のチームで別の道具を使っている組織は珍しくありません。
分けることの利点は、それぞれのチームが自分たちの形に合った道具を使えることです。開発チームは厳密な状態管理と外部連携を保ったまま、営業や制作のチームは軽い道具で日々の進行を回す。この形にすると、どちらのチームからも「使いにくい」という声が減ります。
分けることの欠点は、全体の状況を1画面で見られなくなることです。ただし、実務でその1画面が本当に必要かどうかは、よく考える価値があります。経営層が見たいのは案件ごとの進み具合であって、課題1件ごとの状態ではありません。月に1度、両方から必要な情報を抜いて1枚にまとめれば足りることも多くあります。
分ける場合に決めておくべきなのは、境目です。どの仕事をどちらの道具で扱うのかを曖昧にすると、同じ仕事が両方に登録されて二重管理になります。「開発の実装作業はこちら、それ以外の進行はこちら」といった線を引き、迷ったときの判断基準まで決めておいてください。
統一そのものが目的化すると、誰にとっても中途半端な形に落ち着きます。道具は、仕事の形に合わせて分けてよいものです。統一のために全員が我慢する構図になっていないかを、一度確かめてみてください。
開発以外のチームが求めているもの
開発以外の仕事で工程を管理する場合、必要なものはかなりシンプルです。実際に求められるのは、次の4つに集約されます。
第一に、いま誰が何をしているかが1画面で分かること。カンバンでもガントでも構いませんが、探さずに見えることが重要です。
第二に、締切が近いものが目立つこと。期限切れが赤くなる、今日の線が引かれている、といった形で、見た瞬間に判断できることが求められます。
第三に、その仕事についての会話が同じ場所にあること。作業の一覧が1つの道具にあり、判断の経緯が別のチャットにあると、人が手で同期することになります。2週間もすれば、どちらかが必ず古くなります。
第四に、入力する人が自分で触れること。とりまとめる人が全員ぶんを聞いて回って代わりに入力する形は、その人が休んだ週に止まります。担当者が自分で動かせる形になっているかどうかが、続くかどうかを分けます。
この4つを満たすのに、状態遷移の細かい制御や、複雑な検索の記法は必要ありません。求めているものと道具の得意分野がずれているなら、それは道具の優劣ではなく、組み合わせの問題です。
チームから不満が出たときの聞き取りの手順
とりまとめる立場の人が「使いにくい」と言われたとき、その場で対処を決めないでください。言葉のまま受け取ると、実際とは違う対策を打つことになります。次の順番で聞き取ると、原因にたどり着けます。
まず、直近で使いにくいと感じた場面を1つだけ挙げてもらいます。抽象的な感想ではなく、具体的な操作を聞くのが目的です。「先週の火曜に、依頼を登録しようとしたとき」というところまで降りてもらいます。
次に、そのときに何をしたかったのかを聞きます。依頼を登録したかったのか、状況を確認したかったのか、誰かに伝えたかったのか。やりたかったことが分かると、道具のどの部分が邪魔をしたのかが特定できます。
そのうえで、結局どうしたのかを聞きます。ここが最も重要です。「面倒だからチャットで頼んだ」という答えが返ってきたら、その道具は業務の外に追いやられています。記録が残らない経路で仕事が流れている状態は、道具の使いにくさよりも深刻な問題です。
最後に、同じ場面が月に何回あるかを聞きます。月に1回なら我慢できる範囲ですが、週に何度もあるなら手を打つ必要があります。頻度を聞かずに対処すると、めったに起きないことのために設定を複雑にしてしまいます。
この聞き取りを3人に対して行えば、原因はだいたい絞れます。全員に聞く必要はありません。よく使う人と、ほとんど使わない人の両方から聞くと、偏りが減ります。
乗り換えるときに気をつけること
道具を替えると決めた場合、進め方を間違えると失敗します。よくある失敗は3つです。
1つ目は、全部を一度に移そうとすることです。数千件の課題を移す作業だけで数日かかり、その間に「前のほうが早い」という声が出ます。いま動いているプロジェクトを1件だけ選び、それだけを新しい道具に載せてください。過去の課題は読み取り専用のまま残しておけば十分です。過去を検索する回数は、思っているよりずっと少ないものです。
2つ目は、両方を並行して使い続けることです。旧い道具と新しい道具の両方を更新すると、二重の手間になり、当然ながら前のほうが早く感じます。移した1件については、旧い道具を開かないと決めてください。
3つ目は、新しい道具でも項目を増やしてしまうことです。せっかく移るのだからと、カスタムフィールドを10個作ると、また同じ場所で詰まります。最初は作業名、担当者、締切、状態の4つだけにして、足りないと言われてから足してください。
移行そのものについては、書き出せる形式を先に確認しておきます。CSVで書き出せれば、多くのサービスに取り込めます。作業名、担当者、開始日、終了日、状態の5列があれば、たいていの形式に変換できます。
公開情報から見た、比較のしかた
候補を並べるときは、機能の数ではなく、区切り方で比べてください。何を無料にして、何から有料にするかに、そのサービスの考え方が出ます。
案内ページの料金には、無料プランは5人までとボード10個までで、6人目または11個目のボードから1人あたり月500円(税抜)になると書かれています。機能で絞らず、区切るのは人数とボードの数だけという設計で、ガントチャートもチャットもカスタムフィールドも無料の範囲に入ります。閲覧だけのゲストは人数に数えない、という記載もあります。使える見え方の一覧はできることにまとまっており、カンバンやガントを含む8種類のボードと、それぞれの使い分けが載っています。
他のサービスとの並びは比較の一覧から確認できます。開発以外のチームで検討される機会が多いものとして、Trelloとの比較、Asanaとの比較、Notionとの比較、monday.comとの比較、Backlogとの比較、Jootoとの比較が同じ形式で並んでいます。それぞれ、無料でどこまで使えるかと、機能ごとの対応を表にしてあります。
すでに別のサービスにカードを作ってしまっている場合の取り込みについてはTrelloからの移行に条件が書かれています。社外の相手を含めて共有する場合の考え方は安全性の考え方に整理されており、残りの疑問はよくある質問にまとまっています。
候補を実際に触るときは、比較表を眺める時間より、1件のプロジェクトを載せてみる時間に配分してください。表で分かるのは機能の有無だけで、入力の手数や、画面の探しやすさは触らないと分かりません。無料の範囲で1週間動かしてみれば、いま感じている使いにくさが解消するのかどうかがはっきりします。
そのとき、判断するのは導入する人ではなく、日々使う人にしてください。導入する人は設定を触るのが仕事なので、多少の複雑さを苦にしません。実際に毎日開くのは担当者です。1週間試したあとに、担当者3人に「前と比べてどうか」を聞けば、答えは出ます。使う人が自分で動かせる形になっているかどうかが、最終的にすべてを決めます。
「使いにくい」という言葉は、原因を隠します。分解すれば、設定で直るもの、運用で直るもの、道具の形が合っていないものに分かれます。この記事の順番どおりに切り分けていけば、替えるべきかどうかは自然に決まります。替えないという結論になったとしても、それは十分に価値のある判断です。
Q1. Jiraが使いにくいのは設定を変えれば直りますか？
入力項目が多い、通知が多い、欲しい一覧が出せない、という不満は設定で大部分が直ります。作成画面の必須項目を3つ以内に絞り、通知を自分の担当分だけに限定し、よく使う条件を保存して共有してください。それでも重いなら、設定ではなく仕事の形との相性の問題です。
Q2. 開発以外のチームには向かないのですか？
向かないと断定はできません。同じ形の作業が月に何度も発生し、承認や差し戻しがあり、入力した情報を後から集計するのであれば、設定を詰めれば十分に使えます。案件ごとに工程が違い、集計もしないのであれば、型を作る手間が回収できない可能性が高くなります。
Q3. 無料プランはどこまで使えますか？
公式の日本語の料金ページには、2026年9月4日時点で、10ユーザーまで常に無料、2GBのファイルストレージ、コミュニティサポートという記載があります。メール通知は1日100件までで、超えると翌日まで保留されるとも書かれています。金額はページ上で人数を入れて計算する形式です。
Q4. 乗り換えるとき、過去の課題はどうすればよいですか？
全部を移す必要はありません。いま動いているプロジェクトを1件だけ移し、過去の課題は読み取り専用のまま残すのが現実的です。過去を検索する回数は想像よりずっと少なく、全件移行を目指すと作業だけで数日かかり、その間に元の道具へ戻る流れができてしまいます。