ストーリー
なぜ「組織横断の改善」が必要なのか
局所最適と全体最適の罠
多くの組織では、各チームが自チームの効率化に注力しています。しかし、チーム単位の最適化が組織全体の最適化につながるとは限りません。
局所最適の例:
開発チーム: 「コード品質を上げよう」→ レビュー基準を厳格化
→ レビュー待ち時間が3日に増加
→ QAチームへの受け渡しが遅延
→ リリースサイクルが2週間→4週間に悪化
QAチーム: 「バグを減らそう」→ テストケースを3倍に増加
→ テスト実行に1週間必要
→ 開発チームのフィードバックループが遅延
→ 修正コストが5倍に増加
インフラチーム: 「安定性を上げよう」→ 変更承認プロセスを厳格化
→ デプロイ頻度が月1回に低下
→ 1回のデプロイに含まれる変更が巨大化
→ 障害発生時の原因特定が困難に
「各チームは正しいことをしている。しかし、組織全体で見ると全員が全員の足を引っ張っている。これが局所最適の罠だ」 — 田中VPoE
組織横断改善のインパクト
| 改善の範囲 | 典型的なインパクト | 難易度 |
|---|---|---|
| 個人の改善 | 1人の生産性10%向上 | 低い |
| チーム内改善 | 5-10人の生産性20%向上 | 中程度 |
| 組織横断改善 | 50-200人の生産性30%向上 | 高い |
| 全社改善 | 全社員の働き方が変わる | 極めて高い |
組織横断改善が失敗する5つのパターン
| パターン | 症状 | 根本原因 |
|---|---|---|
| 技術偏重 | 優れたツールを導入したが誰も使わない | 人と組織の課題を無視している |
| トップダウン押し付け | 経営層の号令で始まるが現場が動かない | 現場の痛みを理解していない |
| ボトムアップ空回り | 草の根活動が広がらず疲弊する | 経営層の支援がない |
| 合意なき実行 | 一部の推進者が強引に進めて反発を招く | ステークホルダーの合意形成を怠った |
| 効果不明 | 改善活動自体が目的化し、成果が見えない | 効果測定の仕組みがない |
組織横断改善に必要な4つの力
組織横断改善に必要な力:
1. 可視化する力(Step 1)
└── 組織全体の課題を構造的に分析し、見える化する
2. 優先順位をつける力(Step 2)
└── 限られたリソースで最大の効果を出す施策を選ぶ
3. 人を動かす力(Step 3-4)
├── チェンジマネジメント:変化を設計し、推進する
└── 抵抗への対応:反対意見を味方に変える
4. 成果を証明する力(Step 5)
└── 改善の効果を定量的に測定し、次の投資を引き出す
Month 8 のロードマップ
| Step | テーマ | 得られる成果 |
|---|---|---|
| 1 | 組織の課題を可視化しよう | バリューストリームマップ、ステークホルダーマップ |
| 2 | 改善施策を優先順位付けしよう | インパクト分析、改善ロードマップ |
| 3 | チェンジマネジメントを実践しよう | 変革推進計画、コミュニケーション戦略 |
| 4 | 抵抗勢力を味方に変えよう | 交渉術、推進連合の構築 |
| 5 | 改善の効果を測定しよう | KPI設計、効果測定ダッシュボード |
| 6 | 組織横断改善を完成させよう | 統合改善計画書 |
「技術者として正しいことを言うだけでは不十分だ。正しいことを実現させる力。それがこのMonth 8のテーマだ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 局所最適の罠 | チーム単位の改善が全体の悪化を招くことがある |
| 失敗パターン | 技術偏重、押し付け、空回り、合意不足、効果不明の5つ |
| 必要な力 | 可視化、優先順位付け、人を動かす、成果を証明の4つ |
| Month 8の目標 | 技術力とリーダーシップを組み合わせ、組織横断の改善を推進する |
チェックリスト
- 局所最適と全体最適の違いを理解した
- 組織横断改善が失敗する5つのパターンを把握した
- 組織横断改善に必要な4つの力を理解した
- Month 8のロードマップを把握した
次のステップへ
次は「問題構造の分析手法」を学びます。組織の課題を構造的に分析し、真のボトルネックを特定するためのフレームワークを身につけましょう。
推定読了時間: 15分