Linearの代わりを探すとき｜手放してよい機能を先に決める
Linearの代わりを探し始めるとき、多くの人は候補の一覧を作るところから手をつけます。しかしこの順番だと結論が出ません。比べるべき項目が多すぎて、丸とバツの数を数える作業になるからです。先に決めるべきなのは、いまLinearで使っている機能のうち、何を手放してよいのかという線引きです。この記事では、公式サイトで確認できる情報をもとに、その線引きをどう引くかを整理します。あわせて、乗り換える理由がないケースも先に示します。
そのまま使い続けたほうがよい場合を、先に置いておく
代わりを探す必要がないチームがあります。次の条件に当てはまるなら、乗り換えの検討そのものに時間を使わないほうが合理的です。
・チームの大半がソフトウェアを書く人で構成されている ・作業の単位が課題として自然に切り出せていて、それを一覧で回す運用がすでに定着している ・キーボードだけで操作を完結させることに価値を感じている人が複数いる ・コードの変更と課題の状態が連動していることに、日常的に助けられている
この条件が揃っているチームで乗り換えると、失うもののほうが大きくなります。特に4つ目は、置き換えが効きにくい部分です。開発の流れと課題の状態が一体になっている環境に慣れた人は、その連動が切れた瞬間に、手で状態を更新する作業が増えたと感じます。
逆に、この4つのうち2つ以上が当てはまらないなら、検討する価値があります。以下はその場合の話です。
何を前提に作られている道具なのかを押さえる
代わりを探す前に、いま使っているものが何を前提にしているかを言語化しておく必要があります。ここが曖昧だと、候補との比較が噛み合いません。
Linearの中心にあるのは課題という単位です。公式のドキュメントでは、ワークスペースが最上位の概念で、その中に1つ以上のチームがあり、課題とプロジェクトが作業を管理する中心的な要素だと説明されています。課題は必ず1つのチームに属し、プロジェクトは複数のチームにまたがることができます。
この構造には意味があります。作業が課題として切り出されている前提で、すべての画面が設計されているということです。何を作るかが先に決まっていて、それを分解して割り当てる仕事には非常に噛み合います。
一方で、作業の単位が事前に切り出せない仕事には噛み合いません。問い合わせに応じて動く、案件ごとに必要な工程がまったく違う、といった仕事では、課題を起こす作業そのものが手間になります。ここが、乗り換えを検討する最大の理由になることが多い部分です。
利用の規模については、公式の料金ページに次の記載があります。
Trusted by more than 40,000 companies 出典: linear.app
多くの組織で使われている道具であることは事実として押さえたうえで、自分たちの仕事の形に合っているかは別に判断する必要があります。
プランごとに、どこで線が引かれているか
料金と上限は、比較の土台になります。2026年9月時点で公式の料金ページに表示されている内容は、次のとおりです。通貨は米ドル、いずれも年払いでの表示で、税の扱いは表示に含まれていません。
・無料プラン。メンバー数は無制限、チームは2つまで、課題は250件まで、ファイルのアップロードは10MBまで ・Basicプラン。1ユーザーあたり月額10ドル。チームは5つまで、課題とファイルは無制限、管理者の役割が使える ・Businessプラン。1ユーザーあたり月額16ドル。チーム数は無制限、非公開チームとゲストが使える。分析機能や問い合わせ連携もここから ・Enterpriseプラン。個別見積もりで、年払いのみ。SAMLとSCIM、詳細な管理権限、請求書での支払い、移行と導入の支援が含まれる
比較で効いてくるのは、課題の上限とチームの上限です。無料プランの250件という課題の上限は、実務では早い段階で当たります。5人のチームが1人あたり月10件の課題を起こすだけで、月に50件です。5か月で天井に届く計算になります。
チーム数の制限も見落としやすい項目です。部署ごとにチームを分けたい組織では、無料の2つでは足りず、Basicの5つでも足りなくなることがあります。この場合、必要なのはチーム数だけなのに、Businessプランの単価を全員分払うことになります。
手放すと痛いものと、手放しても平気なもの
ここが本題です。いま使っている機能を、置き換えやすさで3つに分けます。
置き換えが難しいのは、次のものです。
・キーボードだけで操作が完結する速さ。慣れた人ほど、これが失われたときの体感の差は大きくなります ・コードの変更と課題の状態が連動する仕組み。手で状態を更新する作業に戻ります ・一定期間を区切って進める運用の型。期間を区切る機能自体は他にもありますが、画面の作りとして自然に組み込まれているかは道具によって違います
置き換えやすいのは、次のものです。
・課題の一覧と絞り込み。どの道具にもあります ・担当者と期限の管理。同上です ・進捗の可視化。形式は違っても、代わりになるものは多くあります ・チャットとの連携。主要なチャットとの連携は、たいていの道具が持っています
判断のうえで重要なのは、置き換えが難しい3つを「実際に使っているか」です。キーボード操作を使いこなしているのが10人中2人なら、残りの8人にとっては失うものがありません。コードとの連動も、開発をしていないメンバーには関係がない機能です。
紙に書き出して数えてみると、使っている人数が少ない機能に引っ張られて乗り換えを止めていることに気づく場合があります。逆に、2人しか使っていなくてもその2人が中核の開発者なら、乗り換えの判断は変わります。人数だけでなく、誰が使っているかまで見る必要があります。
代わりを探す理由は、たいてい3つのどれか
現場で挙がる理由を整理すると、3つに収まります。自分がどれに当たるかを確かめると、候補の絞り込みが速くなります。
1つ目は、チームの構成が変わった場合です。開発者だけだったチームに、デザイナー、営業、外部の協力会社が加わり、全員が課題という単位で話すわけではなくなった。この場合に必要なのは機能の追加ではなく、共通語彙の変更です。課題ではなく「案件」や「依頼」という単位で回せる道具のほうが噛み合います。
2つ目は、費用が人数に比例して伸びた場合です。10人のときは気にならなかった単価が、40人になると年額でまとまった金額になります。特に、必要な機能が1つだけ上のプランにあるという理由で全員分の単価が上がる構造だと、伸び方が急になります。
3つ目は、社外の相手を巻き込めない場合です。ゲストの利用は公式の料金ページによるとBusinessプラン以降の機能とされています。協力会社10社に見てもらうために全員をBusinessプランにする、という計算になると、費用の話が現実的でなくなります。
3つのうち1つ目が理由なら、道具の乗り換えで解決します。2つ目なら、プラン構成の違う道具を探すのが正解です。3つ目は、社外の相手をどう扱うかという設計の問題なので、候補の選び方が変わります。
理由が複数重なっている場合は、順位を付けてください。3つとも解決する道具を探すと候補がゼロになります。いちばん困っている1つを解決し、残りは運用で吸収するという前提で選ぶほうが、現実的な結論にたどり着きます。
なお、3つのどれにも当てはまらないのに代わりを探している場合があります。誰かが別の道具を勧めてきた、あるいは他社が使っているらしい、といった理由です。この場合は、いま何が困っているのかを先に言葉にしてください。困りごとが出てこないなら、乗り換えの必要はありません。
「課題」という単位が合わなくなる瞬間
チームの構成が変わったことが理由の場合、何が起きているのかをもう少し具体的に見ておきます。
開発だけをしているうちは、作業と課題は一対一で対応します。この画面のボタンを直す、この不具合を潰す、といった単位で切り出せば、そのまま担当者と期限が付きます。
ところが、デザイナーと営業が加わると対応が崩れます。営業が持ち込むのは「A社の提案を今月中に」という依頼で、その中には資料作成、見積もり、レビュー、送付といった作業が含まれます。これを課題として切り出すには、誰かが分解しなければなりません。分解する人がいない場合、依頼が1つの大きな課題として登録され、中身が見えないまま数週間放置されます。
もう1つの崩れ方は、外部の協力会社が入るときです。協力会社は自分の作業しか見ておらず、全体の課題一覧を開く動機がありません。結果として、その人の進捗だけが誰かの頭の中にある状態になり、一覧は実態から離れます。
この2つが起きているなら、必要なのは機能ではなく単位の見直しです。案件や依頼という粗い単位を先に置いて、その中に作業をぶら下げる形にすると、分解する人がいなくても全体が見えます。40件の課題が並ぶ画面より、8件の案件が並んでその中が展開できる画面のほうが、とりまとめる側にとっては扱いやすくなります。
判断の目安を1つ挙げると、開発者以外のメンバーが全体の3割を超えたあたりから、この問題が表面化します。
人数が増えたときに、費用がどう伸びるか
費用が理由の場合は、実際に数字を置いて確かめるのが早道です。2026年9月時点の公式の料金ページに表示されている年払いの単価をもとに、試算してみます。
Basicプランの10ドルで10人なら、月額は100ドルです。この規模なら、料金が議題になることはあまりありません。
同じBasicプランで40人になると月額400ドル、年額で4,800ドルです。ここから、ゲストや非公開チームが必要になってBusinessプランに移ると、単価は16ドルになり、40人で月額640ドル、年額7,680ドルになります。
この伸び方で問題になるのは、金額そのものより構造です。必要になった機能は1つだけなのに、単価は全員分が上がります。40人のうち、その機能を実際に使うのが3人だとしても、請求は40人分です。
チーム数の制限も同じ構造です。部署が6つあってチームを6つ作りたい場合、Basicプランの上限は5つなので、Businessプランに移ることになります。必要だったのはチームを1つ増やすことだけですが、単価は全員分が上がります。
代わりを探す理由がここにあるなら、候補を見るときに確かめるべきは機能の一覧ではなく、プランの区切り方です。何で区切っているのかが、そのまま将来の伸び方を決めます。
社外の相手を、いくらでどう参加させるか
協力会社や取引先を巻き込みたい場合、この項目が判断の中心になります。
公式の料金ページの比較表では、ゲストのアカウントはBusinessプラン以降の項目として記載されています。非公開のチームも同じ位置にあります。つまり、社外の相手を限定的に参加させる運用をしたい場合、Businessプランが前提になるということです。
ここで問題になるのは費用ではなく、相手側の負担であることも多いです。協力会社の担当者が、自社ですでに3つの道具を使っている状態で、4つ目のアカウントを作って毎日開いてもらえるかという話になります。現場では、アカウントを配っても開かれないという結果になりがちです。
対処の方向は2つあります。1つは、相手に開いてもらうことを諦めて、こちら側で代理入力する運用にすること。もう1つは、アカウントを必要としない入口を用意することです。フォームのように、リンクを開いて入力するだけで済む経路があれば、相手の負担は大きく下がります。
候補を比べるときは、ゲストの単価だけでなく、アカウントを配らずに入力してもらう経路があるかを確認してください。10社の協力会社を巻き込む運用では、この差が定着率を決めます。
手放してよい機能の一覧を、どう作るか
線引きを紙に落とす手順を示します。作業時間は1時間ほどです。
まず、直近1か月で自分が実際に開いた画面を書き出します。記憶ではなく、思い出せるものだけで構いません。たいていの人は4つか5つしか挙がりません。
次に、その画面で何をしているかを1行で書きます。「止まっている課題を探す」「今週の担当を割り振る」といった粒度です。ここで書き出されたものが、代わりの道具で必ず必要になる機能です。
3つ目に、他のメンバー2人にも同じことを聞きます。とりまとめる側と入力する側では、開いている画面が違います。両方を集めると、実際に使われている機能の全体像が見えます。
最後に、公式の料金ページに載っている機能の一覧と突き合わせます。一覧にあって、誰も挙げなかったものが「手放してよい機能」です。この作業をすると、比較の対象が一覧の全項目から10個前後に減ります。候補を並べる前にここまでやっておくと、検討は一気に短くなります。
候補を試すときは、全面移行ではなく一部で始める
候補が絞れたら、実際に試す段階になります。ここで全部を移そうとすると、判断する前に体力を使い切ります。
公式のドキュメントでも、評価の段階では一部だけを試す方法が示されています。
If you’re importing when evaluating Linear instead of transitioning all at once, you may wish to run a pilot by importing just a few teams. 出典: linear.app
移る方向は逆でも、考え方は同じです。1つのチーム、あるいは1つの案件だけを候補の道具に載せて、2週間だけ並行で回します。
見るべきなのは機能の有無ではなく、次の3つです。1件を記録するまでに何分かかるか。説明なしで他の人が使えるか。2週間後にまだ開いているか。この3つで判断すると、比較表を作るより早く結論が出ます。
並行運用の期間は短くしてください。2つの場所に書く状態が長引くと、どちらも更新されなくなります。2週間を上限にして、そこで判断すると決めておくのが安全です。
並行運用の2週間で、何を記録しておくか
試す期間を決めたら、何を記録するかも先に決めておきます。記録しないまま2週間が過ぎると、印象だけで判断することになり、社内の説明ができません。
記録するのは次の4つです。いずれも日々の作業の中で数えられるものに限定します。
・1件を登録するまでの時間。ストップウォッチで測る必要はなく、体感で30秒か3分かが分かれば十分です ・説明した回数。他のメンバーから使い方を聞かれた回数を数えます。多いほど、定着に手間がかかる道具だという指標になります ・入力されなかった日数。2週間のうち、誰も何も書かなかった日が何日あったかを数えます ・元の道具に戻って確認した回数。候補の側に情報が揃っていない部分を示します
この4つを並べると、判断の根拠が数字になります。2週間で説明の回数が20回を超えているなら、その道具は全社に広げたときに大量の問い合わせを生みます。逆に、説明が3回以内で入力されなかった日が1日だけなら、広げても問題は起きにくいと判断できます。
記録を残すもう1つの利点は、稟議の資料になることです。機能の比較表より、実際に2週間使った結果の数字のほうが、決裁する側には伝わります。
移行を決めたあと、どの順番で進めるか
判断がついたら、手順を組みます。ここを場当たりで進めると、両方の道具が半端に使われる期間が長引きます。
順番としては、まず新しく発生する分だけを新しい道具に入れる運用に切り替えます。過去の進行中のものは、元の道具に残したまま完了させます。この形にすると、二重に入力する期間が発生しません。
新規分だけで2週間回してから、進行中のもののうち期限が先のものを移します。期限が近いものは移さず、元の場所で終わらせます。移動の途中で状態が変わると、どちらが正しいのか分からなくなるためです。
完了した過去のデータは、最後に扱います。多くの場合、道具に入れ直す必要はありません。書き出したCSVを保管場所に置いておけば、参照する必要が出たときに開けます。実際に過去の課題を開く頻度は、多くのチームで月に1回あるかどうかです。
最後に、元の道具の契約をいつ止めるかを決めます。書き出したデータの保管が済んでいること、進行中のものがすべて移っているか完了していることを確かめてから止めます。契約を止めた後に書き出せるとは限らないので、順番を逆にしないことが重要です。
終了、新規受付、運営、料金改定の4点を確かめる
候補を評価するとき、料金だけを見るのは危険です。次の4点を公式の情報で確かめる必要があります。
・サービスの終了が告知されていないか ・新規の受付が止まっていないか ・運営会社が変わっていないか ・料金体系の改定が予告されていないか
この4点が効いてくるのは導入した後です。終了が決まった道具に移れば、数か月後にもう一度移ることになります。新規受付が止まっているなら、その時点で会社の方針が変わっている可能性があります。運営が変われば、料金と対応方針が変わることがあります。
参考として、いま使っているほうについても同じ確認をしておくと、比較が対等になります。2026年9月時点でLinearの公式サイトを確認した範囲では、サービス終了の告知は見当たらず、料金ページから登録を始められる状態で、新規の受付は継続しています。運営会社の変更については公開資料では確認できませんでした。料金体系については、現在の表示が無料、Basic、Business、Enterpriseの4段階であること、Enterpriseは年払いのみであることが確認できます。過去の改定の履歴は、公開されている範囲では確認できませんでした。
同じ4点を、候補についても必ず確かめてください。公式サイトを開けば、いずれも数分で済みます。
移行の重さを、決める前に見積もる
乗り換えの判断で最後に効いてくるのが、移行にかかる手間です。ここを見ないまま決めると、着手してから止まります。
確認すべきなのは、書き出せるものと書き出せないものの区別です。Linearの場合、公式のドキュメントによると、ワークスペースの管理者は課題のデータをCSV形式で書き出せます。項目には、識別子、チーム、タイトル、説明、状態、見積もり、優先度、プロジェクト、作成者、担当者、ラベル、期日、親課題などが含まれます。
書き出せないものもあります。同じドキュメントには、チームそのものをCSVで書き出す機能は無いと明記されています。また、CSVには添付ファイルの実体が含まれないという記載もあります。コメントの扱いについても、書き出される項目の一覧には含まれていません。
つまり、移行の作業量は「どこまで持っていくと決めるか」で決まります。過去の課題をすべて持っていく方針だと、手作業が大量に発生します。進行中のものだけを持っていき、過去はCSVを保管しておくだけにすれば、作業は1日で終わることもあります。
決めるのは道具ではなく、こちら側です。何を持っていくかを先に決めてから移行の手順を組むと、見積もりが立ちます。
もう1つ、書き出しの権限にも制限があります。公式のドキュメントによると、ワークスペース全体の書き出しができるのは管理者で、Enterpriseプランでは所有者に限られます。一覧画面からの書き出しについても、一般のメンバーは一度に250件まで、管理者は2,000件までという上限が示されています。ゲストは書き出せないとも記載されています。
この制限は、移行の段取りに直接効きます。データを持ち出す作業を誰がやるのかを先に決めておかないと、権限を持つ人が不在の週に作業が止まります。退職や異動で管理者が変わる時期に移行を重ねると、この問題が表面化しやすくなります。
比較のときに見る軸は、3つに絞れる
候補を並べる段階で、見る軸を3つに絞ると判断が速くなります。
1つ目は、作業の単位です。課題という単位で回すのか、案件や板という単位で回すのか。チームの構成が変わったことが乗り換えの理由なら、ここが最重要になります。カードを並べる方式に慣れているメンバーが多いチームであれば、Trelloとの比較に、板とカードで始めたときに何が早く、どこで足りなくなるかを整理してあります。案件と担当の割り当てを軸に置く道具との違いはAsanaとの比較、国内の開発現場で使われている道具との対比はBacklogとの比較にまとめています。
2つ目は、料金の決まり方です。機能ごとにプランが分かれる体系では、必要な機能が1つ上にあるという理由で全員分の単価が上がります。機能で絞らず、区切るのは人数とボードの数だけという組み方なら、この跳ね上がりは起きません。実際の金額は、使いたい機能がプランのどこに置かれているかで変わるので、料金のページと各社の料金ページを並べて確かめるのが確実です。
3つ目は、社外の相手をどう扱えるかです。協力会社や取引先に見てもらう必要があるなら、その相手が何の権限で、いくらで参加できるのかを先に確認してください。ここは道具によって差が大きい部分です。
なお、候補を選ぶうえで正直に書いておくべき点もあります。開発の流れと課題の状態を連動させたい場合、コードを置く場所そのものを兼ねる道具でなければ、その連動は再現できません。自動化と外部連携の数を最重要の条件にしている場合も、そこを強みにしている道具を選ぶほうが目的に合います。自動で取り込める移行元が限られている道具では、手作業の量が増えます。何ができて何ができないかはできることに一覧があり、移行の段取りの考え方はTrelloからの移行にまとめています。社外の相手を含むデータの扱いは安全性の考え方、検討中に出る疑問はよくある質問、他の候補との対応関係は比較の一覧に整理しています。
手放してよい機能を先に決めておけば、この3つの軸で判断するだけで済みます。一覧の全項目を突き合わせる作業は不要です。
検討にかけてよい時間の目安も置いておきます。手放してよい機能の一覧を作るのに1時間、候補の絞り込みに2時間、並行して試すのに2週間。合わせて3週間で判断できます。この範囲を超えて検討が長引いている場合は、比べている項目が多すぎるか、そもそも乗り換える理由が弱い可能性があります。
理由が弱いまま乗り換えると、移行の手間だけが残ります。最初に置いた4つの条件に戻って、いま使っているものをそのまま続けるという結論も、正当な答えの1つです。
Q1. Linearの無料プランはどこまで使えますか？
2026年9月時点の公式の料金ページによると、無料プランはメンバー数が無制限、チームは2つまで、課題は250件まで、ファイルのアップロードは10MBまでです。5人のチームが1人あたり月10件の課題を起こすと月50件になるため、5か月ほどで課題の上限に届く計算になります。長期の運用を想定するなら、この数字を先に確認してください。
Q2. 代わりを探すとき、何から決めればよいですか？
候補を並べる前に、手放してよい機能の一覧を作ってください。直近1か月で実際に開いた画面を書き出し、そこで何をしているかを1行で書き、同じことを他のメンバー2人にも聞きます。公式の機能一覧と突き合わせて、誰も挙げなかったものが手放してよい機能です。比較の対象が10個前後に減ります。
Q3. 乗り換えないほうがよいのは、どういうチームですか？
大半がソフトウェアを書く人で構成されていて、作業が課題として自然に切り出せており、キーボードだけで操作を完結させることに価値を感じる人が複数いて、コードの変更と課題の状態が連動していることに日常的に助けられているチームです。特に最後の項目は、コードを置く場所を兼ねない道具では再現できません。
Q4. 移行にはどれくらい手間がかかりますか？
何を持っていくかで決まります。公式のドキュメントによると、管理者は課題をCSVで書き出せますが、チームそのものを書き出す機能は無く、CSVに添付ファイルの実体は含まれません。過去分をすべて持っていく方針だと手作業が大量に発生します。進行中のものだけを移し、過去はCSVを保管する方針なら1日で終わることもあります。