LinearのViews機能とカスタムフィルターを極限まで使い倒せ：認知負荷ゼロの「最強タスクダッシュボード」構築術
開発組織のスケールに伴い、バックログはゴミ溜めへと変貌する。何百ものオープンチケット、曖昧な優先度、通知の嵐。エンジニアリングマネージャーやリードエンジニアが「今日、本当に手を動かすべき1行」を見つけるために、無駄なコンテキストスイッチを強いられる――この状況こそが、チームのベロシティを殺す最大の癌である。
Jiraの鬱陶しいJQL（Jira Query Language）や、重厚長大なカスタムフィールド地獄に別れを告げよ。次世代の高速開発組織の標準であるLinearには、その圧倒的なUI/UXの裏側に、開発者の認知負荷を限界まで削ぎ落とし、フロー状態を強制生成するための高度なクエリエンジン「Views（カスタムビュー）」が備わっている。
本稿では、LinearのViews機能とカスタムフィルターを骨の髄まで掌握し、あなた専用の「最強タスクダッシュボード」を構築するための低レイヤ＆エキスパート知見を授ける。
—
1. 認知負荷の最適化：なぜ「デフォルトのInbox」では戦えないのか
多くのエンジニアは、Linearのデフォルトで用意されている「My Issues」や「Inbox」をそのまま使っている。これがまず敗因だ。
デフォルトビューは「全体を広く見渡す」ためのものであり、「極限まで集中して今日のスループットを最大化する」ためには設計されていない。情報のサイロ化を防ぎ、タスクの迷子をなくすためには、「時間軸」「コンテキスト」「依存関係」の3軸でデータを垂直に切り取るカスタムViewsが不可欠となる。
LinearのViewsは、単なるフィルターの保存場所ではない。背後にあるGraphQL APIの効率的なフェッチングレイヤと完全に同期しており、適切なクエリ設計を行えば、チーム全体のノイズを完全に遮断できる。
—
2. 実戦投入するべき「神クエリ」：カスタムフィルター設計論
ここからは、実務の現場でベロシティを劇的に跳ね上げる、高度なフィルターの組み合わせとクエリ構築術を具体例とともに解説する。
パターンA：今日・今週の「真のブロッカー」を炙り出すエグゼクティブビュー
自分がアサインされているだけでなく、「他のメンバーの進行を止めている（Blockedの状態を生み出している）」かつ「期限が直近」のチケットを強制的に浮上させる。
- View名: `⚡️ Critical Blockers & My Focus`
- フィルター条件の構成:
- `Assignee` = `Me`
- `Status` = `In Progress` OR `Todo`
- `Priority` = `Urgent` OR `High`
- `Linked Issues` = `Blocking`（他タスクをブロックしているものに限定）
【アーキテクトの解説】
単に「Priorityが高いもの」を見るのはアマチュアのやり方だ。Linearでは、他タスクの前提条件（Blocked By）となっているチケットを優先処理することが、システム全体のスループット（TOC：制約理論）を最大化する唯一の解である。このビューをピン留めし、朝会の前に1秒で目視確認せよ。
パターンB：放置されたゾンビチケットを自動隔離する「Stale Radar」
アサインされたまま3週間以上ステータスが動いていない「ゾンビチケット」は、バックログのメモリを圧迫するガベージ（ゴミ）だ。これを自動検知する。
- View名: `🧟♂️ Stale Tickets Radar`
- フィルター条件の構成:
- `Assignee` = `Me`
- `Status` != `Done` AND `Status` != `Canceled`
- `Updated` = `> 21 days ago`（最終更新から3週間以上経過）
【アーキテクトの解説】
「忘れていた負債」を視覚化することで、クローズするか、スコープを削るか、デッドオアアライブの判断を強制する。これにより、バックログの純度が保たれる。
—
3. Linear API / CLI を叩く「最強の自動化スクリプト」
UIでのポチポチ設定に満足しているうちは中級者止まりだ。真のエンジニアは、LinearのGraphQL APIを直接叩くか、`linear-cli`等のツール群を駆使して、ダッシュボードの構築やステータス同期すらもコード化・自動化する。
以下は、特定のカスタムフィルター条件に合致するチケットのメタデータを抽出し、日報ツールやSlackへ自動通知するTypeScript製スクリプトの極限まで洗練された実装例である。
import { LinearClient } from ‘@linear/sdk’;
// 環境変数からAPIキーを読み込み、最小権限でクライアントを初期化
const linearClient = new LinearClient({ apiKey: process.env.LINEAR_API_KEY });
async function fetchFocusDashboardIssues() {
try {
// 認証ユーザー自身の情報を取得
const me = await linearClient.viewer;
console.log(`[Info] Authenticated as: ${me.name} (${me.email})`);
// GraphQLクエリの精神を内包したSDKフィルターの構築
// 自分がアサインされており、かつ進行中/高優先度のタスクをフェッチ
const issues = await linearClient.issues({
filter: {
assignee: { id: { eq: me.id } },
state: { type: { in: [‘unstarted’, ‘started’] } },
priority: { lte: 2 }, // 0: None, 1: Urgent, 2: High
updatedAt: { ght: new Date(Date.now() – 7 24 60 60 1000).toISOString() } // 直近1週間以内に更新
},
first: 10,
orderBy: ‘priority’
});
console.log(`\n=== 🚀 Today’s Focus Dashboard (${issues.nodes.length} issues) ===`);
for (const issue of issues.nodes) {
const state = await issue.state;
console.log(`- [${issue.identifier}] ${issue.title} (Priority: ${issue.priority}, Status: ${state?.name})`);
}
} catch (error) {
console.error(‘[Error] Failed to fetch Linear issues:’, error);
process.exit(1);
}
}
// 実行
fetchFocusDashboardIssues();
—
4. パフォーマンスとスケーリング：組織全体でViewsを破綻させないための設計思想
組織が50人、100人と拡大するにつれて、各エンジニアが勝手に無数のCustom Viewsを作り始めると、タグの乱立やクエリの肥大化により、Linearのサイドバーはカオスと化す。これを防ぐためのガバナンス設計（ナレッジマネジメントの観点）を提示する。
1. Team-Level Viewsの標準化:
個人的なViewsだけでなく、チーム共通のViews（例: `QA Ready`, `Backend Blockers`, `Release Candidates`）は、チームリードが定義し、トップダウンで共有する。
2. ネーミング規則の厳格化:
絵文字をプレフィックスに付与することで、視覚的なパース速度を極限まで高める。
- `🔥`: 緊急・ブロッカー
- `👀`: レビュー待ち
- `🧊`: スコープ外・凍結中
3. ラベル（Labels）の濫用禁止:
カスタムフィルターの条件として「Labels」を多用すると、スキーマが破綻する。チームで定義されたState（状態）とPriority（優先度）をファーストクラスシチズンとして使い倒し、Labelsは最小限のドメインコンテキスト（例: `frontend`, `infra`, `security`）に限定せよ。
—
5. 結び：ツールに踊らされるな、ツールを骨の髄まで飼い慣らせ
アジャイル開発の本質は、無駄な認知負荷を排し、顧客に対する価値提供（Value Delivery）のリードタイムを極限まで短縮することにある。Linearはそのための極上のエンジンだ。
デフォルトの機能に甘んじるな。独自のViewsを組み上げ、APIを叩き、自分だけの最強のダッシュボードを構築せよ。その数秒の最適化の積み重ねこそが、凡百の開発チームを「圧倒的な成果を出すハイパフォーミング・組織」へと昇華させる唯一の道である。