サイロと封土
ビジネス プラクティス、カルチャ、またはテクノロジの運用に対する大きな変更を成功させるには、成長の思考様式が必要です。 成長の思考様式の中心となるのは、はっきりしない点があっても変化を受け入れ、リーダーシップを発揮する能力です。
成長と変革を望む組織の成長の思考様式が、いくつかのアンチパターンによって阻害されることがあります。 このようなアンチパターンとしては、マイクロマネージメント、先入観にとらわれた思考、排他的行為などがあります。 これらの阻害要因の多くは、全員の個人的な成長の機会を生み出す個人的な課題です。 ただし、IT 部門における 2 つの一般的なアンチパターンであるサイロと封土については、個人の成長や成熟だけでは対応できません。
これらのアンチパターンは、さまざまなチーム内の有機的な変更の結果であり、組織の異常行動を引き起こします。 各アンチパターンを原因とする抵抗に対処するためには、それが形成される根本原因を理解することが重要です。
健全で有機的な IT チーム
IT 全体での人材の区分の作成は自然なことです。 似たような専門知識、共有プロセス、共通の目標、一致するビジョンを持つチームを結成することは正常です。 それらのチームが独自のマイクロカルチャ、共有規範、観点を持つことも自然です。
健全な IT チームは、職務の正常な完了を促進するために、他のチームとの提携に注目します。 健全な IT チームは、自分たちの技術的寄与がサポートするビジネス目標を理解しようとします。 詳細と財務への影響はあいまいな場合もありますが、普通、チーム内ではチームの価値の寄与が理解されています。
健全な IT チームは、自分たちがサポートするテクノロジに対して情熱を持っていますが、変化に対して開放的で、新しい物事を進んで試します。 このようなチームは、通常、クラウドのセンター オブ エクセレンス (CCoE) の取り組みに最も早く、最も強力に寄与します。 彼らの寄与を強く奨励する必要があります。
変更に対する自然な抵抗
健全な IT チーム内のマイクロカルチャは、変更を推進する経営幹部やトップダウンの意思決定にうまく反応できない場合もあります。 共通の規範を持つ人の集団は、外部の脅威を克服するために協力する場合が多いので、この反応は自然です。
チームの日常的な仕事、セキュリティの感覚、または自律性に影響する変化を、人は共同体へのリスクと見なす場合があります。 通常、抵抗の兆候は、チーム メンバーが自分たちは意思決定プロセスに含まれていないと感じていることの早期指標です。
クラウド アーキテクトや他のリーダーが、個人の偏見の排除と、インクルーシブな IT チームの推進に取り組むと、変化に対する抵抗はすぐに減少し、時間の経過と共に解消されます。 CCoE は、クラウド アーキテクトとリーダーがインクルーシブな意思決定を行うのに役立つツールです。
健全な摩擦
抵抗と摩擦はよく混同されます。 一般に、既存の IT チームは、過去のミス、具体的なリスク、ソリューションに関する組織固有の知識、文書化されていない技術的負債についてよく知っています。 残念ながら、最も健全な 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 リーダーは、組織図に対する変更を決して軽視してはなりません。 各サポート チームからのフィードバックを検証し、分析する必要もあります。 ただし、クラウド導入のような変革の取り組みは、この取り組みよりずっと前に注目または対処されずに見過ごされてきた根本的な問題を悪化させる傾向があります。 封土が企業の成功を妨げている場合、おそらくリーダーの変更が必要です。
さいわい、封土のリーダーの排除は、常に解雇という結果にはなるわけではありません。 このような強力で熱心なリーダーは、多くの場合、短期間の内省の後、管理の役割に移行できます。 適切なサポートがあれば、この変更は封土のリーダーと現在のチームにとって有益です。
注意事項
IT 封土のマネージャーにとって、チームをリスクから保護することは、リーダーの明らかな価値なのです。 ただし、保護と孤立には紙一重の差があります。 チームが変更の推進への参加を阻止されると、それがチームに対する心理的および職務上の結論となる可能性があります。 変更に対する抵抗の衝動は、変化が目に見える期間中は特に強くなることがあります。
孤立したチームのマネージャーは、上記のセクションの健全な IT チームに関係するガイダンスに従って試みることで、成長の思考様式を最も分りやすく示すことができます。 ガバナンスや CCoE の活動に積極的かつ楽観的に参加することが、個人の成長につながる可能性があります。 IT 封土のマネージャーは、きゅうくつな思考様式を変え、チームが新しいアイデアを開発できるよう助けるのに最適な立場にいます。
IT 封土は、リーダーシップの体系的な問題の兆候である場合があります。 IT 封土を克服するために、IT リーダーは、運用、職責、そして場合によっては特定のチームのライン管理を行っている人員さえ自由に変更できる必要があります。 その変更が必要な場合は、明確で正当化できるデータ ポイントを使用して変更に取り組むことが賢明です。
必要な変更を推進するために、ビジネスの利害関係者、ビジネス上の動機、およびビジネスの成果との調整が必要なこともあります。 クラウド戦略チーム、クラウドのセンター オブ エクセレンス、クラウド ガバナンス チームとのパートナーシップにより、防衛拠点に必要なデータ ポイントが提供される可能性があります。 必要に応じて、これらのチームは、IT リーダーだけでは対処できない課題に取り組むためのグループ エスカレーションに関与する必要があります。
次のステップ
組織のアンチパターンの破壊はチーム作業です。 このガイダンスに従って行動するには、適切なチーム構造と参加者を特定する組織の準備状況の概要を確認します。