Contents
導入 — Linear ワークフローの概要と対象読者
Linear ワークフローの実務設計を、テンプレート、Cycle運用、Automationまで具体的に整理します。現場ですぐ使える手順と注意点を優先し、導入から運用・移行までカバーします。対象者はPM、エンジニア、導入担当（管理者）です。
対象読者
想定読者はプロダクトマネージャー、ソフトウェアエンジニア、SRE/導入担当者、そしてプロジェクト管理の管理者です。
導入のクイックスタート
短時間で実行に移せる主要アクションを示します。まずは小さなパイロットで検証してください。
- ワークスペース作成と導入オーナーの決定
- Feature/Bug/Hotfix/Spike のIssueテンプレート準備
- 1チームで1〜2サイクルのパイロット実行
- Git/CI/Slack連携と基本Automation（PR→State等）を設定
- レトロでテンプレート・Automationを調整して全社展開へ
非公式ガイドと公式参照
用語集と表記ルール
運用を始める前に用語と表記を統一すると、混乱や誤解を減らせます。ここでは英語／日本語表記の推奨を示します。チームの共通ルールとしてテンプレートに組み込んでください。
用語一覧と表記（推奨）
以下の表は推奨表記の一例です。社内で最終決定を行ってください。
| 用語（英） | 日本語表記 | 推奨表記（使い方） |
|---|---|---|
| Issue | イシュー / Issue | イシュー（Issue） |
| Cycle | サイクル / Cycle（スプリント） | サイクル（Cycle） |
| Project | プロジェクト / Project（エピック） | Project（プロジェクト） |
| Roadmap | ロードマップ / Roadmap | ロードマップ |
| Estimate | Estimate / 見積 | Estimate（SP） / 見積（SP） |
| State | State / ステート | State（Backlog / Ready / In Progress / Review / QA / Done） |
| Automation | Automation / 自動化 | Automation（自動化） |
| AI agents | AIエージェント | AIエージェント（人が最終確認） |
| PR | PR / プルリクエスト | PR（プルリクエスト） |
表記ルール（短く）
用語の一貫性を保つための基本ルールを示します。
- UI 表示は英語のままでも、ドキュメントでは日本語表記の横に英語を併記する。
- Issue 名は「PROJECT-123 短い説明」の形式を推奨する（Project名/Issue番号を明示）。
- State 名は簡潔に保つ（過度な細分化を避ける）。
初期設定：ワークスペース・チーム・権限・テンプレート作成
導入フェーズで設定ミスが後の手戻りを生みます。ここでは必須の初期設定と実務的な注意点をチェックリスト形式で示します。まずは小さなパイロットで運用を固めてください。
導入手順とチェックリスト
導入から最初のCycleまでに行う基本手順です。順番に進め、各項目はパイロットで検証してください。
- 導入オーナーとステークホルダーを決定する。各チーム代表をアサインする。
- ワークスペース作成とチーム構成を決める。命名規則を定める。
- 権限設計を行う（Owners / Admins / Members / Guests）。サービスアカウントの取り扱い定義を作る。
- SAML/SSO・SCIMの要件をセキュリティチームと確認し、テスト環境で検証する。
- Issueテンプレートを作成する（Feature / Bug / Hotfix / Spike）。
- 初期Automationを定義する（PR連携、ラベル→担当者割当、マージ時State遷移など）。
- Cycle長を決め、パイロットで1〜2サイクル試す（初回は短めを推奨）。
- GitHub/GitLab、CI、Slackなどの連携を設定する。サービスアカウントは最小権限で。
- 初期ダッシュボードとKPIウィジェットを作成してベースラインを取得する。
Issueテンプレート（Markdownサンプル）
下記は現場で使えるテンプレート例です。必要に応じてフィールドを追加してください。
Featureテンプレート（Markdown）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
# タイトル（短く） ## 概要 （短文で何をするか） ## ユーザーストーリー - 誰が：〜 - 何を：〜 - なぜ：〜 ## 受け入れ条件 - [ ] 条件1 - [ ] 条件2 ## 影響範囲／依存 - 依存項目や外部影響 ## Estimate - SP: 3 ## 設計リンク - ドキュメントURL |
Bugテンプレート（Markdown）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# タイトル（短く） ## 概要 （不具合の要点） ## 再現手順 1. 操作A 2. 操作B ## 期待される動作／実際の動作 - 期待： - 実際： ## Severity / Priority - Severity: High - Priority: P1 ## 環境・ログ - 環境情報、ログ抜粋 |
Hotfixテンプレート（Markdown）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# Hotfix: タイトル ## 影響範囲（緊急度） - 影響範囲の説明 ## 影響ユーザー数予測 - 推定数 ## ロールバック手順 - 手順を明記 ## 必須テスト - テスト1、テスト2 |
Spikeテンプレート（調査）（Markdown）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# Spike: タイトル（調査項目） ## 調査目的 - 目的を1行で ## 成果物 - 何をもって完了とするか（結論/設計/プロトタイプ） ## 期限・担当 - 期限 - 担当者 |
権限設計とSSO/SCIMの実務注意点
SSO/SCIM の導入はセキュリティと運用に直結します。実務での注意点を挙げます。
- SAML の属性マッピング（email, user_id）やグループ同期を事前確認する。
- SCIM はユーザーのプロビジョニング／デプロビジョニングに強力だが、フィールドマッピングの誤設定で権限漏れが起きる。まずはサンドボックスで検証する。
- 自動プロビジョニングは段階的に有効化する。最初は手動連携〜部分同期で動作確認を行う。
- サービスアカウントは最小権限、キーの定期ローテーション、用途の記録を行う。
実務ワークフロー：新機能開発とバグ／Hotfix対応
ここでは企画からリリースまでの標準フローと、緊急対応の最短フローを整理します。各ステップで何をテンプレ化するかを明確にすると運用が安定します。
新機能開発のフルパス（典型的な流れ）
新機能を企画からリリースする一般的な流れを示します。各項目はテンプレート化・Automation化を検討してください。
- 要望をIssue化（テンプレートに従う）。
- バックログトリアージで優先度を決定（RICE等を参考）。
- Groomingで分割・不確実性をSpikeで解消。
- Cycle計画でIssueを選定しSprint Goalを定める。
- ブランチ命名規則とPRテンプレートで紐付けを徹底する。
- CI/PR連携で自動テスト・ステータス更新を行う。
- レビュー／QAで品質担保、ステージングで検証。
- リリースはタグ・自動リリースノートで管理し、Roadmapを更新する。
- ポストリリースで監視・フォローアップIssueを作成する。
バグ対応／Hotfixワークフロー（緊急対応）
緊急バグ対応は速度と安全性の両立が必要です。事前準備が鍵になります。
- 優先度はSeverity（技術）とPriority（ビジネス）を分離して記録する。
- Hotfixラベルと専用短縮フローを用意しておく。
- 最短手順：Hotfix Issue作成 → hotfixブランチ作成 → 最小差分でPR → 迅速レビューとマージ → デプロイ。
- ロールバック・テストはIssueに明記する。ロールバック手順は定期演習で検証する。
- 通知は専用Slackチャンネルへ自動連携する。
Cycle運用（目標・見積・レビュー・レトロ）
Cycleの設計は継続的改善の基盤です。短いフィードバックループを重視してください。
- 各Cycleに1つの明確なGoalを設定する。
- 見積は相対見積（SP）でチーム基準を合わせる。
- キャパシティは各メンバーの稼働日数で算出し、余裕を残して割り当てる。
- WIP制御で同時着手を制限する。
- Cycle終了直後にデモとレトロを実施し、改善アクションをIssue化する。
Projects／Roadmap と OKR の紐付け
Projects は中長期の機能群を管理する主要コンテナです。OKRと紐づける方法を示します。
- 各Projectに責任者（オーナー）を置く。KRとの紐付けを明示する。
- RoadmapではマイルストーンとKR達成の関係を示す。
- Project間の依存は明文化して優先度調整に利用する。
- エピック（大きな機能）はProjectで管理し、Cycleで細分化して実行する。
連携・自動化・AI活用とセキュリティ
Automation と AI の活用は工数削減に有効ですが、設計とガバナンスが重要です。ここにAutomation例、AI運用ルール、セキュリティ指針を集中して示します。
主要連携（GitHub/GitLab/Slack等）のベストプラクティス
連携はトレーサビリティとノイズ管理の両立が重要です。
- PR／コミットにIssue IDを含めて自動紐付けを有効にする。
- CI/CDでデプロイ成功をIssueに反映するAutomationを設定する。
- Slackは用途別チャンネルで通知を分離し、重要度でフィルタする。
- Sentry/Zendesk連携で課題の自動Issue生成を検討する。
- サービスアカウントは最小権限にし、OAuthスコープを限定する。
Automation と AI の集中運用（実務例と考え方）
Automation と AI の運用は一か所でルール化すると管理しやすくなります。ここでは実務で使える例と設計上の注意点を示します。
- 自動化の例（概念）
- PR作成 → 関連Issueを「In Review」に移動する。
- マージ → Issueを「Done」にする、リリースノート用にタグ付けする。
- ラベル付与 → 担当者自動割当を行う。
-
定期タスク（権限レビュー等） → 定期Issueを自動生成する。
-
AI の実用例（用途）
- 長いIssueスレッドやPRの要約生成（人が必ずレビュー）。
- 会議メモからのIssueドラフト作成。
-
関連Issueの候補提示や重複検出支援。
-
運用ルール（最低限）
- AI が生成した内容は必ず人が検証する。
- Automation の実行ログは保存し、監査できる状態にする。
- トリガー名やUIは変更されるため、具体的な設定は公式ドキュメントで確認する。
次に概念的なAutomationスニペット（擬似YAML）を示します。実際のUIやAPIとは異なる場合があります。
|
1 2 3 4 5 6 7 8 9 10 |
# 擬似例（概念） trigger: pull_request.opened condition: branch: feature/* actions: - update_issue: state: In Progress - add_comment: body: "PRが作成されました。レビューを開始してください。" |
AIガバナンスと禁止データの具体例
AI利用で漏洩リスクを避けるため、具体的に送信を禁止するデータを定めます。例外が必要な場合は承認フローを設けてください。
- 禁止データの例（送信禁止）
- 個人を特定できる情報（PII）：氏名＋メール、電話番号、住所等
- 認証情報：パスワード、APIキー、シークレット、トークン
- 顧客の個人データ、財務情報、医療情報（PHI）
-
機密契約、法律相談内容、社内機密情報
-
ログ保存方針（例）
- Automation/AIの実行ログは中央ログに保管し、アクセスを制限する。
- 保有期間は方針で定める（例：90日を目安にレビューし削除／アーカイブ）。
-
ログに生データが残る場合は匿名化／マスキングを行う。
-
アクセス制御案（例）
- 最小権限の原則でRBACを設定する。
- AI出力を承認するロール（レビュアー）を定義する。
- サービスアカウントは用途ごとに分け、キーのローテーションを実施する。
移行チェックリストとスケール時の設計
既存ツール（例：Jira）からLinearへ移行する際は段階的な検証とマッピングが重要です。ここに高レベルの手順とマッピング例を示します。
移行の高レベル手順
移行は一括ではなく段階的に行うとリスクが低くなります。
- 現行システムのインベントリ作成（Issue数、Projects、ラベル、カスタムフィールド）。
- マッピング定義（ステータス→State、Issue type→ラベル等）を作成する。
- サンプルエクスポートでパイロット移行を実施し検証する。
- 本番移行時はルールを決め、移行期間中の並行運用や作業フリーズの方針を定める。
- 移行後に履歴、コメント、添付、依存の整合性を検証する。
マッピング例（簡易）
| 旧ツール | Linear の取り扱い |
|---|---|
| Jira Epic | Linear Project |
| Jira Story/Task | Linear Issue |
| Jira Bug | Linear Issue + Bugラベル |
| Jira Status（To Do/In Progress/Done） | Backlog / In Progress / Done（要調整） |
スケール時の権限設計と運用マイルストーン
組織が拡大する際の基本設計を示します。
- Team 単位で Project を分離し、横断Roadmapで調整する。
- 役割は Project 管理者、Cycle オーナー、テンプレート編集者に分ける。
- レビュー権限は分離し、重要操作は複数承認を検討する。
- 導入初期は1チームパイロット、段階的に範囲を広げる。
導入ロードマップ（初期〜3ヶ月の例）
初期展開のスケジュール例です。各社の事情で調整してください。
- Week0-1：ワークスペース定義、テンプレート作成、初期Automation、連携設定、パイロット開始。
- Week2-4：初Cycleの実行とレトロ、KPIベースライン取得、Automationの微調整。
- Month2-3：バックログ本格移行、Roadmap整備、権限調整、運用ドキュメント完成。
実例（効果の例）と成功／失敗ケース
ここでは簡潔な数値例を参考として示します。実際の効果はチーム規模・成熟度・自動化範囲によって変わります。
導入効果の例（数値イメージ）
| 指標 | 導入前（例） | 導入後（例） | 備考 |
|---|---|---|---|
| PR Lead Time | 5日 | 3日（約40%短縮） | PR→Issue自動遷移とテンプレ改善の効果例 |
| 手動ステータス更新数（/月） | 200 | 80（約60%削減） | Automationによる自動更新の効果例 |
| Cycle 完了Estimate誤差 | ±40% | ±20% | 見積ガイドラインとレトロの改善例 |
これらはあくまで事例例示です。導入効果を測る際はKPIの定義とベースライン取得を必ず行ってください。
よくある失敗と回避策（短い事例）
- 失敗例：一斉移行でマッピング不備が発覚し、大量の手戻りが発生。
- 回避策：パイロット移行と段階展開を行う。
- 失敗例：State を細分化しすぎて運用が煩雑化。
- 回避策：最小限のStateで開始し、必要に応じて段階的に増やす。
- 成功例：1チームで6週間のパイロットを実施しテンプレートを改善。全社展開で摩擦を軽減。
よくある課題とFAQ
導入・運用で頻出する質問を短く整理します。問題発生時にまずここを確認してください。
SSO/SCIM が連携されない場合
考えられる原因と初動対応を示します。
- 原因例：属性マッピングの不一致、SCIMトークンの権限不足。
- 対応：セキュリティチームと属性マッピングを照合し、テストユーザーで再検証する。ログを取得してエラーを解析する。
Automation が期待どおり動かない場合
チェックポイントを短く示します。
- トリガー条件（ブランチ名やラベル）が正しいか確認する。
- サービスアカウントに必要な権限があるか確認する。
- 実行ログを確認し、失敗ステップを特定する。
AI に送ってよい情報・ダメな情報は？
運用ルールの例を示します。
- ダメ：PII、認証情報、顧客の個別データ、財務/医療情報、機密契約。
- よい：公開仕様、一般的な技術説明、要約やテンプレート作成（ただし人が必ず確認）。
移行で履歴や添付が欠落したとき
移行後検証のポイントを示します。
- まずはサンプルIssueでコメント・添付・依存関係が維持されているか確認する。
- 欠落があればマッピング設定を見直し、部分移行→検証のサイクルを回す。
参考リソース
設定やAPI仕様は公式ドキュメントで常に最新確認してください。以下は導入検討で参考になる主要リソースです。
- Linear 公式ドキュメント: https://docs.linear.app/
- Linear 開発者向けドキュメント（API等）: https://developers.linear.app/
- 導入事例・実務ガイド（参考）: https://www.oflight.co.jp/ja/columns/linear-workflow-cycles-projects-guide-2026
- 導入技術ブログ（参考）: https://techblog.technology-doctor.com/entry/2025/04/04/161159
まとめ
導入を成功させるための要点を短く整理します。まずは小さなパイロットで検証し、テンプレートとAutomationを限定して始めてください。
- 用語と表記を先に統一して運用のブレを減らす。
- 初期はテンプレートと基本Automationに集中し、1〜2サイクルで微調整する。
- SSO/SCIM などはセキュリティチームと協力し、テスト環境で検証する。
- AI は効率化に有効だが、機密情報を送らないルールと監査ログを必須にする。
以上を基に、各チームの実情に合わせてテンプレートとAutomationを段階的に拡張してください。