Jiraの呪縛から解放されろ：Linear移行の完全戦略とベロシティを極限まで高める実践ガイド
テックリードの皆さん、日々のスプリントレビューで「チケットを更新するのに何クリック必要なんだ？」「Jiraが重くて思考が途切れる」と感じていないか？
Jiraは多機能ゆえの「重厚長大化」が進み、エンジニアのフロー状態を奪う最大のボトルネックになりつつある。キーボードから手を離さず、ミリ秒単位でタスクが流れるように動く次世代の課題管理ツール 「Linear」 への移行は、単なるツールの乗り換えではない。チームのベロシティを限界突破させるための構造改革だ。
本稿では、Jiraの負債（数千件の課題、複雑なカスタムフィールド、散逸したコメントや添付ファイル）を完全にクリーンアップしつつ、Linearへ無傷で移行する手順と、移行したその日からチームの生産性を2倍にするための「プロの設定術」を余すところなく伝授する。
—
1. 移行の全体像と直面する「3つの壁」
JiraからLinearへの移行は、公式インポーター（CSVまたはJira連携アプリ）のおかげで物理的には数分で終わる。しかし、「そのまま移すだけ」では絶対に失敗する。
移行プロジェクトにおいてチームが直面する壁は以下の3つだ。
1. ステータスとワークフローの乖離（Jiraの複雑すぎるサブステータスの迷宮）
2. カスタムフィールドの爆発（使われていないゴミフィールドの混入）
3. リンク切れとメンションのロスト（コメント内の旧IDやメンションの不整合）
これらを事前に防ぐための移行戦略を順に見ていこう。
—
2. 移行手順：JiraからLinearへの「無痛」インポート
移行の基本方針はシンプルだ。「過去の遺産をそのままゴミ屋敷に持ち込まない」。
Step A: Jira側の棚卸し（Pre-Migration Cleanup）
移行ボタンを押す前に、Jira側で最低限のデトックスを行う。
- 完了（Done）かつ6ヶ月以上前の課題はインポート対象外にする（アーカイブとしてJira側で凍結）。
- 冗長なカスタムフィールドは削除、または単一の「Description（詳細）」にマージする。
Step B: 公式インポーターの実行
LinearはJiraからの直接インポート機能を提供している。
1. `Settings` > `Workspace` > `Imports` から Jira を選択。
2. Jiraの管理者アカウントで認証し、対象のプロジェクトを指定。
3. マッピングの肝：
- Jiraの `Epic` は Linearの `Initiative` または `Project` へ。
- Jiraの `Story / Task / Bug` は LinearのそのままのIssueタイプへ。
- ステータス（States）の再定義： Jiraの「In QA」「Code Review」「Ready for Deploy」といった細かすぎるステータスを、Linearでは「Todo」「In Progress」「In Review」「Done」の4〜5個の基本ステータスに集約する。アジャイルにおいて細かすぎるステータスは無駄なメンテコストを生むだけだ。
—
3. 現場で震えるほど役立つ！Linearの真価を引き出す設定・ハック
移行が無事に完了したら、ここからが本番だ。チームメンバーが「もうJiraには戻れない」と狂喜乱舞する環境を構築する。
A. 開発スピードを劇的に高める神キーボードショートカット
Linearの最大の武器は「マウスを握らせない」UI設計にある。全員に叩き込むべきショートカットはこれだ。
| ショートカット | 動作 | テックリードの解説 |
| :— | :— | :— |
| `C` | 新規Issue作成 | どこにいても即座に思考をタスク化できる |
| `G` + `I` | インボックス（通知）へ移動 | 朝会前のメンション確認が1秒で終わる |
| `Cmd + K` (Ctrl + K) | コマンドパレット | 全操作・検索のハブ。これさえあれば迷わない |
| `P` | 担当者（Assignee）の割り当て | リスト表示でカーソルを合わせた状態で一撃変更 |
| `S` | ステータス変更 | モーダルを開かずにインラインで変更可能 |
B. 絶対に入れるべき「神インテグレーション（プラグイン）」
Linearのポテンシャルを最大化する公式/サードパーティ連携：
1. GitHub / GitLab連携（必須）
- PRのタイトルやブランチ名に `ENG-123` のようにLinearのIssue IDを含めるだけで、PRのオープン・レビュー・マージに連動してLinearのステータスが勝手に変わる。手動でのステータス更新という「エンジニアにとって最も生産性の低い作業」を完全に根絶する。
2. Slack連携
- `/linear [タイトル]` でSlackから直接Issueを作成。また、特定のプロジェクトやラベルの変更をチームのチャンネルに流し、情報のサイロ化を防ぐ。
3. Figma連携
- デザインファイルから直接LinearのIssueを作成・リンク。プロダクトマネージャー（PM）とデザイナー、エンジニア間のコンテキストのズレを消し去る。
C. チーム開発で役立つ設定の共有化ルール（ワークスペース規約）
野放図に使うとすぐにカオスになる。最低限、以下のルールをワークスペース全体で強制せよ。
- ラベル（Labels）の体系化：
色とプレフィックスで視認性を爆上げする。
- `backend` (青), `frontend` (緑), `infra` (オレンジ), `tech-debt` (赤)
- Triage（トリアージ）機能の有効化：
外部からの起票や雑多なタスクは一度「Triage」に入り、プロダクトオーナー（PO）やテックリードが仕分けてからスプリントやバックログに組み込む。バックログがゴミ溜めになるのを防ぐ防壁となる。
—
4. すぐに使える！Linearワークフロー定義・自動化設定のベストプラクティス
Linear自体はJSON/YAMLによる直接ファイル設定よりもUI上の設定が強力だが、チームとしての運用ルール（Workflow、Cycles、Estimates）をコード（Markdown/YAML）としてリポジトリ（例: `.github/` や `docs/`）で管理し、チームの共通認識とするためのベストプラクティス構成例を提示する。
以下は、チームのオンボーディングやプロジェクトの定義書としてリポジトリに配置する `linear-workflow-standard.yml` の例だ。
=====================================================================
Linear Workflow & Governance Standard for Engineering Team
=====================================================================
version: “1.2.0”
description: “Linear運用ガイドライン：ベロシティ最大化のためのチーム規約”
1. サイクル（スプリント）設定
cycles:
duration_weeks: 2
start_day: “Monday”
auto_archive: true
naming_convention: “Sprint {YYYY}.{WW}” # 例: Sprint 2023.42
2. ステータス定義と厳守事項
workflows:
- state: “Backlog”
type: “backlog”
description: “将来的にやる可能性のあるタスク。優先度未確定。”
- state: “Todo”
type: “unstarted”
description: “次のサイクル、または現在進行中のサイクルで着手するタスク。”
- state: “In Progress”
type: “started”
description: “現在コードを書いている状態。原則として1人同時進行は2件まで。”
- state: “In Review”
type: “started”
description: “PR作成済み、レビュー待ち。CIが通っていることが前提。”
- state: “Done”
type: “completed”
description: “Main/Masterブランチにマージされ、検証環境等にデプロイ完了した状態。”
- state: “Canceled”
type: “canceled”
description: “スコープ外となったもの。理由はコメントに残すこと。”
3. ギット連携・自動化ルール (Automation)
automation:
# PR作成時の挙動
pull_request:
link_issue_required: true # ブランチ名またはPRにIssue IDが必須
move_to_in_review_on_pr_open: true
move_to_done_on_pr_merge: true
# 放置されたIssueへの対策
stale_issues:
warn_after_days_in_progress: 5
action: “notify_assignee_and_lead”
4. 估算（Estimation）ポリシー
estimation:
method: “Fibonacci” # 1, 2, 3, 5, 8, 13
policy: “ベロシティ計測のため、ストーリーポイントは必ず見積もる。迷ったら上のサイズを選ぶ。”
—
5. 移行後のチーム浸透：エンジニアの「慣れ」を最速で突破するコツ
新しいツールを入れただけでは、エンジニアは最初は戸惑う。移行後最初の2週間でチームを完全にLinearネイティブにするための処方箋を授ける。
1. 「JiraのURLを貼ったら怒られる」ミームを作る
- Slackなどで旧Jiraのリンクが貼られたら、冗談めかして「おっと、タイムマシンに乗っちゃってますよ」とツッコミを入れる文化を作り、強制的にLinearへ誘導する。
2. 最初の1週間は「デイリースタンドアップをLinearのボード画面だけで行う」
- 朝会で全員がLinearのActive Cycle画面を投影し、今どこで詰まっているかを視覚的に共有する。LinearのUIの美しさと軽快さが、自然とチームのモチベーションを引き上げる。
3. キーボードショートカット大会を開催する
- 最初の金曜日の夕会などで、`Cmd + K` やショートカットを用いた課題検索・作成の速さを競うミニゲーム（デモ）をやるだけで、エンジニアはゲーミフィケーション感覚で新しいツールをマスターする。
—
結びに代えて
ツールを変えることは、開発プロセスの「血流」を変えることだ。Jiraの重さに縛られていた時間は、エンジニアの創造性を削ぐ最大の無駄だった。
Linearへの移行を契機に、無駄なステータス、誰も見ないカスタムフィールド、そして無意味なクリック数をすべて捨て去れ。速く、美しく、コードを書くことだけに集中できる開発環境を、あなたの手でチームにもたらそう。