集中型デリバリーモデルのメリットとデメリット
集中型モデルは、おそらく最も一般的なエンタープライズ自動化の運用モデルであり、特に中堅企業や「購入志向」の大企業で採用されることが多いモデルです。
基本的な考え方は非常にシンプルです。エンタープライズ自動化という課題の複雑さを認識し、企業は技術ポートフォリオを最適化し、スキルの集約による効率化を図るために、自動化の責任を中央に集約することを選択します。
つまり、エンタープライズ自動化は Enterprise Automation Team（EAT） によって中央集権的に提供され、このチームが戦略を完全に担当します。戦略には、適切なツールセットの選定も含まれます。
EATはまた、「エンタープライズ自動化ファクトリー」としての役割も果たします（戦略とファクトリー機能が、別々のチームに分かれている場合もありますが、密接に関連しています）。
各部門や現場チームがエンタープライズ自動化の課題に取り組む必要がある場合、必要な機能の実装はEATに委託されます。現場チームが要件を定義し、EATがソリューションを提供するという形です。
実際の企業では、複数のCoE（Center of Excellence）が存在するケースも多く、通常はユースケースごとに分かれています。例えば以下のような構成です。
- プロセス自動化CoE
- アプリケーション統合CoE
- データ統合CoE
- API CoE
このような構成は当然ながら、状況をさらに複雑にします。
集中型モデルのメリット
集中型モデルは、その利点から多くのCIOやITリーダーにとって魅力的な選択肢となっています。
中央の「エンタープライズ自動化ファクトリー」は、時間が経つにつれて非常に効率的になる可能性があります。
1. 効率性
中央の「エンタープライズ自動化ファクトリー」は、時間の経過とともに非常に効率的になります。エンタープライズ自動化は彼らの本業であり、日々それに取り組んでいるためです。
その結果、使用するツールへの理解が深まり、独自のアプローチや方法論を確立し、ベストプラクティスを蓄積し、再利用可能なテンプレートを開発するようになります。
実際の事例として、EATの生産性が運用開始から最初の1年で最大50％向上したケースも見ています。
2. 技術とスキルのスケールメリット
EATは当然ながら、可能な限り重複した技術や重なり合うツールを避けようとします。単一のエンタープライズ自動化ツールに完全に統一することはほとんどの場合現実的ではありませんが、少なくとも製品の種類を必要最小限に抑えることは可能です。
これにより、ソフトウェアライセンス、保守、クラウドサブスクリプションなどのコストを削減、または少なくとも管理可能な範囲に抑えることができます。結果として、必要なスキルの種類も限定され、スキル管理が容易になります。
さらに、それらのスキルを共有リソースとして管理することで、需要不足によって人材が手持ち無沙汰になる状況も最小化できます。
3. ガバナンスと統制への強いフォーカス
EATが組織内で唯一のエンタープライズ自動化ファクトリーであるため、セキュリティ、コンプライアンス、サービス品質に関するポリシーを、すべてのプロセスに対して一貫して適用できます。
同様に、以下のような標準化も実施できます。
- 命名規則
- 標準開発パターン
- 再利用可能テンプレート
- 開発プロセス標準
- データガバナンスポリシー
また、EATは実装したすべてのプロセスを把握し、ライフサイクル管理、実行監視、保守、サポートを行うことができるため、エンタープライズ自動化環境全体を完全にコントロールできます。
集中型モデルのデメリット
合理的で最適化されたモデルである一方、集中型モデルにも課題があります。
1. 組織的ボトルネック
EATが有能で信頼できる「ファクトリー」として認識されるようになると、そのサービスへの需要は増加し、すべての要求に迅速に対応できなくなる可能性があります。
そのため、依頼の流入を管理・優先順位付けするために、官僚的なプロセスや手続きを導入する必要が出てきます。つまり、ピーク時にはEATが組織のボトルネックとなり、これは企業が求めるビジネスアジリティとは正反対の結果になります。
2. Time to Value の長期化
EATがどれだけ効率的で規模が大きくても、最も重要で影響が大きく、スポンサーの強い案件が優先されることになります。その結果、優先度の低い要件は後回しになり、場合によっては無期限に延期されることもあります。
これにより、それらの要件に関連するビジネス施策のTime to Valueが長期化し、ビジネス部門の不満が増大し、各部門がEATのリソースを巡って競争する状況が生まれる可能性があります。
3. 主に「エンタープライズ」要件を対象とする
最も重要な要件に集中するという構造上、EATは高度で大規模な「エンタープライズ」クラスの要件に焦点を当てる傾向があります。これはツール選定やスキル採用・育成にも影響します。
その結果、「現場レベル」の要件は「二級市民」のように扱われ、EATが時間に余裕があるときに対応される程度になる可能性があります。また、EATのツールセットは高度な要件向けに設計されているため、現場の比較的シンプルな要件にはオーバースペックになることもあります。
例えば、RPAや従来型ESBを使用している企業の中には、本来であればローコードアプリケーションプラットフォームやiPaaSの方が適しているケースもあります。
集中型モデルの本質的な課題
最終的に、集中型モデルの最大の課題は本質的にアジリティが不足していることです。
このモデルは、エンドツーエンドの全社レベルのエンタープライズ自動化要件に対応する場合には非常に有効です。しかし、現場レベル、ましてや個人レベルの要件を支援するモデルとしては最適ではありません。これらの要件は時間制約があり、必ずしも非常に複雑なものではないことが多いためです。
コスト、ガバナンス、コンプライアンスを重視する企業にとっては、集中型モデルは最大限の統制を実現できるモデルです。
集中型モデルを採用すべきケース
集中型モデルが適しているケースはいくつかあります。少なくとも初期段階では有効なモデルとなります。
- アプリケーションポートフォリオの大半がパッケージソフトウェアやSaaSアプリケーションで構成されている
- 各アプリケーションの専門家は多いが、エンタープライズ自動化スキルは各チームに分散しており、十分に活用されていない
- コスト、ガバナンス、コンプライアンスを重視している
このような場合、これらのスキルを共有リソースとして集約する方が効率的です。
現実の組織は完全な集中型ではない
フェデレーテッドモデル（分散モデル）と集中型モデルは、エンタープライズ自動化要件に対する全く異なるアプローチを表しており、それぞれ企業文化、スキル、ビジネス優先事項の違いを反映しています。
しかし実際には、多くの企業は形式上集中型モデルを採用していても、両者の中間モデルを実装しています。完全に集中型の大企業はほとんど存在しません。
例えば、技術力の高い現場部門がTime to Valueを短縮するため、あるいはEATでは対応できない特定の要件があるために、EATを経由せず自動化を実装するケースがあります。最も厳格に統制された環境であっても、集中型モデルと分散型モデルが共存することになります。
これは、多くの場合、理論上の集中型モデルは一時的な状態に過ぎないことを意味します。EATが分散型の取り組みを再び統制下に置くためには、民主化モデル（現場が実装し、中央チームが支援・統制するモデル）へ移行する必要があるためです。