【入門編】Linear Data Exportと外部BI連携:BigQueryやLooker Studioでチームのパフォーマンス指標を独自ダッシュボード化する – プロジェクト・ナレッジ管理活用バイブル

こんにちは!開発チームのパフォーマンスを限界突破させるために、日々頭を悩ませているエンジニアリングマネージャー(EM)やテックリードの皆さん。

Linear、最高ですよね。あの圧倒的なキーボードショートカットの軽快さ、無駄を削ぎ落とした洗練されたUI。Jiraの重さに苦しんでいたチームがLinearに移行したときの「開発スピードが上がった!」というあの感覚は、一度味わうと戻れなくなります。

しかし、チームがスケールし、経営陣から「今クウォータのベロシティの傾向はどうなっている?」「ボトルネックはどの工程にあるんだっけ?」と問われるようになると、標準のLinear Insightsだけでは、少し物足りなくなってくるのも事実です。

「特定のラベルがついたタスクの平均リードタイムを見たい」
「担当者別の手戻り率(ステータスが差し戻された回数)を追いたい」
「スプリントごとのスコープクリープ(後からタスクが追加される現象)を定量化したい」

そんな高度な欲求を持つあなたへ。今回は、Linearのデータを外に出し、BigQueryとLooker Studioを組み合わせて「最強の独自ダッシュボード」を構築する全手順を、優しく、そして徹底的にディープに解説します。

これをマスターすれば、あなたのチームのメトリクス計測は劇的に進化し、データに基づいた本質的なカイゼンが回せるようになりますよ。

—

1. なぜLinear標準のInsightsでは物足りないのか?

Linearの標準ダッシュボードは非常に美しく、サイクルタイムやベロシティの概要を素早く把握するのには十分です。しかし、組織が成長するにつれて、以下のような「現場のリアルな問い」に答えられなくなります。

1. 多角的なクロス集計の欠如: 例えば、「特定のプロダクト領域 × 優先度 × 担当チーム」といった複雑な軸でスループットを見たい。
2. 時系列のスナップショット保存: タスクのステータスが「いつからいつまでその状態だったか(サイクルの内訳)」の履歴を長期保存し、トレンド分析したい。
3. 他システム(GitHub PRやSentry等)との結合: Linearのチケットと、GitHubのプルリクエストのリードタイムを結合した真のエンジニアリング効率を測りたい。

これらを解決する唯一にして最高のアーキテクチャが、「Linear → API / Webhook → BigQuery (DWH) → Looker Studio (BI)」 のパイプライン構築です。

—

2. 全体アーキテクチャの把握

まずは、これから作る仕組みの全体像を頭に焼き付けましょう。

[ Linear Workspace ]
│
▼ (GraphQL API / Webhooks)
[ データ同期スクリプト (Python / Cloud Functions等) ]
│
▼
[ Google BigQuery (DWH) ] ──(SQLで整形)──► [ Looker Studio (BI) ]

難しそうに見えますが、安心してください。今回は「最もシンプルかつ堅牢に動くアプローチ」として、LinearのGraphQL APIからデータを抽出し、BigQueryに放り込む基本のステップを一緒に見ていきましょう。

—

3. ステップ1:Linear APIの認証とデータ抽出の基本

Linearの強みの一つは、強力でクリーンな GraphQL API が提供されている点です。まずはAPI叩き方の基礎を押さえましょう。

APIキーの発行

1. Linearの `Settings` > `API` に移動。
2. `Personal API keys` または `Team API keys` から新しいキーを発行します。
3. スコープは `read` 権限があれば十分です(セキュリティ担保のため、最小権限の原則を守りましょう)。

最初の「Hello World」スクリプト(Python)

それでは、Pythonを使ってLinearから直近の課題(Issues)を1件取得してみましょう。必要なライブラリ(`requests`)をインストールし、以下のスクリプトを動かします。

import os
import requests

Linear APIのエンドポイント
LINEAR_API_URL = “https://api.linear.app/graphql”

発行したAPIキーを環境変数から取得
LINEAR_API_KEY = os.getenv(“LINEAR_API_KEY”, “your_api_key_here”)

def fetch_latest_issues():
# 取得したいデータを指定するGraphQLクエリ
# 課題のタイトル、状態、作成日、完了日を取得します
query = “””
{
issues(first: 5) {
nodes {
id
identifier
title
state {
name
}
createdAt
completedAt
}
}
}
“””

headers = {
“Authorization”: LINEAR_API_KEY,
“Content-Type”: “application/json”,
}

response = requests.post(
LINEAR_API_URL,
json={“query”: query},
headers=headers
)

if response.status_code == 200:
data = response.json()
return data.get(“data”, {}).get(“issues”, {}).get(“nodes”, [])
else:
raise Exception(f”Query failed with status code {response.status_code}: {response.text}”)

if __name__ == “__main__”:
print(“Linearから直近のタスクを取得しています…”)
issues = fetch_latest_issues()

for issue in issues:
print(f”[{issue[‘identifier’]}] {issue[‘title’]} (Status: {issue[‘state’][‘name’]})”)

このスクリプトを実行し、ターミナルにLinear上のタスクが表示されれば、データ連携の第一歩は大成功です!

—

4. ステップ2:BigQueryへのデータ蓄積デザイン

APIで取得したデータをそのままBIにつなぐこともできますが、データ分析のプロとして、BigQuery(DWH)を一度挟むことを強く推奨します。

理由は以下の通りです:

  • APIのレートリミット(回数制限)を回避できる。
  • 過去データのスナップショット(日次でどう変化したか)を蓄積できる。
  • SQLを使って、後から柔軟にデータ構造を整形できる。

推奨するBigQueryのテーブル設計

BigQuery内に `linear_analytics` というデータセットを作り、例えば `issues_history` というテーブルを用意します。

— BigQueryでのテーブル作成例(パーティショニングを活用)
CREATE TABLE IF NOT EXISTS `your_project.linear_analytics.issues_history` (
id STRING,
identifier STRING,
title STRING,
state_name STRING,
team_name STRING,
created_at TIMESTAMP,
completed_at TIMESTAMP,
synced_at TIMESTAMP
)
PARTITION BY DATE(synced_at);

毎日一度(または数時間おきに)、先ほどのPythonスクリプトを拡張して、取得した全IssuesデータをBigQueryのこのテーブルに `INSERT`(または上書きロード)するようにcronやCloud Schedulerで自動化します。これだけで、揺るぎないアナリティクス基盤の土台が完成します。

—

5. ステップ3:Looker Studioによる独自ダッシュボード化

データをBigQueryに溜め込めたら、いよいよ魔法の時間の始まりです。Googleが提供する無料のBIツール Looker Studio を立ち上げ、BigQueryをデータソースとして接続しましょう。

現場で絶対に作るべき「3つのキラーチャート」

ダッシュボードには、無駄なグラフを並べる必要はありません。EMやチームが見るべき「本質的な3つ」に絞り込みましょう。

1. スループット推移グラフ(時系列棒グラフ)

  • ディメンション: `completed_at` (週単位)
  • 指標: `Record Count` (完了したタスク数)
  • 意味: チームがコンスタントに価値をデリバリーできているか(ベロシティの安定性)を視覚化します。

2. ステータス別・平均リードタイム(スコアカード / 表)

  • 計算フィールド: `TIMESTAMP_DIFF(completed_at, created_at, DAY)`
  • 意味: アイデアが起票されてから完了するまでに何日かかっているか。ボトルネックが「レビュー待ち」にあるのか「開発中」にあるのかが丸わかりになります。

3. 担当者別 / ラベル別タスク分布(円グラフまたは積み上げ棒グラフ)

  • 意味: 特定のメンバーに負荷が偏っていないか(Cognitive Loadの偏り)を検知し、アジャイルな負荷分散を促します。

—

6. 先輩エンジニアからの実践アドバイス:運用を軌道に乗せるコツ

この環境を構築した私が、現場で得た痛い教訓も含めてアドバイスをいくつか送ります。

  • 完璧を目指さない: 最初からすべての履歴やWebhooksを実装しようとすると挫折します。まずは「今日のIssues一覧をBigQueryに溜めて、Looker Studioで円グラフを1つ出す」ところから始めてください。
  • チームに公開する: このダッシュボードはEMの監視ツールではありません。「チームが自分たちの健全性を知るための窓」として、Slackの専用チャンネルにLooker Studioのリンクをピン留めし、レトロスペクティブ(振り返り)の場で活用してください。

まとめ

今回は、LinearのデータをAPI経由でBigQueryに集約し、Looker Studioで独自のパフォーマンス指標をダッシュボード化する手法を解説しました。

  • Linear標準のInsightsの限界を超えることで、チーム特有の課題が見えてくる。
  • PythonとGraphQL APIを使って、必要なデータを定期的にBigQueryに蓄積する。
  • Looker Studioで「スループット」「リードタイム」を可視化し、データドリブンな改善を回す。

これをマスターすれば、あなたのチームの開発プロセスは一段上のステージへと駆け上がります。毎日の作業や定点観測が劇的に楽に、そしてエキサイティングになりますよ。

さあ、今すぐAPIキーを発行して、あなただけの最強ダッシュボードを作りに行きましょう! Happy Coding!

タイトルとURLをコピーしました