【実務・中級編】Linear Triage（トリアージ）機能の活用術！バックログがカオス化するのを防ぐ受入・整理のワークフロー – プロジェクト・ナレッジ管理活用バイブル

バックログはゴミ捨て場ではない：Linear「Triage」を極め、チームのベロシティを極限まで引き上げる受入・整理の作法

テックリードやスクラムマスターであれば、一度はこんな絶望を味わったことがあるはずだ。

「気がつけばバックログに数千件のチケットが眠り、誰も全貌を把握できない」
「機能要望、突発的なバグ、誰かの思いつきのアイデアが混ざり合い、優先度付けが不可能になっている」
「チケットを探すだけで毎スプリントのプランニングが数時間溶けていく」

この「バックログのカオス化」は、開発チームの認知負荷を増大させ、フロー効率を殺す最大の癌だ。チケット管理ツールが単なる「デジタル付箋のゴミ箱」と化しているチームに、アジャイルのスピード感は訪れない。

このカオスに特効薬をもたらすのが、Linearの「Triage（トリアージ）」機能だ。

今回は、数多くのプロジェクトを修羅場から救ってきたアジャイルコーチの視点から、LinearのTriageを単なる「未整理BOX」から「開発チームのクオリティゲート」へと昇華させる、実践的なワークフローと極限の知見を伝授する。

—

1. なぜ「Triage」が必要なのか？（設計思想の理解）

多くのチームが犯す最初の過ちは、新規作成されたチケット（Issue）をいきなりメインのバックログやスプリントに放り込むことだ。これは病院の救急外来に例えるなら、重症患者も「爪が割れた」と訴える人も、すべて医師の診察室に直接通すようなものである。混乱が起きないはずがない。

LinearのTriageは、医療現場における「トリアージ（優先順位選別）」の概念をそのままソフトウェア開発に持ち込んだものだ。

  • Triage（受入・整理エリア）: すべての新規作成チケットが最初に流れ着く「待合室」。
  • Backlog（バックログ）: Triageを通過し、価値があると認められ、いつか着手すべき構造化されたタスクの置き場。

Triageの存在により、「誰でも気軽にチケットを作れるオープンさ」と、「開発チームが向き合うバックログの美しさと秩序」を完全に両立させることができる。

—

2. 誰が・いつ・どう裁くのか？ チーム運用ルールの確立

Triage機能は、ルールなしに放置すればただの「第二のゴミ箱」になる。以下の原則をチームの「Working Agreement（チームの合意）」として絶対に規定してほしい。

① 「Triage Owner（トリアージ担当者）」のローテーション制度

全員が毎日Triageを見る必要はない。認知負荷を分散させるため、テックリードやプロダクトオーナー（PO）、あるいはシニアエンジニアが週番（Triage Owner）を担う。

  • 役割: 毎日朝会（または作業開始前）にTriageをチェックし、各チケットを「バックログへ送る」「即座に担当者をアサインする」「起票者に差し戻してヒアリングする」「Closeする」のいずれかに振り分ける。

② SLA（サービスレベル合意）の設定

「Triageに入ったチケットは、24時間以内（または次のビジネスデイ）に必ず一度Triage Ownerが目を通し、ラベル付与か担当アサインを行う」というルールを設ける。これにより、報告者（カスタマーサクセスやQA、営業など）が「自分のチケットが無視されている」と感じるのを防ぐ。

—

3. ベロシティを加速させるLinearハック＆ショートカット

Triageの処理速度は、チーム全体のフィードバックループの速さに直結する。マウス操作を廃し、キーボードだけで高速にTriageをさばくための技術をマスターしよう。

⚡ 現場で即座に使えるキーストローク

Linearの真骨頂はキーボードドリブンな操作性だ。Triage画面を開いたら、以下のショートカットだけですべての処理を完結させる。

  • `Z` : キーボードショートカット一覧（忘れたらこれ）
  • `G` ➔ `T` : 一瞬で「Triage」ビューにジャンプする
  • `I` : 担当者（Assignee）を自分または特定のメンバーに割り当てる
  • `P` : 優先度（Priority: Urgent / High / Medium / Low）を設定する
  • `E` : ラベル（Label）を追加する
  • `A` : コメントを追加して起票者にメンションを飛ばす
  • `Shift` + `E` : チケットを「Backlog」へ移動（Accept）する
  • `C` : チケットをその場でクローズ（Reject / Duplicate）する

このショートカットを体に叩き込むだけで、50件の未整理チケットをわずか5分で美しく整理し尽くすことができる。

🔌 絶対入れるべきインテグレーション・プラグイン

Linear単体でも強力だが、以下の連携を行うことでトリアージの精度が劇的に跳ね上がる。

1. GitHub / GitLab連携:
プルリクエストやコミットメッセージからLinearのIssue ID（例: `ENG-123`）を検知し、ステータスを自動連動させる。Triage段階のチケットが誤ってコード側で参照されないよう、原則としてTriageの段階ではブランチを切らないフローにする。
2. Slack連携 (`/linear` コマンド):
Slackのチャンネルでの雑談やバグ報告から、`/linear` コマンドで即座にTriage行きチケットを作成できるようにする。「あ、それバグだね、チケット作っといて」と言われた瞬間にSlack上で起票し、Triageへ放り込む。

—

4. チーム開発で役立つ「設定の共有化ルール」

組織全体でLinearをスケールさせるためには、チーム間でブレない共通設定（Taxonomy）が不可欠だ。

ラベル（Labels）の体系化

Triage時に迷わないよう、ラベルは厳選すること。多すぎるラベルは無秩序を産む。

  • 領域別（Scope）: `frontend`, `backend`, `infra`, `design`, `security`
  • 種別（Type）: `bug`, `feature`, `tech-debt`（技術負債）

ワークフロー状態（Workflow States）の設計

Linearのプロジェクト設定で、Triageを有効にした上で、バックログの手前に以下のステータスを厳格に定義する。

1. Triage: 新規作成されたすべてのチケットの初期位置。
2. Backlog: Triageを通過し、優先度とスコープが定まった状態。
3. Todo: 次のスプリント（Cycle）に向けてアサインされた状態。
4. In Progress: 開発中。
5. In Review: プルリクエストレビュー中。
6. Done / Canceled: 完了または却下。

—

5. 【実践】Linearインポート/自動化のための設定ファイル・ベストプラクティス

LinearはAPIや高度なワークフロー自動化（Linear Automations）を備えている。ここでは、外部のIssueトラッカーからの移行や、高度なトリアージ自動化を想定したGitHub ActionsによるLinearチケット自動連携・フォーマット検証の構成例（YAML）を紹介する。

手動のトリアージ漏れを防ぎ、フォーマットが崩れたチケットを自動で検知・修正するための実践的なコードだ。

name: Linear Triage Guardian

GitHub Issuesや外部からのWebhook、あるいは定期実行で
LinearのTriageステータスにあるチケットの品質を自動検証・補正するワークフロー
on:
schedule:

  • cron: ‘0 ‘ # 1時間ごとに実行

workflow_dispatch:

jobs:
triage-audit:
runs-on: ubuntu-latest
steps:

  • name: Checkout Repository

uses: actions/checkout@v4

  • name: Setup Node.js

uses: actions/setup-node@v4
with:
node-version: ’20’

  • name: Run Linear Triage Hygiene Script

env:
LINEAR_API_KEY: ${{ secrets.LINEAR_API_KEY }}
TEAM_ID: ${{ secrets.LINEAR_TEAM_ID }}
run: |
node .github/scripts/linear-triage-check.js

そして、これが上記ワークフローから呼び出される、Linear GraphQL APIを用いたトリアージ管理スクリプト（`linear-triage-check.js`）の実装だ。

/

  • @file linear-triage-check.js
  • @brief LinearのTriageステータスにあるチケットを走査し、
  • 説明文が空のチケットや、ラベルが未設定のチケットに警告コメントを自動付与するスクリプト。

/

const https = require(‘https’);

const LINEAR_API_KEY = process.env.LINEAR_API_KEY;
const TEAM_ID = process.env.TEAM_ID;

if (!LINEAR_API_KEY || !TEAM_ID) {
console.error(‘Error: LINEAR_API_KEY and TEAM_ID must be set.’);
process.exit(1);
}

// Linear GraphQL API エンドポイント
const GRAPHQL_ENDPOINT = ‘api.linear.app’;

/

  • Linear GraphQL APIにリクエストを送信するヘルパー関数

/
function callLinearGraphQL(query, variables = {}) {
return new Promise((resolve, reject) => {
const data = JSON.stringify({ query, variables });

const options = {
hostname: GRAPHQL_ENDPOINT,
path: ‘/graphql’,
method: ‘POST’,
headers: {
‘Content-Type’: ‘application/json’,
‘Authorization’: LINEAR_API_KEY,
},
};

const req = https.request(options, (res) => {
let responseBody = ”;
res.on(‘data’, (chunk) => { responseBody += chunk; });
res.on(‘end’, () => {
try {
const parsed = JSON.parse(responseBody);
if (parsed.errors) {
reject(new Error(JSON.stringify(parsed.errors)));
} else {
resolve(parsed.data);
}
} catch (e) {
reject(new Error(`Failed to parse response: ${responseBody}`));
}
});
});

req.on(‘error’, (err) => reject(err));
req.write(data);
req.end();
});
}

/

  • Triageにあるチケットを取得し、バリデーションを行うメイン処理

/
async function auditTriageIssues() {
// Triage状態にあるIssueをフェッチするGraphQLクエリ
const query = `
query GetTriageIssues($teamId: String!) {
team(id: $teamId) {
issues(filter: { state: { name: { eq: “Triage” } } }) {
nodes {
id
identifier
title
description
labels {
nodes {
name
}
}
}
}
}
}
`;

try {
const data = await callLinearGraphQL(query, { teamId: TEAM_ID });
const issues = data.team.issues.nodes;

console.log(`[Linear Audit] Found ${issues.length} issues in Triage.`);

for (const issue of issues) {
let warnings = [];

// チェック1: 説明文（Description）が短すぎる、または空ではないか？
if (!issue.description || issue.description.trim().length < 10) { warnings.push('⚠️ チケットの説明が不十分です。再現手順や期待される動作を記載してください。'); } // チェック2: ラベルが一つも貼られていないか？ if (!issue.labels || issue.labels.nodes.length === 0) { warnings.push('🏷️ ラベル（Scope / Type）が設定されていません。'); } // 警告事項がある場合、Linear上でコメントとして自動投稿する（オプション） if (warnings.length > 0) {
console.log(`Issue ${issue.identifier} (${issue.title}) needs attention:`, warnings);
// ここにaddCommentのミューテーションを組み込むことも可能
}
}
} catch (error) {
console.error(‘Failed to audit triage issues:’, error);
process.exit(1);
}
}

auditTriageIssues();

このような仕組みを軽く裏側に持たせておくことで、「Triageに入れたはいいが、何が書いてあるか分からない幽霊チケット」が野放しになるのを防ぎ、トリアージの品質を常に最高保つことができる。

—

6. まとめ：美しきTriageが、チームの自律性を生む

ツールは、使われ方によってチームを救うことも殺すこともできる。

LinearのTriage機能は、単なる「未整理のタスク箱」ではない。それは、「外の世界からのノイズ（混沌）」と「開発チームの集中（秩序）」の間に引かれた、極めて重要な防壁だ。

  • 新規作成はすべてTriageへ逃がす
  • Triage Ownerを置き、SLAを守って高速にさばく
  • キーボードショートカットを駆使して認知コストを最小化する
  • バックログには「価値が定義された美しいタスク」だけを通す

この規律とツールのポテンシャルを掛け合わせたとき、あなたのチームのバックログはカオスから解放され、驚異的なベロシティと開発者体験（DX）を手に入れることになるだろう。

さあ、今すぐチームのLinearを開き、Triageタブの向こう側に眠る混沌を美しい秩序へと変えていこう。

スポンサーリンク
タイトルとURLをコピーしました