ストーリー
田
田中VPoE
文化メトリクスの設計、サーベイの運用方法、継続的改善サイクル。Step 5の理論はすべて学んだ。いよいよ実践だ
あなた
NetShop社の文化メトリクスダッシュボードを設計するんですね
あ
田
田中VPoE
そうだ。ただし、ダッシュボードはただの「表示板」じゃない。変革の進捗を可視化し、改善アクションを導くための意思決定ツールだ。経営層が見て投資判断ができ、チームリーダーが見て改善ポイントが分かり、エンジニアが見て自分たちの成長を実感できる。読者に応じたビューが必要だ
あなた
メトリクス体系の設計から、サーベイの設問設計、ダッシュボードのレイアウトまで、一気通貫で設計します
あ
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | 文化メトリクスダッシュボード設計 |
| 想定時間 | 60分 |
| 成果物 | メトリクス体系 + サーベイ設問 + ダッシュボードレイアウト + 改善サイクル設計 |
| 対象組織 | NetShop株式会社(Step 1-4と同一シナリオ) |
前提条件
NetShop社の現在の文化変革状況
文化変革の進捗(Month 9時点):
パイロットチーム(2チーム): 変革完了
検索チーム: Westrumスコア 4.5、DORA Elite
商品チーム: Westrumスコア 4.2、DORA High
横展開中(4チーム):
フロントエンドチーム: 展開開始3ヶ月目、ブレームレスPM定着
モバイルチーム: 展開開始2ヶ月目、CI/CD改善中
EC基盤チーム: 展開開始1ヶ月目、Jカーブの底
決済チーム: 展開未着手(来月開始予定)
課題:
・文化変革の進捗を定量的に示せていない
・経営層から「投資効果の可視化」を求められている
・チーム間の進捗差が感覚的にしか把握できていない
利用可能なデータソース
| データソース | 取得可能なデータ |
|---|
| GitHub | PR数、マージまでの時間、レビュー数、クロスチームPR |
| PagerDuty | オンコール参加率、MTTR、インシデント件数 |
| Confluence | ドキュメント更新頻度、ポストモーテムレポート数 |
| Slack | チャネル活動量、リアクション数、質問/回答数 |
| Jira | 改善チケット数、完了率、サイクルタイム |
| Google Forms | サーベイ結果(未導入、これから設計) |
Mission 1: メトリクス体系を設計する
要件
NetShop社の文化変革を測るメトリクスKPI体系を設計してください。
- 5カテゴリ(心理的安全性、学習文化、コラボレーション、オーナーシップ、継続的改善)ごとに2-3個のKPIを設定
- 各KPIのデータソース、計測頻度、目標値を明記
- 自動収集可能な指標とサーベイで収集する指標を区別
解答例
文化メトリクスKPI体系
心理的安全性
| KPI | データソース | 頻度 | 現在値 | 目標値(1年後) | 種別 |
|---|
| Edmonsonスコア(5段階平均) | 四半期サーベイ | 四半期 | 未計測 | 4.0 | サーベイ |
| ポストモーテム発言者率 | ファシリテーター記録 | 毎回 | 40% | 80% | 手動記録 |
| インシデント報告までの平均時間 | PagerDuty | 自動 | 30分 | 10分 | 自動収集 |
学習文化
| KPI | データソース | 頻度 | 現在値 | 目標値(1年後) | 種別 |
|---|
| ポストモーテム実施率 | Confluence | 月次 | 50% | 100% | 自動収集 |
| アクションアイテム完了率(30日以内) | Jira | 月次 | 30% | 80% | 自動収集 |
| CoP/LT参加率 | イベントログ | 月次 | 10% | 30% | 手動記録 |
コラボレーション
| KPI | データソース | 頻度 | 現在値 | 目標値(1年後) | 種別 |
|---|
| クロスチームPR率 | GitHub API | 月次 | 5% | 15% | 自動収集 |
| チーム間コラボレーションスコア | 四半期サーベイ | 四半期 | 未計測 | 4.0 | サーベイ |
| ペアプログラミング実施頻度 | カレンダーデータ | 月次 | 月1回 | 週1回 | 半自動 |
オーナーシップ
| KPI | データソース | 頻度 | 現在値 | 目標値(1年後) | 種別 |
|---|
| 開発者オンコール参加率 | PagerDuty | 月次 | 20% | 70% | 自動収集 |
| SLO設定チーム率 | 内部Wiki | 四半期 | 33%(2/6チーム) | 100% | 手動記録 |
| オーナーシップスコア | 四半期サーベイ | 四半期 | 未計測 | 4.0 | サーベイ |
継続的改善
| KPI | データソース | 頻度 | 現在値 | 目標値(1年後) | 種別 |
|---|
| 改善提案チケット数 | Jira | 月次 | 月5件 | 月20件 | 自動収集 |
| レトロスペクティブ実施率 | カレンダー | 月次 | 50% | 100% | 半自動 |
| 実験実施数 | Jira(ラベル: experiment) | 月次 | 月1件 | 月5件 | 自動収集 |
自動収集 vs サーベイの比率
- 自動収集: 9指標(60%)
- サーベイ: 4指標(27%)
- 手動/半自動: 2指標(13%)
自動収集の比率を高めることで、サーベイ疲れを防ぎつつデータの継続性を確保。
Mission 2: 四半期サーベイを設計する
要件
Mission 1のサーベイ指標を含む四半期サーベイの設問を設計してください。
- 20問以内(回答時間10-15分)
- 5つのカテゴリをカバー
- 回答バイアスを排除した質問設計
- 自由記述は2問まで
解答例
NetShop DevOps文化サーベイ(四半期版)
回答について:
- 所要時間: 約10分
- 回答はチーム単位の匿名(5名以上のチーム)で集計します
- 結果は全社に公開し、改善アクションにつなげます
- 「過去3ヶ月」を振り返って回答してください
セクション1: 心理的安全性(4問)
| # | 質問 | スケール |
|---|
| Q1 | 過去3ヶ月で、チーム内で自分のミスや失敗を率直に報告できた | 1〜5 |
| Q2 | 技術的に「わからない」ことを認めても、否定的な反応をされなかった | 1〜5 |
| Q3 | チームの意思決定に対して異なる意見を述べることが歓迎されていた | 1〜5 |
| Q4 | リスクのある新しいアプローチを試すことが奨励されていた | 1〜5 |
セクション2: 学習文化(4問)
| # | 質問 | スケール |
|---|
| Q5 | インシデント発生後のポストモーテムで、組織として有益な学びが得られた | 1〜5 |
| Q6 | 他チームの知見やベストプラクティスにアクセスし、自チームに取り入れた | 頻度: なし/1回/2-3回/4回以上 |
| Q7 | 新しい技術やツールを試すための時間が確保されていた | 1〜5 |
| Q8 | 社内コミュニティ(CoP、ギルド等)の活動が自分の業務に役立った | 1〜5 |
セクション3: コラボレーション(4問)
| # | 質問 | スケール |
|---|
| Q9 | 開発チームとSRE/運用チームの間で、対等なパートナーシップが築けていた | 1〜5 |
| Q10 | 他チームのメンバーに技術的な相談をする際、気軽に連絡できた | 1〜5 |
| Q11 | コードレビューで建設的かつ学びのあるフィードバックが得られた | 1〜5 |
| Q12 | チーム間の壁(サイロ)が以前より低くなっていると感じた | 1〜5 |
セクション4: オーナーシップ(4問)
| # | 質問 | スケール |
|---|
| Q13 | 自チームのサービスの品質と可用性に対して、チーム全体で責任を持てていた | 1〜5 |
| Q14 | 障害やパフォーマンス問題に対して、開発チームが主体的に対応できた | 1〜5 |
| Q15 | 技術的な意思決定において、十分な裁量が与えられていた | 1〜5 |
| Q16 | 自分の担当サービスのSLI/SLOを理解し、意識して開発していた | 1〜5 |
セクション5: 継続的改善(2問)
| # | 質問 | スケール |
|---|
| Q17 | 業務プロセスやツールの改善提案が実際に実行に移されていた | 1〜5 |
| Q18 | レトロスペクティブが定期的に行われ、具体的な改善につながっていた | 1〜5 |
セクション6: 自由記述(2問)
| # | 質問 |
|---|
| Q19 | 過去3ヶ月で「これは良い変化だ」と感じたことを教えてください |
| Q20 | DevOps文化をさらに良くするために、最も改善すべきことは何ですか |
バイアス対策
| 対策 | 実施方法 |
|---|
| 匿名性の確保 | チーム単位匿名(5名以上) |
| 期間の明示 | 「過去3ヶ月を振り返って」と全セクションに明記 |
| 質問の順序 | セクション内の質問順序をランダム化 |
| 中立的な表現 | 誘導的表現(「~すべき」等)を排除 |
| 回答時間 | 「約10分」と明記し、回答疲れを防止 |
Mission 3: ダッシュボードを設計する
要件
メトリクスを可視化するダッシュボードのレイアウトと、継続的改善サイクルを設計してください。
- 3つのビュー(経営層向け、チームリーダー向け、全社向け)のレイアウト
- 更新頻度とデータ取得の自動化方針
- 四半期ごとの改善サイクルの運用設計
解答例
ダッシュボードビュー設計
ビュー1: 経営層向け(四半期レビュー用)
┌──────────────────────────────────────────────────┐
│ DevOps文化変革ダッシュボード - Executive View │
├──────────────────────────────────────────────────┤
│ │
│ ■ 変革進捗サマリー │
│ ┌────────┬────────┬────────┬────────┐ │
│ │完了 │進行中 │未着手 │全体進捗 │ │
│ │2チーム │3チーム │1チーム │ 67% │ │
│ └────────┴────────┴────────┴────────┘ │
│ │
│ ■ 文化スコア推移(四半期) │
│ 4.5│ ──● │
│ 4.0│ ──● │
│ 3.5│ ──● │
│ 3.0│● │
│ └──Q1──Q2──Q3──Q4── │
│ │
│ ■ DORAとの連動 │
│ 文化スコア +1.0 → デプロイ頻度 +250% │
│ 文化スコア +0.8 → MTTR -67% │
│ │
│ ■ ROI │
│ 投資: 変革推進チーム2名 + ツール = 2,500万円/年 │
│ 効果: 生産性向上 + インシデント削減 = 4,200万円/年 │
│ ROI: 68% │
└──────────────────────────────────────────────────┘
ビュー2: チームリーダー向け(月次レビュー用)
┌──────────────────────────────────────────────────┐
│ DevOps文化メトリクス - Team View │
├──────────────────────────────────────────────────┤
│ │
│ ■ チーム別ヒートマップ │
│ 心理 学習 コラボ オーナー 改善 │
│ 検索 4.5 4.3 4.0 4.2 4.1 │
│ 商品 4.2 4.0 3.8 3.9 3.7 │
│ FE 3.8 3.5 3.5 3.3 3.4 │
│ モバイル 3.5 3.2 3.0 2.8 3.0 │
│ EC基盤 3.0 2.8 2.5 2.3 2.5 │
│ 決済 2.8 2.5 2.3 2.0 2.3 │
│ │
│ ■ 自動収集メトリクス(月次トレンド) │
│ クロスPR率: 5%→8%→12% ↑ │
│ PM実施率: 50%→70%→85% ↑ │
│ オンコール参加率: 20%→35%→45% ↑ │
│ 改善チケット数: 5→10→15 ↑ │
│ │
│ ■ アラート │
│ ⚠ EC基盤チーム: オーナーシップスコアが前月比-0.3 │
│ ⚠ モバイルチーム: CoP参加率が10%を下回っている │
└──────────────────────────────────────────────────┘
ビュー3: 全社向け(常時公開)
┌──────────────────────────────────────────────────┐
│ DevOps文化の今 - Everyone View │
├──────────────────────────────────────────────────┤
│ │
│ ■ 今月のハイライト │
│ ・ポストモーテム実施率が85%に到達! │
│ ・クロスチームPRが先月比+50% │
│ ・CoP参加者が累計50名を突破 │
│ │
│ ■ 全社文化スコア: 3.6 / 5.0(前四半期比 +0.4) │
│ ████████████████████░░░░░░░░░ 72% │
│ │
│ ■ 今四半期の改善テーマ │
│ 「チーム間コラボレーションの強化」 │
│ 目標: クロスチームPR率 15% │
│ 現在: 12% ████████████░░░ 80%達成 │
│ │
│ ■ 最近の成功事例 │
│ 商品チーム: ブレームレスPMでMTTR 75%短縮 │
│ FEチーム: 日次デプロイを達成 │
└──────────────────────────────────────────────────┘
データ取得の自動化方針
| データソース | 取得方法 | 頻度 | 自動化ツール |
|---|
| GitHub | GitHub API (GraphQL) | 日次バッチ | GitHub Actions + BigQuery |
| PagerDuty | PagerDuty API | 日次バッチ | Scheduled Lambda |
| Confluence | Confluence REST API | 週次バッチ | Scheduled Lambda |
| Jira | Jira REST API | 日次バッチ | Scheduled Lambda |
| Google Forms | Google Sheets API | サーベイ完了後 | Apps Script |
| 表示 | Grafanaダッシュボード | リアルタイム | BigQueryデータソース |
四半期改善サイクルの運用設計
| タイミング | 活動 | 担当 | 所要時間 |
|---|
| 四半期初 Week 1 | 前四半期のメトリクス/サーベイ結果の集計 | 変革推進チーム | 3日 |
| 四半期初 Week 2 | 結果の全社公開 + 経営層レビュー | 変革推進チーム | 半日 |
| 四半期初 Week 2 | 文化変革レトロスペクティブ(KPT) | 全チャンピオン | 90分 |
| 四半期初 Week 3 | 改善仮説の策定 + OKR設定 | 変革推進チーム | 1日 |
| 四半期中 | パルスサーベイ(月次) | 全メンバー | 各2分 |
| 四半期中 | 月次メトリクスレビュー | チームリーダー | 各30分 |
| 四半期末 Week 11 | 四半期サーベイの実施 | 全メンバー | 10分 |
| 四半期末 Week 12 | 仮説の検証 + 次四半期の準備 | 変革推進チーム | 2日 |
達成度チェック
| 観点 | 達成基準 |
|---|
| メトリクス体系 | 5カテゴリをカバーし、自動収集/サーベイの区別が明確 |
| サーベイ設計 | バイアス対策がされた20問以内の設問。回答時間10-15分 |
| ダッシュボード | 読者別(経営層/リーダー/全社)のビューが設計されている |
| 改善サイクル | 四半期単位のPDCAが具体的なタイムラインで設計されている |
| 実現可能性 | 既存のデータソースを活用した現実的な設計になっている |
推定所要時間: 60分