Linear Automations完全ガイド:手動更新の呪縛から解放され、開発スピードを極限まで高める技術
テックリードの仕事は、コードを書くことだけではない。真に価値ある仕事とは、開発チームが「コードを書くこと」以外の雑務(=ステータスの手動更新、チケットの割り振りの遅延、PRとIssueの紐付け忘れ)に認知負荷を奪われないエコシステムを構築することだ。
Jiraの複雑怪奇なワークフロー設定や、Notionでの手動メンテに疲弊したチームを救う聖杯、それが Linear である。そして、Linearの真価は、その圧倒的なUIの軽快さだけでなく、「Automations(自動化)」機能をどこまで深くインフラストラクチャに組み込めるかにある。
本稿では、LinearのAutomationsを駆使し、ルーティンワークを全廃してチームのベロシティを劇的に高めるための実践的知見を余すところなく伝授する。
—
1. なぜ「手動でのステータス更新」は開発の悪なのか?
「PRを出したらLinearのステータスを『In Review』に動かしてください」
「このラベルを貼ったら、あの人にアサインし直して…」
こうした運用ルールを口頭やドキュメントで徹底させようとするチームは、例外なく失敗する。人間は忘れる生き物であり、コンテキストスイッチのたびにタスク管理ツールの更新を忘れる。結果として何が起きるか?
- カンバンボードが実態と乖離し、スタンドアップミーティングが「現状確認」という名の無駄な時間に変貌する。
- マネージャーが「このPRの進捗どうなってる?」とエンジニアにチャットを投げ、貴重なフロー状態(Deep Work)を破壊する。
「ツールが人間を管理するのではなく、システムが人間のワークフローに寄り添うべきだ」
LinearのAutomationsは、Gitのライフサイクルとシームレスに結合し、チケットの状態遷移を完全に自動化するための強力なエンジンである。
—
2. 現場で即効性を発揮する!神・自動化ルール設定例
Linearのプロジェクト設定(Settings > Teams > [Your Team] > Automations)から構築すべき、実戦投入必須の自動化ルールを厳選して紹介する。
① PRオープン時に「In Progress / In Review」へ自動遷移
- トリガー: GitHub / GitLabでプルリクエストがオープンされたとき
- アクション: Issueのステータスを `In Review`(またはブランチ戦略によっては `In Progress`)へ移行
- 効果: コーディング完了からレビュー依頼までのタイムラグをゼロにする。開発者は「PRを作る」という自然なアクションだけで、ボード上のチケットが勝手に動く。
② PRのマージ時に「Done」へ自動遷移 & 自動クローズ
- トリガー: 紐づいたPRが `merged` になったとき
- アクション: Issueのステータスを `Done` に変更
- 効果: 「あ、チケット動かすの忘れてた」を永久に根絶する。リリースノートの自動生成(LinearのChangelog機能)の精度も飛躍的に向上する。
③ 特定ラベル付与による「担当者(Assignee)の自動アサイン」
- トリガー: Issueに特定のラベル(例: `backend`, `security`, `design-system`)が付与されたとき
- アクション: 該当領域のプレイングオーナー(テックリードや専門チーム)を `Assignee` に自動設定
- 効果: 「トリアージの担当者誰だっけ?」というボトルネックを消滅させ、インバウンドのタスクを瞬時に適切なステークホルダーへルーティングする。
—
3. ベロシティを加速させる!知られざるキーボードショートカット & 拡張ハック
Automationsの効果を最大化するためには、エンジニア自身の操作スピードも極限まで高めておく必要がある。マウスに手を伸ばした時点で負けだ。
⚡ 開発者が覚えるべき神ショートカット
- `C` : どこにいても瞬間的に新しいIssueを作成
- `P` : コマンドパレット(ここから `Automation` の設定画面にも一瞬でジャンプ可能)
- `O` または `Shift + O` : 選択中のIssueに紐づくGitHubのPRを直接ブラウザで開く
- `I` : 担当者のアサイン(`Assignee`)パネルを瞬時に開く
- `S` : ステータスの変更セレクトボックスを開く
🔌 絶対入れるべき神プラグイン・連携
1. Linear Official GitHub / GitLab Integration
- 単なる連携にとどまらず、PRのタイトルやコミットメッセージに `ENG-123` のようにIssue IDを含めるだけで、自動的に双方向リンクが張られる。また、PRのドラフト状態(Draft PR)とLinear側のステータスを連動させる設定はマスト。
2. Linear + Slack 連携(Deep integration)
- Slack上で `/linear` コマンドを叩いてその場でIssueを切るのは基本中の基本。さらに、Slackのスレッドからリアクション(例: 👀 や ✅)をつけることで、Linearのステータスやコメントを同期させる高度なワークフローも構築可能。
—
4. チームで共有すべき「Linear設定・運用ルール」のベストプラクティス
ツールの機能を導入しても、チームの共通認識(ガバナンス)が崩壊していれば意味がない。組織全体でスケールするLinear運用ルールを定義せよ。
- ステータス定義の厳格化: `Todo`(バックログから起票されたもの), `In Progress`(現在着手中・ブランチを切った状態), `In Review`(PR作成済み), `Done`(マージ完了)。この定義から外れた曖昧な運用を禁止する。
- ラベル(Labels)の命名規則: 属人性を排するため、ラベルはコロン構称(例: `type:bug`, `type:feature`, `area:auth`, `area:billing`)で統一し、自動化のトリガーとして安全に利用できるようにする。
- プロジェクトとサイクルの活用: 個別のタスクだけでなく、2週間単位などの「Cycles(スプリント)」を必ず設定し、ベロシティの計測を自動化する。
—
5. 【実践】Linear API / Webhook を用いた高度な自動化設計
標準のAutomations機能ではカバーしきれない複雑な社内ワークフロー(例:「特定のセキュリティ脆弱性チケットが起票されたら、自動でP1(最高優先度)に引き上げ、特定のプライベートチャンネルに通知を飛ばす」など)を構築するためには、LinearのGraphQL APIやWebhookを活用する。
以下に、チーム独自の拡張を行う際のベースとなる、堅牢なWebhook受信サーバーの構成例(Node.js / Express)を示す。
📁 実用設定ファイル・スクリプト例
`linear-webhook-handler.ts`
import express, { Request, Response } from ‘express’;
import crypto from ‘crypto’;
const app = express();
app.use(express.json());
// Linear Webhookの署名検証用シークレット(環境変数から取得)
const LINEAR_WEBHOOK_SECRET = process.env.LINEAR_WEBHOOK_SECRET || ”;
/
- LinearからのWebhookリクエストの正当性を検証するミドルウェア
/
const verifyLinearSignature = (req: Request, res: Response, next: Function) => {
const signature = req.headers[‘linear-signature’] as string;
if (!signature || !LINEAR_WEBHOOK_SECRET) {
return res.status(401).send(‘Missing signature or secret’);
}
const hmac = crypto.createHmac(‘sha256’, LINEAR_WEBHOOK_SECRET);
const digest = hmac.update(JSON.stringify(req.body)).digest(‘hex’);
if (signature !== digest) {
return res.status(403).send(‘Invalid signature’);
}
next();
};
/
- Webhookエンドポイント
- 例:Criticalなラベルが貼られた瞬間にアラートを飛ばす、または外部DBと同期する
/
app.post(‘/webhook/linear’, verifyLinearSignature, async (req: Request, res: Response) => {
const { action, type, data, updatedFrom } = req.body;
// Issueが新規作成または更新されたイベントをキャッチ
if (type === ‘Issue’) {
console.log(`[Linear Webhook] Issue ${data.identifier} (${action})`);
// 例: 優先度が最高 (Priority 1 = Urgent) に変更された場合のカスタム処理
if (action === ‘update’ && data.priority === 1 && updatedFrom?.priority !== 1) {
console.warn(`🚨 緊急チケット検知: ${data.title} [${data.url}]`);
// TODO: PagerDutyや特定のSlack Webhookへ緊急通知を送信するロジックをここに記述
}
}
// Linearへ正常受信を即座に返す(タイムアウトを防ぐため非同期処理の前にレスポンスを返す)
return res.status(200).send({ received: true });
});
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
console.log(`Linear Webhook handler listening on port ${PORT}`);
});
💡 このコードの狙い:
標準機能のAutomationsでは実現できない「外部システム(PagerDutyや社内SaaS)との高度な連携」や「特定条件下での動的なバリデーション」が必要になった場合、LinearのWebhookを起点にすることで、開発プロセスの自動化レイヤーを無限に拡張できる。
—
結び:ツールに雑務を委ね、エンジニアはコードと向き合え
優れたエンジニアリングチームとは、単にコードが書ける集団ではない。「開発以外の摩擦(Friction)」を極限まで排除し、プロダクトの価値創造に全リソースを投下できる組織のことだ。
LinearのAutomations機能は、単なる「便利機能」ではない。それは、チームの規律をコードとシステムによって担保し、手動更新という名の無駄な認知負荷を消し去るための「武器」である。
今すぐチームのLinear設定を見直し、ルーティンワークを全廃せよ。あなたのチームのベロシティは、まだその本領を発揮していないはずだ。