0→1 よりも難しい 1→10 の世界、CCoE 設立後の落とし穴

この記事は CCoEクリスマス！クラウド技術を活用して組織をカイゼンした事例を投稿しよう！ by KINTOテクノロジーズ Advent Calendar 2023 5日目の記事です。

こんにちは、_awache です。

今回は CCoE 立ち上げ ~ 軌道に乗せるまでで僕自身が一番苦労したポイントをフィクションを交えながら記事にしてみようと思います。

プロローグ

とある企業に勤める A さんはある日、クラウドをもっといい感じに活用できる様にするため組織横断的に活動して欲しいと言われ CCoE を組成した。

CCoE とは

CCoE（Cloud Center of Excellence）は、企業や組織が専門的な知識やベストプラクティスを集約し、共有するための組織の中枢です。

CCoE の主な役割は以下の通りです。

• クラウド技術の導入や活用に関するガイドラインの策定
• ベストプラクティスの共有と普及
• クラウドプロジェクトの支援とコンサルティング
• セキュリティやコンプライアンスの管理
• 技術トレーニングと教育の提供

CCoE立ち上げ期の高い成果

CCoE をはじめとする横断組織の 0 → 1 期は実は成果が出しやすいフェーズだと個人的には思っています。

なぜなら組織の組成直後はやることが明確であったり、課題を聞いてやることを自身で立てることがしやすいため、アウトプットが非常に出しやすい立場にあるからです。

つまり、このタイミングでは WHY が明確であり、そしてそれに伴う WHAT と HOW を自分たちで考えて適用することができるということです。これには下記の要素が大きく関係しています。

エース級の人材の投入

組織を形成する際にはやはり成果を出せる人材をアサインすることが多いと思います。

またそれを取り囲むメンバーも少なくとも CCoE に興味がある、Cloud を一定触ることができるメンバーでしょう。

更にエース級の人材というのは大抵の場合社内事情にも詳しく、企業横断的な立ち振る舞いをするときにそれぞれの事業のメンバーに対して説得力を備えており、政治的にも強いことが多いです。

だからこそある程度抽象的な課題であっても CCoE はそれを解決する方法を自ら見つけ出し、それを企業全体に適用するための HOW を作ることができるのです。

経営層に非常に近いレポートライン

組成直後、CCoE のトップは CIO や CTO、もしくは部長クラスの方々がマネージャーとして兼務しているパターンをよく耳にします。なぜなら CCoE は企業課題に立ち向かうために組成される組織だからです。だからこそ CCoE は経営を巻き込んだ勅命で動くことが多く、短期的視点だけでは実施できないような大きな判断を実行に移すことができる、というメリットを併せ持つことになります。

短期的視点だけでは実施できない大きな判断の例としては

• EC2 を脱却し、すべてのサービスを (ECS/EKS など) コンテナや (lambda/AWS Batch など) Serverless 構成にすること
• セキュリティやガバナンスを適用するために AWS Config を有効にし、それをすべての部署が遵守すること

など、トップダウンだからこそできる大きな投資を実現することが挙げられます。

また CCoE の施策に対してネガティブな反応をされたとしても Executive Sponsor からの後押しがあることで、多少強引だとしても施策を適用することも不可能ではありません。

これらの要素があるからこそ、CCoE は自分たちの施策をビジネスに適用し、より良い成果を上げることがしやすいのが CCoE の立ち上げ期です。

インターミッション

A さんはまず企業の現状を把握するために AWS Trusted Advisor や AWS Config を使って、企業のセキュリティやガバナンス、そしてコスト最適化、など様々なモノゴトを可視化していった。

「クラウドをもっといい感じに活用できる様にするため」という目的を達成するために、クラウドサービスを適切に利活用して、そしてそれらを誰でも見える様にするためダッシュボード化や Slack 通知などを実装し、経営に現状を分かりやすく説明できる状態になった。

経営陣も期待通り、もしくはそれ以上の成果を見せてくれている CCoE により一層の期待を寄せることとなった。

が、しかし、この先には落とし穴が。。。

0→1 よりも難しい 1→10 の世界、CCoE 設立後の落とし穴

組織の役割の拡大とその反動

さて、ここからが 1 → 10 フェーズへの入り口です。

現状を可視化するためのダッシュボードや通知の仕組みなど、開発したサービスの運用や、経営からの課題の本質である「クラウドをもっといい感じに活用できる」状態を作らなければなりません。

CCoE としてやるべきことがアプリケーション (クラウド) エンジニアリングから組織全体に準拠してもらうため、自分たちだけでできることを超えて、それを扱うユーザーに直してもらう、というフェーズに入ることとなるのです。

例えば AWS Config の準拠率を改善する、として、どんなに簡単な設定変更でも自分たちではなく事業の人たちに直してもらわない限り適用されないのです。

運用フェーズになったときに突然やってくるモチベーション低下

個人的に持ったことのある横断組織に関しては漏れなくこの呪いにかかりました。

急激に成長したからこそ発生するのですが 0 → 1 の時のような勢いでアウトプットができなくなる、これが大きな要素です。

このフェーズになるとそれまでのイケイケだったアウトプットに比べるとどうしても動きの鈍化にモヤモヤを感じてしまいます。

更に 0 → 1 フェーズで出したアウトプットの次を考えたときに、より良いことをしたい、しなければいけないというプレッシャーとも戦うことにもなります。

会社に対する価値の還元と本気で向き合うこと

これは 1 → 10 フェーズで最も大切なことだと思っています。正直マネジメントしている身としては非常に辛い時期でもありました。

CCoE に限らずですが、横断組織は自分たちのアウトプットが継続的にビジネスに反映される状態でなければ意味がありません。横断組織はそこにあるだけでは何に使われているか分からない税金と同じなのです。

実践：Cloud Center of Excellence を中心としたクラウド戦略 より抜粋

この状態に陥ると全ての CCoE アクティビティに対して、この施策は自分たちが目指していることに繋がっているのか、無意味なことをしていないか、など自分たちの施策の一つ一つに疑心暗鬼な状態になってしまいます。

モチベーションがなくなり異動や退職ということを考えるメンバーも出てくるかもしれません。その悪い雰囲気は他のメンバーにも少なくない影響を与えてしまいます。
0.9 * 1.1 = 0.99
の様にモチベーション低下したメンバーをフォローするためには下がった分と同じ量を上げても元には戻らないのです。これがチームに浸透してしまうと修復不可能な状態になってしまいます。

落とし穴に完全に落ちないためにやるといいこと

自分たちの成果を書き出して伝える

CCoE の内部にいると外部にどの様に良い影響を与えているのか、自分たちの成果を客観的に感じる機会は実はなかなか無いと思います。だからこそ僕自身は最初に書き出して伝えると言うことを行いました。これをすることで自分たちのアクティビティが会社にもたらした変革を感じる手助けになったと思っています。下記はその一部です。

目標設定時にメンバーの期待役割を伝える

それまで僕は目標設定時には各自の立ててくれた目標を肯定しつつ、CCoE としてこれを実現するためにどうして欲しいのか、の様な、どちらかというとメンバー個人ではなく、チームのアウトプットを出すために実現して欲しいモノゴトを伝えていました。

やはりメンバーは一人の人です。施策を達成するための目標と、メンバー一人一人の特性に合わせた動き方の期待値をしっかりと伝えることは「なぜあなたがこのチームに必要なのか」を伝えることになり、メンバーのモチベーションを保つためにも重要なことだと感じました。

コミュニティへの参加

当時 CCoE をメインで扱うコミュニティは Google Cloud のエンタープライズユーザー会である Jagu’e’r の CCoE 研究分科会のみでした。そこで Google Cloud の当時の営業の方にお願いしてこのコミュニティに入らせていただきました。

企業の中ではファーストペンギンかもしれませんが世の中を見渡すと共通の課題を持っている人たちがたくさんいます。このようなコミュニティに参加することで、私たちは単に情報を共有する以上の価値を得ることができました。

異なる背景を持つメンバーとの対話を通じて、新しい視点やアイデアを得ることだけでなく、共通の課題に対する多様な解決策を学ぶことで、僕たちのアプローチにも柔軟性が生まれ、より効果的な戦略を開発することが可能になりました。

Vision の再作成と CCoE サービスメニューの作成

コミュニティから刺激を受けて自分たちに出来ること、目指すべきことを見直しました。メンバー全員が納得するまで話し合い、そして一つのゴールを設定しました。それが「CloudNative を実現する」というものです。文字にするとこれだけですが、これを作るには 1年ほど時間がかかりました。ここに至るまでに非常に多くの検討をしました。

そして最終的に自分たちが実現することを示した「CCoE サービスメニュー」と併せて決定することで Vision と戦術を備えた状態になりました。

下記は CCoE 4本の柱の一つである Security のサービスメニューです。小さいのは、、いろいろ察してください。。

まとめ

今回は CCoE の立ち上げよりも実は 1 → 10 フェーズの方が難しいと言う話と、実際にその問題に対してどんな対応をしたのか、を記載させていただきました。

組織の 0 → 1のフェーズでの成功は、明確な目的、エース級の人材の投入、そして経営層との密接な連携に支えられています。しかし、1 → 10への移行は、これらの初期の成功を経て、複雑な道のりを歩いていくことになります。

組織が拡大するにつれて出てくるモチベーションの低下や、組織間の協力の必要性などの問題を克服するために、CCoE 内部での成果の明確化、メンバーの役割の明確化、外部コミュニティへの参加、そして目的と戦略の再定義が鍵となります。

このブログを読んで、皆さんが自身の組織やプロジェクトで直面するかもしれない課題に対して、新たな視点や解決策を見つけることができれば幸いです。

おまけ

文中にも出てきました Jagu'e'r CCoE 研究分科会では Jagu'e'r CCoE 歳末Meet UP!
を実施予定です。 Jagu'e'r 会員なら誰でも申し込み可能なのでこの機会にぜひ Jagu'e'r 会員となって申し込みしてみてください。
新しい発見があるかもしれません！

実際のアクティビティは下記の Speaker Deck に詳しく書いてあるので興味があればご確認ください。

DXを成功に導くクラウド活用推進ガイド CCoEベストプラクティス : 通称 CCoE 本に僕たちの活動が先進事例として登場しています、よろしければこちらも手に取ってみてください。