Linearの限界を突破せよ：BigQueryとLooker Studioで構築する、究極のエンジニアリング・パフォーマンス・パイプライン
組織がスケールし、アジャイル開発のベロシティが最大化するにつれ、標準のプロジェクト管理ツールが持つ「デフォルトの可視化機能」の限界に直面する。Linearはその洗練されたUIと圧倒的なキーボード・ナビゲーションで開発体験の極北に位置しているが、標準の「Insights」機能だけでは、データドリブンなエンジニアリングマネージャー（EM）やデータアナリストの飢えを満たすことはできない。
「特定のコンポーネントごとの手戻り率（Reopened Rate）のトレンドはどうなっているか？」
「サイクルタイムのp95値は、どのチームのどのラベルのタスクで跳ね上がっているか？」
「PRのマージからデプロイまでのリードタイムと、Linear上のステータス遷移の相関は何か？」
これらに答えるためには、Linearのデータを完全に掌握し、DWH（Data Warehouse）へリアルタイムに同期した上で、BIツールで独自の多次元分析モデルを構築するほかない。
本稿では、LinearのGraphQL APIおよびWebhooksを駆使してBigQueryへデータを全量・差分同期し、Looker Studioで「現場が本当に使える」カスタムダッシュボードを構築するアーキテクチャの全貌を解説する。生半可な連携ではない。高負荷に耐え、スキーマ進化（Schema Evolution）を考慮した、プロダクショングレードのパイプライン設計の極意を授けよう。
—
1. 全体アーキテクチャ：なぜ「APIポーリング」ではなく「イベント駆動＋日次スナップショット」なのか
データのサイロ化を防ぎ、かつアナリティクスのパフォーマンスを最大化するためには、データの鮮度と整合性のバランスを取る必要がある。
[Linear Webhooks] ──(リアルタイム)──> [Cloud Functions / Cloud Run]
│
[Linear GraphQL API] ──(日次フル同期)────────┼──> [Google Cloud BigQuery (DWH)]
│ │
▼ ▼
[Cloud Storage] [Looker Studio (BI)]
アーキテクチャの要件定義
1. リアルタイム性（イベント駆動）: ステータスの遷移やコメント追加などのアクティビティは、Webhooksをトリガーに即座にBigQueryへストリーミングインサートする。
2. 整合性（フルスナップショット）: Webhooksの取りこぼしやデータ不整合（データドリフト）を防ぐため、日次でGraphQL APIを叩き、全Issues/Projectsの現在の状態を上書き・マージするバッチを走らせる。
3. スキーマ設計: Linearの動的なカスタムフィールドや複雑なリレーション（Issue, Cycle, Project, Label, User）を、BigQuery上でネスト・リピート構造（`ARRAY` / `STRUCT`）を駆使して効率的にモデリングする。
—
2. Linear GraphQL APIからの効率的データ抽出（Python実装）
LinearのAPIは強力だが、数万件規模のIssueを持つ組織において、単純なページネーションはネットワークI/Oのボトルネックになる。カーソルベースのページネーション（Relayスタイル）を正しく実装し、レートリミット（Rate Limit）のハンドリングを組み込んだ堅牢なエクストラクターを書く必要がある。
以下は、BigQueryへ直接バルクインサートを行うためのPythonスクリプトのコアロジックだ。
import os
import time
requests
from google.cloud import bigquery
LINEAR_API_URL = “https://api.linear.app/graphql”
API_KEY = os.environ.get(“LINEAR_API_KEY”)
BQ_PROJECT = os.environ.get(“BQ_PROJECT”)
BQ_DATASET = “linear_raw”
headers = {
“Authorization”: API_KEY,
“Content-Type”: “application/json”
}
def fetch_issues_page(cursor=None):
“””
Linear GraphQL APIからIssuesをカーソルベースで取得する。
レートリミット（complexity）を考慮し、必要に応じてバックオフを行う。
“””
query = “””
query ($after: String) {
issues(first: 100, after: $after) {
pageInfo {
hasNextPage
endCursor
}
nodes {
id
identifier
title
state { name type }
assignee { id email }
team { id name }
createdAt
updatedAt
completedAt
canceledAt
dueDate
estimate
cycle { id number }
project { id name }
labels { nodes { id name } }
}
}
}
“””
variables = {“after”: cursor}
response = requests.post(
LINEAR_API_URL,
json={“query”: query, “variables”: variables},
headers=headers
)
if response.status_code == 429:
print(“Rate limit hit. Backing off for 60 seconds…”)
time.sleep(60)
return fetch_issues_page(cursor)
data = response.json()
if “errors” in data:
raise Exception(f”GraphQL Error: {data[‘errors’]}”)
return data[“data”][“issues”]
def sync_issues_to_bigquery():
client = bigquery.Client(project=BQ_PROJECT)
table_id = f”{BQ_PROJECT}.{BQ_DATASET}.issues_snapshot”
has_next_page = True
cursor = None
all_rows = []
print(“Starting Linear Issues extraction…”)
while has_next_page:
result = fetch_issues_page(cursor)
nodes = result[“nodes”]
page_info = result[“pageInfo”]
for node in nodes:
# BigQueryのスキーマに合わせたマッピング
row = {
“id”: node[“id”],
“identifier”: node[“identifier”],
“title”: node[“title”],
“state_name”: node[“state”][“name”] if node[“state”] else None,
“state_type”: node[“state”][“type”] if node[“state”] else None,
“assignee_email”: node[“assignee”][“email”] if node[“assignee”] else None,
“team_name”: node[“team”][“name”] if node[“team”] else None,
“created_at”: node[“createdAt”],
“updated_at”: node[“updatedAt”],
“completed_at”: node[“completedAt”],
“estimate”: node[“estimate”],
“cycle_number”: node[“cycle”][“number”] if node[“cycle”] else None,
“project_name”: node[“project”][“name”] if node[“project”] else None,
“labels”: [label[“name”] for label in node[“labels”][“nodes”]],
“synced_at”: time.strftime(‘%Y-%m-%d %H:%M:%S’)
}
all_rows.append(row)
has_next_page = page_info[“hasNextPage”]
cursor = page_info[“endCursor”]
# BigQueryへロード（パーティション・クラスタリングを効かせたテーブルにMERGEするのがベスト）
print(f”Loaded {len(all_rows)} issues. Inserting into BigQuery…”)
errors = client.insert_rows_json(table_id, all_rows)
if errors:
print(f”Encountered errors while inserting rows: {errors}”)
else:
print(“Successfully synced Linear snapshot to BigQuery.”)
if __name__ == “__main__”:
sync_issues_to_bigquery()
—
3. BigQueryでのデータモデリング：生のログを「使える指標」へ昇華させる
単に生データをDWHに突っ込むだけでは、BIツール側で複雑な計算が発生し、クエリコストが爆発する。BigQuery側で中間テーブル（Datamart）を構築し、アジャイルの主要指標をあらかじめ算出しておくことがエンジニアリングマネージャーの腕の見所だ。
サイクルタイム（Cycle Time）とリードタイム（Lead Time）の算出SQL
以下のSQLは、Issueが「作成されてから完了（Completed）するまで」の時間を算出し、チームごとのp50/p95を割り出すためのマート作成クエリである。
CREATE OR REPLACE TABLE `your-project.linear_datamart.fct_issue_metrics` AS
SELECT
id,
identifier,
team_name,
project_name,
estimate,
created_at,
completed_at,
— 営業日考慮やタイムゾーン補正を入れる場合はここでTIMESTAMP_DIFFを調整
TIMESTAMP_DIFF(completed_at, created_at, HOUR) AS lead_time_hours,
— ステータスが “started” になってからの時間をInProgress Timeとする場合は履歴テーブルと結合
CASE
WHEN TIMESTAMP_DIFF(completed_at, created_at, HOUR) <= 24 THEN 'Under 1 day'
WHEN TIMESTAMP_DIFF(completed_at, created_at, HOUR) <= 72 THEN '1-3 days'
ELSE '3+ days'
END AS lead_time_bucket
FROM
`your-project.linear_raw.issues_snapshot`
WHERE
completed_at IS NOT NULL
AND created_at IS NOT NULL;
さらに、このマートに対して次のような集計ビューやテーブルを用意することで、BI側の描画速度を0.2秒以下に抑えることが可能になる。
-- チームごとのサイクルタイム・パーセンタイル集計
SELECT
team_name,
APPROX_QUANTILES(lead_time_hours, 100)[OFFSET(50)] AS p50_lead_time_hours,
APPROX_QUANTILES(lead_time_hours, 100)[OFFSET(95)] AS p95_lead_time_hours,
COUNT(id) AS completed_issues_count
FROM
`your-project.linear_datamart.fct_issue_metrics`
GROUP BY
team_name;
---
4. Looker Studioによる独自ダッシュボードの構築：真の可視化
BigQueryに最適化されたデータマートができあがれば、あとはLooker Studio（旧Google Data Studio）を接続するだけだ。標準のInsightsでは決して描けない、以下の「攻めのダッシュボード」を構築せよ。
A. 組織スループットとベロシティの乖離トレンド
- グラフ形式: 複合グラフ（棒グラフ：週次完了ストーリーポイント、折れ線グラフ：p95サイクルタイム）
- 示唆: 「ベロシティ（ポイント数）は上がっているが、p95のサイクルタイムも悪化している」場合、技術的負債の蓄積や、1タスクあたりのスコープ肥大化（Bloat）が起きていると即座に検知できる。
B. ボトルネック・ヒートマップ
- グラフ形式: ピボットテーブル（行：チーム、列：現在のステータス、値：Issue数・平均滞留日数）
- 示唆: 「In Review」や「QA」のステータスで何日も滞留しているカードを赤くハイライトすることで、コードレビュープロセスの詰まりやQAリソースの不足を定量的につきつける。
C. ラベル別・手戻り影響度分析
- グラフ形式: 散布図（X軸：累計Issue数、Y軸：Reopen回数、バブルサイズ：平均リードタイム）
- 示唆: 「`bug`」や「`tech-debt`」というラベルがついたタスクが、どの程度開発リソースを蝕んでいるかを可視化し、プロダクトバックログリファインメントの優先順位付けの強力な武器とする。
—
5. 運用上の極意とアンチパターン
最後に、このパイプラインを数年にわたって運用し続けるための、現場の知見に基づく教訓を記す。
1. APIレートリミットを甘く見てはならない:
LinearのAPIはComplexity（複雑性）に基づくリミットを採用している。一度に全フィールド（特にコメントや履歴の全履歴）を取得しようとすると、すぐにブロックされる。必要最小限のフィールド選択（Field Selection）を徹底すること。
2. Webhooksの冪等性（Idempotency）の担保:
リアルタイム同期のためにCloud FunctionsでWebhooksを受ける場合、同一イベントが重複配送されることは日常茶飯事である。BigQueryへのインサート時は、`event_id`や`timestamp`をキーにした重複排除（Deduplication）のロジックを必ず挟むこと。
3. スキーマ変更（Schema Evolution）への耐性:
Linear側がカスタムフィールドや新しいメタデータを追加した際、素朴なJSONパーサーは即座にクラッシュする。BigQueryの `JSON` 型を活用するか、マート構築層でパースエラーをハンドリングする堅牢な設計にしておくべきだ。
—
結びにかえて：データを「武器」に変えるエンジニアリング
ツールを使いこなす段階から、ツールを「ハックして自社の組織最適化のエンジンにする」段階へ移行したとき、開発組織のパフォーマンスは非線形に跳ね上がる。
Linearの美しさはそのスピードにあるが、そのデータをBigQueryとLooker Studioという強固なパイプラインで昇華させた瞬間、それは単なるチケット管理システムから、「組織の健康状態を映し出す鏡、そして未来のボトルネックを予測する予言装置」へと変貌を遂げる。
さあ、APIキーを発行し、パイプラインのコードをデプロイせよ。あなたのチームの真のベロシティが、今、可視化される。