クラウド組織のアンチパターン
多くの場合、クラウド導入によってお客様の組織構造にアンチパターンが発生します。 さまざまな要因によって、これらの問題が発生するおそれがあります。
- ツールセット
- パートナー
- エンジニア
- 連携を欠いた IT 部署
クラウド導入のシナリオを成功させるには、これらの要素の役割を理解することが重要です。
アンチパターン: IT をコスト センターとして扱う
多くの企業が IT 部署をコスト センターとして扱います。 このアプローチの場合、IT は会社に価値を付加しないという認識が生じるおそれがあります。 従業員は、IT をイネーブラーではなくプロバイダーと見なすと落胆するおそれがあります。 また、企業が適切な人材を引き込むことも困難になります。 モチベーションが下がり、ライフサイクル時間が長くなります。 IT の仕事の質が低下したり、サイロと封土が形成されたりするおそれがあります。
例: IT をコスト センターとして扱う
ある企業は、IT 部署を、最高財務責任者 (CFO) に対して責任を負うコスト センターとして管理しています。 取締役会は IT を会社の最も大きなコスト要因の 1 つである低速なサービス プロバイダーとして認識しています。 取締役会は、IT 部署が発注した資産のほとんどをモビリティの部署が消費していることを認識していません。 IT はすべての部署が使用するためのデータセンターを購入しますが、モビリティ部署がこの特大の資産を受け取ります。 取締役会は、IT をイネーブラーまたはパートナーと見なしていません。
推奨される結果: IT をイネーブラーと見なす
IT 部署をコスト センターとして管理するのではなく、次のいずれかのアプローチを検討します。
- チャージバック: 各部署が IT コストをそれぞれの予算の中の運用経費と同様に扱います。
- ショーバックまたは認識バック: IT がエージェントとして機能します。 事業へ戻すレポートにおいて、IT はすべての直接費を関連する部署に帰属させます。
コストとビジネスの透明性を高めるためのツールとしてクラウドを使用することができます。 たとえば、コストの透明性を向上させるために Cost Management の規範を実装します。 そうすると、さまざま部署のコストをもっと認識できるようになります。 IT 部署をそれらの部署のイネーブラーと見なすようになります。
透明性を向上させるには、クラウドを導入する場合の可視性、アカウンタビリティ、最適化に焦点を合わせます。 詳細については、「コスト志向の組織を構築する」を参照してください。
アンチパターン: 事業を関与させずに新しいテクノロジに投資する
多くの場合、IT 部署は、堅牢なプラットフォームとツールセットの構築と展開に膨大な人的および財務リソースを投資します。 しかし、IT が設計と開発のフェーズにおいて各部署とそのニーズを考慮しきれていないことがあります。 このような漏れがあると、新しいプラットフォームは各部署にとって最小限の関連性しかないものになります。 すると、従業員は新しいテクノロジを受け入れることに消極的になります。 結果として、導入が広がらない、または遅くなるおそれがあります。 また、各部署がそのプラットフォームを使用しなければ、IT 内部に挫折感が生じることにもなります。
例: 部署を介さずにプラットフォームを設定する
あるデータ分析企業の IT 部署は、どの部署も関与させずに Azure プラットフォームを設定およびカスタマイズしました。 そのプラットフォームを使用しているときに部署の開発者たちは:
- デプロイに必要なアクセス許可が付与されていないことに気が付きます。
- 制限された数のサービスしか使用できません。
- サポート チケットを発行します。そうすると承認サイクルが長くなります。
- 新しいプラットフォームに疑問を持ち始めます。
結局、一部の開発者は IT の規則や規制の煩わしさを回避するために、Azure サブスクリプションを自分で購入しました。 シャドウ IT の出現です。 この企業はシャドウ IT をほとんど制御できないため、高いセキュリティ リスクが生じます。
推奨される結果: 意思決定に部署を関与させる
エンタープライズ対応のクラウド プラットフォームをデプロイする場合は、IT サイロを作らないようにしてください。 部署から開発者と技術関連の意思決定者 (TDM) を設計および開発プロセスに参加させます。 プラットフォーム導入状況を改善するには、部署の意見に耳を傾けます。
導入の速度が向上する、開発者向けに調整された Azure のベスト プラクティスと設計原則については、「クラウド導入フレームワークのエンタープライズ規模ランディング ゾーンから開始する」を参照してください。 コンプライアンスと柔軟性の適切なバランスを取ります。 たとえば、開発環境をアジャイルに維持しながら、ガバナンスとセキュリティのポリシーを満たす方法を見つけます。
アンチパターン: 中心的なビジネス機能をアウトソーシングする
コンサルティング パートナーやマネージド サービス プロバイダー (MSP) は、クラウド導入において重要な役割を果たします。 しかし、企業は、ビジネスにおいて最も価値の高い機能がパートナーや MSP の作業によって提供される状態にならないように注意する必要があります。 MSP またはクラウド コンサルタントに責任をアウトソーシングする企業は、これらのプロバイダーに依存しないようにする必要があります。
例: クラウドの導入と移行をアウトソーシングする
ある研究機関に、タイム クリティカルなクラウド移行プロジェクトがあります。 クラウド導入期間を短縮するために、MSP を採用して Azure の基盤を構築し、移行を実装します。 その機関は、クラウド導入フェーズについて学習してスキルを高める代わりに、Azure に関するすべての責任を MSP に任せることを選択します。 その機関にはクラウドまたは Azure の知識がないため、MSP がすべての決定を主導し、そのために研究所は MSP に依存することになります。
推奨される結果: 重要な設計領域を企業の責任にする
優れたコスト削減戦略としてアウトソーシングを念頭に置くことができます。 ただし、これらの重要な設計領域が含まれる場合は、自社内で意思決定を行います。
- ガバナンス
- リスク
- コンプライアンス
- ID
セキュリティ資産にとって重要なこれらの、および他の領域については、会社内部で責任を負う必要があります。 導入にかかる時間を短縮するために外部パートナーを利用します。 しかし、プロバイダーへの依存を避けるために、すべてをアウトソーシングすることはしないでください。
アンチパターン: クラウド エンジニアを育成する代わりに、技術的な意思決定者を雇う
企業は適切な人材を見つけることを重視します。 その結果、クラウド導入の初期段階で、TDM を採用または育成することがよくあります。 クラウド導入の成功は TDM に依存しています。 しかし、さらに重要なこととして、クラウドの導入には、一致協力する精神と高い技術的スキルとを備えたエンジニアが必要です。
例: TDM のみを採用する
ある研究機関は、クラウド導入を主導させるために複数の TDM を採用しました。 最初の高度な概念のフェーズが終了し、実装フェーズが始まります。 その後、クラウドのデプロイがオンプレミスのデプロイとは動作が異なることに気付きます。 コードとしてのインフラストラクチャ (IaC) の概念とポリシー駆動型ガバナンスを適切に実装するには、追加のクラウド エンジニアリング作業が必要です。
推奨される結果: 実装フェーズにクラウド エンジニアを使用する
クラウドの自動化とランディング ゾーンの概念を適切に実装するには、エンジニアが不可欠であることに留意してください。 サービス モデルを採用するときに責任とタスクが大きく変化する可能性があります。 クラウド プロバイダーに責任を移すことで、より迅速に運用に進むことができます。 また、意思決定に TDM を使用することもできますが、高度なエンジニアリング知識を必要とするタスクには、能力のあるクラウド エンジニアを使用します。 そうすれば、クラウドで提供される利点を実現できます。