Linear実践ワークフロー完全ガイド — Issues・Cycles・Projects・Roadmapsの使い方と連携【2026年版】

Linearのワークフローは「Triage（受信）→ Backlog（優先順位付け）→ In Progress（作業中）→ In Review（レビュー中）→ Done（完了）」の5ステージで構成されます。新しいリクエストはまずTriageに入り、優先度評価後にBacklogへ移動。開発者がスプリント（Cycle）に取り込んだ段階でIn Progressとなり、PRレビューを経てDoneに到達します。この流れをLinearの各機能がどう支えるかを本記事で詳しく解説します。

IssueはLinearの作業の最小単位です。シンプルなタイトル入力だけでなく、豊富なメタデータで課題を構造化できます。

Sub-issuesを使うことで、大きなタスクを細かな作業単位に分解しながら親Issueで進捗を一目確認できます。

CyclesはLinearのスプリント機能です。1〜8週間の任意の期間で繰り返しサイクルを設定でき、チームの開発リズムを作ります。Cycleは手動作成のほか、自動生成設定（例：毎月曜日に新Cycle開始）も可能です。 キャパシティプランニング: 各IssueにStory Pointを設定することで、Cycle全体のキャパシティと消化量をリアルタイムで可視化できます。オーバーコミットを事前に防ぎ、チームのベロシティを安定させます。 自動繰り越し: Cycleが終了した時点で未完了のIssueは、次のCycleに自動的に繰り越されます（設定でオフ可）。手動で移動させる手間が不要で、何が積み残されているかが常に明確です。

Projectsは関連するIssuesを目的別にグルーピングする機能です。「v2.0リリース」「決済機能リニューアル」のような横断的なイニシアチブを管理するのに最適です。 主な機能: - マイルストーン: プロジェクト内のフェーズやリリース目標日を設定 - 進捗表示: 完了Issue数と全体数を自動集計してパーセンテージ表示 - プロジェクトオーナー: 責任者を明確にすることで説明責任が生まれる - ドキュメント: プロジェクトのPRD（要件定義書）やメモをProject内に紐付け - 複数チーム横断: エンジニアリングとデザインが同一Projectを共有して連携 一般的なスプリント（Cycle）がベロシティの追跡に最適な一方、Projectは「完成物」を目標とした中長期の管理に向いています。

Roadmaps（有料プラン）は複数のProjectsを時系列で可視化し、四半期・年間の戦略目標と日々の開発を接続します。

Roadmapsがあることでプロダクトマネージャーが経営陣に開発進捗を報告する際、LinearのURLを共有するだけで最新情報を届けられます。

LinearとGitHubのネイティブ連携は、開発フローの手動更新作業を大幅に削減します。 ブランチ命名規則: Issueページの「Copy Git Branch」ボタンで`<username>/<issue-id>-<title>`形式のブランチ名をコピー。このブランチ名を使うとLinearがPRと自動的にリンクします。 PR連動の自動ステータス変更:

コミットメッセージに`Fixes LINEAR-123`と記述するだけでIssueと紐付きます。手動でステータスを更新する作業が完全になくなります。

LinearのSlack統合でチームのコミュニケーションと作業管理を一体化できます。 できること: - Slackチャンネルに新規Issue・ステータス変更・コメントを自動通知 - Slackメッセージ上の「⋯」メニューから直接Issueを作成 - `@Linear`をメンションしてIssueの詳細をSlack内で確認 - 特定のラベル・優先度・チームに絞った通知フィルタリング 設定手順: Linear設定 → Integrations → Slack → チャンネルを選択 → 通知条件を設定。チームのSlackチャンネルにLinearボットを追加することで、スタンドアップで「おはようございます」とタイプする前にLinearを開く必要がなくなります。

Linear Methodは、Linearが公開している開発運営の哲学・実践原則集です（linear.app/method）。主な考え方は以下の通りです。 1. サイクル駆動の開発: 計画を立て、実行し、振り返る一定リズムを守ることで、チームのベロシティと予測可能性が向上します。 2. プロジェクトオーナーシップ: 各プロジェクトには1人の責任者を置き、委員会設計を避けます。オーナーが優先順位を決定することで意思決定が速くなります。 3. 書くことで考える: IssueやProjectのDescriptionを丁寧に書くことがチームの共通理解を生み出します。口頭で補完する必要のない自己説明的なIssueが理想です。 4. シンプルさを保つ: ツールの機能より「使われる機能」を重視。必要以上のカスタムフィールドやワークフローは認知負荷を高めるだけです。 Linear Methodを実践することで、ツールの使い方だけでなくチーム全体の開発文化が改善します。

Q1. CyclesとProjectsの違いは何ですか？ Cyclesは時間軸で区切られたスプリント（例：2週間の繰り返し）、Projectsは目的・成果物で区切られたグループ（例：認証機能v2）です。1つのProjectが複数のCycleにまたがることも一般的です。 Q2. Triageはいつ使うべきですか？ Slackやメールから入ってくる急ぎの依頼やバグ報告など、優先度が未評価のIssueを一時的に保管する場所として使います。週1回のTriageレビューセッションで整理するとBacklogが散らかりません。 Q3. チームが複数ある場合、Issueはどう管理しますか？ Issueは各チーム（Engineering・Designなど）に属しますが、ProjectやRoadmapで横断管理できます。チーム間の依存はIssueのRelationsで明示します。 Q4. GitHubのOrganization全体をLinearと連携できますか？ はい。Organization全体のリポジトリをLinearに接続することも、特定リポジトリのみに絞ることも可能です。 Q5. Cycleのベロシティはどこで確認できますか？ Cycles一覧画面に各Cycleの完了Issue数・完了ポイント・スコープ変化が表示されます。Insightsページではチーム全体のベロシティ推移をグラフで確認できます。 Q6. Roadmapsは無料プランで使えますか？ RoadmapsはStandard以上のプランが必要です（月額9ドル/人〜）。小規模チームはProjectsの進捗表示とCycleで代替できます。

LinearによるIssue管理・スプリント運営の基盤が整ったら、次はAIエージェントや自動化ツールとの連携で開発生産性をさらに引き上げることが可能です。Oflightでは、Linear導入設計からGitHub Actions・Slack・社内システムとの統合、チームへのトレーニングまでワンストップで支援しています。 AIコンサルティングサービスを見る