Contents
Linearの概要と主要概念（使い方の基本）
ここではLinearのコア概念と主要用語を実務目線で整理します。操作やプラン差は設定依存なので、重要箇所は公式ドキュメントを併せて確認してください。
主要概念（Issue／Project／Cycle等）
以下は実務で頻出する最小限の概念です。各項目はチームルールで厳格に定義してください。
- Issue（課題）：単一のタスク。タイトル、本文、担当者、Estimate、Label等を持ちます。
- Project（プロジェクト）：機能や大きな取り組みをまとめるコンテナです。
- Cycle（サイクル）：スプリント単位の期間枠。計画→実行→レビューを回します。
- Workflow（ワークフロー）：State（状態）とトランジションで定義するIssueの流れです。
- State（ステータス）：Backlog、Ready、In Progress、Review、Done等。
- Team（チーム）：担当範囲と通知の単位になります。
設定依存の注意（SSO/SCIM・Linear AI・連携挙動）
ここで紹介する機能の一部はプランや環境設定で挙動が変わります。設定変更はテスト環境で検証してください。
- SSO／SCIM：利用可否や設定項目はプラン依存です。設定前にプラン表と公式ドキュメントを確認してください（公式 docs: https://linear.app/docs、料金: https://linear.app/pricing）。
- Linear AI：機能の可否やデータ取扱は組織設定に依存します。AI導入前にプライバシーポリシーとドキュメントを必ず確認してください。
- Git/Slack連携の自動トランジション：PR作成やマージでの自動遷移は、統合設定やリポジトリの権限に依存します。動作検証を推奨します。
用語集（表記ルール）
以下は本記事での表記ルールです。英語・日本語を併記します。
| 表記（英） | 表記（日本語） | 備考 |
|---|---|---|
| Issue | Issue／課題 | そのまま「Issue」を使い、括弧で日本語表記を併記します |
| Project | Project／プロジェクト | 同上 |
| Cycle | Cycle／サイクル | 同上 |
| Workflow | Workflow／ワークフロー | 同上 |
| State | State／ステータス | 同上 |
| Estimate | Estimate（見積り） | チーム定義を必須化。例：ストーリーポイント or 時間 |
| Story point | ストーリーポイント | 見積りを相対評価で行う場合の単位 |
| Owner / Admin / Member | オーナー／管理者／メンバー | 役割は統一して使うことを推奨 |
初期セットアップと権限設計（実操作ガイド）
ワークスペースの初期化は運用安定性に直結します。ここでは手順をUI操作に即した形で示します。
アカウント作成とワークスペース初期設定（UI手順）
まずはアカウントとワークスペースを作ります。UIは更新されるため、メニューが見つからない場合は画面内検索を使ってください。
- ブラウザで https://linear.app を開き、「Sign up / Get started」をクリックします。
- サイン方法を選択（Google / GitHub / Email / SSO）。組織でSSOを使うなら最初から認証方法を統一します。
- Workspace名を入力してワークスペースを作成します。
- 初回管理者（Owner）アカウントを1名に設定します。権限管理は後で細かく設定できます。
メンバー招待とロール設計（実務ルール）
招待前にロール設計を決めます。権限は最小限の原則で与えてください。
- Workspace内の「Settings（設定）」→「Members（メンバー）」を開きます。
- 「Invite members（メンバー招待）」を選び、メールまたはSSOグループで招待します。
- 役割を割り当てます（例：Owner＝ガバナンス、Admin＝設定管理、Member＝通常運用）。
- 招待ポリシーをドキュメント化します（例：SSOユーザ優先、外部アカウントはゲスト扱いなど）。
SSO／SCIMの設定とテスト（設定依存・公式参照）
SSO／SCIMは事前準備とテストが必須です。必ずテストアカウントで検証してください。
- まずプランで利用可否を確認します（https://linear.app/pricing）。
- Settings→Security または Integrations→SSO の画面でSAML設定を開始します。IdPのメタデータを投入し、属性マッピング（email 等）を設定します。
- SCIMを使う場合、プロビジョニングのトークンを発行し、IdP側に設定します。
- テスト：テストユーザーでログインできるか確認します。ユーザーの作成・削除・属性同期が期待通りか確認します。
- 問題があればログを取得し、IdPのサポートと連携して調査します。公式ドキュメントを参照してください（https://linear.app/docs）。
Issue管理とワークフロー（実操作手順とガイドライン）
Issue品質とワークフローは生産性に直結します。ここではUI操作を含む実務的な手順を示します。
Issue作成のUI手順（即時実行できる操作）
Issueを作る作業を実際に行う流れです。キーボードショートカットは環境差があるため画面のショートカット一覧も確認してください。
- 画面の「New issue」または「＋」ボタンをクリックします。
- タイトルを入力します。短く要点を含めます。
- 本文に目的、期待される結果、再現手順（バグ）、参照URL（Figma/Notion/PR）を記載します。
- Team／Project／Cycleを割り当てます。未定の場合はUnassignedを明示します。
- Estimate（見積り）とPriority（優先度）、Labelを設定します。
- 保存してIssueを作成します。必要な場合はコメントやリンクを追加します。
キーボード操作例：コマンドパレット（Cmd/Ctrl+K）で「Create issue」や「New issue」を選択できます。ショートカットは画面から確認してください。
ワークフローとトランジション設定（UI手順）
Workflowはシンプルを維持します。誰がどの状態に移せるかを明確にします。
- Settings→Workflow（ワークフロー）を開きます。
- 対象Teamを選択し、State（ステータス）を定義します。例：Backlog → Ready → In Progress → Review → Done。
- 各Stateの説明（Definition）を記載します。Readyの定義は厳格にします（受け入れ基準・Estimate済み・依存解消）。
- トランジション権限を設定します（例：レビュー完了はReviewerがClose可）。
- 必要ならWIP制限を設定します。
ワークフロー変更は管理者のみで行い、変更前にテストCycleで確認することを推奨します。
ビューと保存フィルタの作成（Board／List／Roadmap）
保存ビューを活用して日常運用を効率化します。以下は作成手順です。
- 適切なView（Board / List / Roadmap）を開きます。
- フィルタ（Team、State、Label、Assignee、Cycleなど）を設定します。
- 「Save view」または「Save as」を選んで名前を付けます（例：My Open Issues、Current Cycle）。
- チーム共有が必要なら共有オプションを設定します。
- Boardでは列をStateに合わせて配置し、ドラッグでIssueを移動します。
保存ビューは日次チェックやレトロ向けダッシュボードに組み込みます。
Cycleとプロジェクト運用（計画〜レビューとKPI）
Cycleは計画から改善まで回す単位です。ここでは計画手順とKPIの計測方法を具体的に示します。
Cycle運用のステップ（計画→実行→レビュー）
Cycleの一連の運用です。各ステップを短く記述します。
- プランニング：Cycle期間を決め、候補IssueをPullします。Estimate合計を算出します。
- キャパシティ計算：チーム人数と過去ベロシティを使い現実的に詰めます。例：チーム4人、平均ポイント/人＝8 → キャパ = 32pt。
- 割り当てと分割：必要ならIssueを子Issueに分割し粒度を揃えます。
- 実行：デイリースタンドでCycleビューを確認しブロックを可視化します。
- レビューとクロージング：デモで成果確認。未完は再トリアージ。
- レトロ：改善アクションをIssue化して次Cycleへ反映します。
見積り・進捗管理と実務上の操作
見積りはチーム合意で統一します。進捗はCycleビューで日次に確認します。
- 見積りはストーリーポイント（相対）か時間のいずれかをチームで決めます。
- Cycle内の進捗は「Estimateの合算」や「完了したEstimate割合」で見ると安定します。
- さらに分析が必要な場合はCSVエクスポートかAPIでデータを取得します。
KPIの定義と計測方法（具体例と目標値の目安）
KPIは測定方法を定義してから追います。ここは具体的な計測式と目安の例です。
- 完了率（計画対実績）
- 計算式例：完了したEstimate合計 ÷ 計画したEstimate合計 × 100
-
目安：70〜90%（チーム成熟度に応じて調整）
-
Cycleベロシティ（Estimate合計）
- 測定：直近3〜6Cycleの平均を算出しトレンドを確認
-
目安：安定性（CV=標準偏差/平均）を20%未満にすることを目標に調整
-
平均解決時間（MTTR）／リードタイム
- リードタイム例（hours）：AVG(closed_at − created_at)
- MTTR：インシデントラベル付きIssueの平均解決時間を測定。P1は組織方針で目標を設定（例：応答30分、解決数時間）
- SQLサンプル（CSVエクスポート後の汎用例）：
SELECT AVG(TIMESTAMP_DIFF(closed_at, created_at, HOUR)) AS avg_lead_hours
FROM issues
WHERE state = 'Done' AND created_at >= '2026-01-01';
- PRレビュー時間
- 計測方法：PR作成〜マージ時間の中央値を算出。目安：24〜72時間以内を目指す（チームにより異なる）。
注意：上記クエリはデータのスキーマに依存します。LinearのAPI/GraphQLを使う場合は公式APIドキュメントを参照してください（https://linear.app/docs）。
連携と自動化（Slack・Git・Linear AI）
連携は効率化に有効ですが、誤設定でノイズや誤作動が発生します。設定前に通知ポリシーを設計してください。
Slack連携の設定手順と通知設計（実操作）
Slack連携の基本的な設定とテスト方法です。実際のボタン名はUIで変わる可能性があります。
- Settings→Integrations→Slack を開きます。
- 「Connect」または「Install Slack app」をクリックしてSlackワークスペースを認可します。
- 通知を送るチャンネルを選択し、送信するイベントを選びます（例：Issue created, State changed）。
- テスト：Slack上でメッセージのアクションやSlashコマンドでIssueを作成し、Linear側に反映されるか確認します。
- ノイズ対策：P1のみ即時通知、低優先は日次まとめのように分けます。
GitHub/GitLab連携の設定と自動トランジションのテスト（実操作）
Git連携での一般的なセットアップと検証手順です。自動遷移はIntegrationの設定に依存します。
- Settings→Integrations→GitHub/GitLab を開きます。
- 「Install Linear app on GitHub」や「Connect」ボタンを押し、組織／リポジトリを選びます。必要な権限を与えます。
- マッピング設定で「PR作成時にIssueをIn Reviewへ移行」「マージ時にIssueをDoneにする」等のルールを設定します。
- テスト手順：テストIssueを作成 → ブランチを切る（例：feature/ISSUE-123-xxx） → PRを作成しIssueのURLを説明欄に記載 → PR作成・マージでIssueが期待通り遷移するか確認します。
- 問題があればWebhookの配信ログと権限を確認してください。挙動は設定と権限に依存します。
※注意：Issue参照の書き方や自動遷移のトリガーは設定により異なります。設定依存のため、公式ドキュメントと統合画面の説明を確認してください。
Linear AIの活用とデータ取り扱いルール（禁止情報と監査）
Linear AIは補助的な機能です。提案は人が検証してください。AIに投入してはいけない情報を明確に定めます。
- AIに投入してはならない情報（例）
- APIキー、パスワードなどの機密情報
- 顧客の個人識別情報（PII）：氏名＋識別子、クレジットカード情報、健康情報等
- 法務上の機密文書や裁判資料
- 運用ルール例
- AI提案はDraftタグを付け、必ず人がレビューしてから採用する。
- AI利用ログや提案の採否を記録し、監査可能とする。
- AI機能の有効化は管理者に限定する。
- 監査とログ
- AIイベントや提案のログは定期的に確認します。監査ログ機能やエクスポートはプラン依存のため、該当機能の有無を公式ドキュメントで確認してください。
公式ドキュメントも合わせて確認してください（https://linear.app/docs）。
テンプレート・移行・運用チェックリスト（テンプレート集と移行手順）
テンプレートは一か所で管理すると運用が安定します。移行は段階的に行い、リスクを低減させます。以下は統合された実務テンプレートと移行手順です。
移行手順（Jira／Trello等からの移行、実操作）
移行はテスト→本番の2段階で行います。具体的な手順とチェックポイントです。
- 現行ツールからエクスポート（CSV／JSON）を取得します。添付や履歴は別途エクスポートを検討します。
- フィールドマッピングを作成します。例：summary→title、description→body、labels→labels、assignee→assignee。
- サンプルインポートを実行（目安：100件または全体の5%）。ユーザーID・ラベル・リンクの整合性を確認します。
- 添付ファイルは外部ストレージ（S3等）に一括保存し、Issue内は参照リンクに置き換える運用を推奨します。
- 本番インポート後は一定期間（推奨：14日〜30日）を並行運用期間とし、問題発生時に旧ツールへロールバックできるようにします。
- 移行後チェック：インポート件数の一致、ランダム抽出で50件前後の詳細確認、ユーザーマッピング漏れの再確認。
主な失敗パターンと対処例
- 添付が欠落：添付を一括保存しリンクで参照させる。欠落分は旧ツールからダウンロードして復旧。
- ユーザーマッピング漏れ：未割当ユーザーを一時的に"imported_user_placeholder"にして手動で割当。
- コメント履歴未移管：重要コメントはエクスポートしてNotion等に保存し、Issueにリンクを添付。
テンプレート共通事項（全テンプレに共通の必須項目）
テンプレートの共通ルールを先に定義します。これにより重複を避けます。
- 共通必須フィールド：タイトル、目的／要約、担当者、Estimate、Priority、Labels、受け入れ基準（DoD）
- ラベル命名規則：team-、type-、priority- のプレフィックスを使用することを推奨
- タイトルフォーマット：先頭にタイプを表すプレフィックスを入れる（例：[Bug]、[Feature]）
- トリアージ手順：Untriaged→週次トリアージでLabel・Estimateを割当
バグ（Bug）テンプレート
バグ報告用のテンプレートです。必須項目を埋めてもらう運用にします。
- タイトル（例）：[Bug] 短い要約
- 説明：再現手順／期待される挙動／実際の挙動
- 環境情報：ブラウザ・OS・バージョン等
- ログ／エラーメッセージ（URL or paste）
- 影響範囲（ユーザ数や機能）
- 優先度（P1/P2/P3）とEstimate（暫定）
機能（Feature）テンプレート
機能追加用のテンプレートです。受け入れ基準を明確にします。
- タイトル（例）：[Feature] 機能名／目的
- 概要・背景：誰にとって何を解決するかを明示する
- ユーザーストーリー：As a ... I want ... so that ...形式推奨
- 受け入れ条件（DoD）：動作確認項目／テスト項目／ドキュメント更新
- Labels／Estimate／関連Design／SpecのURL
調査（Spike）テンプレート
技術調査やリスク調査用です。アウトプットを明確に。
- タイトル（例）：[Spike] 調査テーマ
- ゴール：調査の目的と成功基準を具体化する
- 期限：調査完了予定日
- 出力物：設計ドキュメント、推奨実装案、課題一覧
- Estimate（例：2日／3ポイント）
インシデント（Incident）テンプレート
オンコールや障害対応向けテンプレートです。時系列で追える形式にします。
- タイトル（例）：[Incident] 概要（短く）
- 発生日時／検知方法：UTC等で統一表記
- 影響範囲：ユーザ影響の程度と対象範囲
- 一次対応：対応者と実施アクション
- 恒久対策案：次のアクションと担当
- ポストモーテム：原因、対策、再発防止策、担当、期限
初期導入チェックリストとトラブル対処フロー
導入直後の確認項目と代表的トラブルの対処手順です。
- 初期チェック（実操作）
- Ownerの設定、Adminの割当を確認する。
- TeamとWorkflowが最小構成で定義されているか確認する。
- テンプレート（Bug/Feature/Spike/Incident）を各Teamへ配布する。
- Slack/Git連携をテスト用チャンネル・リポジトリで検証する。
-
1Cycleの試運転を実施しKPIを初回収集する。
-
代表的トラブルと対処
- 同期エラー：連携の再認証 → Webhook配信ログ確認 → 必要な権限付与。
- 権限不足：該当ユーザーのロール確認 → 権限付与ログを監査。
- 通知過多：通知種別のフィルタリング→チャンネル設計の見直し。
-
重複Issue：検索で重複を特定 → マージまたはクローズ運用を明文化。
-
監査ログ確認手順（プラン依存）
- Settings→Audit logs（監査ログ）を開き、対象アクション／ユーザー／期間でフィルタする。
- 必要ならCSVでエクスポートして分析する。監査ログの有無・機能はプランに依存します。
まとめ
最初に権限とテンプレートを定め、まずは1サイクルで運用テストを行うことが成功の鍵です。
SlackやGitの連携は通知ポリシーを先に設計してから接続してください。
移行は必ずテストインポートと並行運用期間（推奨14〜30日）を設け、添付・履歴は別管理でリスクを下げてください。
主要アクション（短期）
- 最低限のWorkflowとテンプレートを作成し、チームに周知する。
- Slack/Git連携を1チャンネル・1リポジトリで接続してテストする。
- 1Cycleを試運転し、KPIを計測してレトロで改善をIssue化する。
公式ドキュメント参照（必須確認）
- Linear Docs: https://linear.app/docs
- Linear Pricing: https://linear.app/pricing
（操作や連携の詳しい挙動は設定やプランに依存します。実運用では必ず公式ドキュメントの該当ページを確認し、テスト環境で検証してください。）