はじめに
開発組織が成長するにつれて、「チームのパフォーマンスをどう計測するか」は避けて通れないテーマになります。
OLTA株式会社では開発生産性を定量的に可視化する基盤を Apache DevLake + Grafana で構築しました。本記事では、ツール選定の判断基準、GCE + Docker Compose + Cloud SQL によるインフラ設計、そして指標設計の考え方までを紹介します。
背景・課題
開発チームが複数のプロダクトを並行開発する体制の中で、以下の課題がありました。
- 開発組織のキャパシティがブラックボックスになっている
- 「どれくらいの時間で、どれくらいのアウトカムが出せるのか」の共通認識がない
- PR のサイクルタイムやスループットが感覚値でしか把握できていない
- 経営層への報告で定量的な説明ができない
「計測できないものは改善できない」という前提のもと、まずは計測基盤を構築することにしました。
ツール選定
検討した選択肢
| ツール |
判断 |
理由 |
| Apache DevLake |
◎ |
Apache 財団傘下で開発強度が高い。GitHub Delpoyment, Issueとの連携が標準サポート。DORA メトリクスのダッシュボードが同梱されており、Grafana ベースでカスタマイズ性も高い。OSS のため無料で始められる |
| 開発生産性 SaaS |
○ |
個人スタッツや DevOps 分析など機能や導入に向けたサポート体制は充実している。ただ「どの指標を見るべきか」が定まっていない段階で SaaS に投資するのは時期尚早と判断し却下。予算に余裕がある場合には間違いない選択肢になりうる |
| Middleware |
△ |
DevLake と同様のアーキテクチャ構成（Python + Flask + TypeScript + Postgres）だが、2025 年にリリースが 2 回のみと開発強度が低く、長期的なメンテナンスリスクが高い |
| 自作 (GitHub API + BigQuery + dbt) |
△ |
柔軟性は最も高いが、データモデルの設計・メンテナンスコストが大きい。DevLake のデータモデルで十分な要件をカバーできた |
選定のポイント
決め手は 「開発強度」と「最速で Four Keys を可視化できること」 の2点でした。
開発生産性 SaaS は完成度が高く、PR のマージ数からチームのスループットを把握したり、個人スタッツを 1on1 で活用するなど、導入後のユースケースも明確でした。しかし、まず無料で小さく始めて指標の有用性を検証し、可視化の文化が定着してから SaaS への移行を検討する方が合理的と判断しました。
Middleware は DevLake と同等の機能を持つ OSS ですが、開発コミュニティの活発さで大きな差がありました。OSS ツールの選定では「今の機能」だけでなく「将来のメンテナンス」も重要な判断基準です。
アーキテクチャ
GitHub (データソース)
↓ GitHub App 経由で収集
┌─────────────────────────────────┐
│ Cloud Load Balancer │
│ (HTTPS / Google マネージド証明書) │
└──────────────┬──────────────────┘
│
┌────▼────┐
│ IAP │ ← 社内ドメインのみ許可
└────┬────┘
│
┌──────────────▼──────────────────┐
│ GCE e2-medium │
│ ┌──────────────────────────┐ │
│ │ Docker Compose │ │
│ │ ┌────────┐ ┌─────────┐ │ │
│ │ │devlake │ │config-ui│ │ │
│ │ │ :8080 │ │ :4000 │ │ │
│ │ └────────┘ └─────────┘ │ │
│ │ ┌────────┐ │ │
│ │ │grafana │ │ │
│ │ │ :3000 │ │ │
│ │ └────────┘ │ │
│ └──────────────────────────┘ │
└──────────────┬──────────────────┘
│ Private IP (VPC 内通信)
┌──────▼──────┐
│ Cloud SQL │
│ MySQL 8.0 │
│ db-f1-micro │
└─────────────┘
DevLake の設定画面
Grafana で可視化された PR Opened / Merged の数
なぜ GKE ではなく GCE + Docker Compose か
| 比較対象 |
不採用理由 |
| GKE |
社内ツールに対してオーバーエンジニアリング。Helm チャートの管理やリソース設計が不要なシンプルさを優先 |
| Cloud Run |
DevLake のデータ収集は長時間実行されるため、60 分のタイムアウト制限に抵触するリスクがある。コストも +$30/月ほど増加 |
GCE + Docker Compose であれば、cloud-init で初期化を自動化でき、最小構成で立ち上げられます。
また何より公式の Release に docker-compose.yml が用意されてるので、Claude Code を使えば数十分構築できます。
なぜ Cloud SQL か
| 比較対象 |
不採用理由 |
| GCE 内 MySQL コンテナ |
ディスク拡張が手動、バックアップ設定を自前で管理する必要がある |
Cloud SQL にすることで、自動バックアップ（7日間保持）と自動ストレージ拡張が得られます。将来 GKE 等へ移行する場合にもデータベースをそのまま使えます。
なぜ GitHub App か
| 比較対象 |
不採用理由 |
| Personal Access Token (PAT) |
退職時のリスク、権限が過剰になりやすい、監査が困難 |
GitHub App は組織に紐づくため、個人の退職に影響されません。権限も必要最小限（Read-only）に設定できます。
構築のポイント
1. Docker Compose の構成
DevLake 公式の docker-compose.yml をベースに、MySQL コンテナを除外し、Cloud SQL に Private IP で接続する構成にしています。
services:
devlake:
image: apache/devlake:latest
environment:
DB_URL: "mysql://devlake:xxx@<CLOUD_SQL_PRIVATE_IP>:3306/lake"
ports:
- "8080:8080"
config-ui:
image: apache/devlake-config-ui:latest
ports:
- "4000:4000"
grafana:
image: apache/devlake-dashboard:latest
ports:
- "3000:3000"
Cloud SQL Proxy ではなく、GCE と Cloud SQL を同一 VPC 内に配置して Private IP で直接接続しています。cloud-init でVM 初回起動時に Docker のインストールとコンテナの起動を自動化しています。
2. IAP による認証
VPN を使わず、Load Balancer + IAP で社内メンバーのみがアクセスできるようにしています。自社ドメインのユーザーだけが認証を通過できる設定です。
3. GitHub App の権限設定
データ収集に必要な権限はすべて Read-only に設定しています。
Repository permissions (Read-only):
- Contents, Pull requests, Commit statuses, Deployments, Actions, Checks, Issues, Metadata, Administration
Organization permissions (Read-only):
- Members
4. シークレット管理
GitHub App の Private Key、App ID、DB パスワード、暗号化キーはすべて GCP Secret Manager で管理しています。
指標設計
可視化する指標
| 指標 |
見たいこと |
データソース |
自動/手動 |
| PR マージ数/週 |
チームのスループット |
GitHub |
自動 |
| 平均サイクルタイム |
PR 作成〜マージまでの速さ |
GitHub |
自動 |
| 投資配分 |
何にどれだけ時間を使っているか |
GitHub (PR ラベル) |
ラベル付与は手動 or CI |
ローカル検証の段階で、平均サイクルタイム 7.56 時間という実データが取れており、DevLake のデータモデルで十分な精度が出ることを確認しています。
投資配分の計測
PR に feature、bugfix、hotfix などのラベルを付与し、ラベルごとに集計することで「チームが何にどれだけの時間を使っているか」を可視化します。
例: 今月の PR 内訳
feature: 60% → 新機能開発
bugfix: 25% → バグ修正
chore: 15% → 技術的負債の返済
これにより「新機能開発にどれくらいの投資ができているか」が定量的に把握でき、経営層との対話に使えます。
ラベルの付与は手動だと信頼性が低いため、GitHub Actions で PR タイトルから自動判定する仕組み、あるいは Claude Code でのPR 作成時に自動付与する仕組みを検討中です。
指標設計で意識したこと
「指標は改善のきっかけであり、個人の評価ではない」 という方針を最初に明文化しました。
開発生産性の数値を個人評価に使うと、数字のゲーミング（PR の細分化、形式的なレビューなど）が発生します。Grafana のダッシュボードへのアクセスもリード以上のエンジニアに限定し、あくまでチーム単位のトレンドを見てプロセス改善の議論に使う、という位置づけを組織内で合意しています。
計画達成率は別の仕組みで
DevLake は GitHub のメトリクス収集には強い一方、Asana や Notion などのプロジェクト管理ツールとの連携は現時点でサポートされていません。「計画に対してどれだけ達成できたか」は別の枠組みで計測する必要があります。
コスト
| 項目 |
月額 (USD) |
| GCE e2-medium |
~$25 |
| Cloud SQL db-f1-micro |
~$15 |
| Load Balancer |
~$20 |
| Persistent Disk 20GB SSD |
~$2 |
| Static IP |
~$3 |
| 合計 |
~$65/月（約 1 万円） |
年間約 $780（約 12 万円）です。開発生産性 SaaS と比較すると、桁が違うコストで同等の基本機能が得られます。
今後の展望
短期
- 経営層への定期報告フローの確立
- PR ラベルの自動付与（GitHub Actions or Claude Code）
- Grafana アラートの設定（サイクルタイムの閾値超過を Slack 通知）
中期
- DORA Four Keys の変更失敗率・復旧時間を計測するため、インシデント管理ツールとの連携
- チームごとのダッシュボード分割
長期
- DevLake のデータを BigQuery にエクスポートし、事業 KPI との相関分析
- AI を活用した開発の生産性向上効果の定量測定（例: コミット量の増加とレビュー指摘数の減少の相関）
まとめ
DevLake は Apache 財団傘下の OSS でありながら、DORA Four Keys の可視化を最速で立ち上げられるツールです。GCE + Docker Compose + Cloud SQL という構成で月額 $65 程度に抑えつつ、IAP と GitHub App で適切なセキュリティを確保できます。
重要なのはツール自体ではなく、可視化した指標をどう使うかです。個人の評価ではなくチームのプロセス改善に使うという方針を先に決めたこと、そしてアクセス権限をリード以上に限定したことで、組織への導入がスムーズに進みました。
開発生産性の可視化はゴールではなくスタートです。まずは OSS で小さく始めて、データに基づいた改善サイクルを回していく ― その第一歩として DevLake は良い選択肢だと考えています。
