肥大化するLinearの呪縛を断つ：データベースの熱力学的エントロピーを制御し、検索性とベロシティを極限まで高めるアーキテクチャ設計
プロダクトのライフサイクルが長くなり、アジャイル開発のイテレーションが重なるにつれて、あらゆる課題管理ツールは「情報の墓場」へと変貌するリスクを孕む。数万件に及ぶ「Closed」イシュー、文脈の失われたゾンビタスク、そして乱立したプロジェクト。これらは単にUIのレスポンスを悪化させるだけでなく、エンジニアリング組織全体のコンテキストスイッチコストを跳ね上げ、認知負荷という見えない負債を蓄積させる。
世の中の大半のマニュアルは「定期的に古いタスクを閉じましょう」という精神論で終わる。しかし、我々が対峙すべきは、情報のエントロピー増大という物理法則そのものである。
本稿では、最高峰のスピードと洗練されたUIで知られる「Linear」の内部特性を解剖し、そのデータ構造とAPI、そして高度な自動化パイプラインを駆使して、チームの認知負荷をゼロに近づけるための極限のデータ整理術・アーカイブ戦略を解説する。
—
1. Linearのデータ構造と「アーカイブ」の真実
まず、Linearのアーキテクチャおよびデータライフサイクルにおける基本原則を再確認する。多くのエンジニアが誤解しているが、Linearにおける「Closed（完了）」と「Archived（アーカイブ）」は全く異なるレイヤーに存在する。
- Closed / Canceled: ステータスの一つ。ワークフローの終端であり、検索インデックスや通常のビュー、グラフ（Cylcles, Initiatives）の計算対象に残り続ける。
- Archived: データベースのストレージ最適化およびクエリ最適化の文脈で、アクティブなインデックスから切り離された状態。APIのデフォルトクエリやグローバル検索のノイズから完全に排除される。
なぜ手動でのアーカイブでは破綻するのか？
開発者が手動でアーカイブを行う運用は、100%の確率で失敗する。人間の意思決定コストをタスク管理の維持に割くべきではない。「完了してから一定期間が経過したイシューは、自動的にシステムが冷温ストレージ（Archived）へ移行する」という不変のパイプラインを構築することこそが、スケーラブルな組織運営の絶対条件である。
—
2. 自動アーカイブの限界突破：Linear APIとGraphQLによる完全自動化構成
Linearの標準機能にもアーカイブのトリガーはあるが、より複雑なビジネスロジック（例：「親イシューがアーカイブされたら、紐づくサブタスクも強制アーカイブする」「特定ラベルが付与されたものは例外的に保持する」など）を実装するには、Linearの強靭な GraphQL API を叩く独自の自動化ワーカーを構築する必要がある。
以下に、Node.jsと `@linear/sdk` を用いて、最終更新から180日以上経過したClosed/Canceledイシューを検出し、自動でアーカイブするヘッドレススクリプトの全貌を示す。
駆動型自動化スクリプト（TypeScript）
import { LinearClient } from ‘@linear/sdk’;
// 環境変数からAPIキーをロード（セキュアなCI/CDランナー上で実行を推奨）
const linear = new LinearClient({ apiKey: process.env.LINEAR_API_KEY });
async function archiveStaleIssues() {
const thresholdDays = 180;
const cutoffDate = new Date();
cutoffDate.setDate(cutoffDate.getDate() – thresholdDays);
console.log(`[Sync Engine] 基準日時: ${cutoffDate.toISOString()} 以前に完了したイシューのアーカイブを開始します…`);
let hasMore = true;
let cursor: string | undefined = undefined;
let archivedCount = 0;
try {
while (hasMore) {
// GraphQLクエリの最適化: ページネーションを用いてメモリ消費を抑制
const issuesPage = await linear.issues({
first: 50,
after: cursor,
filter: {
and: [
{ state: { type: { in: [‘completed’,قصCanceled’ as any] } } }, // 完了またはキャンセル
{ updatedAt: { lt: cutoffDate.toISOString() } },
{ archivedAt: { null: true } } // すでにアーカイブされていないもの
]
}
});
const issues = issuesPage.nodes;
for (const issue of issues) {
const team = await issue.team;
console.log(`Archiving: [${team?.key}-${issue.number}] “${issue.title}” (最終更新: ${issue.updatedAt})`);
// イシューのアーカイブ実行
await issue.archive();
archivedCount++;
}
hasMore = issuesPage.pageInfo.hasNextPage;
cursor = issuesPage.pageInfo.endCursor;
}
console.log(`[Sync Engine] 処理完了。合計 ${archivedCount} 件のイシューをアーカイブしました。`);
} catch (error) {
console.error(‘[Error] アーカイブ処理中に致命的なエラーが発生しました:’, error);
process.exit(1);
}
}
archiveStaleIssues();
このスクリプトを GitHub Actions の `cron` トリガー（例：毎週日曜日の深夜3時）で実行することで、人間の手を一切介さずにLinearのエントロピーを常に最小値に保つことが可能となる。
—
3. アーカイブされたデータの効率的な検索方法：認知負荷ゼロのインベントリ設計
「過去の意思決定の経緯（Why）」や「技術的負債の背景」を探す際、アーカイブされたデータが完全にブラックボックス化しては本末転倒である。Linearはアーカイブされたイシューも通常の検索から「明示的にスコープを広げる」ことでアクセスできる。
エキスパートが実践する検索性の維持ハックを以下に記す。
1. 検索構文の完全掌握（`is:archived`）
Linearのコマンドメニュー（`Cmd + K` または `Ctrl + K`）において、検索窓に `is:archived` 修飾子を付与することで、検索対象をアクティブ領域からアーカイブ領域へ即座に切り替えられる。
- 例: `is:archived “Memory Leak” auth-service`
2. 外部ナレッジベース（Notion / Confluence / GitHub Wiki）への非同期同期
真に重要な設計判断や仕様変更のコンテキストは、Linearのイシューコメントの中に埋もれさせてはならない。LinearのWebhookを発火させ、イシューが「Closed」ステータスになった瞬間に、そのサマリーと決定事項をAI（LLM）で自動要約させ、ナレッジベース（例: Notionデータベース）に自動蓄積するパイプラインを構築する。
これにより、Linear側は「純粋なタスクの消化ログ（インベントリ）」としてのみ機能させ、検索の大部分を構造化されたドキュメント側にオフロードできる。
—
4. チーム全体のインベントリ整理術：プロジェクトとリソースのライフサイクル管理
イシュー単体のアーカイブにとどまらず、上位概念である Project（プロジェクト） や Cycle（サイクル） の整理も、エンジニアリング組織のパフォーマンスに直結する。
プロジェクトのステータス監査ルール
1. Completed / Canceled プロジェクトの速やかな閉塞:
リリースノートが発行され、プロダクトに機能が統合されたプロジェクトは、直ちに「Completed」ステータスにし、親イシュー群を含めて一括アーカイブの対象とする。
2. ゾンビプロジェクトの強制Kill:
「着手したものの、優先順位の変更によって3ヶ月以上進捗が止まっているプロジェクト」は、容赦なく「Canceled」とし、理由（`Scope changed`, `Deprioritized`）をタグ付けしてアーカイブ送りにする。
ダラダラと残されたゾンビプロジェクトは、チームのフォーカスを散漫させる最大の要因である。
—
5. アーキテクトからの提言：ツールを飼い慣らせ
ツールとは、開発チームの認知プロセスの拡張である。Linearが持つ圧倒的な軽快さと美しさは、データがクリーンに保たれているという前提の上に成り立っている。
放置された数千件の古いタスクは、チームの視界を濁らせ、新規メンバーのオンボーディングコストを増大させる毒でしかない。本稿で示したAPIによる自動化スクリプトと厳格なライフサイクルポリシーを導入し、「常に今、目の前の価値に集中できる環境」をコードの力で担保し続けろ。
それこそが、真のアジャイル開発組織を率いるエンジニアリングリーダーの責務である。