Linearの使い方と、小さなチームでの課題管理の進め方

Linearを入れてみたものの、Issue、Cycle、Project、Initiativeと聞き慣れない言葉が並び、どこから手を付ければよいのか分からなくなった人は多いはずです。この記事では、Linearの使い方を、基本の考え方、始め方の手順、小さなチームで回すための決まりの順に整理します。

結論を先に書くと、Linearは「1つの仕事を1つのIssueとして登録し、チームごとの状態の流れに沿って動かす」道具です。最初からProjectやInitiativeまで使いこなす必要はありません。小さなチームなら、Issueとワークフローの状態、それに1〜2週間の区切りであるCycleの3つだけで十分に回り始めます。なお、Linearはソフトウェア開発のチームを主な対象にした道具です。開発以外の仕事も含めて日本語の画面でボードやガントを使いたい場合は、Pinatecaのような汎用のプロジェクト管理の道具も候補になります。

Linearとはどんな道具か

Linearは、ソフトウェア開発のチームが課題やタスクを管理するための道具です。不具合の修正、新しい機能の開発、細かな改善、社内からの依頼など、チームが追いかけるべき仕事を1件ずつ登録し、誰が担当し、いまどこまで進んでいるかを一覧で見られるようにします。

公式サイトによれば、Linearを使っている会社は4万社を超えます。動作が速いこと、キーボードの操作だけで大半の作業ができること、画面の情報が絞り込まれていて迷いにくいことが、開発者に選ばれている理由としてよく挙げられます。

Linearを使っている人の文章には、次のような声があります。

Aのプロジェクトがあって、それにはこれが必要だから、このチケットを置いて・・・。と全ての業務をプロジェクトからトップダウンにタスクに分割して管理するのは毎日変化があるスタートアップ(もしくはどんな企業でも)がするのは難しいのではないかと感じています。お客さん・CSからの改善要望、サポート依頼が毎日流れてくる環境にタスクとして流し込むには、Issueを起票するのはなるべく簡単にする必要があります。 出典: note.com

ここで言われているのは、仕事の登録を手軽にしておくことの大切さです。Linearは、思いついたときにすぐIssueを作れること、そのIssueを後から整理できることを重視して作られています。最初に完璧な計画を立てるより、まず登録して、あとで並べ替えるという使い方が合っています。

一方で、Linearの公式のドキュメントは英語で書かれています。開発以外の部署の人や、英語の画面に慣れていない人が使う場合は、最初に用語の意味をそろえる時間が必要です。

Linearの基本の考え方を整理する

Linearを使いこなすには、まず公式のドキュメントのConceptsのページにある基本の考え方を押さえます。主な用語を表にまとめます。

用語	意味	小さなチームでの使い方
Issue	仕事の最小の単位。不具合、機能、依頼など	すべての仕事をまずここに登録する
Workflow	Issueが通る状態の並び（未着手、進行中、完了など）	最初は標準のままで使う
Team	仕事を持つ単位。チームごとに状態の並びや計画の周期を持つ	最初は1つで十分
Cycle	チームが繰り返す計画の期間	1〜2週間で区切る
Project	共通の成果に向けたIssueのまとまり	機能の公開など、複数のIssueにまたがる仕事に使う
Milestone	Project の中の段階	大きなProjectで使う
Initiative	複数のProjectを束ねる、より大きな目標	小さなチームでは使わなくてよい
View	同じ仕事を別の切り口で見る画面	自分の担当、今のCycleなど
Triage	新しく来た仕事を確認し、どう扱うか決める流れ	外からの依頼が多いチームで使う

公式のドキュメントは、これらの関係を次のようにまとめています。Issueが個々の仕事を追い、Teamがその仕事の通る流れを持ち、Cycleが短い期間の計画を助け、ProjectがIssueを成果物の単位でまとめ、InitiativeがProjectをより大きな目標でまとめ、Viewがそのすべてを行き来しやすくする、という関係です。

この表を見て大切なのは、全部を使う必要はないということです。小さなチームが最初に使うのは、Issue、Workflow、Cycleの3つで十分です。ProjectやInitiativeは、仕事が増えて「このIssueは何のための作業か」が見えにくくなってから足せば間に合います。

料金プランと無料でできる範囲

Linearの料金は公式の料金ページに載っています。2026年10月時点の主な内容は次のとおりです（金額は米ドル建てで、年払いの場合の1人あたりの月額です）。

プラン	料金	主な上限
Free	無料	メンバー無制限、チーム2つ、Issue 250件、ファイルの添付は10MBまで
Basic	1人あたり月10ドル（年払い）	チーム5つ、Issue無制限、ファイルの添付無制限、管理者の役割
Business	1人あたり月16ドル（年払い）	チーム無制限、非公開チームとゲスト、分析機能など
Enterprise	個別見積もり（年払いのみ）	SAML・SCIM、監査ログなど

無料プランで気をつけたいのは、Issueの上限が250件であることです。メンバーの数は無制限ですが、日々の細かな仕事をすべてIssueにすると、小さなチームでも数か月で上限に近づきます。完了したIssueも数に含まれるかどうかなど、細かな扱いは料金ページと公式のドキュメントで確かめてください。

無料プランは、まず数人で試し、使い方が合うかを確かめる期間と考えるのが現実的です。本格的に使うと決めたら、Basicに移るか、ほかの道具を選ぶかを判断します。

Linearを始める手順

ここからは、小さなチームがLinearを使い始めるまでの手順を順番に説明します。

1. アカウントを作り、ワークスペースを用意する

Linearの公式サイトから登録します。登録すると、ワークスペースと呼ばれる入れ物が作られます。ワークスペースは会社やチーム全体の仕事を入れる場所で、「linear.app/会社名」のような固有のURLを持ちます。複数のワークスペースに参加している場合は、画面の左上のメニューで切り替えます。

2. チームを作る

ワークスペースの中にチームを作ります。小さな会社なら、最初は1つのチームで始めて構いません。チームごとに状態の並び、Cycleの設定、ラベルなどを持つため、チームを分けすぎると設定の手間が増えます。

3. 状態の並びを確かめる

チームの設定でワークフロー（Issueの状態の並び）を確かめます。Linearには標準の並びが最初から用意されていて、チームの設定で変えられます。最初は標準のままで使い、実際に回してみて足りない状態が出てきたら追加します。

4. メンバーを招待する

一緒に使う人を招待します。無料プランでもメンバーの数に上限はありません。

5. 最初のIssueを作る

いまチームが抱えている仕事を、思いつく順にIssueとして登録します。最初から細かく分ける必要はありません。

前の会社で法人営業をしていた頃、チームの仕事はExcelの共有ファイルと、上司から届くメールと、付箋の3か所に散らばっていました。誰が何をしているかを知るために、毎朝のミーティングで一人ずつ口頭で確認していたのを覚えています。正直、あの時間がいちばん疲れました。仕事を1か所に集めるだけで、確認のための会話がどれだけ減るかは、道具を変えてみて初めて実感できることです。Linearでも、最初の目標は「仕事が1か所に全部ある状態」を作ることです。

Issueの作り方と、書くときの決まり

LinearのIssueは、作る方法がいくつも用意されています。公式のドキュメントにある主な方法は次のとおりです。

1. キーボードの「C」を押して、Issueを作る画面を開く
2. 画面左上の作成のアイコンを押す
3. ブラウザのアドレス欄に「linear.new」と入れる（ログインしていれば作成画面に移る）
4. 文章を選んで、書式のバーから選択した部分をもとにIssueを作る
5. テンプレートから作る場合は、Option（Windowsの場合はAlt）とCを押す

IssueはどれもいずれかのTeamに属し、作られた順に番号が振られます。題名と状態は必ず入れる項目です。

Issueの題名と説明の書き方

あとから一覧で見たときに中身が分かるように、題名は「何をするか」が伝わる短い文にします。「ログイン画面」ではなく「ログイン画面でパスワードを間違えたときの文言を直す」のように書くと、担当者以外が見ても分かります。

説明の欄には、なぜこの仕事が必要か、終わったと言える条件は何か、関連する資料はどこか、の3つを書きます。終わりの条件がないIssueは、いつまでも完了にできずに残りがちです。

下書きと、繰り返しの仕事

Issueを書いている途中で別の画面に移ると、Linearは一時的な下書きを残します。Escキーや閉じるボタンで画面を閉じる場合は、下書きとして保存するかを選べます。保存した下書きはサイドバーの「Drafts」から開けて、6か月たつと自動で削除されます。

毎週の定例の準備や毎月の請求の確認のような繰り返しの仕事は、繰り返しのIssueとして登録できます。Issueを作る画面のメニューから「Make recurring…」を選び、周期を決めます。決まった仕事を毎回手で登録する手間が省けます。

Cycleで1〜2週間の計画を回す

Cycleは、チームが一定の期間に取り組む仕事を決めて進めるための仕組みです（公式のドキュメント）。公式のドキュメントでは、よく使われるスプリントに近い考え方だと説明されています。違いは、Cycleがリリースの時期と結び付いていない点です。

Cycleの設定

チームの設定の「Cycles」で有効にします。主な設定は次のとおりです。

設定	内容
1回の長さ	1週間から8週間の間で選ぶ
開始の曜日	Cycleが始まる曜日。チームのタイムゾーンで午前0時1分に始まる
休みの期間	Cycleの後に休みの期間を入れられる。この期間にIssueは割り当てられない
先の分の作成	先のCycleをいくつ作っておくか。最大15

小さなチームなら、まず1週間か2週間で始めるのがおすすめです。長い期間にすると、途中で予定が変わったときに計画が古くなります。

Cycleの回し方

Cycleの始めに、そのCycleで取り組むIssueを選んで割り当てます。期間中は状態を動かしながら進め、終わったら完了しなかったIssueを確かめます。公式のドキュメントによれば、Cycleは自動の予定で回り、終わるCycleに割り当てられたままの未完了のIssueは次のCycleへ持ち越されます。着手済みや完了済みでCycleが付いていないIssueを、今のCycleに自動で加える設定もあります。

大切なのは、Cycleを「全部終わらせる約束」ではなく「この期間に集中する仕事の目安」として扱うことです。毎回すべてが終わるように計画すると、Issueを少なめに見積もる癖がつきます。終わらなかったIssueがあっても、次のCycleでどうするかを決めれば十分です。

予定より早く次のCycleを始めたいときは、Cyclesの画面で次のCycleのメニューから「Start cycle today」を選びます。ただし、一度開始日を変えると元に戻せないので注意します。

Projectでまとまった仕事を管理する

Issueが増えてくると、「この作業は何のためにやっているのか」が見えにくくなります。そこで使うのがProjectです。

公式のドキュメントでは、Projectは共通の成果に向けてIssueをまとめるもので、機能の公開、顧客の移行、画面の作り直し、技術的な改善など、複数のIssueにまたがる仕事に向いていると説明されています。Projectを作ると、関係するIssueの進み具合をまとめて見られ、関係者に状況を伝えやすくなります。

Projectの中は、Milestoneでさらに段階に分けられます。たとえば「新しい予約画面の公開」というProjectなら、「設計が終わる」「試作が動く」「公開する」の3つのMilestoneを置き、Issueをそれぞれに割り当てます。Milestoneごとに完了の割合が見えるので、どこで止まっているかが分かります。

Projectのさらに上にあるのがInitiativeです。複数のProjectが同じ大きな目標に向かっているときに使います。小さなチームでは、まずProjectまでで十分です。

Triageで外から来る依頼をさばく

顧客や社内のほかの部署から、毎日のように依頼や不具合の報告が届くチームでは、Triageの考え方が役立ちます。

公式のドキュメントでは、Triageを「新しい仕事を確認し、次にどうするかを決める流れ」と説明しています。具体的には、問題をはっきりさせる、記録として追うべき仕事か決める、担当を決める、優先度を決める、次の状態に動かす、といった作業です。届いた依頼をいきなり作業の一覧に入れず、一度Triageで確認することで、依頼が埋もれるのを防げます。

Slackからの登録

Slackを使っているチームなら、Slackのメッセージから直接Issueを作れます。公式のドキュメントによれば、メッセージのメニューから「Connect to apps」を選び「Create new issue…」を選ぶと、そのメッセージをもとにIssueを作れます。Slackの連携を使えるのは、そのSlackにいるLinearの利用者だけです。

メールからの登録

Linearのアカウントを持たない人からの依頼を受けたい場合は、チームごとにメールの受け付け用のアドレスを作れます。チームの設定の「General」から「Create issues by email」を有効にします。ただし、送った人には確認のメールや更新の通知は届かないと書かれているので、依頼した人への連絡は別の方法で行います。

Viewとキーボード操作で日々の確認を速くする

Linearを毎日使うようになると、同じ確認を何度も繰り返すことになります。その手間を減らすのがViewとキーボード操作です。

Viewで見る切り口を決めておく

Viewは、同じ仕事を別の切り口で見るための画面です。公式のドキュメントでは、自分に割り当てられたIssue、特定のProjectの仕事、今のCycleのIssue、チームの未着手の一覧、複数のチームをまたいだ絞り込みなどが例に挙げられています。Viewは仕事そのものを変えるものではなく、整理して集中しやすくするためのものです。

小さなチームなら、次の3つのViewを用意しておくと日々の確認が速くなります。

1. 自分の担当で、まだ完了していないIssue
2. 今のCycleに入っているチーム全体のIssue
3. 担当が決まっていない、または優先度が付いていないIssue

1つ目は毎朝自分が何をするかを決めるため、2つ目はチームの進み具合を見るため、3つ目は誰も拾っていない仕事を見つけるために使います。

キーボード操作を覚える

Linearはキーボードの操作が充実しています。最初に覚えたいのは、Issueを作る「C」と、コマンドの一覧を開く「Cmd+K」（Windowsの場合はCtrl+K）の2つです。コマンドの一覧では、やりたい操作の名前を打ち込むと、メニューを探さずに実行できます。たとえば、Issueの説明の過去の版を確かめたいときは、コマンドの一覧で「Issue description history」と打つと、以前の版を見て元に戻せます。

Issueを別のチームに移す場合は、Cmd+Shift+M（WindowsはCtrl+Shift+M）で移せます。移したIssueには新しい番号が付きますが、古い番号やURLからも新しいIssueにたどり着けると公式のドキュメントに書かれています。

全部の操作を一度に覚える必要はありません。よく使う操作を1つずつ覚えていけば、数週間で手の動きが速くなります。

GitHubと連携して開発の流れとつなぐ

開発のチームがLinearを選ぶ大きな理由の1つが、GitHubとの連携です。公式のドキュメントでは、LinearのチームとGitHubのリポジトリを結び付けて、両方のIssueを自動で作成・同期できると説明されています。コメントも双方向に同期されます。

もう1つ便利なのが、プルリクエスト（コードの変更を取り込む前の確認の依頼）とIssueの結び付けです。公式のドキュメントによれば、プルリクエストの状態が変わると、結び付いたLinearのIssueの状態も自動で更新できます。たとえば、プルリクエストを出したらIssueが「レビュー中」に、取り込まれたら「完了」に動く、という使い方です。開発者が手で状態を動かす手間が減り、Issueの一覧と実際のコードの進み具合がずれにくくなります。

特定のIssueを自動で結び付けたくない場合は、プルリクエストの説明に「skip」や「ignore」とIssueの番号を書くと、結び付けを止められます。

連携の設定はワークスペースの管理者が行います。設定の前に、どのリポジトリとどのチームを結び付けるかを決めておくと、後から整理し直す手間が省けます。

導入して最初の1か月の進め方

道具を入れたものの使われなくなる、という失敗を避けるために、最初の1か月を次のように区切って進めると定着しやすくなります。

期間	やること
1週目	今の仕事を全部Issueにする。状態の並びは標準のまま使う
2週目	1週間のCycleを始める。毎日、状態を動かす習慣を作る
3週目	よく使うViewを作る。ラベルを3〜5個に絞って決める
4週目	1か月を振り返り、状態の並びやCycleの長さを見直す

1週目は、Issueの書き方の細かな決まりにこだわらず、とにかく1か所に集めることを優先します。2週目からCycleを始めると、毎週の計画と振り返りの習慣ができます。3週目に入ると、どんな切り口で一覧を見たいかが分かってくるので、そこでViewを作ります。

ラベルは最初から多く作りすぎないことが大切です。「不具合」「改善」「依頼」のように数個から始め、必要になったら足します。ラベルが多すぎると、付ける人によって選び方がばらつき、絞り込みに使えなくなります。

4週目の振り返りでは、使われていない機能や、毎回飛ばされている状態がないかを確かめます。チームの実際の流れに合わせて道具の設定を変えるのは、自然なことです。

小さなチームで回すための決まりの例

道具を入れても、使い方の決まりがないと、登録されないIssueや放置されたIssueが増えていきます。3〜5人の小さなチームなら、次のような決まりから始めると回りやすくなります。

決まり	内容
仕事は全部Issueにする	チャットや口頭で頼まれた仕事も、その場でIssueにする
担当は1人	1つのIssueに担当は1人だけ。複数人の仕事は分ける
状態はその日のうちに動かす	着手したら進行中、終わったら完了に動かす
週に1回、Cycleの見直し	次のCycleで取り組むIssueを決め、古いIssueを整理する
1か月動かないIssueは見直す	本当に必要か、優先度を下げるか、閉じるかを決める

この中でいちばん大切なのは、仕事を全部Issueにすることです。チャットで頼まれた仕事がIssueになっていないと、一覧を見ても全体が分からず、結局また口頭で確認することになります。

在宅で業務委託のメンバーと一緒に仕事をするチームでは、決まりの大切さがさらに増します。顔を合わせない分、Issueの一覧が「いま誰が何をしているか」を知る唯一の手がかりになるからです。

Linearが合うチームと、合わないチーム

ここまでの内容を踏まえて、Linearが合うチームと合わないチームを整理します。

合うチーム

ソフトウェア開発のチームで、不具合の修正や機能の開発を1件ずつ追いかけたい場合は、Linearの設計がよく合います。GitHubとの連携、キーボード中心の操作、Cycleによる短い計画の繰り返しなど、開発の仕事の流れに沿った機能がそろっています。英語の画面とドキュメントに抵抗がなく、仕事を細かく登録する文化があるチームに向いています。

合わないチーム

開発以外の部署（営業、総務、制作など）が中心のチームや、英語の画面に慣れていないメンバーが多いチームでは、用語に慣れるまでの負担が大きくなります。また、ガントチャートで期間の重なりを見たい、カレンダーで締め切りを並べたいといった使い方は、Linearの主な設計の中心ではありません。無料プランのIssueの上限も、日々の細かな仕事を全部登録するチームには早めに当たります。

迷ったときの試し方

合うかどうか迷う場合は、実際の仕事で2週間ほど試してみるのがいちばん確実です。試すときは、チーム全員ではなく2〜3人で始め、1つのCycleを最後まで回します。そのうえで、次の3つを確かめます。

1. 全員が毎日、状態を動かせたか
2. 一覧を見るだけで、誰が何をしているかが分かったか
3. 英語の画面や用語が、作業の妨げになっていなかったか

3つとも問題がなければ、チーム全体に広げます。どれかでつまずいた場合は、使い方の決まりを変えれば解決するのか、道具そのものが合っていないのかを分けて考えます。決まりで解決できることを、道具のせいにしないことが大切です。

開発以外の仕事も一緒に管理したいときの候補

開発のIssueだけでなく、営業の案件、制作の進行、社内の手続きなど、さまざまな仕事を同じ場所で管理したいチームもあります。そうした場合の候補の1つがPinatecaです。日本語の画面で、カンバン、ガント、カレンダー、リスト、ディスカッション、グリッド、時間割、リソースの8種類のボードとチャットが最初から使えます。5人まで、ボード10個までなら無料で、ガントチャートやチャットも無料のプランから使えます。Trelloからボードやカードをそのまま移す取り込みの機能があり、ChatGPTやClaudeからボードの内容を読んだりカードを作ったりする使い方にも対応しています。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

道具を選ぶときは、どちらが優れているかではなく、チームの仕事の形に合うかで決めます。開発の課題を細かく追いかけるならLinear、部署をまたいだ仕事を日本語のボードで見渡したいならPinatecaのような汎用の道具、というように、目的に合わせて選ぶと失敗が少なくなります。

ほかの道具からLinearへ移るとき

すでに別の道具で課題を管理していて、Linearに移りたい場合は、取り込みの機能を使えます。公式のドキュメントでは、Jira、GitHub Issues、Asana、Shortcutからの取り込みが案内されています。取り込みの細かな動きは元の道具によって違うので、それぞれの手順のページを読んでから進めます。

移る前に、今の道具に残っている古い課題を整理しておくと、移った後の一覧がすっきりします。何年も動いていない課題までそのまま移すと、無料プランの上限にもすぐ近づきます。

在宅のチームで課題管理の道具を使いこなす意味

最後に、在宅で働く人にとって、課題管理の道具を使いこなすことがどんな意味を持つかを考えます。

在宅や業務委託で仕事をする場合、依頼主とのやり取りの多くは文字で行われます。課題管理の道具を使えるかどうかは、そのまま仕事の進めやすさに直結します。依頼主が使っている道具にすぐ慣れ、Issueの題名と説明を分かりやすく書き、状態をこまめに動かせる人は、離れた場所にいても「進み具合が見える人」として信頼されます。

開発の仕事を在宅で受ける場合、Linearのような道具の使い方は前提の知識として求められることが増えています。どんな開発の仕事があるかは、アプリケーション開発のお仕事で仕事の種類と求められるスキルを確認できます。課題管理の道具の導入や使い方の定着を支援する仕事もあり、業務改善の相談を受ける仕事の全体像はAIコンサル・業務活用支援のお仕事で紹介しています。

20年この市場を見てきた立場から言えば、長く在宅で仕事を続けている人ほど、依頼主の道具に合わせて進み具合を見せることに手間を惜しみません。状況が見える人には、次の仕事も任されやすいからです。仲介を挟まずに依頼主と直接やり取りできる場では、同じ予算でも受け手の手取りが厚くなり、依頼主も同じ金額でより多くを頼めます。進み具合を見せる力は、その直接の取引で信頼を得る土台になります。

業務の流れそのものを見直す力を体系的に身につけたい人には、経営や業務改善の知識を幅広く扱う中小企業診断士の学習範囲が参考になります。チームの在宅勤務の環境を整える費用については、テレワーク 助成金 2026で使える制度を確認できます。

よくある質問

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

無料プランでは、メンバーの数は無制限で、チームは2つまで、Issueは250件まで、ファイルの添付は10MBまで使えます。Issue、Project、Cycleといった基本の機能は無料プランから使えます。日々の細かな仕事を全部登録すると数か月で上限に近づくので、試用の期間と考えて使い方を確かめるのが現実的です。

Q. Linearを使うのに最初に覚えることは何ですか？

まずIssue（仕事の単位）、Workflow（Issueの状態の並び）、Cycle（1〜2週間の計画の区切り）の3つです。ProjectやInitiativeは、仕事が増えて目的が見えにくくなってから使えば十分です。キーボードの「C」でIssueを作れることを覚えておくと、登録の手間が減ります。

Q. CycleとProjectはどう使い分ければよいですか？

Cycleは期間で区切る仕組みで、「今週から来週にかけて何に取り組むか」を決めるのに使います。Projectは成果で区切る仕組みで、「新しい画面の公開」のように複数のIssueにまたがる仕事をまとめるのに使います。1つのIssueが、あるProjectに属しながら、あるCycleに割り当てられることもあります。

Q. 開発以外のチームでもLinearは使えますか？

使えないわけではありませんが、Linearは開発のチームを主な対象にして作られており、公式のドキュメントも英語です。営業や制作など開発以外の仕事が中心で、ガントチャートやカレンダーで期間を見たい場合は、汎用のプロジェクト管理の道具も比べてから決めると失敗が少なくなります。