ストーリー
田
田中VPoE
ここまでの5つのStepで、組織横断改善に必要なすべての要素を学んだ。課題の可視化、優先順位付け、チェンジマネジメント、抵抗への対応、効果測定。最後の総合演習だ
あなた
すべてを統合した計画書を作る、ということですね
あ
田
田中VPoE
そうだ。CTOと経営会議に提出する「組織横断改善推進計画書」を完成させる。この文書が承認されれば、全社的な改善プロジェクトが正式にキックオフする
田中VPoEは真剣な表情で続けました。
田
田中VPoE
この計画書には2つの読者がいる。1人目はCTO佐藤。技術的な妥当性と実行可能性を見る。2人目は経営会議のメンバー。投資対効果とリスク管理を見る。両方を納得させる計画書を作ってくれ
あなた
5つのStepで学んだ知見を総動員して、説得力のある1つの計画書にまとめます
あ
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | 組織横断改善推進計画書 |
| 想定時間 | 90分 |
| 成果物 | 組織横断改善推進計画書（経営層承認用・7章構成） |
計画書の構成
以下の7章構成に従って、組織横断改善推進計画書を作成してください。
第1章: エグゼクティブサマリー
1ページで計画の全体像を伝えてください。
| 項目 | 内容 |
|---|---|
| 現状の課題 | DevFlow社の開発組織が直面している課題（データ付き） |
| 改善の目標 | 達成すべきゴール（定量的） |
| 投資と効果 | 必要な投資と期待される効果（ROI） |
| 実行計画 | ハイレベルスケジュール |
| リスクと対策 | 主要リスクの概要 |
解答例
DevFlow社の開発組織は、リードタイム43日（業界平均の3倍）、変更失敗率22%、開発者満足度4.2/10と、深刻な課題を抱えています。チーム間の依存関係管理の不在とプロセスの非効率が構造的原因です。
本計画は30週間で以下を実現します:
- リードタイム: 43日 → 20日（53%短縮）
- デプロイ頻度: 月2回 → 週2回（4倍）
- 変更失敗率: 22% → 10%以下
- 開発者満足度: 4.2 → 7.0以上
必要投資: 5,000万円（ツール・外部支援費）+ 専任2名の人件費 期待効果: 年間1.5億円以上の生産性向上 ROI: 200%以上（2年目以降）
4フェーズで展開: 準備(4W) → パイロット(8W) → 拡大展開(12W) → 定着化(6W)
主要リスクはチーム間の温度差と抵抗ですが、段階的な展開とクイックウィン戦略で対応します。
第2章: 課題分析（Step 1の成果）
| 項目 | 内容 |
|---|---|
| バリューストリームマップ | 現状VSMのサマリー（プロセス効率、ボトルネック） |
| 問題構造分析 | なぜなぜ分析の結果（構造的原因） |
| ステークホルダー分析 | 主要ステークホルダーの利害と態度 |
解答例
バリューストリームマップ:
- プロセス効率: 12%（付加価値時間5.2日 / 総リードタイム43日）
- 最大ボトルネック: コードレビュー待ち（平均72時間）
- 第2ボトルネック: QAテスト待ち（平均5日）
構造的原因:
- チーム間の依存関係管理の不在 → 待ち時間の増大
- テスト自動化の未整備 → 手動QAがボトルネック
- CI/CDパイプラインの不統一 → チーム間のデプロイプロセスが異なり、ベストプラクティスが共有されない
第3章: 改善施策と優先順位（Step 2の成果）
| 項目 | 内容 |
|---|---|
| 施策一覧 | 改善施策の概要 |
| 優先順位 | ICEスコアリング結果 |
| 依存関係 | 施策間の依存マップ |
解答例
| 順位 | 施策 | ICEスコア | 投資対効果 |
|---|---|---|---|
| 1 | CI/CDパイプライン標準化 | 8.5 | 年間3,000万円のコスト削減 |
| 2 | テスト自動化推進 | 8.0 | QA待ち時間70%削減 |
| 3 | コードレビュープロセス改善 | 7.5 | レビュー待ち時間50%削減 |
| 4 | モニタリング統一 | 7.0 | MTTR 75%短縮 |
| 5 | API契約管理導入 | 6.5 | チーム間依存の可視化 |
第4章: ロードマップ（Step 2の成果）
| フェーズ | 期間 | 主要マイルストーン | Go/NoGo基準 |
|---|---|---|---|
| Phase 0: 準備 | Week 1-4 | 体制構築、ベースライン測定 | チーム編成完了 |
| Phase 1: パイロット | Week 5-12 | チームAでの改善実施 | リードタイム30%短縮 |
| Phase 2: 展開 | Week 13-24 | 全チームへの展開 | 4チーム以上で展開完了 |
| Phase 3: 定着 | Week 25-30 | 標準化と効果定着 | 全KPI目標達成 |
第5章: チェンジマネジメント計画（Step 3-4の成果）
| 項目 | 内容 |
|---|---|
| コッター8段階 | 各段階のアクションプラン |
| コミュニケーション計画 | 対象別メッセージ |
| 推進連合 | メンバー構成と役割 |
| 抵抗への対応 | 想定される抵抗と対応戦略 |
解答例
推進連合:
| 役割 | メンバー | 影響力の種類 |
|---|---|---|
| スポンサー | CTO佐藤 | 公式な権限 |
| 変革リーダー | 改善リーダー（あなた） | プロジェクト推進 |
| テクニカルチャンピオン | チームAリーダー | 技術的信頼 |
| QA代表 | QA部長 松本 | 品質の専門性 |
| 非公式リーダー | インフラ部シニア | 非公式な影響力 |
想定される抵抗と対応:
| 抵抗 | 対応 |
|---|---|
| 「忙しいから後にしたい」（慣性的） | 変化しないコストを定量化して提示 |
| 「品質が落ちるのでは」（論理的） | パイロットデータで品質向上を実証 |
| 「自分の仕事がなくなる」（感情的） | 新しい役割とキャリアパスを提示 |
第6章: 効果測定計画（Step 5の成果）
| 項目 | 内容 |
|---|---|
| KPI体系 | 3階層のKPI一覧 |
| ROI算出方法 | コスト項目と効果項目の定義 |
| レポーティング | 月次/四半期の報告計画 |
第7章: リスク管理
| リスク | 影響度 | 発生確率 | 対策 |
|---|---|---|---|
| チーム間の温度差 | 高 | 高 | 段階展開 + クイックウィン |
| QA部の離職リスク | 高 | 中 | キャリアパス設計 + スキル移行支援 |
| スポンサーの関与低下 | 中 | 中 | 月次15分ブリーフィング + 自動レポート |
| 技術的な障壁 | 中 | 低 | 外部コンサル支援 + 段階的導入 |
| 予算超過 | 中 | 低 | フェーズゲートで管理 + リスク準備金10% |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| 全体構成 | 7章すべてが含まれている |
| 一貫性 | 課題分析→施策→ロードマップ→効果測定が論理的につながっている |
| 定量性 | 主要な主張に数字の裏付けがある |
| チェンジマネジメント | 技術面だけでなく、人と組織を動かす計画が含まれている |
| リスク管理 | 楽観的すぎず、リスクと撤退基準が明記されている |
| 実行可能性 | DevFlow社のリソース制約の範囲内で実現可能 |
推定所要時間: 90分