組織的変革

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 を参照してください

関連スキル

• 組織設計
• チーム文化構築
• 上司への報告
• 難しい会話を持つこと