Linearが使いにくいと感じるとき｜合っていないのは道具か、組み方か
Linearが使いにくいという話は、たいてい原因が1つではありません。言葉が合っていないのか、画面の作法に慣れていないのか、権限の設計を誤ったのか、上限に当たっているのか。原因が違えば手当ても違います。ここでは2026年9月時点の公式ドキュメントで確かめられる事実だけを使い、組み方を直せば消えるものと、設計思想なので変わらないものを分けて整理します。
「使いにくい」を4つに割ってから考える
進行をとりまとめる立場で、チームから「使いにくい」という声が上がったとき、そのまま道具の問題として受け取ると判断を誤ります。まず4つに割ってください。
1つ目は言葉です。画面に出ている用語が、いま自分たちが使っている言葉と対応していない。これは組み方で大部分が直ります。
2つ目は画面です。操作の作法が体に入っていない、あるいは表示そのものが読みにくい。ここは慣れで縮む部分と、そもそも切り替えられない部分に分かれます。
3つ目は権限です。誰でも設定を変えられる、あるいは見せたい人に見せられない。ここはプランと設定の話で、大半は変えられます。
4つ目は上限です。件数やチーム数の壁に当たっている。これは組み方では直りません。プランを上げるか、運用を変えるかの二択です。
現場で出る「使いにくい」の内訳は、経験的に言葉と権限に偏ります。機能が足りないという理由は、実は少数です。だから、機能の比較表を作り直す前に、この4つの切り分けをやる価値があります。以下、順に見ていきます。
言葉が合っていないときに、何が起きているか
この道具がとっつきにくい最大の原因は、用語の対応が取れていないことです。公式に対応表が用意されていること自体が、そこが難所だと認識されている証拠です。
対応はおおよそ次のようになっています。
・スプリントはサイクルと呼ぶ ・ストーリーはイシューにまとめられている。ストーリーという層は用意されていない ・エピックはプロジェクトが近い ・カンバンはボードレイアウトという表示の選び方 ・スイムレーンは行という副次的なグループ分け ・減っていく形の消化のグラフではなく、積み上がる形のグラフが対応する
階層についても明記があります。他のツールが「プロジェクト、エピックやコンポーネント、ストーリー、タスク、サブタスク」と積み上げるのに対し、こちらは「ワークスペース、イニシアチブ、プロジェクト、マイルストーン、イシュー、サブイシュー」という並びです。段の数を意図して抑えた設計だと明記されています。
ここで起きがちなのが、層を減らされたことによる窮屈さです。仕事の種類ごとに細かく型を分けて運用してきたチームは、入れた瞬間に「入れる場所がない」と感じます。ドキュメントには、ストーリーという概念を持たない理由として、複雑さと層の数を減らすためだと書かれています。そして代替案も示されていて、種類を分けたいならラベル、ラベルのグループ、親イシュー、カスタムビューを組み合わせて表現する、という考え方です。
つまり、型を増やすのではなく、同じ器に印を付けて絞り込む設計です。この違いを理解しないまま使うと、「あの分類が作れない」という不満が延々と出ます。理解したうえでラベルの設計をやり直せば、多くは解決します。
もう1つ、状態の名前は自分たちで決められます。ワークフローの状態はチーム単位で定義でき、設定画面から変えられます。既定のものを使い続けているせいで違和感が出ているなら、そこを直すだけで印象が変わります。開発チームと運用チームで名前が違っても構いません。
言葉の問題は、導入の初日に30分かけて対応表を作るだけで、その後の数か月の摩擦がほとんど消えます。逆に、ここを飛ばすと、ずっと「使いにくい」と言われ続けます。ボードの用語や運用が違う道具と比べたいなら、Trelloとの比較やBacklogとの比較のように、言葉の設計が違う道具を並べてみると、何に引っかかっているのかが言語化しやすくなります。
画面が英語であることと、キーボード前提であること
見た目の問題は2つに分かれます。表示の言語と、操作の作法です。
表示の言語について、公開されている個人の設定のページには、言語を切り替える項目が見当たりません。並んでいるのは、既定で開く画面、氏名の表示方法、週の始まりの曜日、絵文字への変換、コメントの送信キー、文字の大きさ、カーソルの形、リンクの下線、テーマの選択、デスクトップアプリの挙動、スペルチェックの有無といった項目です。
これは、組み方では直りません。日本語の画面であることが人を増やす条件になっているチームでは、ここが決定的な障害になります。逆に、ステータスやラベルやイシューの本文はすべて日本語で書けるので、日常的に読む文字の大半は自分たちの言葉にできます。画面の枠が英語であることをどれだけ許容できるかは、チームの構成次第です。
操作の作法のほうは、慣れと共有で縮みます。中心になるのはコマンドメニューで、CmdまたはCtrlとKで開きます。ドキュメントは多くの操作について、この入り口からたどる手順を載せています。移動の割り当ても決まっていて、Gに続けてTでトリアージへ、他のチームを見ているときはOに続けてTで対象を選ぶ、と説明されています。右側の情報の欄はCmdまたはCtrlとIで開き、分析の欄はCmdまたはCtrlとShiftとIです。
受け箱の画面では、1で受け入れ、2で重複としてまとめる、3で断る、Hで後回し、という割り当てです。重複の処理はMを続けて2回でも動きます。
ここで起きる分断は、一部の人だけが速くなって、残りが取り残されることです。手当ては単純で、毎日使うものを5つだけ選んで全員に配ります。一覧を配っても誰も覚えません。受け箱で使う1と2と3、そしてコマンドメニューと右側の欄の開き方。この5つを配るだけで、日々の操作はほぼ足ります。
なお、文字の大きさとテーマは設定で変えられます。読みにくさを訴える人がいるなら、まずここを確かめてください。設定のページには、明るい表示と暗い表示をいくつか選べること、独自の配色を作れること、外部の公開サイトに70種類を超える配色が集まっていることが書かれています。
仕掛かりを絞る運用をしてきたチームがぶつかる壁
ボードを使って流量を管理してきたチームには、設計思想として合わない部分があります。これは設定では変えられません。
We don't limit work in progress as this does not match our philosophy. We deliberately reduce roadblocks and friction to ensure every user is empowered to take the actions they need to take. 出典: linear.app
仕掛かりの数を制限しないこと、そして障害と摩擦を意図して減らし、各自が必要な行動を取れるようにすること。これが明言されている方針です。列ごとに上限を掛けて、それ以上は入れられないようにする運用は、この道具の考え方の外にあります。
この方針が良いか悪いかは、チームの性格によります。各自の判断を信頼して詰まりを自律的に解消する文化なら、制限が無いほうが速く動きます。一方で、手を広げすぎる傾向があるチームでは、制限が無いことで仕掛かりが膨らみます。
制限が無い前提で詰まりを見えやすくする手はあります。状態の数を減らすことです。状態が8個ある運用は、どこで詰まっているかが分散して見えなくなります。4つ程度に絞ると、確認待ちに何件たまっているかが一目で分かります。制限をかける代わりに、見えやすくする。この置き換えができるかどうかで、合う合わないが決まります。
分析の画面を使えるプランなら、受け箱にとどまった時間や、着手から完了までの時間を指標として出せます。これも詰まりを見つける手段になります。ただし、この画面はビジネスプランとエンタープライズプランでのみ使えると明記されているので、無料や入門のプランでは別の方法が要ります。
工程表として使おうとすると、必ず当たる制約
紙やExcelで工程表を引いてきたチームが、最初に壁を感じるのがここです。
時間軸に並べる画面はタイムラインと呼ばれ、対象はプロジェクトです。個々のイシューはタイムラインに表示できず、リストかボードで見ることになると明記されています。計画を立てる画面と、手を動かす画面を、混ぜないようにしてあるということです。
つまり、作業1件ずつの棒を日付の軸に並べて全体を見せる使い方は、想定されていません。これは設定では変えられません。
プロジェクトの単位でなら、かなりのことができます。粒度は日、週、月、四半期、年から選べます。イニシアチブなどでグループ分けでき、マイルストーン、責任者、優先度、状態、健康状態といった項目を表示に出すかどうかを選べます。チームのサイクルを重ねて表示することもできます。
依存関係も引けますが、対応しているのは終了から開始へ向かう形だけだと明記されています。開始と開始を揃える形や、終了と終了を揃える形は、この一文の範囲では確認できません。線の色で状態が分かり、守られている依存は青、破られている依存は赤です。棒を引っ張ると、まだ始まっていない後続や計画中のものが追随して動きます。
手当ての方向は2つです。1つは、プロジェクトの粒度を細かくして、工程表に載る単位に近づけること。ただし細かくしすぎると、上の層で見る意味が薄れます。もう1つは、工程表を求めている相手が本当に何を知りたいのかを確かめることです。多くの場合、知りたいのは「いつ終わるか」と「どこが遅れているか」であって、棒の並びそのものではありません。プロジェクトの進み具合のグラフには完了の見込みが出ますし、更新の文章で事情を伝えられます。
それでも作業単位の棒が必要なら、この道具の設計とは合っていません。ボードと工程表を同じ画面の切り替えで行き来したいなら、Backlogとの比較やmonday.comとの比較のように、見せ方の前提が違う道具を並べて検討する段階です。
上限に当たっているなら、組み方では直らない
「急に作れなくなった」「警告が出ている」という種類の使いにくさは、上限の問題です。ここは組み方では解決しません。
無料のプランで当たる上限は3つです。チームは2つまで、イシューは250件まで、ファイルの添付は10MBまでです。人数では止まりません。メンバーは無制限と書かれています。
Basicに上げるとチームが5つまで、イシューとファイルが無制限になります。Businessでチーム数も無制限になります。金額はBasicが1ユーザーあたり月10ドル、Businessが月16ドルで、いずれも年払いの表示です。
有料でも当たる上限があります。専用のページに、性能と速さを保つため、チーム1つあたり保管していないイシューを60,000件までに制限していると書かれています。保管済みのイシューはこの数に入りません。この上限を超えたチームでは、連携やAPIから新しいイシューを作ることが止められます。
対処として案内されているのは、不要な古いイシューを消すこと、別のチームに移すこと、自動で保管される時期を早めることです。完了しただけでは数から外れず、保管して初めて減る点が重要です。数年単位で使い込む前提なら、保管の運用を最初から決めておいてください。
書き出しにも上限があります。画面ごとの書き出しは、一般のメンバーが一度に250件まで、管理者が2,000件までです。ゲストは書き出しできません。ワークスペース全体の書き出しは管理者が実行でき、届くダウンロードのリンクは12時間で期限切れになります。年に一度の記録を取る運用なら、この上限を前提に手順を組む必要があります。
サイクルにも上限があります。先に作っておける将来のサイクルは15本までです。2週間のサイクルならおよそ半年先までで、それより先の計画は別の形で持つことになります。
通知が多すぎて、誰も受信箱を見なくなっている
「使いにくい」の中身が、実は通知の量であることもよくあります。連携を一気に入れた直後に起きます。
この道具では、連携経由で作られたイシューや、そのチームに属していない人が作ったイシューが、受け箱に集まる仕組みです。ここまでは整理される方向に働きます。問題は、その後の通知をどこまで流すかです。
更新の記録には、2026年9月に受信箱の構成が変わったことが載っています。活発なワークスペースでは1日にかなりの量の通知が出るのに、これまではすべて同じ扱いだった、という説明が付いています。新しく追加された欄は、いま注意が要るものとあとでよいものを分けるためのもので、公開を止めているレビューのような重要なものが埋もれないようにする狙いだとされています。既定では自動で選ばれ、通知の種類を指定したり条件を作ったりして自分で調整もできます。これまでどおりの使い方も続けられると書かれています。
つまり、受信箱が埋まる問題そのものは認識されていて、手当てが用意されています。まずここを設定し直すのが先です。
更新のまとめを受け取る仕組みにも、頻度の設定があります。管理者が既定の頻度を毎週月曜、毎営業日、なし、から選べます。個人が自分で決めた場合はそちらが優先されます。「なし」を選べることが重要で、全員に毎日届ける必要はありません。届くのは現地時間の午前6時ごろとされています。
外に流す側も見直してください。すべての変更をチャットに流す設定にすると、チャット側が読まれなくなります。まとまった単位の更新だけを、専用のチャンネルに送る形が勧められています。細かい変更は道具の中に残し、人に届けるのは要約だけにする。この切り分けができていないと、どちらの画面も読まれなくなります。
連携を増やす前に確認する設定もあります。外部のアプリの承認という仕組みが有料のプランで使え、管理者が導入前に確認して承認する形だと案内されています。誰でも自由に連携を増やせる状態を避けたいなら、先に有効にしておいてください。
移行の途中で「使いにくい」が出ているとき
導入の直後に不満が集中する場合、原因が道具ではなく移行の作業そのものにあることがあります。
取り込みの手段は2つに分かれています。専用の取り込み機能が用意されているのは、Jira、GitHub Issues、Asana、Shortcut、そしてLinear同士の移行です。この一覧に無いツールから移る場合は、CSVを用意してコマンドラインの道具で流し込む形になります。
ここで落ちるものが明記されています。コマンドラインの取り込みでは、コメントやプロジェクトは引き継がれません。専用の取り込み機能のほうが元のデータをより多く保てるため、そちらが使える場合は勧められています。
つまり、専用の取り込みが用意されていないツールから移った場合、過去のやり取りが全部落ちている可能性があります。「前は経緯が追えたのに、いまは追えない」という不満は、道具の機能ではなく移行の方式が原因です。この場合の手当ては、元のツールを一定期間そのまま参照用に残すことです。
使える項目も限られています。CSVで持ち込めるのは、題名、説明、優先度、状態、担当者、作成日、完了日、ラベル、見積もりです。独自に持っていた項目は、この並びに収まらなければ落ちます。見積もりについては、取り込んだイシューのチームで見積もりの機能を有効にしないと表示されない、という注意も付いています。
取り込みを実行できるのはワークスペースの管理者だけです。移行元のサービス側でも、データを取り出すために強い権限が要る場合があると添えられています。作業が特定の人に集中するので、その人が不在のあいだ移行が止まることがあります。
やり直しについても記載があります。同一のチームへ重ねて流し込むと、前回入った分は処理の対象から外れます。きれいにやり直したいときは、前の取り込みを消してから実行してください。専用の取り込み機能なら、まとめて取り消せる利点があるとも書かれています。
取り込みの案内ページには、何を持ち込むかの考え方についての助言もあります。日常の仕事にもう関わらないデータは、そもそも持ち込まなくてよいのではないか、という問いです。区切りを付けるために必要な分だけを入れて始める組織もあれば、履歴をできるだけ1か所に残したい組織もある、と両方の立場が併記されています。過去の未整理な分類をそのまま写すと、新しい画面が最初から散らかった状態で始まります。使いにくさの原因が、実は持ち込んだ古い分類にあることも珍しくありません。
人を入れられない、見せられないときの原因
「あの人に見せられない」「協力会社を入れられない」という種類の使いにくさは、権限とプランの組み合わせが原因です。
出発点として、社外の人を招く仕組みそのものが上位の2つのプランに置かれています。無料や入門のプランには、範囲を限って外部の人を入れる手段が用意されていません。さらに、この枠で入れた人も通常のメンバーと同額で請求されると明記されています。名前から安い席を想像すると外れます。
ゲストに見えるのは、明示的に追加されたチームのイシュー、プロジェクト、ドキュメントです。そのチームの中ではメンバーと同じ操作ができます。見えないものも列挙されています。ワークスペースの全体に掛かるビュー、顧客からの要望、会社の目的を束ねる層。これらは範囲の外です。設定についても、自分のアカウントの欄以外には触れられません。チームの責任者に任命することもできないと書かれています。
非公開のチームも同じく、ビジネスプランとエンタープライズプランでのみ使えます。人事や経営の案件を同じワークスペースに置きたい場合は、上のプランが必要になります。
逆方向の困りごと、つまり「誰でも設定を変えられてしまう」も、プランの問題です。役割のページには、無料のプランではすべてのユーザーが管理者になると明記されています。5人なら問題になりませんが、15人を超えたあたりから、意図しない設定の変更が起き始めます。有料に上げると、上げた人が管理者の役割を持つ形になります。
チームごとに責任者を置く仕組みは、ビジネスプランとエンタープライズプランで使えます。この役割だけに限定される操作は、チームの削除、チームの非公開化、親のチームの変更の3つです。それ以外は設定で調整でき、ラベルの管理、テンプレートの管理、チームの設定の管理、メンバーの追加について、全員に許すかオーナーだけにするかを選べます。ゲストの追加だけは、この設定に関わらずオーナーに限られます。
抜け道についての注意も書かれています。ワークスペース単位で入れた連携は外部の人からも使えてしまうため、招いていないチームの情報に届く余地が残るという指摘です。人を招く前に、いま入れている連携を一覧にして確認する手順を挟んでください。
誰も更新しなくなったときに、疑う順番
「使いにくい」がはっきりした不満として出てこず、ただ更新が止まるという形で現れることもあります。この場合は、次の順番で疑ってください。
最初に疑うのは、状態の数です。状態が8個あると、人は選ぶときに迷います。迷う操作は続きません。ワークフローの状態はチームごとに変えられるので、4つ程度まで減らしてみてください。確認待ちに何件たまっているかが一目で分かるようになれば、動かす意味が生まれます。
次に疑うのは、粒度です。1件が1サイクルで終わらない大きさだと、状態が長いあいだ動きません。動かない箱を持っている人は、更新する機会がありません。サイクルは1週間から8週間で設定できるので、その期間で終わる大きさに割り直してください。大きいものはプロジェクトにして、中をイシューに分けます。
3つ目に疑うのは、入れた内容が誰かに届いているかです。自分が書いたことに誰も触れないなら、書く理由が消えます。更新が集まる画面には、反応が多いものを優先して並べる切り替えが用意されています。反応そのものを仕組みで促すことはできませんが、読んでいる人がいると分かる状態を作ることはできます。
4つ目に疑うのが、報告との関係です。入力した内容が、そのまま人に見せられる形になっていないなら、二度手間になります。この場合は、絞り込みの条件を保存した画面を用意して、報告をその画面で行う形に変えてください。清書をやめるだけで、入力の丁寧さが変わります。
ここまでやって直らないなら、そのときに初めて道具の相性を疑います。順番を逆にすると、道具を替えても同じことが起きます。
直せるものと、直せないものを分けて次を決める
ここまでを整理します。組み方で直るものと、直らないものは次のように分かれます。
組み方で直るもの。用語の対応が取れていないこと。ステータスの名前が既定のままであること。ラベルの設計が型を増やす発想になっていること。操作の割り当てが共有されていないこと。文字の大きさや配色が読みにくいこと。報告のための画面が用意されていないこと。責任者を置き忘れて更新が止まっていること。
プランを上げれば解けるもの。チームの数の上限。イシューの件数の上限。権限を分けられないこと。社外の人を入れられないこと。非公開のチームを作れないこと。数字で振り返る画面が開かないこと。
設計思想なので変わらないもの。画面の枠が英語であること。仕掛かりの数を制限しないこと。作業1件ずつを時間軸の棒で並べられないこと。階層が浅いこと。
最後の4つに当たっているなら、それは道具の問題ではなく相性の問題です。無理に運用でねじ伏せると、入力する人の負担だけが増えて、結局は誰も更新しなくなります。
道具を選び直す段階に入ったなら、比べる軸を先に決めてください。効くのは3点です。席の数え方、つまり見るだけの人や社外の人がどう数えられるか。上限の置き場所、つまり人数で止まるのか件数で止まるのか機能で止まるのか。そして、報告のための作り直しが発生するかどうか。壁の置き方には別の流儀もあります。機能で絞らず、区切るのは人数とボードの数だけという線の引き方をしている道具では、いま欲しい機能が使えないからプランを上げる、という悩み方をしません。
他の道具と並べて見たいときは、比較の一覧に主要なサービスとの対照が置かれています。ボード中心の運用ならTrelloとの比較、仕事の型と権限の細かさならAsanaとの比較、文書と台帳を混ぜるならNotionとの比較、国内の開発現場での定着ならJootoとの比較が出発点になります。機能そのものの並べ方はできることに、料金の刻み方の考え方は料金にまとまっています。いま使っているボードを持ち込めるかどうかはTrelloからの移行に、社内の情報をどこまで預けてよいかの判断材料は安全性の考え方に、導入前に出やすい疑問はよくある質問にあります。
Q1. 画面を日本語にできますか？
2026年9月時点で公開されている個人設定のページに、表示言語を切り替える項目は見当たりません。並んでいるのは既定の表示画面、氏名の表示方法、週の始まりの曜日、文字の大きさ、配色などです。ただしステータス、ラベル、イシューの本文はすべて日本語で書けるので、日常的に読む文字の大半は自分たちの言葉にできます。
Q2. 急にイシューが作れなくなったのはなぜですか？
上限に当たっている可能性があります。無料のプランではイシューが250件までです。有料でも、性能を保つためにチーム1つあたり保管していないイシューが60,000件までに制限されており、超えたチームでは連携やAPIからの作成が止まります。完了しただけでは数から外れず、保管して初めて減ります。
Q3. ボードの列に仕掛かりの上限を設定できますか？
公式の用語の対応表に、仕掛かりの数を制限することはしない、それは思想に合わないと明記されています。設定では変えられません。代わりに状態の数を4つ程度まで減らして、どこに何件たまっているかを見えやすくする方法があります。分析の画面が使えるプランなら、受け箱にとどまった時間なども指標にできます。
Q4. 協力会社を安い席で入れられませんか？
できません。ゲストのアカウントはビジネスプランとエンタープライズプランでのみ使え、通常のメンバーと同じように課金されると明記されています。見える範囲は明示的に追加されたチームに限られ、ワークスペース全体のビューやイニシアチブは見られません。ゲストはイシューの書き出しもできず、チームのオーナーにもなれません。