organizational-transformation

組織変革

2 人のプロダクトリーダーの知見を活用し、ユーザーが組織をモダンなプロダクトプラクティスへと変革できるよう支援します。

支援方法

ユーザーが組織変革の支援を求めた場合：

1. 現在の状況を把握する - 現在のモデル（フィーチャーチーム、アウトプット重視、ウォーターフォールなど）と、変革の必要性を生んでいる要因を尋ねます
2. 変革への準備状況を診断する - 変革を推進する権限と意欲があるのは誰か、どのような抵抗が予想されるかを確認します
3. アプローチを設計する - パイロットチーム、段階的な働きかけ、より広範な変革施策のどれを選ぶか検討できるよう支援します
4. 変革を管理する - コミュニケーション、進捗の測定、抵抗への対処について案内します

基本原則

フレームワークは手段であり、目的ではありません

John Cutler：「ほとんどの企業は、フレームワークの導入を最終目標と捉えています。」目標は、特定の手法を導入することではなく、より良い成果を実現することです。Scrum や SAFe などのフレームワークを、特定の組織が抱える固有の課題の解決に役立つかどうかで評価してください。

パイロットから始めて、展開する

Marty Cagan：「TRANSFORMED の目標は、実際に変革する方法、つまり変革のテクニックを共有することでした。」まずは、モデルが機能することを実証できる、権限を与えられた少数のプロダクトチームから始めましょう。その成功を活用し、より広範な変革への信頼を築いてください。

従来型の企業には慎重に働きかける

John Cutler は、システム全体からの拒絶を招かずに、シリコンバレー以外の企業をモダンなプラクティスへと「少しずつ導く」ことを重視しています。急進的な変革案は、しばしば拒絶されます。既存の権力構造を脅かさない形で、新しいプラクティスを導入する方法を見つけてください。

構造、文化、そしてプロセスを変える必要があります

Marty Cagan は、「フィーチャーチーム」から「プロダクト運営モデル」への移行について説明しています。これには、構造（チームの編成方法）、文化（人々が仕事をどう捉えるか）、プロセス（意思決定の方法）の変更が必要です。どれか 1 つの側面だけを変えても、うまくいきません。

ユーザーを支援するための質問

• 「変革が必要になった理由は何ですか？ 現在、何がうまくいっていませんか？」
• 「この変革を後援する権限と意欲があるのは誰ですか？」
• 「現在のモデルはどのようなものですか？ フィーチャーチーム、ウォーターフォール、それとも別の形ですか？」
• 「どこから始めますか？ 新しいアプローチを試験導入できそうなチームや領域はありますか？」
• 「どのような抵抗が、誰から予想されますか？」
• 「変革がうまくいっているか、どのように判断しますか？」

注意すべきよくある間違い

• フレームワークの導入を目標にする - Scrum を導入しても、変革したことにはなりません。儀式ではなく、成果に焦点を当ててください
• 一気に変革しようとする - すべてを一度に変えようとしても、たいてい失敗します。パイロットから始めてください
• 文化を無視する - 文化を変えずにプロセスだけを変えても、抜け道が生まれます。行動だけでなく、考え方にも対処してください
• 経営幹部の後援がない - 上層部の支援がない変革は、組織の抗体によってつぶされます
• シリコンバレーを盲目的に模倣する - Google でうまくいくことが、創業 50 年の企業でもうまくいくとは限りません。模倣するのではなく、適応させてください

詳細

2 人のゲストによる 2 件の知見すべてについては、references/guest-insights.md を参照してください

関連スキル

• 組織設計
• チーム文化の構築
• 上司との関係構築
• 難しい会話への対応