集中化か分散化か？

ほとんどの大規模な IT 組織では、ある時点で、何を集中化し、何を分散化するかという決断を迫られます。ある組織はシェアードサービスグループの設立を決定し、別の組織はセキュリティとアーキテクチャのガバナンスの集中化や、調達と財務管理の集中化を検討します。しかし、このような集中化された機能は、下手をするとボトルネックとなり、シェアードサービスと分散化されたチームとの相互作用によって、管理上の無駄が生じる可能性があります。企業は何を集中化するのかをどのように決めればよいのでしょうか。そして、集中化したサービスと分散化したユニットとの相互作用をどのように組織化すれば、無駄を省けるのでしょうか。

国土安全保障省（ DHS ）の構成機関の CIO として、私は自分自身が負担の大きい集中化の犠牲者だと考えていました。新しいサーバーやデータセンターの変更が必要な場合は、データセンターを管理する契約会社を監督する DHS の契約部署に訴えなければなりませんでした。ネットワークインフラは DHS の他の部門と共有され、集中的に管理されていたため、小さなネットワーク変更であっても、書類作成や審査、そして長い時間が必要でした。IT プロジェクトでは、DHS の管理枠組みである MD-102 (そう、私が著書や講演で頻繁に揶揄しているものです) の厳しい要件に従わなければなりませんでした。これは沿岸警備隊のカッター建造を監督するためのものです(沿岸警備隊も DHS の一部です)。 この組織は、ソフトウェアシステムの納入も管理し、結果的に巨大な資本投資と物理的な対象物を中心に据えていました。集中化は、私たちが成し遂げたいことすべての妨げになるように思えました。

今日のデジタルな働き方においては、分散化され、権限を与えられた、自律的なチームが求められています。これは、中央集権的な機能やガバナンスと調和させるのは困難です。一方、どうしても分散化できない機能や、分散化すると非効率になる機能もあります。私たちの場合、DHS 本部が組織全体のセキュリティに責任を持ち、ベンダーとの契約を集中的に交渉することで、購買量を活用してより良い値引きを実現することができました。

今日のデジタルIT環境の中核には、集中化と分散化の緊張関係が存在します。当然のことながら、私が企業のリーダーと話をする際にも、何らかの形でこの問題に触れることがあります。

このトレードオフをどうするか、私はまず、今日の環境ではスピードとイノベーションが重要である、という原則から始めたいと思います。そのためには、権限を分散させ、自律的で権限を持った部門横断的なチームで仕事をすることが最も効果的です。このようなチームは、顧客との距離が近く、市場の変化を感じ取りやすく、部門を越えてアイデアを出し合い、部門間の引き継ぎがない状態、つまり迅速に仕事を遂行することができるのです。自律的なチームが中央集権的な機能に依存すると、スピードが落ち、管理上のオーバーヘッドが発生し、官僚主義が蔓延して、イノベーションが制限される傾向があります。

これが私の出発点ですが、この質問にはもっとニュアンスの異なる扱いが必要です。どのような場合に機能を集中させるべきでしょうか。私の最初の答えは、分散したチームのスピードを上げ、イノベーションをサポートする場合です。もし集中化された組織が、各チームが自分たちで提供しなければ時間がかかるようなサービスを提供し、各チームの速度を低下させるような管理上のオーバーヘッドなしにそれを行うなら、それは良いことです。例えば、DHS がデータセンターの管理契約を監督している場合を考えてみましょう。このままでは、インフラが必要なときに、チームの動きが鈍くなってしまいます。しかし、もし集中化されたチームが、各チームがインフラを必要とするときに、迅速なプロセスで、事前に交渉した上で契約を結んでいれば、各チームにとって時間の節約になり、有益だったことでしょう。

もちろん、クラウドがあるため、データセンターの心配をする必要はもうありません。ここで、集中管理されたクラウドプラットフォームチームが、ソフトウェアデリバリーチームが作業できるように準備されたインフラを提供することを想像してみてください。各チームは、プラットフォームチームがプロビジョニングするのを待つことなく、必要なインフラを自分でプロビジョニングすることができます。その代わり、プラットフォームチームは、各チームがインフラを自らプロビジョニングする際に、セキュリティチームが検証・設定し、財務チームが費用対効果について承認したクラウド上のリソースを自動的に使用するようにプラットフォームを設定します。いまでは、集中化されたプラットフォームチーム組織が、デリバリーチームのために実際に作業を迅速化しています。なぜなら、デリバリーチームはリソースのセキュリティを評価する必要がなく、追加のセキュリティエンジニアリングを行う必要もなく、使用するリソースの費用対効果を正当化する必要もないためです。また、インフラを独自に構築できるため、管理上のオーバーヘッドも発生しません。

この場合、集中化された機能は、実際に分散化されたチームをスピードアップさせたのです　-これは大きな勝利ですね！　先ほどの DHS の例では、集中化された機能が門番の役割を行い、他のチームへの引き継ぎも伴うため、遅延やフラストレーションを引き起こしていたのと対照的であることに注目してください。

このように、機能を集中化させることでスピードが増すのであれば、確かに集中させるべきでしょう。しかし、それがすべてではありません。組織が機能を集中化するもう一つの理由は、企業全体のガバナンスを行うためです。DHS では、本部がセキュリティや支出を管理する必要があるため、これらの業務を行う組織を集中化しています。このようなニーズに、スピードを落とさずに応えるにはどうしたらよいのでしょうか。

まず、そのような中央集権的なガバナンスが本当に必要なのかどうか、問う必要があります。私の著書では、IT業界における条件反射的な標準化に注意するよう説いています。 慎重に分析すれば、標準化によって得られるビジネス上の価値は、標準を遵守させるためのガバナンス機能にかかる追加コストや時間の長さを正当化できないかもしれないのに、標準化が必要だと思い込んでしまうことがよくあるのです。また、私は、ガバナンスによる管理とマネジメントによる管理の間のトレードオフを指摘するのが好きです。ガバナンスは、ルールを作り、ガバナンスメカニズムを導入し、その結果コストが発生します。しかし、優れたマネジメントによって、同じかそれ以上の結果を得られることもよくあります。例えば、ガバナンスは、標準化されたソフトウェアデリバリープラットフォームを使用するようチームに強制するかもしれません。一方、経営陣は、標準化されたプラットフォームを使用しなかったチームに、その理由を尋ねるかもしれません。そうしないことを決めたとき、彼らは本当に会社の利益を一番に考えていたのでしょうか？良い行動を取るために、必ずしも規則や強制力が必要なわけではありません。多くの場合、有能なマネジメントが問題を解決してくれます。

しかし、中央集権的なガバナンスが必要だとしましょう。幸いなことに今日では、分散したチームのスピードを落としたり、オーバーヘッドを増やしたりしないようなガードレールによって、自動化で実現できることが多いのです。私は時々、「お役所仕事を自動化する」という話をします。今日、私たちは「コードとしてのコンプライアンス」、「コードとしてのポリシー」、「コードとしての監査」を実現することができます。官僚主義はスピードと創造性を妨げず、ガードレールの中でそれらを調整するだけです。

自動化されたお役所仕事の例をすでに挙げました。プラットフォームチームは、チームがセルフプロビジョニングで使用するために、吟味されたリソースのみを提供します。セキュリティチームのガバナンスは、利用可能なコンポーネントの選択の中にすでに組み込まれています。彼らはこれ以上干渉する必要はないのです。もう一つの例です。セキュリティチームが、他のすべての IT チームが使用できるように、ポリシーに準拠しているかどうかをチェックする自動テストを作成しました。コードがセキュリティテストに合格していることを確認することで、デリバリーチームは独立して最高のスピードで作業を進めることができました。また、テストを通じてセキュリティチームはガバナンスを提供しました。同様に、財務管理も自動化することができます。例えば、使用されていないリソースをシャットダウンしたり、費用対効果の低いリソースを使用するチームを止めたり、あるいは、高額になりそうなことをチームが計画した場合は財務担当に通知したりすることができます。これらの自動化されたメカニズムはすべて、集中化された機能で決定されたガバナンスコントロールを実施しますが、チームのペースを落としたり、創造性を妨げたり、管理上のオーバーヘッドを増やしたりするものではありません。

そこで、集中化と分散化のトレードオフを管理するための経験則を紹介します。

• デフォルトで分散化する
• 分散したユニットをスピードアップさせる場合は集中化させる
• ガバナンスが必要な場合は集中化するが、依存関係を作らない自動化された方法で行う

-Mark

この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文はこちらです。