EXERCISE 90分

ストーリー

田
田中VPoE
成功パターンの抽出、ストーリーテリング、スケーリング戦略、抵抗マネジメント。横展開に必要な知識はすべて揃った。いよいよ実践だ
あなた
NetShop社で成功事例を横展開する計画を策定するんですね
あ
田
田中VPoE
そうだ。パイロットチーム（検索チームと商品チーム）が成功した。この成功を残りの4チームに広げる具体的な計画を立ててくれ。ただし、各チームの状況は異なる。一律のアプローチではなく、チームごとにカスタマイズした計画が必要だ
あなた
抵抗への対処も含めた現実的な計画にします
あ

ミッション概要

項目内容
演習タイトル成功事例の横展開計画
想定時間90分
成果物横展開計画書（成功パターン + スケーリング戦略 + チーム別計画 + 抵抗対策）
対象組織NetShop株式会社（Step 1-3と同一シナリオ）

前提条件

パイロットチームの成果

パイロット結果（6ヶ月後）:

  検索チーム（10名）:
    デプロイ頻度: 週2回 → 日次（+250%）
    リードタイム: 3日 → 4時間（-94%）
    変更障害率: 10% → 5%（-50%）
    MTTR: 1時間 → 20分（-67%）
    Westrumスコア: 4.5（+1.6）

  商品チーム（15名）:
    デプロイ頻度: 週1回 → 日次（+400%）
    リードタイム: 5日 → 8時間（-93%）
    変更障害率: 15% → 8%（-47%）
    MTTR: 2時間 → 30分（-75%）
    Westrumスコア: 4.2（+1.3）

  主な成功要因:
    ・チャンピオンの存在（各チーム1名）
    ・ブレームレスポストモーテムの定着
    ・CI/CDパイプラインのGitHub Actions移行
    ・SREとの共同オンコール

横展開対象チームの状況

チーム人数DORA（現在）特徴予想される抵抗
EC基盤チーム20名低（月2回デプロイ、LT 14日）Jenkinsのレガシーパイプラインが複雑。モノリスアーキテクチャ「モノリスだからDevOpsは無理」「Jenkinsを触りたくない」
決済チーム12名最低（月1回、LT 21日）厳格なセキュリティ要件。変更管理委員会の承認が重い「セキュリティリスクが高い」「承認プロセスは変えられない」
モバイルチーム13名中（2週に1回、LT 10日）アプリストアの審査プロセスがボトルネック「ストア審査があるからデプロイ頻度は上げられない」
フロントエンドチーム10名中〜高（週1回、LT 5日）比較的DevOpsに前向き。スキルレベルが高い抵抗は少ないが「自分たちのペースでやりたい」

Mission 1: 成功パターンを抽出する

要件

パイロットチームの成果から成功パターンを3つ以上抽出してください。

  1. 各パターンをアレグザンダー形式で記述（名前、コンテキスト、問題、解決策、結果）
  2. 「統一すべき要素」と「カスタマイズ可能な要素」の分離
  3. パターン間の依存関係
解答例

パターン1: ブレームレスへの段階的移行

要素内容
コンテキストポストモーテムが形骸化または犯人探しになっている
問題障害から学ぶ文化がなく、同じ問題が繰り返される
解決策Stage 1: 外部ファシリテーター → Stage 2: テンプレート+チーム内ファシリ → Stage 3: 自律運営
統一要素ブレームレスの原則、テンプレート、全社公開のルール
カスタマイズファシリテーターの選定、実施頻度、記録フォーマット

パターン2: CI/CDモダナイゼーション

要素内容
コンテキストレガシーCI/CD（Jenkins）で手動プロセスが多い
問題デプロイが遅く、エラーが起きやすい
解決策GitHub Actionsへの段階的移行。テスト→ビルド→デプロイの順で自動化
統一要素GitHub Actionsのテンプレート、セキュリティスキャンの統合
カスタマイズパイプラインの構成、テスト戦略、デプロイ先の設定

パターン3: 共同オンコールによるオーナーシップ構築

要素内容
コンテキスト障害対応がSREに丸投げされている
問題開発チームのオーナーシップが低く、MTTRが長い
解決策SREとのペアオンコール → シャドウイング → 自律的オンコール
統一要素オンコールのエスカレーションポリシー、ランブック形式
カスタマイズローテーション頻度、対応範囲、サポート体制

依存関係

パターン1（ブレームレス文化）→ パターン3（共同オンコール）→ パターン2（CI/CD改善）

心理的安全性がなければ共同オンコールへの抵抗が強い。共同オンコールでオーナーシップが育ってからCI/CDを改善する方が効果的。

Mission 2: チーム別スケーリング計画を策定する

要件

4チームそれぞれに対して、カスタマイズされたスケーリング計画を策定してください。

  1. チームごとの導入優先順位（どのパターンから始めるか）
  2. 各チームの3ヶ月マイルストーン
  3. 導入順序（全4チームをどの順番で着手するか）
  4. リソース配分計画（チャンピオン、アンバサダーの配置）
解答例

導入順序

1位: フロントエンドチーム（前向き、スキル高い→クイックウィン） 2位: モバイルチーム（中程度の抵抗、独自課題を先に解消） 3位: EC基盤チーム（レガシー課題大きい、丁寧なサポートが必要） 4位: 決済チーム（最も抵抗が強い、他3チームの成功後に着手）

フロントエンドチーム（Month 1-3）

月マイルストーン施策
M1ブレームレスポストモーテム開始商品チームのチャンピオンがファシリテーション指導
M2CI/CD最適化完了既に週1デプロイ→日次化。GitHub Actionsの最適化
M3自律的改善サイクル確立独自のチャンピオンが誕生。他チームへのアンバサダー活動開始

モバイルチーム（Month 2-4）

月マイルストーン施策
M2ストア審査を考慮したCI/CD設計フィーチャーフラグ導入で内部デプロイと審査を分離
M3ブレームレスポストモーテム開始検索チームのチャンピオンが支援
M4共同オンコール開始SREとのペアオンコール

リソース配分

リソース配置先期間
検索チームチャンピオンモバイルチーム支援2週間のアンバサダー派遣
商品チームチャンピオンフロントエンドチーム支援2週間のアンバサダー派遣
変革推進チームEC基盤チーム（最も支援が必要）月4時間の定期コーチング

Mission 3: 抵抗マネジメント計画を策定する

要件

各チームで予想される抵抗に対する具体的な対処計画を策定してください。

  1. チームごとの抵抗分析（ADKARモデルで阻害段階を特定）
  2. キーパーソンへの個別アプローチ計画
  3. 変革のJカーブ対策（パフォーマンス低下期の支援計画）
解答例

EC基盤チームの抵抗分析（ADKAR）

ADKAR段階状態対策
Awareness低（「今のままで十分」）DORAメトリクスで他チームとの差を可視化
Desire低（「モノリスだから無理」）モノリスでも成功した他社事例を共有。段階的アプローチを提示
Knowledge中（技術力は高い）Jenkins→GitHub Actions移行のハンズオン
Ability低（モノリスの複雑さ）アーキテクトチームの支援、モジュラーモノリスへの段階的移行

決済チームへのキーパーソンアプローチ

キーパーソン懸念アプローチ
決済チームリーダーセキュリティリスク「DevSecOpsで今よりセキュリティが強化される」ことを具体例で示す
セキュリティチームリーダー承認プロセスの弱体化「リスクベースの変更分類で、高リスク変更はむしろ厳格に」と提案
CAB議長権限の喪失CABの役割を「承認者」から「リスクアドバイザー」に再定義

Jカーブ対策

期間予想される状況支援策
導入1-2週目新しいツールへの習熟に時間がかかり、一時的に生産性低下ペアプログラミング、アンバサダーによる伴走
導入3-4週目古いプロセスと新しいプロセスの並行運用で混乱明確な移行スケジュール、旧プロセスの段階的廃止
導入5-8週目成果が見え始めるが、まだ安定しない小さな成功を即座に共有、経営層への中間報告

達成度チェック

観点達成基準
パターン抽出成功要因がパターンとして構造化され、統一/カスタマイズの分離ができている
チーム別計画各チームの特性を考慮したカスタマイズされた計画になっている
導入順序リスクと効果を考慮した合理的な順序になっている
抵抗対策ADKARで阻害段階が特定され、キーパーソンへの個別アプローチがある
実現可能性リソース制約の中で実行可能な計画になっている

推定所要時間: 90分