組織のベロシティを極限まで引き上げる：Linear Initiatives & Roadmapによる複数プロダクト統括のアーキテクチャ
組織がスケールし、プロダクト群が拡大するにつれて、開発チームが直面する最大の敵は「コードの複雑性」ではない。「情報の断絶と文脈の喪失」だ。
幾つものスクワッドチームが並行して動き、GitHubのPRが怒濤の勢いでマージされ、Slackの通知が流れていく。しかし、経営陣やステークホルダーが知りたいのは「今、どの巨大な賭け（Initiative）が、どの程度の確度で進んでいるのか」という一点に尽きる。ここでJiraの重厚長大なポートフォリオ管理を持ち込んでは、アジャイルの機動力そのものが死に絶える。
LinearのInitiativesとRoadmapは、このジレンマを美しく解決する。しかし、単にGUIをポチポチ触って「それっぽいロードマップ」を作ったところで、実務では一瞬で形骸化する。
本稿では、Linearの内部データモデルを解剖し、APIとCLIを駆使した完全自動化パイプライン、そして複数プロダクト・複数チームが織りなすカオスを制御し、ステークホルダーを沈黙させるための極限のナレッジマネジメント手法を伝授する。
—
1. Initiatives機能による巨大な目標のグルーピングとドメイン駆動アプローチ
Linearにおける `Initiative` とは、単なる「ラベルの親玉」ではない。複数のプロジェクト（Projects）を束ね、四半期あるいは半期単位のビジネス目標（OKRs）へと収斂させるための論理的コンテキストの境界（Bounded Context）である。
内部データモデルの理解
LinearのAPI（GraphQL）を叩いたことがある者なら知っている通り、Issue、Project、Initiativeの階層構造は以下のように定義されている。
[ Initiative ] (例: Q3 グローバルインフラのゼロトラスト化)
└── [ Project A ] (例: IAMプロバイダのMigration)
└── [ Project B ] (例: Zero Trust Network Accessの導入)
└── [ Issue 1 ] (子タスク)
└── [ Issue 2 ] (子タスク)
この階層を設計する際、最大のアンチパターンは「機能（Feature）単位」でInitiativeを切ることだ。Initiativeは、ビジネスインパクト単位（Outcome-driven）で設計せよ。
組織をミスリードしないための命名規則とメタデータ設計
複数プロダクトに跨る環境では、Initiative名を見ただけで「誰が責任を持ち、どのKPIに寄与するのか」が一目でわからなければならない。
- 推奨フォーマット: `[Quarter] [Domain] / [Outcome-drivenの目標]`
- 例: `Q3 Core / Payment Gatewayのレイテンシーを30%削減し離脱率を改善する`
さらに、LinearのカスタムフィールドやDescription（Markdown）を高度に活用し、各Initiativeの冒頭には必ず以下のメタデータを埋め込むことをチームのルール（あるいはCIでの強制）とする。
🎯 Objective & Key Results (OKRs)
- O: グローバル決済基盤の堅牢性とスケーラビリティの確立
- KR1: p99レイテンシーを 120ms 以下に抑える
- KR2: 可用性 99.99% を達成する
👥 Stakeholders & DRI
- Executive Sponsor: @cto
- DRI (Directly Responsible Individual): @lead-infra-architect
- Cross-functional Teams: #secops, #core-platform, #sre
—
2. 複数プロダクト・チームに跨るロードマップの見せ方とステークホルダー向け共有のコツ
ステークホルダー（経営陣、PdM、Biz側）は、エンジニアが苦悩する「ストーリーポイントのベロシティ」には興味がない。彼らが見たいのは「タイムライン」「依存関係（Dependencies）」「リスク」の3点のみである。
Roadmapビューの最適化戦略
LinearのRoadmap機能では、プロジェクトの期間（Target Dates）をタイムライン上にマッピングする。複数プロダクトを横断する際、ごちゃ混ぜのビューを作ると情報ハイパーノイズが発生する。
これを防ぐための極意は、「視点のレイヤー化」だ。
1. Executive Roadmap:
- Initiative単位のみを表示。プロダクトごとの縦軸（Swimlane）を切り、四半期のマイルストーンにどうヒットするかだけを可視化する。
2. Product-specific Roadmap:
- 各スクワッドが所有するProject単位を展開し、マイルストーンとタスクのクリティカルパスを追跡できるようにする。
依存関係（Project Dependencies）の厳密な管理
複数プロダクトに跨るプロジェクトで最も恐ろしいのは、「プロダクトAの完了が遅れたせいで、プロダクトBのローンチが芋づる式に崩壊する」という事態だ。LinearのProject Dependencies機能を使い、必ず「Blocked by」の関係性を明示せよ。
Roadmapビュー上で赤い依存関係の矢印が見えた瞬間、それはチーム間の交渉テーブルを開く合図となる。ステークホルダー向け共有会では、この依存関係のクリティカルパスだけをハイライトして報告することで、無駄な詮索を排除し、必要な経営資源の再配分（リソースアロケーション）を即座に引き出すことができる。
—
3. 四半期ごとの計画立案から進捗トラッキングまでの実務フロー
アジャイルの美しさは「変化への適応」にあるが、中長期のロードマップには「予測可能性」が求められる。この二律背反をハックする実務フローを構築する。
四半期計画立案のフェーズ（Q-1の最後の2週間）
[Backlog Grooming & Discovery]
↓ (自動集計)
[Initiativeドラフト作成]
↓ (クロスチームレビュー)
[Capacity Allocation (工数割り当て)]
↓
[Roadmap確定 & Lock]
1. Discovery & Estimation: 各プロジェクトの親Issue群に対し、大まかなTシャツサイズ（S/M/L/XL）または日数見積もりを付与。
2. Initiativeドラフトの自動生成: 後述のAPIスクリプトを用い、前四半期の未完了プロジェクトとバックログの重要度をスコアリングして次期Initiativeの候補を自動生成。
3. Capacity Allocation: エンジニアリングリソースの総キャパシティ（人月）に対し、Initiativeの負荷が80%を超えないように調整する（残り20%はテクニカルデット解消と突発的バグ対応のバッファとする）。
進捗トラッキングと週次レーダーの自動化
進捗管理でやってはいけない最大の過ちは、「毎週金曜日に各メンバーに『進捗どう？』と聞いて手動でステータスを更新させること」である。これは組織のエネルギーを無駄に消耗する最悪のアンチパターンだ。
Linearの強力なGraphQL APIとWebhook、そしてCLIを駆使し、「進捗はコードとIssueの移動から自動算出される」パイプラインを構築する。
—
4. 【実践】Linear API & CLIによる完全自動化スクリプト
ここからが本題だ。UIをポチポチ叩く作業はジュニアエンジニアやPdMの初期教育以外には不要である。
複数プロダクトのInitiativeの進捗状態を集計し、Slackへサマリーを自動投稿、さらにはスケジュール遅延を検知してアラートを飛ばす Node.js (TypeScript) による自動化スクリプトを提示する。
実装: Initiative進捗自動集計・通知スクリプト
/
- Linear Initiative Progress Aggregator & Slack Notifier
- Requires: @linear/sdk, dotenv
/
import { LinearClient } from ‘@linear/sdk’;
import as dotenv from ‘dotenv’;
dotenv.config();
const linear = new LinearClient({ apiKey: process.env.LINEAR_API_KEY });
async function auditInitiativeProgress() {
console.log(‘🚀 Fetching Initiatives and Projects from Linear…’);
try {
// 1. すべてのInitiativeを取得
const initiatives = await linear.initiatives();
for (const initiative of initiatives.nodes) {
console.log(`\n—————————————-`);
console.log(`📌 Initiative: ${initiative.name} (${initiative.state})`);
// 2. 紐づくプロジェクトを取得
const projects = await initiative.projects();
let totalProjects = projects.nodes.length;
let completedProjects = 0;
if (totalProjects === 0) {
console.log(` ⚠️ No projects attached to this initiative.`);
continue;
}
for (const project of projects.nodes) {
const progress = project.progress; // 0.0 – 1.0 の進捗率
const state = project.state;
console.log(` – Project: ${project.name} [State: ${state}] Progress: ${Math.round(progress 100)}%`);
if (state === ‘completed’ || progress === 1.0) {
completedProjects++;
}
}
// 3. 全体進捗の算出
const overallProgress = Math.round((completedProjects / totalProjects) 100);
console.log(`✨ Overall Initiative Progress: ${overallProgress}% (${completedProjects}/${totalProjects} projects done)`);
// 4. 遅延検知のロジック（ターゲット日を過ぎているのに完了していない場合など）
if (initiative.targetDate) {
const target = new Date(initiative.targetDate);
const now = new Date();
if (now > target && overallProgress < 100) {
console.warn(`🔥 ALERT: Initiative "${initiative.name}" has passed its target date (${initiative.targetDate}) but is only ${overallProgress}% complete!`);
// ここでSlack Webhook等を叩いてアラートを飛ばす処理を実装する
}
}
}
} catch (error) {
console.error('❌ Failed to fetch linear data:', error);
process.exit(1);
}
}
auditInitiativeProgress();
パフォーマンスとレートリミット（Rate Limit）の最適化ハック
LinearのAPIはGraphQLベースであり非常に高速だが、組織の規模が大きくなり、数千のIssueや数百のProjectを一度に走査（Traversal）すると、Linear APIのRate Limit（複雑度制限: Complexity Limit）に抵触する。
- N+1問題の回避: 上記コードの `initiative.projects()` のように、ループ内でリクエストを投げると瞬時にリミットに達する。実運用では必ず GraphQLのフラグメント と `include` を用いて、一撃のクエリでツリー全体（Initiative -> Projects -> Issues）を取得せよ。
- キャッシュ戦略: CI/CDパイプラインやcronで定期実行する際は、前回の取得結果のハッシュと比較し、差分（Delta）のみを処理するインクリメンタル・シンク（Incremental Sync）のアーキテクチャを導入せよ。
—
5. 組織文化としてのナレッジ共有：サイロ化を防ぐ仕組み
どれほど優れたツールと自動化を導入しようとも、チーム間の心理的安全性が欠如し、情報を囲い込む文化があればシステムは腐敗する。
1. 「公開がデフォルト（Default to Public）」の原則:
- LinearのProjectやInitiativeは、特段の機密情報を除き、社内全員が閲覧可能な状態（Public）に設定する。他チームのロードマップを覗き見できる環境こそが、予期せぬシナジーや重複開発の防止を生む。
2. ドキュメントとのシームレスな統合:
- LinearのProject DescriptionやUpdate機能だけで長文を書くな。重要な意思決定（ADR: Architecture Decision Record）や仕様書はNotionやConfluenceに集約し、LinearのProjectに「Project Documents」として必ずリンクさせろ。コード、タスク管理、ドキュメントの三位一体が揃った瞬間、情報のサイロは完全に破壊される。
—
結言：ツールを飼いならし、開発の純粋なエネルギーを解き放て
LinearのInitiativesとRoadmapは、単なる「綺麗な進捗表」ではない。それは、複雑怪奇に絡み合う複数プロダクトの開発組織を、一つの巨大なベクトルへと収斂させるための誘導ミサイルの誘導装置である。
GUIに依存するな。APIを叩き、データを自動化し、構造をデザインせよ。
ツールに仕事を合わせるのではなく、ツールを自らのアーキテクチャの拡張として飼いならしたとき、開発チームのベロシティは理論値の限界を突破する。
さあ、今すぐコードエディタを開き、最初の自動化スクリプトをデプロイしろ。組織の未来は、あなたの手の中にある。