Linearの使い方で詰まるとき｜合っていないのは道具か、組み方か

Linearの使い方の基本は、チームを作り、ワークフローの状態を決め、イシューを起票し、サイクルで期間を区切って回し、まとまった仕事をプロジェクトで束ねる、という5つの段取りです。この順番を飛ばして画面を触り始めると、「どこに何を入れればいいのか分からない」「使いにくい」という声がチームから上がります。この記事では、2026年10月8日にLinearの公式の料金ページとドキュメントで確かめた事実をもとに、使い方の手順と、詰まったときに原因が道具にあるのか組み方にあるのかを見分ける方法を整理します。

Linearの使い方を5ステップで押さえる

上位に出てくる入門記事の多くは、機能の紹介から入ります。けれども、進行をとりまとめる立場の人がまず知りたいのは「最初の1週間で何を決めれば、チームが迷わず使い始められるか」です。公式ドキュメントの基本概念のページと小規模チーム向けの手引きをもとに、決める順番を並べると次のようになります。

ステップ1：ワークスペースとチームを作る

ワークスペースは会社ひとつ分の入れ物で、ワークスペースごとに固有のURLが付きます。その中に「チーム」を作ります。公式ドキュメントはチームを組織の基本単位と位置づけ、ワークフロー、サイクル、ラベルをチームごとに持つと説明しています。小規模チーム向けの手引きでは、エンジニアリング、デザイン、マーケティングのように職能で分ける例が示されています。

ここで最初の分かれ道があります。無料プランで作れるチームは2つまでです。職能ごとに分けたくても、無料のうちは2つに収める必要があります。

ステップ2：ワークフローの状態を決める

イシューは、チームごとに定義された状態の並びを移動していきます。この状態はリスト表示ではグループに、ボード表示では列の見出しになります。初期値の並びが用意されていて、チームの設定画面で変えられます。現場の呼び方と状態名が合っていないと、誰もイシューを動かさなくなります。「レビュー待ち」「確認中」など、すでにチーム内で使っている言葉に寄せておくと定着が早くなります。

ステップ3：イシューを起票する

公式ドキュメントでは、キーボードの C でイシュー作成の画面が開くと案内されています。テンプレートから作るときは Option（Windowsでは Alt）と C です。ブラウザのアドレス欄に linear.new と入れても作成画面に飛べます。リスト表示とボード表示の切り替えは Cmd（Windowsでは Ctrl）と B です。起票は軽くする設計で、Slackとの連携を使えばチャットのやり取りからも起票できます。

ステップ4：サイクルで期間を区切る

サイクルは、チームが繰り返す計画の期間です。開始日と長さを決めると自動で次々に作られます。長さは1週間から8週間の範囲で選びます。

ステップ5：プロジェクトとイニシアチブで束ねる

複数のイシューがひとつの成果に向かうときはプロジェクトにまとめ、プロジェクトの中の節目はマイルストーンで区切ります。さらに上位の目的で複数のプロジェクトを束ねるのがイニシアチブです。

この5ステップのうち、使いにくさの原因になりやすいのはステップ1とステップ2です。チームの切り方と状態の名前が現場と合っていれば、残りの操作は数日で手に馴染みます。

用語と階層が合わないときの組み直し方

Linearを入れたチームから最も多く聞くのは、「自分たちの言葉で仕事を登録できない」という不満です。これは機能が足りないのではなく、階層の考え方が違うことから来ています。

公式ドキュメントの基本概念のページでは、構成が次のように説明されています。

・イシューは個々の仕事を追う ・チームは、イシューが通るワークフローを持つ ・サイクルは、チームの短期の計画を助ける ・プロジェクトは、関連するイシューを成果物のまわりにまとめる ・イニシアチブは、関連するプロジェクトをより大きな目標のまわりにまとめる ・ビューは、これら全部を見て回るための見方

他の道具で「エピック、ストーリー、タスク、サブタスク」と段を重ねてきたチームは、この並びに移ると段が足りないと感じます。たとえば、ストーリーを入れる専用の層はありません。仕事の種類を分けたいときは、層を増やすのではなく、ラベルで印を付けて、ビューで絞り込むのがLinearの組み方です。

組み直すときの手順は次のとおりです。

1. 今の道具で使っている階層を紙に書き出す（例：案件、機能、作業、細かい作業）
2. 案件をプロジェクト、機能をマイルストーン、作業をイシュー、細かい作業をサブイシューに当てる
3. 当てはまらない分類（不具合か改善か、社内か社外か）はラベルに回す
4. よく見る切り口をビューとして保存し、チーム全員が同じビューを見るようにする

ここで注意したいのは、ラベルの数を増やしすぎないことです。ラベルが30個を超えると、起票する人が選べなくなり、結局どのラベルも付かないイシューが増えます。最初は種類を示すラベルを5つ前後に絞り、足りないと言われてから足すほうが運用は続きます。

もうひとつ、チームの切り方も見直す価値があります。ワークフローやサイクルはチーム単位で持つので、仕事の進め方が違う人たちを1つのチームに入れると、状態の並びがどちらにも合わなくなります。逆に、人数が少ないのにチームを細かく分けると、横断で見る手間が増えます。5人から10人程度なら、まず1チームで始めて、進め方が明確に違う集団が出てきたときに分けるのが無難です。

リスト表示とボード表示を使い分ける

「画面が見づらい」という声も、使いにくさの理由としてよく挙がります。Linearでは、同じイシューの集まりをリスト表示でもボード表示でも見られます。公式ドキュメントのボード表示のページには、ほとんどのビューがリストに加えてボードでも表示できると書かれており、切り替えは Cmd（Windowsでは Ctrl）と B、または表示の設定の横にあるアイコンで行います。

ボード表示では、ワークフローの状態がそのまま列になります。列の上にある追加の印からその列にイシューを作れ、使わない列はメニューから隠せます。空の列を隠す設定もあります。カンバンに慣れた人には、まずボード表示を見せるほうが入りやすく、状態の動きも目で追えます。

一方、リスト表示は件数が多いときの確認に向いています。並べ替えや絞り込みをかけて、担当者ごと、優先度ごとに一気に見渡せます。進行をとりまとめる人が朝に全体を確認するならリスト、チームの定例でみんなの前で状態を動かすならボード、と場面で分けると、それぞれの表示の良さが活きます。

ここで決めておきたいのは、チームで共有するビューを1つか2つに絞ることです。人によって違うビューを見ていると、定例で「自分の画面ではそうなっていない」という食い違いが起きます。共有のビューを作って名前を付け、定例ではそのビューを開く、と決めておくだけで、画面の見づらさに関する不満の多くは収まります。日付の線で工程を一覧したい要望には、プロジェクトの期日やマイルストーンを使ったビューで応える形になりますが、工程表のように細かく線を引きたい人には物足りないことがあります。その差は次の節以降で扱います。

サイクルが回らないときに見るところ

サイクルは、使い方を誤ると「毎週、終わらなかったイシューが溜まっていくだけの仕組み」になります。公式ドキュメントのサイクルのページには、つまずきどころに直結する仕様がいくつか書かれています。

1つ目は繰り越しです。サイクルが終わると、未完了のイシューは基本的に次のサイクルへ自動で移ります。閉じたサイクルに未完了のイシューを残しておく方法は用意されていません。このため、見積もりが甘いままでも画面上は何となく回っているように見え、問題が表に出にくくなります。繰り越しが続くイシューは、サイクルの振り返りで毎回取り上げる、と決めておくと膨らみを止められます。

2つ目はクールダウンです。サイクルの後に休みの期間を挟む設定があり、この期間にはイシューを割り当てられません。技術的な負債の返済や次の計画に使う時間として用意されています。クールダウンを入れずに1週間のサイクルを続けると、計画のための時間がどこにも取れず、サイクルの区切りが形だけになります。

3つ目は自動追加です。サイクルが付いていない進行中のイシューを、今のサイクルに自動で入れる設定があります。これを有効にすると、計画していない仕事もサイクルに入ってきます。「計画した量」と「実際にやった量」を見比べたいチームは、この設定の有無で数字の意味が変わることを押さえておく必要があります。

長さの決め方も迷いどころです。1週間から8週間まで選べますが、最初は2週間から始めるチームが多く、振り返りの頻度と計画の手間の釣り合いが取りやすい長さです。開発以外の仕事、たとえば月次の締めや広報の仕事を同じチームに入れていると、2週間の区切りが仕事の周期と合わず、サイクルが使いにくいと感じます。その場合はサイクルを使うチームと使わないチームを分けるか、サイクルを無効にしてプロジェクトの期日で管理するほうが自然です。サイクルを無効にすると、進行中のサイクルは完了扱いになり、予定されていたサイクルは消えますが、終わったサイクルの記録は残ると公式に書かれています。

無料プランの上限と、有料に移る境目（2026年10月8日時点）

「無料で使い始めたら、ある日イシューが作れなくなった」という相談は、Linearでよく聞く詰まり方のひとつです。2026年10月8日にLinearの料金ページを開いて確かめた内容は次のとおりです。金額は米ドル、有料プランは年払いのときの1人あたり月額です。

プラン	月額（1人あたり）	チーム数	イシュー数	ファイルアップロード
Free	$0	2	250	10MBまで
Basic	$10	5	無制限	無制限
Business	$16	無制限	無制限	無制限
Enterprise	個別見積もり（年払いのみ）	無制限	無制限	無制限

メンバーの人数はどのプランでも無制限です。つまり、無料プランで効いてくる壁は人数ではなく、イシューの件数とチームの数です。イシューを1日に5件起票するチームなら、50日ほどで250件に届きます。

公式の請求とプランの説明には、有料プランを解約したときの扱いも書かれています。データは削除されませんが、イシューが250件を超えていると新しいイシューは作れなくなります。また、無料プランでは全員が管理者になるため、解約するとメンバーは管理者に変わります。権限を分けて運用していたチームでは、この点を見落とすと設定を誰でも変えられる状態に戻ります。

Basicで解除されるのは、チーム数が5つまで、イシュー件数とアップロードの制限、そして管理者の役割を分けられることです。社外の協力者をゲストとして招きたい、非公開のチームを作りたいという場合は、Businessが必要になります。業務委託やフリーランスと一緒に進めるチームは、ここで1人あたりの単価が$16に上がることを前提に予算を組む必要があります。

請求は月払いと年払いを選べ、年払いでは途中で人数が増減すると月ごとに差額が精算されます。途中解約の返金は無いと明記されているため、1年分を払う前に月払いで試すよう公式自身が勧めています。税は請求先の住所によってかかる場合があると説明されています。

開発以外の人が混ざると使いにくくなる理由

小規模チーム向けの手引きの冒頭には、Linearがソフトウェア開発の「計画」と「構築」を支えるために作られていると書かれています。主な連携先として最初に挙がるのもGitHubとGitLabで、プルリクエストの状態からイシューの状態を自動で進める使い方が前提にあります。

この前提は、エンジニアだけのチームにとっては強みです。コードの変更とイシューが結び付き、手で状態を動かす手間が減ります。一方で、デザイナー、営業、経理、外部の制作会社といった、コードに触らない人が同じ場所で進行を共有しようとすると、次のような詰まり方をします。

・状態が自動で進まないので、開発以外のイシューだけ更新が止まる ・イシューという単位が細かすぎて、「この案件は今どこまで来ているか」を一目で見られない ・日付の線で工程を見たい人にとって、サイクルとイシューの一覧では全体像がつかみにくい ・社外の人を入れるにはゲストの仕組みが必要で、上位プランが前提になる

ここで起きているのは、道具の出来の問題ではなく、道具が想定している使い手と、実際に使う人の範囲がずれていることです。開発チームの中ではLinearを使い、それ以外の関係者には別の形で進み具合を伝える、という分け方をしている現場もあります。関係者全員が同じ画面を見る必要があるかどうかで、選ぶ道具は変わります。

進行をとりまとめる人にとって大事なのは、入れた道具をチームが使い続けてくれるかです。入力する人が増えないと、進捗の表はすぐ実態と合わなくなります。開発以外の人が更新しない状態が2週間続いたら、それは組み方ではなく道具の範囲の問題だと見たほうが早く判断できます。

他の道具からLinearへ移すときの手順と注意点

使いにくさの原因が、移行のやり方にあることも少なくありません。前の道具の中身を全部そのまま持ち込んだ結果、何千件もの古いイシューが並び、どれが今の仕事なのか分からなくなる、という詰まり方です。

公式ドキュメントの取り込みのページでは、Jira、GitHub Issues、Asana、Shortcutから取り込む手段が案内されています。そのうえで、日々の仕事に関係しなくなったデータは、そもそもLinearに入れる必要があるかを考えるよう勧めています。解決済みの古いイシューはCSVで書き出して保管すれば足りる場合もあり、移行を「区切り」として必要なものだけを持ち込む組織もあれば、履歴をできるだけ1か所に残したい組織もある、と両方の考え方が紹介されています。

進行をとりまとめる立場から見ると、判断の基準は次の3つです。

1. 今後3か月以内に触る見込みがあるイシューだけを移す
2. 取引先や監査のために残す必要がある記録は、書き出したファイルで別に保管する
3. 移した直後の1週間は、古い道具を読み取り専用で残しておき、取りこぼしを確かめる

無料プランのまま移行する場合は、件数にも気を付けてください。取り込んだイシューも250件の上限に数えられるかどうかは、移す前に公式の窓口で確かめておくほうが安全です。上限に近い件数を一度に持ち込むと、移行した翌日から新しいイシューを作れない、という事態になりかねません。

もうひとつ見落としやすいのが、担当者と状態の対応です。前の道具の状態名がLinearのワークフローの状態と1対1で対応していないと、取り込んだイシューが意図しない状態に入ります。移す前に、前の道具の状態とLinearの状態の対応表を作り、足りない状態はチームの設定で先に作っておくと、移行後の手直しが減ります。

最初の2週間で決めておく運用の決まり

道具が合っていても、運用の決まりが無いまま使い始めると、2週間ほどで「誰がいつ何を更新するのか」が曖昧になり、画面の情報が実態から離れていきます。Linearの場合、最初に決めておくとよいのは次の5つです。

・起票は誰がしてよいか。全員が起票してよいなら、トリアージで誰が振り分けるか ・状態を動かすのは担当者本人か、レビューする人か ・優先度の付け方。緊急、高、中、低のどれを、どんな条件で使うか ・サイクルに入れる量の目安。前のサイクルで終わった件数を超えて入れないなど ・振り返りの日。サイクルの最終日に15分だけ、繰り越しのイシューを見直す

トリアージは、公式ドキュメントで「新しく入ってきた仕事を見て、次にどうするかを決める工程」と説明されています。問題を明確にする、追うべき仕事かを決める、担当を割り当てる、優先度を付ける、次の状態に動かす、といった作業が含まれます。外部からの要望が多いチームほど、ここを決めずに始めると、未整理のイシューがバックログに積み上がり、使いにくいという印象につながります。

決まりは細かく作りすぎないことも大切です。最初の2週間は5つ程度に絞り、詰まったところだけを足していくと、チームが決まりを覚えきれずに形だけになる事態を避けられます。決まりはLinearのドキュメント機能やチームのチャットの固定メッセージに書いておき、新しく入った人がすぐ読めるようにしておくと、問い合わせの手間も減ります。

道具を変えるべきか、組み方を変えるべきかの見分け方

ここまでの話を、判断の材料として並べ直します。「使いにくい」の声が上がったら、次の表のどこに当たるかを先に確かめてください。

症状	原因の所在	手当て
入れる場所が分からない	用語と階層	階層の対応表を作り、ラベルとビューで補う
サイクルに未完了が溜まる	サイクルの設定	長さとクールダウンを見直し、繰り越しを振り返りで扱う
イシューが作れなくなった	無料プランの上限	Basicに移るか、不要なイシューを整理する
誰でも設定を変えてしまう	権限	Basic以上で管理者の役割を分ける
社外の人を入れたい	プラン	Businessのゲスト機能を使う
開発以外の人が更新しない	道具の想定範囲	開発以外の進行を別の道具で持つことを検討する

表の上の4行は、組み方とプランで解決できます。道具を変える必要はありません。とくに用語と階層の問題は、最初の1週間に対応表を作るだけで大半が消えます。Linearの入門記事の多くが「小さく始められる」と書いているとおり、起票の軽さと動作の速さは、開発チームにとってそのまま使い続ける理由になります。

次の文章は、スタートアップの開発でLinearを使う利点を紹介した記事からの引用です。起票を軽くすることが、日々の変化が多い現場でどれだけ効くかがよく表れています。

お客さん・CSからの改善要望、サポート依頼が毎日流れてくる環境にタスクとして流し込むには、Issueを起票するのはなるべく簡単にする必要があります。Slackとの連動もその一つで、スタンプ一つで起票できたり、スラッシュコマンドでの作成なども提供されています。 出典: note.com

一方、表の下の2行に当たる場合は、組み方をいくら直しても解消しにくい部分です。社外の人を入れるたびに上位プランの単価がかかる、開発以外の人の更新が止まる、という状況が続くなら、関係者全員で使う板を別に持つことを考える時期です。他のサービスを横に並べて見たい場合は、比較の一覧に、ボード型やチャット型の道具を同じ項目で並べた表があります。

ボード型のタスク管理ツールと並べたときの位置づけ

最後に、開発以外の人も同じ画面で進行を見る必要があるチームのために、ボード型のタスク管理ツールを選択肢のひとつとして並べておきます。ここでは、この記事を載せているサイトが提供しているボード型のプロジェクト管理ツールについて、案内サイトの料金と機能のページで2026年10月8日に確かめた事実を書きます。

料金のページによると、5人まで、ボード10個までなら期限なしで無料で、ガントチャート、チャット、カスタムフィールドといった機能は無料プランからすべて使えます。料金が変わるのは人数とボードが増えたときだけで、6人目または11個目のボードからはスタンダードプランの1人あたり月額500円（税抜、年払いなら月額400円）です。閲覧だけのゲストは人数に数えません。Linearが件数とチーム数で区切るのに対して、こちらは機能で絞らず、区切るのは人数とボードの数だけという区切り方です。

できることのページには、カンバン、ガントチャート、カレンダー、リスト、時間割、リソースなど8種類のボードが並んでいます。同じカードのまま見え方だけを切り替えられるので、日付の線で工程を見たい人と、列で状態を見たい人が同じ情報を見られます。社外の協力者には、案件ごとにワークスペースを分けて、見せる範囲を絞る運用が案内されています。

ただし、弱い点もはっきりしています。コードのリポジトリと結び付ける機能はなく、プルリクエストに合わせて状態を自動で進めるような開発向けの自動化や外部連携で勝負する道具ではありません。画面は日本語のみで、他の道具から自動で取り込めるのはTrelloからの移行だけです。エンジニアがコードと一緒にイシューを回すことが中心なら、Linearのままのほうが合っています。

現実的な組み合わせは、開発チームの中のイシューはLinearで回し、デザイナーや営業、社外の制作会社を含めた案件全体の工程はボード型の道具で持つ、という分け方です。どちらか一方に寄せるのではなく、誰が更新するのかで管理する場所を決めると、進捗の表が実態とずれにくくなります。Backlogのような国産の道具と並べて検討したい場合は、Backlogとの比較も判断の材料になります。

Q1. Linearは無料でどこまで使えますか？

2026年10月8日時点の公式の料金ページでは、無料プランはメンバー数が無制限で、チームは2つ、イシューは250件、ファイルのアップロードは10MBまでです。イシューを毎日起票するチームは数か月で250件に届くため、件数の推移を見ながら有料プランへの切り替え時期を決めておくと、急に起票できなくなる事態を避けられます。

Q2. Linearの有料プランはいくらですか？

同じく2026年10月8日時点で、Basicが1人あたり月額$10、Businessが月額$16です（いずれも年払いのときの米ドル表記）。Enterpriseは個別見積もりで年払いのみです。社外のゲストを招く機能や非公開のチームはBusinessから使えるため、業務委託と一緒に進めるチームはBusinessの単価で予算を組んでください。

Q3. Linearのサイクルとスプリントは何が違いますか？

サイクルは開始日と長さを決めると自動で繰り返し作られる計画の期間で、長さは1週間から8週間です。公式ドキュメントでは、スプリントと違ってリリースに結び付かないと説明されています。終わらなかったイシューは基本的に次のサイクルへ自動で繰り越されるので、繰り越しが続くイシューを振り返りで扱う決まりを作ると運用が安定します。

Q4. エンジニア以外のメンバーもLinearを使えますか？

使えますが、Linearはソフトウェア開発の計画と構築を支える前提で作られており、GitHubなどと連携して状態を自動で進める使い方が中心です。コードに触らないメンバーのイシューは手で状態を動かす必要があり、更新が止まりやすくなります。開発以外の進行を別の道具で持つかどうかは、2週間ほど運用して更新の様子を見てから判断すると確実です。