開発の「摩擦」を排除せよ：Linear Copilotでベロシティを極限まで高める実践的戦略
開発現場における最大の敵は、コードを書く時間そのものではない。「コンテキストの切り替え」と「事務的な事務作業」による認知負荷だ。
Linearは、単なるチケット管理ツールではない。開発体験（DX）を最大化するためのエンジンだ。今回は、Linear Copilotを核とし、現場のベロシティを劇的に向上させるための「極限の知見」を共有する。
—
1. Linear Copilot：事務作業を「思考」に変える魔法
「イシューを書く」という行為は、往々にしてクリエイティブな思考を中断させる。Copilotを使えば、Slackの雑多な会話や、ふと思いついたメモから、構造化されたイシューを一瞬で生成できる。
思考を加速させるプロンプトの鉄則
Copilotに投げるプロンプトは「構造」を指定するのがコツだ。以下のテンプレートをスニペット登録（`cmd/ctrl + K` > `Snippets`）しておくことを強く推奨する。
プロンプト例:
> 以下のメモからイシューを作成して。
> 1. タイトルは簡潔なアクション形式で
> 2. Acceptance Criteriaを箇条書きで3点
> 3. 優先順位を判断してラベルを適用して
>
> [ここにメモを貼り付け]
スレッド要約で「文脈の欠落」を防ぐ
長大なコメントスレッドを読み返す時間は、チームにとって最大の浪費だ。Copilotの要約機能は、単なる要約ではない。「決定事項」と「未解決の論点」を抽出する意識を持つこと。これにより、新規参加者が即座にコンテキストを同期できるようになる。
—
2. ベロシティを倍増させる「隠れた」ショートカットと設定
キーボードから手を離した瞬間、あなたの生産性は低下する。以下の操作を筋肉に刻み込め。
- `Cmd/Ctrl + K` (Command Menu): 全ての起点。これ以外の操作は原則禁止。
- `Cmd/Ctrl + Shift + O` (Quick Peek): イシュー詳細を開かず、右側のスライドオーバーで編集。コンテキストを維持したまま修正できる。
- `G` + `I`: 自分の担当タスクへ即時遷移。
開発チームで共有すべき「神設定」
チーム全体の生産性を底上げするには、`Linear Settings`のテンプレート化が不可欠だ。特に`Issue Templates`は、以下の構成をYAML（またはJSON）で定義し、チームのGitHubリポジトリの`.linear/`配下に置くことを推奨する。
.linear/issue_template.yaml
チームの定義を強制し、属人化を防ぐ設計
templates:
- name: “Feature Request”
description: “新機能追加の標準テンプレート”
template: |
目的
- なぜこれが必要か？
実装案
- どのようなアプローチをとるか
完了条件 (AC)
- [ ]
- [ ]
参考資料
—
3. なぜ「情報のサイロ化」が起きるのか？
ツールを使いこなしても、運用ルールが甘ければ情報は死ぬ。以下の「チームの鉄則」を導入せよ。
1. 「Slackで完結させない」: 技術的な意思決定がSlackで行われたら、即座にCopilotで要約し、Linearのチケットに追記せよ。これは「記録」ではなく「資産」を作る行為だ。
2. イシューの粒度は「1日以内」: 3日かかるイシューは分解せよ。Copilotに「このイシューを1日で完了可能なタスクに分割して」と投げれば、適切な粒度を提案してくれる。
3. Labelの徹底的な自動化: ワークフロー（ステータス変更）と連動した自動化設定を徹底せよ。手動でラベルを貼る時間は、年間で数日分を浪費する。
—
4. 最後に：ツールは「文化」である
Linearを単なるタスク管理ツールとして使うのは、フェラーリで近所のコンビニに行くようなものだ。
我々の目的は「チケットを消化すること」ではなく、「開発という行為の摩擦を取り除き、エンジニアが最もクリエイティブでいられる時間を最大化すること」にある。
明日から、以下の3つをチームで試してほしい。
1. 全員のスニペットに「Copilot用要約プロンプト」を登録する。
2. イシューのテンプレートをYAMLで定義し、GitHubで管理する。
3. 「Slackの議論は、必ずLinearのコメントに要約を転記する」というルールを1週間徹底する。
これだけで、チームのベロシティは確実に1.5倍に跳ね上がる。さあ、面倒な事務作業はAIに委ね、我々はコードと設計に魂を注ごう。
「自動化できるものは、すべて自動化せよ。それがプロの矜持だ。」