SREチームを「事業貢献が見える組織」に変える：6つの目標設定スキームと自動可視化基盤の構想
- #SRE
- #目標設定
- #KPI
- #可視化
- #BigQuery
- #LookerStudio
- #DevOps
「SREって、何してるかわかりにくいよね」
こう言われたことはないでしょうか。障害が起きなければ目立たない、起きたときだけ矢面に立つ——それがSREの宿命のように語られることがあります。しかし本来、SREはサービスの信頼性を技術で担保し、開発スピードを落とさずに事業成長を支える存在です。
その貢献が見えないのは、貢献の「計測・可視化」が設計されていないからです。
この記事では、SREチームをコストセンターから「事業貢献を数値で証明する組織」へと変えるための、6つの目標設定カテゴリーと自動可視化基盤の構想を紹介します。
設計の基本方針：多角的な貢献を称え合う文化へ {#design-policy}
この目標設定スキームは、「やっていない人を見つける」ためのものではありません。
エンジニアによって得意領域は異なります。障害対応が強い人、コードレビューで組織を支える人、AI活用で業務を変革する人——そのすべてを「貢献」として可視化し、称え合える仕組みを目指します。
そのために重要なのが、既存ツールのデータを自動的に収集・集計する基盤です。Jiraのチケットやリポジトリのコミット履歴、監視ツールのインシデントログは、すでにチームの活動ログとして存在しています。それを人手を介さずに可視化することで、エンジニアは入力作業から解放され、本質的な開発・運用業務に集中できます。
6つの目標カテゴリーとKPI定義 {#six-categories}
① Business Impact（事業インパクト）
SREを “Revenue Protection Agency（収益保護機関）” と定義し、技術指標を事業の数字に翻訳します。障害はただの「システム停止」ではなく、機会損失です。それを可視化することで、SREへの投資対効果を経営層に伝えられます。
| KPI | 概要 |
|---|---|
| Incident Impact Time | 障害によるサービス停止時間 |
| Revenue at Risk | 障害発生時の推定損失額（機会損失） |
| SLO Achievement Rate | サービスレベル目標の達成率 |
② Reliability Engineering（信頼性エンジニアリング）
システムの安定性を維持し、障害の影響を最小化する能力を測ります。MTTRやエラー予算の消費ペースは、チームの技術的成熟度を示す指標です。
| KPI | 概要 |
|---|---|
| MTTR / MTTA | 平均復旧時間・平均認知時間 |
| Error Budget Consumption | エラー予算の消費スピード |
| Incident Recurrence Rate | 同一障害の再発率 |
③ Delivery Velocity（開発スピード / Move Fast）
「速く動く」とは、雑にやることではありません。小さな単位で素早く価値を届ける仕組みを整えることが「Move Fast」の本質です。
| KPI | 概要 |
|---|---|
| Deployment Frequency | 本番デプロイの頻度 |
| Time to First Commit | アイデアから最初のアクションまでの速さ |
| Small Batch Rate | 小さな単位でリリースできているかの割合 |
④ Operational Agility（運用の機敏性）
開発プロセスのボトルネックを可視化します。「レビューが詰まっているのか」「マージに時間がかかっているのか」を数字で把握することで、改善施策を打てます。
| KPI | 概要 |
|---|---|
| Review Lead Time | MR作成から初回レビューまでの時間 |
| Merge Lead Time | MR作成からマージまでの総時間 |
⑤ Technical Excellence（AI活用と技術卓越性）
AIを単なる検索ツールとして使うのではなく、業務プロセスを再設計するレベルの活用を目指します。AIの「使った・使わない」ではなく、実質的なインパクトを測ることが重要です。
| KPI | 概要 |
|---|---|
| AI Assisted MR Rate | AIが寄与したマージリクエストの割合 |
| AI Impact Score | 削減時間 × 影響人数 × 頻度 で算出するインパクト指数 |
⑥ Community & Influence（コミュニティと影響力）
数字に表れにくい貢献——チームを跨いだ支援、ドキュメント整備、知識共有——を評価します。いわゆる「縁の下の力持ち」を可視化するカテゴリーです。
| KPI | 概要 |
|---|---|
| Review Participation Count | 他者のコードへのレビュー参加数 |
| Knowledge Sharing | ドキュメント作成・勉強会開催などの頻度 |
データの自動収集基盤：人に入力させない {#data-pipeline}
KPIを定義しても、手動で集計していては継続できません。「人に入力させない」設計が、この仕組みを持続させる鍵です。
Single Source of Truth：既存ツールをデータソースにする
新しいツールを導入する必要はありません。チームがすでに使っているツールが、活動ログの宝庫です。
チケット管理・バックログ系
- Jira、Backlog、GitHub Issues、Linear など
バージョン管理系
- GitHub、GitLab、Bitbucket など（コミット・MR・デプロイ履歴）
監視・オブザーバビリティ系
- Datadog、New Relic、Grafana、PagerDuty など（インシデント・SLO・アラート）
これらを Single Source of Truth（唯一の信頼できる情報源） として位置づけ、APIで定期的にデータを取得します。
パイプラインの構成例
各ツールのAPI
↓（定期Pull）
スケジューラー（Cloud Run / Cloud Functions / Lambda など）
↓
データウェアハウス（BigQuery / Snowflake / Redshift など）
↓（SQLでKPI定義・集計）
可視化ツール（Looker Studio / Tableau / Grafana など）ポイントは、KPIの計算ロジックをデータウェアハウス側のSQLで定義することです。ツール側に計算を持たせると、ツール変更のたびにロジックが散逸します。BigQueryなどに集約することで、KPIの定義変更・追加が柔軟に行えます。
設計の考え方
- Pull型で定期収集：Webhook依存ではなく、定期バッチでデータを引っ張る設計にすることで、ツール側の変更に強くなります。
- 生データを保持：集計前の生ログをそのまま保存しておくことで、後からKPI定義を変えても再計算できます。
- KPIロジックはSQL：エンジニアなら誰でも読み書きできるSQLでKPIを定義することで、属人化を防ぎます。
Looker Studioでの可視化と役割別ビュー {#visualization}
データが集まったら、誰でもいつでも見られるダッシュボードとして公開します。
役割別ビューの設計
Executiveビュー（経営層向け）
- SLO達成率、Revenue at Risk、Incident Impact Timeを中心に構成
- 「今月、サービスはどれだけ安定していたか」「障害による機会損失はいくらか」が一目でわかる
Flow Analysisビュー（現場向け）
- Review Lead Time、Merge Lead Timeなどのボトルネック指標
- 「どこで詰まっているか」を可視化し、改善施策に繋げる
Contributionビュー（メンバー別）
- 各カテゴリーのKPIをメンバー軸で可視化
- 「あの人はレビューが多い」「AI活用が進んでいる」など、多軸の貢献を可視化
重要な設計思想：貢献を称えるための可視化
このダッシュボードの目的は監視ではなく、貢献の発見です。グラフを見て「この人は数字が低い」ではなく、「この人はこの軸で突出している」という読み方ができる設計にします。
さらに、可視化されたデータを表彰制度に繋げることで、文化として定着させることができます。例えば：
- Reliability Guardian Award：障害対応・再発防止で貢献したメンバー
- AI Transformer Award：AI活用で業務を変革したメンバー
- Team Enabler Award：レビューや知識共有でチームを支えたメンバー
まとめ：数字が文化をつくる {#summary}
SREの貢献は、仕組みがなければ見えません。
6つのカテゴリーでKPIを設計し、既存ツールのデータを自動収集して可視化する——この基盤を整えることで、SREチームは「何をしているかわからない組織」から「事業貢献が数字で見える組織」へと変わります。
重要なのは、完璧なシステムを最初から作ることではありません。まず1〜2個のデータソースと1〜2個のKPIから始め、徐々に拡張していく進め方が現実的です。
チームの活動はすでにツールのログとして存在しています。あとはそれを「見える化」するだけです。