ストーリー
田
田中VPoE
成熟度モデル、文化アセスメント、DORAメトリクス — 評価の道具立ては揃った。ここからは実践だ。架空の組織シナリオを使って、DevOps成熟度アセスメントを一通り実施してもらう
あなた
総合的なアセスメントですね。どういった組織が対象ですか
あ
田
田中VPoE
中堅のEC企業だ。DevOpsツールは一通り導入済みだが、「文化が変わらない」と悩んでいる。まさに今回のミッションのど真ん中だ。彼らの現在地を正確に評価し、改善の方向性を提言してくれ
あなた
フレームワークを使って客観的に評価します
あ
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | DevOps成熟度アセスメントの実施 |
| 想定時間 | 60分 |
| 成果物 | DevOps成熟度アセスメントレポート（7軸評価 + Westrum診断 + DORAメトリクス分析 + 改善提言） |
| 対象組織 | 中堅EC企業（社員300名、うち開発120名） |
前提条件
組織の概要
会社概要:
会社名: NetShop株式会社（架空）
事業: BtoC EC（アパレル・雑貨のオンラインストア）
社員数: 300名
開発部門: 120名
売上: 年間200億円
月間アクティブユーザー: 500万人
設立: 2012年
技術スタック:
フロントエンド: React + Next.js
バックエンド: Java (Spring Boot) + Go (一部マイクロサービス)
インフラ: AWS (ECS, RDS, ElastiCache, CloudFront)
CI/CD: Jenkins (レガシー) + GitHub Actions (新規)
モニタリング: Datadog
IaC: Terraform (一部), 手動構築も残る
コミュニケーション: Slack, Confluence
組織構造:
CTO
├── 開発部（80名）
│ ├── EC基盤チーム（20名）← モノリス中心
│ ├── 商品チーム（15名）
│ ├── 決済チーム（12名）
│ ├── 検索・レコメンドチーム（10名）
│ ├── モバイルチーム（13名）
│ └── フロントエンドチーム（10名）
├── インフラ部（25名）
│ ├── SREチーム（8名）
│ ├── ネットワーク・セキュリティチーム（7名）
│ └── DBA（4名）+ クラウドインフラ（6名）
└── QA部（15名）← 独立した組織DevOps関連の現状データ
DORAメトリクス（直近6ヶ月の平均）:
| メトリクス | EC基盤チーム | 商品チーム | 決済チーム | 検索チーム | モバイル |
|---|---|---|---|---|---|
| デプロイ頻度 | 月2回 | 週1回 | 月1回 | 週2回 | 2週に1回 |
| 変更リードタイム | 14日 | 5日 | 21日 | 3日 | 10日 |
| 変更障害率 | 25% | 15% | 30% | 10% | 20% |
| MTTR | 4時間 | 2時間 | 8時間 | 1時間 | 6時間 |
文化サーベイ結果（全社平均、7段階）:
| 項目 | スコア |
|---|---|
| 情報共有が活発に行われている | 3.8 |
| 失敗やミスから学ぶ姿勢がある | 3.2 |
| 新しいアイデアが歓迎される | 4.1 |
| チーム間の協力は自発的に行われる | 2.9 |
| 問題を報告する人は評価される | 3.0 |
| リスクを取ることが奨励されている | 3.5 |
| 部門間の対立は建設的に解決される | 2.7 |
インタビュー抜粋:
| 発言者 | コメント |
|---|---|
| EC基盤チームリーダー | 「Jenkinsのパイプラインが複雑化していて誰もメンテしたくない。でも動いているから触れない」 |
| SREチームリーダー | 「開発チームがデプロイしたあと、障害の対応はうちに丸投げされる。共同責任なんて名ばかり」 |
| 商品チームメンバー | 「GitHub Actionsに移行してからデプロイが楽になった。でも他チームはまだJenkins」 |
| QA部長 | 「リリース前のテストフェーズが2週間。自動テストが不十分なので手動テストが必須」 |
| 決済チームリーダー | 「セキュリティと変更承認のプロセスが重くて、簡単な修正でも1週間かかる」 |
| CTO | 「DevOpsツールには投資した。でも本番障害は減らないし、リリーススピードも上がらない」 |
| 開発メンバーA | 「ポストモーテムはやるけど、いつも同じ結論。で、アクションアイテムは放置される」 |
| インフラメンバーB | 「Terraformはあるが、緊急時にコンソールから直接変更する人がいて、ドリフトが発生する」 |
Mission 1: 7軸成熟度評価の実施
要件
前提条件の情報をもとに、NetShop社のDevOps成熟度を7軸で評価してください。
- 7軸それぞれのスコア（Level 1-5）と根拠
- レーダーチャートの概形（テキストで表現）
- 最も成熟している軸と最も遅れている軸の特定
解答例
7軸評価
| 評価軸 | レベル | 根拠 |
|---|---|---|
| CI/CD | 2 | Jenkins（レガシー）とGitHub Actions（新規）が混在。一部チームで自動化が進んでいるが全社標準化はされていない |
| インフラ管理 | 2 | Terraform導入済みだが、手動変更が残る。緊急時のコンソール直接変更でドリフト発生 |
| モニタリング | 3 | Datadogを全社導入。ただしSLI/SLOの定義がチームによってまちまちと推測 |
| コラボレーション | 2 | SREチームへの障害対応「丸投げ」が常態化。QA部が独立組織で開発とのサイロあり |
| 学習と改善 | 1 | ポストモーテムは実施するが形骸化。アクションアイテムが放置される |
| セキュリティ | 2 | 決済チームに重い変更承認プロセスがある。ただしシフトレフトされておらずスピードとの矛盾 |
| ガバナンス | 2 | 変更管理プロセスは存在するが、チームごとにバラバラ。統一的なガバナンスフレームワークなし |
最も成熟: モニタリング（Level 3）
最も遅れ: 学習と改善（Level 1）
Mission 2: Westrum組織文化診断
要件
文化サーベイ結果とインタビュー抜粋を分析し、以下を作成してください。
- Westrum組織類型の判定（スコアと根拠）
- 5つの文化次元の評価（心理的安全性、学習志向、共同責任、継続的改善、顧客志向）
- サーベイ結果とインタビュー発言の乖離点の指摘
解答例
Westrum組織類型
平均スコア: 3.3 → 官僚的（Bureaucratic）
| 項目 | スコア | 分析 |
|---|---|---|
| 情報共有 | 3.8 | 中程度。Slackは使っているが、チーム間の壁がある |
| 失敗から学ぶ | 3.2 | 低め。ポストモーテムが形骸化していることと整合 |
| 新しいアイデア | 4.1 | 比較的良好。ただしチームによって差が大きいと推測 |
| チーム間協力 | 2.9 | 低い。SREの「丸投げ」発言と整合 |
| 問題報告の評価 | 3.0 | 低い。問題を報告しても「犯人探し」になる兆候 |
| リスクの奨励 | 3.5 | 中程度。一部チーム（検索）は実験的、他は保守的 |
| 対立の解決 | 2.7 | 最低スコア。部門間の対立が建設的に解決されていない |
5つの文化次元
| 次元 | 評価 | 根拠 |
|---|---|---|
| 心理的安全性 | 低〜中 | 問題報告の評価が3.0。犯人探しの文化が残っている可能性 |
| 学習志向 | 低 | ポストモーテムの形骸化、アクションアイテムの放置 |
| 共同責任 | 低 | SREへの丸投げ、QA独立組織によるサイロ |
| 継続的改善 | 低 | Jenkins問題の放置（「動いているから触れない」） |
| 顧客志向 | 中 | EC事業なので顧客指標は意識しているが、内部プロセスの議論が中心 |
サーベイとインタビューの乖離
- 「新しいアイデアが歓迎される」（4.1）は比較的高いが、「動いているから触れない」という発言と矛盾。アイデアは歓迎されるが実行に移されない可能性がある
Mission 3: 統合分析と改善提言
要件
Mission 1と2の結果を統合し、以下を作成してください。
- DORAメトリクスの全社分析（チーム間のばらつきと全社平均の判定）
- 成熟度 × 文化 × DORAの統合分析（3つの評価の相関）
- 優先度付き改善提言（短期・中期・長期の3フェーズ）
解答例
DORAメトリクス全社分析
| メトリクス | 全社平均 | 判定 | チーム間ばらつき |
|---|---|---|---|
| デプロイ頻度 | 約週1回 | Medium | 大きい（月1回〜週2回） |
| 変更リードタイム | 約10日 | Medium | 大きい（3日〜21日） |
| 変更障害率 | 約20% | Medium | 中程度（10%〜30%） |
| MTTR | 約4時間 | High | 大きい（1時間〜8時間） |
全社判定: Medium（ただしチーム間のばらつきが最大の課題）
統合分析
| 観点 | 分析 |
|---|---|
| 技術 vs 文化のギャップ | モニタリング（L3）は技術投資で進んでいるが、学習と改善（L1）が追いついていない。典型的な「ツール先行・文化遅延」パターン |
| DORAとWestrumの相関 | 検索チーム（DORA最良）はWestrumの「新しい試み」が高いと推測。決済チーム（DORA最悪）は重いガバナンスプロセスがボトルネック |
| 最大のボトルネック | コラボレーション（L2）と学習文化（L1）の低さがDORA全指標を制約している |
改善提言
| フェーズ | 期間 | 施策 | 期待効果 |
|---|---|---|---|
| 短期 | 0-3ヶ月 | ブレームレスポストモーテムの再設計とアクションアイテム追跡の仕組み化 | 学習文化の立ち上げ（L1→L2） |
| 短期 | 0-3ヶ月 | 検索チームの成功パターンを他チームへ共有するショーケース開催 | チーム間ばらつきの縮小 |
| 中期 | 3-6ヶ月 | SREと開発チームの共同オンコール体制構築（Shared ownership） | コラボレーション改善（L2→L3） |
| 中期 | 3-6ヶ月 | CI/CDパイプラインの全社標準化（Jenkins→GitHub Actions移行） | CI/CD成熟度向上（L2→L3） |
| 長期 | 6-12ヶ月 | 全チームでのDORAメトリクス計測と文化サーベイの定期実施 | データ駆動の継続的改善サイクル確立 |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| 7軸評価 | 各軸にエビデンスに基づくレベル判定と根拠がある |
| Westrum診断 | サーベイスコアとインタビュー発言を統合した分析がある |
| DORA分析 | チーム間のばらつきを把握し、全社平均の判定が妥当 |
| 統合分析 | 3つの評価結果を横断的に分析し、相関を見出している |
| 改善提言 | 優先度とフェーズが明確で、実行可能な施策が提示されている |
推定所要時間: 60分