こんにちは！プロダクト開発の現場を駆け巡る中で、こんな絶望感を味わったことはありませんか？
「朝起きたら、Slackやカスタマーサポートから数えきれないほどのバグ報告や機能要望が降ってきている……」
「気づけばバックログが名もなきタスクの墓場と化し、誰も全体像を把握できなくなっている……」
多くのチームが、この「情報の洪水」の前に疲弊しています。チケット管理ツールを導入したはずが、いつの間にかカオス製造機になってしまっているのです。
でも、安心してください。次世代の超高速チケット管理ツール「Linear（リニア）」には、このカオスを美しく浄化する最強の武器が備わっています。それが今回解説する「Triage（トリアージ）」機能です。
これをマスターすれば、あなたのチームのバックログは常に整理された「次に進むべき美しい道」へと生まれ変わります。さあ、一緒にその扉を開きましょう！
—
1. そもそも「Linear Triage」とは何か？（ツールの本質）
医療の現場における「トリアージ（Triage）」を思い浮かべてみてください。病院に運ばれてきた患者の重症度を素早く判断し、治療の優先順位を決めるプロセスですね。
LinearのTriageも全く同じです。
ユーザー、QA、セールス、そしてエンジニア。あらゆるステークホルダーから投げ込まれる「まだ誰も精査していない、生煮えのタスク（Issue）」が最初に流れ着く「未承認エリア」、それがTriageです。
なぜバックログに直接入れちゃいけないのか？
初心者がやりがちな最大のアンチパターンが、すべての新規タスクを直接「Backlog」に放り込むことです。
これをやると何が起きるか？ バックログは「誰がやるのか」「いつやるのか」「そもそも本当に必要なのか」が分からない雑多なアイデアのゴミ捨て場になり、優先度の高い重要なタスクが埋もれてしまいます。
LinearのTriage機能は、「受信トレイ（インボックス）」と「審判の場」を兼ねています。ここで「捨てる」「育てる」「今すぐやる」を仕分けすることで、バックログの聖域を守る防壁となるのです。
—
2. 準備と基礎セットアップ：Triage機能を有効化する
それでは、実際にLinearでTriageワークフローを構築していきましょう。セットアップは驚くほど簡単ですが、ここでの設定がチームの未来を左右します。
ステップ1: Triage機能の有効化
まずはプロジェクトまたはチームの設定で、Triageが有効になっているか確認します。
1. Linearのサイドバーから、対象のチーム設定（Team settings）を開きます。
2. 「Triage」の項目へ移動します。
3. `Enable triage` のトグルをオンにします。
これだけで、チームのビューに「Triage」という専用の受信箱が出現します。
ステップ2: 誰が「トリアージ」するのか？（役割の定義）
ここがアジャイルの肝です。全員がバラバラにトリアージを始めると、ルールが崩壊します。
- おすすめの運用: 「Triage Owner（トリアージ担当者）」を1週間ごとの持ち回りにする（スクラムマスターやテックリード、あるいはプロダクトマネージャーが最適です）。
- 役割: その週にTriageに溜まったチケットを毎日1回（あるいは数時間に1回）、数分かけて仕分けする。
—
3. 実践！「HelloWorld」的トリアージ・ワークフロー
それでは、実際に1件の「混沌としたバグ報告」が舞い込んだと仮定して、Linear上でどのように処理していくか、その一連の流れ（HelloWorld）を体験してみましょう。
シナリオ：
> Slackに届いた悲鳴：
> 「なんかログイン画面のボタンが押せなくて、先に進めないんだけど！直して！」
これをLinearのTriageに起票してもらう（あるいはインテグレーションで自動連携される）と、あなたのTriage受信箱にこう入ってきます。
[Issue #404] ログインボタンが押せない
- 報告者: カスタマーサポート
- 状況: Triage (未整理)
このチケットをどう処理するか？ トリアージ担当者であるあなたは、以下の「3つのアクション（仕分け）」のいずれかを即座に実行します。
┌─────────────── アクション 1: 棄却 (Decline) ──────────────┐
│ (重複、仕様通り、再現性なし) │
▼ ▼
┌──────────────────┐ ┌───────────────┐
│ Triage に到着 │ │ Closed (完了) │
└──────────────────┘ └───────────────┘
▲
│ (情報不足)
├─────────────── アクション 2: ラベル・担当者追加 ────────┐
│ (Backlog へ昇格) ▼
▼ ┌───────────────┐
┌──────────────────┐ │ Backlog / │
│ Accept (受入) │ ─────────────────────────────────► │ Active Cycle │
└──────────────────┘ └───────────────┘
アクション A: 「即座に受け入れる (Accept)」
情報が揃っており、明らかに修正すべきバグ、または価値ある要望だと判明した場合。
- 操作: ショートカットキー `A`（または「Accept」ボタン）を押す。
- 結果: チケットはTriageから抜け出し、正式な「Backlog」へと送られます。この際、適切なLabels（`bug` など）やEstimate（工数見積もり）を付与してから送ると完璧です。
アクション B: 「情報を求めて差し戻す (Comment & Wait)」
「どのブラウザで起きたか分からない」など、情報が足りない場合。
- 操作: コメントで「確認ありがとうございます！ 発生したブラウザのバージョンを教えていただけますか？」と返信し、必要であればLabelに `needs-info` を付与してTriageにとどめておきます。
アクション C: 「丁重にお断りする (Decline)」
仕様通りの挙動である場合や、すでに修正済みの重複チケットである場合。
- 操作: ショートカットキー `D`（または「Decline」）を押す。
- 結果: チケットはクローズされ、報告者にも自動的に（または手動でコメントを添えて）「仕様です／対応見送りです」と伝えることができます。
—
4. チームのベロシティを爆発させる「極上の運用ルール」
最後に、このTriageを形骸化させず、チームの生産性を極限まで高めるための「現場の知見」をいくつか授けましょう。これを守るだけで、開発チームの空気が劇的に変わります。
1. 「24時間ルール」を設ける
Triageに溜まったチケットは、遅くとも24時間以内（できれば毎日の朝会前）に必ず誰かが目を通すというルールを作ります。
放置された受信箱は、チームのモチベーションをじわじわと削る毒になります。「あそこに投げれば、誰かがすぐに一次対応してくれる」という安心感が、組織全体の心理的安全性を高めるのです。
2. エンジニアをトリアージから解放する
開発チームのメンバーが、日々のコーディングを中断してひっきりなしに飛んでくるチケットの対応に追われていませんか？ それは最悪のアンチパターンです。
トリアージ担当者をローテーション制にすることで、「今週は〇〇さんがトリアージ担当だから、他のメンバーは開発に集中できる」という聖域を作り出すことができます。
3. ショートカットキーを溺愛する
Linearの真骨頂はその圧倒的なスピードです。マウスを使う暇があったらキーボードを叩きましょう。
- `A`: Accept（バックログへ送る）
- `D`: Decline（却下する）
- `E`: Assigneeを変更する
- `P`: Priority（優先度）を設定する
これらを指に覚え込ませてください。数秒で1件のトリアージが終わる快感に目覚めるはずです。
—
おわりに：カオスを愛せる開発チームへ
タスク管理ツールは、ただの「デジタル付箋の貼り付けボード」ではありません。それは、チームの意志疎通をスムーズにするための「神経系」です。
新規タスクの入口である「Triage」という関所を正しく機能させることで、バックログは常に澄んだ水のように美しく保たれ、チーム全員が「いま、本当にやるべきこと」に集中できるようになります。
「これをマスターすれば、毎日の作業が劇的に楽になりますよ。」
さあ、今日からあなたのチームのLinearでも、美しいTriageワークフローを始めてみませんか？ 開発のスピードと心地よさが、まるで別次元に進化するのを実感できるはずです。