Jiraの代わりを探すとき｜手放してよい機能を先に決める
Jiraの代わりを探し始めた人が最初にやりがちなのは、候補のサービスを並べて機能の一覧を比べることです。この進め方だと、どの候補も一覧の上では見劣りせず、決め手が出ません。順番を変えてください。先に決めるのは「いま使っている機能のうち、手放してよいのはどれか」です。ここが決まれば、比べる相手は自然と2つか3つに絞られます。この記事では、その棚卸しの手順と、公式ページで確かめられる範囲の事実を整理します。
代わりを探す理由は、3つのどれかに当てはまる
相談の場でよく出る理由は、次の3つに分かれます。
・費用が人数に比例して増え、負担が読めなくなってきた ・使う人が機能を持て余していて、入力が定着しない ・開発以外の部署にも広げたいが、作りが噛み合わない
この3つは、選ぶべき代わりの形がそれぞれ違います。1つ目なら費用の区切り方を見ることになりますし、2つ目なら決めることの少ない道具を探すことになります。3つ目は、開発の工程を前提にした作りから離れられるかどうかの話です。
理由が混ざったまま探すと、候補を絞れません。たとえば費用が理由なのに機能の豊富な候補を選ぶと、結局同じ位置に戻ります。使いこなせないことが理由なのに、設定の自由度が高い候補を選べば、同じ場所で詰まります。
最初にやるのは、この3つのどれが自分たちの主な理由かをはっきりさせることです。複数当てはまる場合は、重い順に並べてください。並べた順番が、そのまま比較の判断基準の重みになります。全部を満たす候補を探そうとすると、決められないまま時間だけが過ぎます。
理由をはっきりさせる方法として使えるのが、直近3か月に社内で出た不満を書き出すことです。会議の場で出た言葉、雑談で漏れた愚痴、請求のたびに出るため息。それらを3つの分類に振り分けると、どこに重みがあるか一目で分かります。振り分けられない不満が多い場合は、道具の問題ではなく、仕事の進め方そのものに原因がある可能性があります。
もう1つ、探し始めた理由が「上から言われたから」であることもあります。この場合は、言った人が何を問題だと感じているのかを先に確かめてください。費用の話なのか、報告が上がってこないことなのか、他社が使っている道具に揃えたいのか。ここが分からないまま候補を並べると、どの案を出しても採用されません。
いま使っている機能を、実際の利用で棚卸しする
次にやるのが棚卸しです。ここで大事なのは、「使えること」ではなく「実際に使っていること」を数えることです。
書き出す項目は次の6つで足ります。
・課題（イシュー）の種類と状態の数 ・ワークフローで定義している遷移の制限 ・自動化の設定の数と、その内容 ・追加で入れているアプリの数と、それぞれの用途 ・保存している検索条件（フィルタ）とダッシュボードの数 ・外部のサービスとの連携
書き出したあと、それぞれに「これが無くなったら、誰がどう困るか」を1行で添えます。答えられないものは、実際には使っていない機能です。経験的には、この段階で半分近くが落ちます。
特に落ちやすいのが、導入時に作ったまま誰も見ていないダッシュボードと、一度きりの目的で作られた自動化です。逆に、落とせないものとして残りやすいのは、外部のサービスとの連携と、監査や権限に関わる設定です。
この棚卸しには、意外な効用もあります。書き出す過程で「これは設定を減らせば今のままでも楽になる」と気づくことがあり、そもそも替える必要が無いという結論に至る場合があります。替えないという結論も、立派な結論です。
棚卸しは、とりまとめる立場の人が1人で書かないほうが正確になります。管理する側から見えている使い方と、日々入力している人の使い方は、しばしば違います。管理者が「重要な設定」と思っているものを現場が回避して使っていることもあれば、逆に誰も知らせていない使い方が定着していることもあります。関わる人を3人から4人集めて、それぞれが直近1週間に実際にやった操作を書き出すのが、いちばん精度の高いやり方です。
書き出す期間も決めておいてください。半年や1年をさかのぼると、一度きりの使い方まで拾ってしまいます。直近の1か月に絞れば、日常的に使っているものだけが残ります。
公開されている料金の区切りを確かめる
費用が理由なら、まず区切り方を正確に押さえます。公式の料金ページには、無料のプランについて次のように書かれています。
Free forever for up to 10 users. Includes backlog, board, timeline, reports, 2 GB storage, and community support. 出典: atlassian.com
同じページの表示では、Standardが1人あたり月7.91米ドル、Premiumが1人あたり月14.54米ドルとなっています。Standardには保存領域250ギガバイト、Premiumには保存領域の上限なしと24時間体制の対応が含まれると説明されています。いずれも2026年9月10日時点で公式ページに表示されていた米ドル建ての金額です。日本円での請求額や税の扱いは契約の条件によって変わるため、購入の画面で確かめてください。
区切りとして効くのは人数です。無料のプランは10人までで、それを超えるとStandardの体験期間に自動で切り替わる、と公式ページの説明にあります。11人目が入る瞬間に費用が発生する構造なので、人数が増えつつあるチームは、その境目を先に把握しておく価値があります。
もう1つ見ておくべきは、機能が契約の段階で区切られていることです。監査の記録や細かい権限の設定は上の段階に含まれます。つまり、いま無料の範囲で足りていても、必要になった機能が上の段階にあれば、その時点で全員分の費用が動きます。人数と機能の両方で費用が動く形だ、と理解しておくと見積もりを外しません。
料金の裏で動いている4つの事実を見る
道具を選ぶときは、料金だけを見ると足をすくわれます。金額が同じでも、その裏の前提は動きます。確かめるのは、提供が終わる予定の有無、新しい申し込みを受け付けているかどうか、運営する会社に変更がないか、そして値上げや体系の変更が予告されていないかの4つです。
Jiraの場合、自分のサーバーに置く形（Server）については公式の資料に明確な記載があります。データの取り込みに関する公式の説明ページには、Data Centerがクラウド以外での主な提供形態であり、Serverの版はもう対応していない、と書かれています。自社で持つ形を前提に検討している場合は、この点を踏まえる必要があります。
対応の期間についても方針が公開されています。
Atlassian supports releases for two years after the initial feature or Long-Term Support (LTS) release. 出典: confluence.atlassian.com
同じページには例として、2025年1月22日に出された版が2年後の2027年1月22日まで対応される、と示されています。自分たちで持つ形を選ぶ場合、この期限が更新の計画そのものになります。
料金の改定については、いま契約している側の告知だけでなく、候補として挙げているサービスの過去の改定の履歴も見ておくと参考になります。過去3年で値上げが何回あったか、そのとき既存の契約者にどの程度の猶予があったか。この2つが分かると、移った先で同じ検討をやり直す時期がおおよそ読めます。
この4点の確認は、代わりの候補にも同じように当てるべきです。候補として挙がったサービスが、実は新規の受付を止めていた、という話は現実に起きます。料金ページだけを見て比べると、この種の変化は見えません。会社の告知の一覧と、公式の更新情報のページを両方見るのが確実です。
手放してよい機能から決める
棚卸しの表が揃ったら、上から順に「手放せるか」を決めていきます。判断の基準は3つです。
1つ目は、無くなったときに業務が止まるかどうか。止まるなら残す機能です。2つ目は、代わりの手段があるかどうか。表計算ソフトや、既に使っている別の道具で埋められるなら、手放せる側に入ります。3つ目は、使っている人が何人いるか。1人しか使っていない機能のために、全員が使う道具を決めるのは順序が逆です。
この基準で分けると、多くの場合、残るのは次のあたりです。課題の一覧と状態の管理、担当と期日、コメントでのやり取り、そして数種類の絞り込み。これらは、どの候補にもある機能です。だからこそ、比較の決め手は機能の有無ではなく、その先にあります。
残す機能を決めたら、それぞれに優先順位を付けてください。「無いと導入できない」ものと、「あると助かる」ものを分けます。前者が5つを超えるようなら、条件が厳しすぎて候補が残らない可能性があります。その場合は、もう一度3つの基準に照らして絞り直すことになります。分けておくと、候補を比べるときに「この点は劣るが、あると助かる側だから許容できる」という判断ができるようになります。
手放す判断でよく迷うのが、細かい権限の設定です。「誰がどの状態に動かせるか」を厳密に定義してきた場合、それを手放すことは統制を緩めることに見えます。ただ、実務でその制限が実際に働いた回数を数えてみると、思ったより少ないことがあります。運用の中で人が確認しているなら、道具側の制限は保険として働いているだけです。緩めてよいかどうかは、監査の要件があるかどうかで判断が変わります。
自動化と追加アプリの扱いが分かれ目になる
棚卸しの結果、自動化の設定と追加のアプリが多く残った場合は、慎重に進める必要があります。この2つは、代わりの候補に同じものが存在することがまずありません。
自動化については、まず内容を分類してください。「状態が変わったら通知する」「期日が近づいたら担当に知らせる」といった単純なものは、多くの道具が標準で持っています。一方、「特定の条件を満たしたら課題を分割して別のプロジェクトに複製する」といった込み入ったものは、そのまま置き換えられません。
置き換えられないものについては、3つの選び方があります。人の手作業に戻す、外部の連携の仕組みで組み直す、あるいはその業務のやり方そのものを見直す。多いのは3つ目です。自動化が込み入っているとき、その背景に「そもそも工程が複雑すぎる」という事情が隠れていることがあります。
自動化の数を数えるときは、動いている頻度も一緒に見てください。設定はしてあるが、この半年で1度も条件を満たしていない、というものが混じります。頻度の分かる記録が残っているなら、実際に動いた回数の多い順に並べ、上位5つだけを移行の対象として考えるのが現実的です。残りは、必要になったときに作り直せば足ります。
追加のアプリは、用途ごとに分けて考えます。工程表の表示、時間の記録、帳票の出力といった用途なら、代わりの道具が標準で持っている場合があります。逆に、自社の業務に合わせて作られたものは、移行の対象から外すか、別の仕組みとして残すことになります。ここの見積もりを甘くすると、移行の直前で計画が崩れます。
検索と保存した条件は、そのままでは持ち出せない
棚卸しで残りやすいのに、移行の計画から漏れやすいのが、保存してある検索の条件です。独自の書き方で条件を組み、その結果を一覧やダッシュボードに並べている場合、その定義は他の道具にそのままの形では移せません。
ただし、持ち出せないのは書き方であって、目的ではありません。実際に見ている一覧を数えると、たいてい3つから5つに収まります。自分の担当で期日が近い順のもの、期日を過ぎているもの、今週動きの無いもの、確認待ちのもの。この程度です。数十の条件を保存していても、毎週開いているのはその中のごく一部です。
やるべきことは、条件の定義を写すことではなく、「毎週見ている一覧」を書き出すことです。書き出した数だけ、移行先で同じ一覧を作れるかを確かめます。作れるなら、それで足ります。作れない一覧が出てきたら、その一覧が何のためのものかを確かめてください。報告のためなら、報告の形そのものを見直したほうが早い場合があります。
ダッシュボードも同じです。導入時に作ったまま誰も開いていないものが並んでいることは珍しくありません。移行の作業を始める前に、直近3か月で実際に開かれたものだけを残す判断をしておくと、運ぶ量が目に見えて減ります。
試す期間に、何を確かめるか
候補が2つか3つに絞れたら、実際に触る段階に入ります。ここで確かめるべきなのは、機能があるかどうかではありません。それは資料を読めば分かります。触ってしか分からないのは、次の3つです。
1つ目は、初めて開いた人が説明なしでどこまで進めるかです。とりまとめる立場の人ではなく、実際に入力する側の人に触ってもらってください。最初の10分で1件も登録できないなら、全体に配ったときには同じことが人数分だけ起きます。
2つ目は、いま扱っている案件を1つ、そのまま移してみたときに形が保てるかです。架空の例では確かめられません。実際の案件には、担当が複数いる作業や、期日が決まっていない項目や、途中で止まっているものが必ず混ざっています。それらが表現できるかどうかが、実運用に耐えるかの分かれ目になります。
3つ目は、外から見たときの見え方です。取引先や別の部署に共有する場面があるなら、その画面を実際に出してみてください。共有のたびに書き出しや加工が必要なら、その手間は毎回発生します。
体験できる期間は候補によって異なります。公式ページの説明では、StandardとPremiumについて7日間の無料の体験が案内されています。短い期間で判断するなら、上の3つに絞って確かめるのが現実的です。全機能を触ろうとすると、期間内に結論が出ません。
替えないという判断が正しい場面
代わりを探している立場で書きにくいことですが、替えないほうがよい場合は確かにあります。
ソースコードの管理や配布の仕組みと課題が結びついていて、その連携が日常の作業に組み込まれている場合。監査の要件があり、誰がいつ何を変えたかの記録を残す必要がある場合。開発の工程が繰り返し発生し、定義した型が実際に守られている場合。この3つに当てはまるなら、替えることで失うもののほうが大きくなりがちです。
もう1つ、人数が多い組織で、複数の部署が別々の設定で使っている場合も、移行の難度が跳ね上がります。部署ごとに事情が違うので、全員が納得する移行先は存在しません。この場合は、全体を替えるのではなく、噛み合っていない部署だけを別の道具に移す選択肢が現実的です。
替えない判断をした場合でも、やるべきことは残ります。棚卸しで「使っていない」と分かった設定を実際に消すことです。使われていない種類、埋まらない項目、誰も見ていない一覧。これらを減らすだけで、初めて触る人の迷いは目に見えて減ります。替えるかどうかの検討で得られた情報を、そのまま今の環境の整理に使えるということです。
消すときは、いきなり削除せず、まず無効にして1か月置く形が安全です。誰かが月に1度だけ使っていた、という場合に気づけます。声が上がらなければ削除する。この手順なら、必要なものを消してしまう事故を避けられます。
道具を分けることには当然の欠点があります。全体を1つの画面で見られなくなり、部署をまたぐ仕事の追跡が難しくなります。ただ、実態として部署をまたぐ仕事が少ないなら、その欠点は表に出ません。1つに統一することが目的化していないか、一度確かめる価値があります。
代わりの候補は、3つの型に整理できる
候補として挙がるものは、おおむね3つの型に分かれます。
1つ目は、開発の工程に特化した型です。課題の管理と、コードや配布の仕組みとの連携を強みにします。いま使っている用途が開発中心で、費用や画面の複雑さだけが不満なら、この型の中で比べるのが素直です。
2つ目は、汎用のボード型です。板の上にカードを並べて、列で状況を表す形。決めることが少なく、初めて開いた人でも操作が分かります。開発以外の部署にも広げたい場合や、入力が定着しないことが理由の場合に向きます。
3つ目は、自分たちのサーバーに置く型です。費用の形が利用料から保守の手間に変わります。社内に技術の担当がいて、データを外に出せない事情がある場合に選ばれます。
型を選ぶときに効くのが、使う人の内訳です。全体の8割が開発に関わる人なら1つ目、開発と他部署が半々なら2つ目、というように、多数派が誰かで決まります。少数派の要望に合わせて全体の道具を決めると、多数派の入力が定着せず、結局どちらの目的も果たせません。少数派に必要な機能は、別の道具を併用する形で埋めるほうが現実的です。
型を決めてから個別のサービスを見ると、比較の項目が少なくなります。型が違うもの同士を並べて機能の数を比べても、判断の材料にはなりません。目的が違う道具を、同じ物差しで測っていることになるからです。
社内をどう通すか
技術的な検討が終わっても、決裁が通らずに止まることがあります。ここでつまずく原因は、説明の順番にあることが多いです。
費用の比較から入ると、「今のままでも動いているのに、なぜ変えるのか」という問いに答えられません。最初に置くべきなのは、いま何が起きているかです。入力が定着せず進捗の把握が口頭に戻っている、報告のたびに表計算ソフトへ転記している、人数が増えて費用の見通しが立たない。こうした具体的な状態を先に共有します。
次に、それを放置した場合に何が起きるかを示します。転記の作業が週に2時間発生しているなら、年間では100時間に近づきます。この数字は自分たちで測れます。確かめようのない一般的な効果を並べるより、社内の実測のほうがはるかに説得力があります。
そのうえで、選択肢を3つ示します。今のまま設定だけ見直す案、道具を替える案、部署ごとに分ける案。それぞれの費用と手間を並べ、推す案を1つ明示する。決裁する側が求めているのは選択肢の一覧ではなく、担当者の判断とその理由です。並べるだけで判断を預けると、話は次の会議に持ち越されます。
移行の費用は、機能ではなく人の慣れに出る
見積もりで抜けやすいのが、慣れ直すための時間です。データを運ぶ作業は数日で終わっても、全員が新しい画面に慣れるまでには数週間かかります。
その間、進捗の把握は一時的に粗くなります。両方の道具を並行して動かすと二重の入力が発生し、片方を止めると移行前の情報を参照できなくなる。どちらを選んでも負担は生じるので、負担の形を選ぶことになります。実務でよく採られるのは、進行中の案件だけを新しい側に移し、終わった案件は元の環境を読み取り専用で残す形です。
費用として見積もるべきは、次の4つです。データを運ぶ作業の時間、設定を組み直す時間、全員に説明する時間、そして慣れるまでの間の生産性の落ち込み。最後の1つは数字にしにくいですが、無視すると計画が破綻します。2週間から4週間は落ちるものとして予定を組んでおくのが安全です。
移行の時期も選べます。案件の切れ目、期の変わり目、長期の休みの前後。動いているものが少ない時期を選ぶだけで、運ぶ量が減ります。急いで替える理由が無いなら、次の切れ目まで待つ判断は合理的です。
慣れ直す期間を短くする方法もあります。全員に同時に配るのではなく、1つの案件と3人から5人で先に始め、そこで出た質問を集めてから全体に広げる形です。先に触った人が、広げたときの相談先になります。全員が同時に初心者になる状況を避けられるので、とりまとめる立場の人に質問が集中しません。
そしてもう1つ、契約の解約の条件も先に確かめてください。年間の契約を結んでいる場合、途中で移っても支払いは続きます。重なる期間の費用は移行の費用に含めて見積もる必要があります。次の更新の時期を起点に計画を引くと、この重なりを避けられます。
比較のときに見る区切り方
候補を並べる段階になったら、機能の一覧ではなく区切り方を見てください。人数で区切るのか、機能で区切るのか、保存容量で区切るのか。この違いが、1年後の費用と運用の摩擦を決めます。
機能で区切る形は、使い始めの費用を抑えられる代わりに、必要な機能が上の段階にあると分かった時点で全員分の費用が動きます。人数で区切る形は、最初から費用が読める代わりに、少人数のうちは割高に感じることがあります。どちらが向くかは、人数の増え方と、使う機能が増える見込みで決まります。
ボード型のプロジェクト管理ツールの中には、機能で絞らず、区切るのは人数とボードの数だけという考え方を取っているものもあります。契約の段階で使える機能が変わらないので、社内に説明するときの前置きが要りません。何ができるかはできることにあり、費用の区切り方は料金で確かめられます。
個別の候補と並べたい場合は、形の近いものから見るのが早いです。国産のものならBacklogとの比較とJootoとの比較、海外のものならTrelloとの比較、Asanaとの比較、Notionとの比較、monday.comとの比較にそれぞれの向き不向きを整理しています。どれから見るか決めかねる場合は比較の一覧を入口にしてください。
こちら側の弱点も先に挙げておきます。コードを保管する仕組みは持っていません。処理を自動で走らせる機能や、他のサービスとつなぐ口の多さを強みにしてはいません。表示は日本語だけで、既存のデータを自動で引き取れるのはTrelloに限られます。棚卸しの結果、開発の連携と込み入った自動化が残ったなら、比較の対象は1つ目の型の中で探すほうが確実です。データの移し方はTrelloからの移行に、預けたデータの扱いの考え方は安全性の考え方に書いてあります。細かい条件はよくある質問を先に確かめると、問い合わせの往復が減ります。
代わりを探す作業の本体は、候補を調べることではなく、手放すものを決めることです。決まっていれば、比較は1日で終わります。決まっていないと、何か月調べても決まりません。棚卸しの表を作るところまでを、まず1週間の作業として予定に入れてください。そこまで進めば、候補が2つに絞れているか、あるいは替える必要が無いという結論が出ているか、どちらかになっているはずです。
Q1. Jiraの無料プランは何人まで使えますか？
公式の料金ページには、無料のプランは10人まで、保存領域は2ギガバイト、対応は利用者どうしの場での案内、と書かれています。人数がこれを超えると、Standardの体験期間に自動で切り替わる旨も同じページに記載があります。11人目が入る時点で費用の判断が必要になると考えてください。
Q2. 代わりを探すとき、最初に何をすればよいですか？
候補を調べる前に、いま実際に使っている機能の棚卸しをしてください。課題の種類と状態、ワークフローの制限、自動化、追加のアプリ、保存した検索条件、外部連携の6つを書き出し、それぞれに「無くなったら誰がどう困るか」を1行で添えます。答えられないものは使っていない機能です。
Q3. 替えないほうがよいのはどんな場合ですか？
コードの管理や配布の仕組みと課題の連携が日常の作業に組み込まれている場合、監査の要件で変更の記録が必要な場合、開発の工程が繰り返し発生して定義した型が実際に守られている場合の3つです。この場合は替えることで失うもののほうが大きくなりがちです。
Q4. 移行にはどのくらいの期間と負担を見ておくべきですか？
データを運ぶ作業自体は数日で終わることが多い一方、全員が新しい画面に慣れるまでには数週間かかります。生産性が2週間から4週間は落ちる前提で予定を組み、案件の切れ目や期の変わり目など動いているものが少ない時期を選ぶと、運ぶ量と混乱の両方を抑えられます。