ビジネス プラクティス、文化、またはテクノロジの運用に対する大きな変更を成功させるには、成長の考え方が必要です。 成長の考え方の中心にあるのは、あいまいさにもかかわらず変化を受け入れ、リーダーシップを提供する能力です。
一部のアンチパターンは、成長と変革を望む組織の成長の考え方をブロックします。 これらのアンチパターンには、マイクロ管理、偏った思考、除外プラクティスが含まれます。 これらの阻害要因の多くは、すべての人に個人的な成長機会を生み出す個人的な課題です。 しかし、IT における 2 つの一般的なアンチパターンであるサイロと封土には、個々の成長や成熟度以上の対応が必要です。
これらのアンチパターンは、さまざまなチーム内の有機的な変化の結果であり、その結果、組織の異常な動作が発生します。 各アンチパターンによって引き起こされる抵抗に対処するには、形成の根本原因を理解することが重要です。
健全で有機的な IT チーム
IT 部門全体で分業を行うのは当然です。 同様の専門知識、共有プロセス、共通の目標、および一致したビジョンを持つチームを確立することは健全です。 また、これらのチームが独自のマイクロカルチャー、共有規範、および視点を持つことも自然です。
健全な IT チームは、他のチームとの提携に重点を置き、業務の正常な完了を促進します。 健全な IT チームは、テクノロジの貢献がサポートするビジネス目標を理解することを目指しています。 詳細と財政効果はあいまいな場合がありますが、チームの価値貢献度は通常、チーム内で理解されます。
健全な IT チームは、サポートするテクノロジに情熱を持っていますが、変化を受け入れ、新しいことを試そうとしています。 通常、これらのチームは 、クラウド センター オブ エクセレンス (CCoE) の取り組みに最も早く、最も強力な貢献者です。 あなたは彼らの貢献を強く奨励したいと思っています。
変化に対する自然な抵抗
場合によっては、健全な IT チーム内のマイクロカルチャーは、経営幹部やトップダウンの意思決定に対して反応が悪く、変化を促進する可能性があります。 この反応は自然です, 共有規範を持つ人間の集団は、多くの場合、外部の脅威を克服するために協力します.
チームの日常の仕事、安心感、または自律性に影響を与える変更は、集団のリスクとして見られる場合があります。 抵抗の兆候は、通常、チーム メンバーが意思決定プロセスの一部であると感じていない初期の指標です。
クラウド アーキテクトや他のリーダーが個人の偏見を廃止し、包括的な IT チームを推進することに投資する場合、変化に対する抵抗は時間の経過と同時に急速に減少し、解消される可能性があります。 CCoE は、クラウド アーキテクトとリーダーが包括的な意思決定を作成するのに役立つツールです。
健全な摩擦
抵抗と摩擦を混同するのは簡単です。 既存の IT チームは、過去のミス、具体的なリスク、ソリューションに関する部族の知識、文書化されていない技術的負債についてよく知られています。 残念ながら、最も健全な IT チームでさえ、変更すべきではない特定の技術的なソリューションの一部として、これらの重要なデータ ポイントを記述するというトラップに陥る可能性があります。 このコミュニケーションアプローチは、チームの知識を隠し、抵抗の認識を生み出します。
これらのチームに将来の見た目の用語で通信するためのメカニズムを提供すると、データ ポイントが追加され、ギャップが特定され、提案されたソリューションに関する健全な摩擦が生じます。 追加の摩擦がソリューションの荒い部分を滑らかにし、長期的な価値を促進します。 会話を変更するだけで、複雑なテーマを明確にし、より成功したソリューションを提供するためのエネルギーを生み出すことができます。
企業ポリシーの定義に関するガイダンスにより、ビジネス利害関係者とのリスクベースの会話が容易になります。 ただし、この同じモデルを使用して、クラウドに耐性があると認識されているチームとの会話を容易にすることができます。 抵抗の認識が広がっている場合は、 クラウド ガバナンス チームのチャーターに抵抗解決プラクティスを含めるのが賢明な場合があります。
アンチパターン
健全な IT チームを作成する IT 内の有機的で応答性の高い成長により、変革とクラウド導入を妨めるアンチパターンが生じる可能性もあります。 IT サイロと独立領域は、健全な IT チーム内の自然なマイクロカルチャーとは異なります。 どちらのパターンでも、チームの焦点は「芝」の保護に向けられる傾向があります。 チーム メンバーは、運用を変更して改善する機会に直面したときに、肯定的な解決策を見つけるよりも、変更をブロックするために多くの時間とエネルギーを費やします。
前述のように、健全な IT チームは自然な抵抗と肯定的な摩擦を生み出すことができます。 サイロと封土は異なる課題です。 どちらのアンチパターンの先行インジケーターも文書化されていません。 これらのアンチパターンは、 クラウド センター オブ エクセレンス と クラウド ガバナンス チーム の取り組みの数か月後に識別される傾向があります。 彼らは継続的な抵抗の結果として発見されます。
有毒な文化であっても、CCoE とクラウド ガバナンス チームの取り組みは、文化の成長と技術的な進歩を促進するのに役立つ必要があります。 数か月の努力の後、いくつかのチームはまだ包括的な行動の兆候を示さなくなり、変化に対する抵抗にしっかりと立ち向かうかもしれません。 これらのチームは、サイロや縄張りのいずれかのアンチパターンモデルで運用されている可能性があります。 これらのモデルの症状は似ていますが、根本原因と抵抗への対処方法は根本的に異なります。
IT部門の分断
IT サイロ内のチーム メンバーは、いくつかの IT ベンダーや技術的な特殊化の領域との連携を通じて自分自身を定義する可能性があります。 しかし、サイロと IT の領域を混同しないでください。 サイロは快適さと情熱によって駆動される傾向があり、サイロは時には封土の背後にある恐怖主導の動機よりも克服しやすいことがあります。
このアンチパターンは、多くの場合、特定のソリューションに対する共通の情熱から生まれます。 その後、IT サイロは、その特定のソリューションへの投資の結果として、チームの高度なスキルによって強化されます。 この優れたスキルは、変化への抵抗を克服できれば、クラウド導入の取り組みに対するアクセラレータになります。 また、サイロが分割されている場合や、チーム メンバーがオプションを正確に評価できない場合にも、大きな阻害要因になる可能性があります。 さいわい、組織図に大きな変更を加えることなく、通常は IT サイロを克服できます。
IT サイロからの抵抗に対処する
IT サイロに対処するには、次の方法を使用します。 最適なアプローチは、抵抗の根本原因によって異なります。
仮想チームを作成する: クラウド導入フレームワークの 組織の準備 のセクションでは、4 つの仮想チームを統合および定義するための多層構造について説明します。 この構造の利点の 1 つは、組織間の可視性と包含です。 クラウドのセンター オブ エクセレンスを導入すると、トップ エンジニアが参加したいと考える、注目度の高い熱望チームが作成されます。 この変更は、組織図の制約に拘束されない新しいソリューション間の配置を作成するのに役立ちます。 また、IT サイロによって保護されているトップ エンジニアの参加も促進されます。
クラウド戦略チームを導入すると、クラウド導入の取り組みに関する IT の貢献がすぐに可視化されます。 IT サイロが分離のために戦う場合、この可視性は、IT およびビジネス リーダーがそれらの耐性のあるチーム メンバーを適切にサポートする動機付けに役立ちます。 このプロセスは、利害関係者のエンゲージメントとサポートへのクイック パスです。
実験と露出を検討します。 IT サイロのチーム メンバーは、しばらくの間、特定の方法を考えるのに制約を受けている可能性があります。 視野を狭める考え方を打ち破ることが、抵抗に対処するための第一歩です。
実験と露出は、サイロの障壁を打破するための強力なツールです。 チーム メンバーは競合するソリューションに対して耐性がある可能性があるため、既存のソリューションと競合する実験を担当するのは賢明ではありません。 ただし、クラウドの最初のワークロード テストの一環として、組織は競合するソリューションを実装する必要があります。 サイロ化されたチームは、入力とレビューのソースとして参加するように招待する必要がありますが、意思決定者としては招待されません。 運用環境のソリューションに移行する前に、意思決定者としてより深く関与するというコミットメントをチームに明確に伝えます。
競合するソリューションのレビュー中に、「 企業ポリシーの定義 」に記載されているプラクティスを使用して、実験の具体的なリスクを文書化し、サイロ化されたチームが将来の状態に慣れるのに役立つポリシーを確立します。 このアプローチにより、チームは新しいソリューションに公開され、将来のソリューションが強化されます。
境界を超えよう: クラウド導入を推進するチームは、ワクワクする革新的なクラウドネイティブソリューションを探索することで、容易に限界を突破します。 これは、境界を削除するアプローチの半分です。 しかし、その考え方は、IT サイロをさらに強化することができます。 既存の文化を考慮せずに迅速かつ慎重に変化を推し進めすぎると、健全でない摩擦が生じ、自然な抵抗を引き起こす可能性があります。
IT サイロが抵抗し始めたら、独自のソリューションで "境界のない" 状態にすることが重要です。 1 つの単純な真実に留意してください。クラウドネイティブが常に最適なソリューションであるとは限りません。 IT サイロの既存の投資を将来に拡張する機会を提供する可能性のあるハイブリッド ソリューションを検討してください。
また、IT サイロ チームが現在使用しているソリューションのクラウドベースのバージョンも検討してください。 ソリューションを試し、IT サイロで作業するチーム メンバーの視点に触れることができます。 少なくとも、新しい視点が得られます。 多くの状況では、IT部門の敬意を得ることで、抵抗を軽減できる場合があります。
教育への投資: IT サイロに住む多くの人々は、独自の教育を拡大した結果、現在のソリューションに情熱を持つようになりました。 これらのチームの教育への投資は、ほとんど間違って行われません。 自己学習、クラス、または会議に参加する時間をこのような人たちに割り当てて、現在のソリューションに日々注力することを阻止します。
教育が投資になるには、経費から何らかの利益が得られる必要があります。 投資と引き換えに、チームは、クラウド導入に関与する他のチームに提案されたソリューションを示す場合があります。 また、提案されたソリューションを採用する上で、具体的なリスク、リスク管理のアプローチ、および必要なポリシーのドキュメントを提供することもできます。 各特典は、ソリューション内のチームを引き付け、彼らの部族の知識を使用します。
ロードブロックを減速帯に変える: IT サイロは、変革を遅延もしくは停止させる可能性があります。 実験とイテレーションは方法を見つけますが、プロジェクトが動き続ける場合に限ります。 ロードブロックをスピードバンプに変えることに重点を置く。 継続的な進行と引き換えに、すべてのユーザーが一時的に快適に使用できるポリシーを定義します。
たとえば、セキュリティ ソリューションがクラウド内の侵害された保護されたデータを監視できないために IT セキュリティが障害となっている場合は、データ分類ポリシーを確立します。 同意できるソリューションが見つかるまで、分類されたデータをクラウドにデプロイしないようにします。 保護されたデータを監視するために、ハイブリッドまたはクラウドネイティブ ソリューションの実験に IT セキュリティを招待します。
ネットワーク チームがサイロとして動作する場合は、自己完結型で、ネットワークの依存関係がないワークロードを特定します。 並行して、ハイブリッドまたは代替ソリューションに取り組みながら、ネットワーク チームの実験、公開、教育を行うことができます。
忍耐強く、包容力を持ち: IT サイロのサポートなしで進むことは魅力的です。 しかし、この決定は中断と道路の障害を引き起こします。 IT サイロに関する考え方を変えるには時間がかかる場合があります。 彼らの自然な抵抗に忍耐強い。 値に変換します。 包摂的になり、健全な摩擦を促して、将来の解決策を改善します。
決して競争しない: 理由により、IT サイロが存在します。 これは理由により保持されます。 チーム メンバーが熱心に取り組んでいるソリューションを維持するための投資があります。 ソリューションや IT サイロと直接競合すると、ビジネス成果を達成するという本当の目標から気が散ります。 このトラップにより、多くの変換プロジェクトがブロックされています。
ゴールの 1 つのコンポーネントではなく、目標に集中し続けます。 IT サイロのソリューションの肯定的な側面を強調し、チーム メンバーが将来に最適なソリューションについて賢明な意思決定を行うのに役立ちます。 現在のソリューションをインスクルまたはデグレードしないでください。これは逆効果であるためです。
ビジネスとの提携: IT サイロがビジネス成果を妨げているのではない場合、なぜ気にしますか? 完璧なソリューションや完璧な IT ベンダーはありません。 競争は理由で存在します。それぞれに独自の利点があります。
強力な クラウド戦略チームをサポートして調整することで、多様性を受け入れ、ビジネスを含めます。 IT サイロがビジネス成果をブロックするソリューションをサポートしている場合、技術的なスクワッドのノイズを発生させずに、その障害を簡単に伝達できます。 非ブロッキング IT サイロのサポートは、目的のビジネス成果に対してパートナーを組む方法を示しています。 これらの取り組みは、IT サイロが正当な阻害要因となる場合に、ビジネスからより多くの尊敬とサポートを得ています。
ITの縄張り
IT部門のチームメンバーは、特定のプロセスや責任分野に沿って自分自身を位置づける傾向があります。 チームは、責任の領域に対する外部の影響が問題につながるという前提で運営されています。 封建領は恐怖によって生まれるアンチパターンになりがちで、これを克服するには、重要なリーダーシップのサポートが必要です。
封土は特に、IT ダウンサイズが行われた組織、IT スタッフが頻繁に動揺する組織、または IT リーダーシップが不足している組織で一般的です。 企業が IT を純粋にコスト センターと見なすと、フィフダムが発生する可能性がはるかに高くなります。
一般的に、封建領は、チームとその関連する権力基盤を失うことを恐れる部門管理者が原因で生じます。 多くの場合、これらのリーダーはチームに対する義務感を持ち、部下を否定的な結果から保護する必要があると感じています。 「変化からチームを守る」や「プロセスの中断からチームを保護する」などのフレーズは、リーダーシップからのより多くのサポートを必要とする可能性がある過度に保護されたマネージャーの指標です。
IT 封土からの抵抗に対処する
IT の縦割り組織は、IT サイロの抵抗に対処するためのアプローチを取り入れることで、成長を遂げることができます。 IT 部門からの抵抗に対処する前に、まずチームを IT のサイロと見なして扱うことをお勧めします。 このような種類のアプローチで大きな変化が生じなかった場合、抵抗を示しているチームはITの権限専有のアンチパターンに苦しんでいる可能性があります。 ITの独立領域の根本原因を対処するには少し複雑です。なぜなら、この抵抗は直接のラインマネージャーや組織内の上級リーダーから生じることが多いからです。 IT サイロ主導の課題は、通常、克服しやすくなります。
IT 封土からの抵抗が続いてクラウド導入の取り組みが妨げられますが、既存の IT リーダーと状況を評価する取り組みを組み合わせることが賢明な場合があります。 IT リーダーは、意思決定を行う前に、 クラウド戦略チーム、 クラウド センター オブ エクセレンス、 クラウド ガバナンス チーム からの分析情報を慎重に検討する必要があります。
注
IT リーダーは、組織図の変更を軽く受け入れるべきではありません。 また、各サポート チームからのフィードバックを検証して分析する必要もあります。 しかし、クラウド導入のような変革の取り組みは、この作業のずっと前に気付かれていない、または対処されていない根本的な問題を拡大する傾向があります。 フィフダムが会社の成功を妨げている場合、リーダーシップの変更が必要である可能性があります。
幸いなことに、フィフダムのリーダーを削除しても、必ずしも終了するとは限りません。 これらの強力で情熱的なリーダーは、多くの場合、少しの反省の後に管理の役割に移行することができます。 適切なサポートにより、この変更は、Fiefdom のリーダーと現在のチームにとって正常です。
注意事項
IT 部門のマネージャーにとって、チームをリスクから保護することは明確なリーダーシップの価値です。 ただし、保護と分離の間には細かい線があります。 チームが運転変更への参加をブロックされると、チームにとって精神的、専門的な結果を招く可能性があります。 特に目に見える変化の時には、変化に抵抗する意欲が強いかもしれません。
分離されたチームのマネージャーは、前のセクションの健全な IT チームに関連するガイダンスを試すことで、成長の考え方を実証するのに最適です。 ガバナンスと CCoE 活動への積極的かつ楽観的な参加は、個人の成長につながる可能性があります。 IT フィフダムのマネージャーは、息苦しい考え方を変え、チームが新しいアイデアを開発するのを助けるのに最適な立場にあります。
ITの権限分散領域は、時にシステム全体のリーダーシップの問題を示すことがあります。 ITの独立王国を克服するためには、ITリーダーが業務、責任、そして場合によっては特定のチームのライン管理を提供する管理者に変更を加える自由が必要です。 これらの変更が必要な場合は、明確で防御可能なデータ ポイントを使用して変更にアプローチすることをお勧めします。
ビジネスの利害関係者、ビジネスの動機、ビジネス成果との連携は、必要な変更を促進するために必要な場合があります。 クラウド戦略チーム、クラウド センター オブ エクセレンス、クラウド ガバナンス チームとのパートナーシップにより、防御可能な位置に必要なデータ ポイントを提供できます。 必要に応じて、これらのチームは、IT リーダーだけでは対処できない課題に対処するためのグループエスカレーションに関与する必要があります。
次のステップ
組織のアンチパターンを中断することは、チームの取り組みです。 このガイダンスに従うには、組織の準備の概要を確認して、適切なチーム構造と参加者を特定します。