ストーリー

ミッション概要

前提条件

組織の概要

会社概要:
  会社名: DevFlow株式会社（架空）
  事業: BtoB SaaS（ワークフロー自動化ツール）
  社員数: 400名
  開発部門: 150名
  売上: 年間40億円
  顧客数: 2,500社
  設立: 2016年

開発組織構造:
  CTO 佐藤
  ├── 開発本部長 山田
  │   ├── プロダクトチームA（25名）-- コア機能
  │   ├── プロダクトチームB（20名）-- 連携機能
  │   ├── プロダクトチームC（20名）-- モバイル
  │   └── プラットフォームチーム（15名）-- 共通基盤
  ├── QA部 松本（20名）
  ├── インフラ部 高橋（25名）
  │   ├── SREチーム（10名）
  │   └── クラウドインフラチーム（15名）
  └── セキュリティ部 渡辺（10名）

現在の開発プロセスの状況

各チームの声

開発プロセスの流れ

現状の開発プロセス:

1. 企画（PM）: 要件定義、仕様書作成 → 平均5日
2. 設計（TL）: 技術設計、API設計 → 平均3日
3. 実装（開発者）: コーディング → 平均8日
4. コードレビュー（TL + 別チーム）: → 平均2日（待ち時間: 平均3日）
5. セキュリティレビュー（セキュリティ部）: → 平均1日（待ち時間: 平均5日）
6. QAテスト（QA部）: → 平均5日（待ち時間: 平均3日）
7. ステージング検証: → 平均2日（待ち時間: 平均2日）
8. リリース承認（CTO + 開発本部長）: → 平均0.5日（待ち時間: 平均2日）
9. デプロイ（インフラ部）: → 平均0.5日（待ち時間: 平均1日）

Mission 1: 問題構造分析

要件

前提条件の情報をもとに、DevFlow社の開発速度低下の問題構造を分析してください。

1. なぜなぜ分析: 「リリース頻度が75%減少した」を起点に、5回の「なぜ」で根本原因に到達する
2. 因果ループ図: 主要な悪循環を2つ以上特定し、図示する
3. 制約理論: バリューチェーンのボトルネックを特定し、5つの集中ステップでの改善案を提示する

問題: リリース頻度が週2回→月2回に75%減少

Why 1: なぜリリース頻度が下がったのか？
  → リリース前のテストとレビューに時間がかかりすぎるから

Why 2: なぜテストとレビューに時間がかかるのか？
  → テストは手動で範囲が広い。セキュリティレビューは担当者不足で5日待ち

Why 3: なぜテスト範囲が広く、レビュー待ちが長いのか？
  → チーム間の依存関係が複雑で、1つの変更の影響範囲が読めない。
    セキュリティ部は10名で全チームのレビューを担当している

Why 4: なぜ依存関係が複雑で、セキュリティ部がボトルネックなのか？
  → チーム間のAPI契約が曖昧で事前通知なく変更される。
    セキュリティレビューを自動化・分散する仕組みがない

Why 5: なぜAPI契約の管理とセキュリティの自動化が進まないのか？
  → プラットフォームチームに各チームからの個別依頼が集中し、
    横断的な基盤整備に時間を割けていない。
    組織全体の優先順位付けの仕組みがない

構造的原因:
  「チーム間の依存関係の管理不在」+
  「横断的課題の優先順位付けメカニズムの欠如」+
  「テスト・レビューの自動化投資の不足」

悪循環1: 品質低下スパイラル
  チーム間依存の複雑化 → 変更の影響範囲拡大 → 障害増加
  → 承認プロセス厳格化 → リリース頻度低下
  → 1回のリリースの変更量増大 → チーム間依存の複雑化 (R)

悪循環2: プラットフォームチーム過負荷
  個別依頼の増加 → プラットフォームチームの過負荷
  → 横断基盤の整備遅延 → 各チームが個別にワークアラウンド
  → 技術的一貫性の低下 → さらなる個別依頼の増加 (R)

ボトルネック: セキュリティレビュー（待ち時間5日 = 最長）

1. 制約を特定: セキュリティレビュー（10名で全チーム対応）
2. 徹底活用: レビュー基準の明確化で1件あたりの時間を短縮
3. 従属: 開発チームはセキュリティチェックリストで事前セルフチェック
4. 強化: SAST/DASTツール導入で自動化、各チームにセキュリティチャンピオン配置
5. 次の制約: QAテスト（待ち3日+実行5日）が新たなボトルネックに

Mission 2: バリューストリームマップの作成

要件

開発プロセスの情報をもとに、現状VSMと改善VSMを作成してください。

1. 現状VSM: 各工程のPT、LT、待ち時間を記載し、プロセス効率を算出する
2. ムダの特定: 7つのムダの観点から、最も影響の大きいムダを3つ特定する
3. 改善VSM: 改善後の目標値を設定し、改善ポイントを説明する

Mission 3: ステークホルダーマップの作成

要件

DevFlow社の開発改善プロジェクトについて、ステークホルダー分析を行ってください。

1. ステークホルダーの洗い出し: 主要なステークホルダーを8名以上特定する
2. 影響力×関心度マトリクス: 4ゾーンに分類する
3. RACIチャート: 主要活動5つについてRACIを定義する
4. エンゲージメント戦略: 各ステークホルダーの現在の態度と望ましい態度のギャップを分析する

達成度チェック

推定所要時間: 60分