Amazon Web Services ブログ

今から始める CCoE、3 つの環境条件と 3 つの心構えとは

昨今、クラウドがビジネスにもたらす経済的価値を追求し、会社や組織全体としてこれを享受するための施策を立案/推進するチームを立ち上げるお客さまが珍しいものではなくなりました。このチームは「クラウド活用推進組織」や「クラウド CoE (Centre of Excellence)」、もしくは省略して「CCoE」と呼ばれています。この記事では、CCoE がなぜ必要になるのか、うまく機能するための環境条件、そしてどんな心構えを持って臨むのが効果的なのかを紹介します。

みなさん、こんにちは。カスタマーソリューションマネージャー (CSM) の山泉です。

この記事は、次のような方を読者として想定しています。

  • まだ CCoE を組成していないお客さまで、CCoE について知りたい もしくは CCoE を組成しようと考えている方
  • CCoE を組成しているお客さまで、業務の質を良くしたい もしくは 業務の幅を広げたいと考えている方

CCoE に属する もしくは 同様の役割を遂行するメンバーは、どんな使命と意思を持って日々の業務を遂行しているのでしょうか。AWS がこれまでご支援してきたお客さまとの対話の中から抽出したエッセンスをご紹介します。

クラウドがビジネスにもたらす経済的価値

AWS Executive Insights で示しているように、お客さまがクラウドへの移行によるビジネス価値を定量化するのをサポートするために私たちは Cloud Value Framework を開発しました。

お客さまご自身によって もしくは AWS によるサポートを受けて、クラウドを活用することでお客さまが獲得しうる経済的価値を発見/定義できたとします。では、AWS の利用を開始すればただちにこれらの価値を享受できるのでしょうか。

これが簡単ではないことは、直感的にも想像に難しいものではないでしょう。コスト削減や TCO の圧縮を成果として得るためには、既存の環境をクラウドに移行するために時間と費用を投資しなければなりません。スタッフ生産性の改善を実感するためには、移行先であるクラウド環境における運用業務が定着することはもちろん、移行元のオンプレミス環境の運用が終了または縮小することで総合的な運用負荷が低減する必要があります。レジリエンス向上はインフラやシステムのスコープを超えた議論が必要になるでしょう。例えば BCP/DR において、業務設計を見直さずにインフラやシステムを AWS へ移行するだけで得られるメリットは限定的です。クラウドだからこそ取りうる(今までは選べなかったような)手段について認識いただくことで、ビジネスを継続するための選択肢の幅を広げることができます。ビジネスの俊敏性、すなわちアジリティを獲得するためには、インフラの調達やアプリケーションデプロイにかける時間を短縮するだけでは実現できません。会社や組織として新しい価値を市場セグメントへ投入するために必要な一切の業務プロセスを加速させる必要があります。

価値を追い求める道のり〜クラウドジャーニー〜

このように、経済的価値を享受するためには、ありたい姿を明確にするとともに現状を振り返って両者の Gap を特定することが肝要です。そして特定した Gap を解消する課題を設定し、これらを達成するプロジェクトを立ち上げて推進していくことになります。これが私たちがクラウドジャーニーと呼んでいるものです。

このクラウドジャーニーには大まかに 2 つの歩み方があります。

  • 既存の IT 資産があり、これを移行または/かつ改修を施した上でクラウド化を進める
  • 既存の IT 資産がなく、新たに構築するビジネスモデルに即したシステムをクラウド上に構築する

そしてこれまで AWS がご支援してきた実績から、このクラウドジャーニーには、よく遭遇するハードルがあることがわかってきました。これらのハードルに遭遇する前に回避したり、遭遇したとしてもその影響を極小化することはできないでしょうか?

  1. 机上評価から抜け出し、実際に使ってみて経験を積む
  2. クラウド活用の経済的価値に対する理解を、会社/組織全体に広げる
  3. セキュリティリスクを集約して判断し、ガバナンスを機能させる
  4. 個別プロジェクトに閉じず、会社/組織全体で最適化な解決策を検討する仕組みを持つ
  5. インフラだけでなく、アプリケーションや業務アーキテクチャを変革する
  6. 業務要件から技術選定するだけでなく、技術が持つ可能性から業務要件を検討する
  7. 会社/組織のルールや業務プロセスの変更を忌避せず検討する
  8. 現場で生まれる知識と経験を汲み取り、会社/組織全体のレベルアップに活かす
  9. パートナーさまと役割を線引きするのではなく、共通の目標として協業する
  10. クラウド人材の働く環境をよくする

クラウド活用推進組織(CCoE)

クラウドジャーニーに点在するこれらのハードルは、似たようなものが複数の異なる開発チームに出現したり、時には部門をまたがって大きなハードルとして出現したりします。そして、これらのハードルを突破するための充分な知識と経験を持つリソース(人的資本)が開発チームに不足していると、より状況が難しくなります。うまく進めるためには、開発チームの活動を停滞させない支援が必要です。さらに言えば、まだそのような価値を見出していない他の開発チームに気づきを与えるような環境構築が必要です。

であるならば、貴重な専門知識と経験を一箇所に集めて専門家集団(Centre of Excellence)とし、リスクや課題を集約して槍のように一点突破しようというのが「活用推進組織」の構想です。とくにクラウドについてのそれを、クラウド活用推進組織(CCoE; Cloud Centre of Excellence)と呼びます。裏を返せば、上記条件に合致しない場合は、CoE の組成を強く求めるものではないと言えます。ぜひ、所属される会社/組織において、どのような課題が、どのように分布しているか調査/分析してみてください。

CCoE は、現場で活用できる貴重な専門知識と経験を持った人的資本の集合体です。しかし、そのメンバーがすべてのプロダクトやサービスの開発を直接的に担っているとは限りません。CCoE を専任とするメンバーであるなら当然ですが、兼任する場合であっても同様です。すなわち、あるプロダクトの開発チームに所属している専門人材が、兼務として CCoE を担い、他のプロダクト開発チームに助言するようなプロセスになるからです。

ゆえに CCoE は、現場の良き相談相手となることが理想的です。あくまでクラウド活用の主役は現場です。現場がクラウドを安心、安全に、効率的に、そして楽しく使えるように環境を整備するのが CCoE の仕事になります。

現場を支えるために必要な環境整備を行う。このような仕事は、事業や業務構造に依存し、また組織構造に依拠して多岐にわたると想像できるでしょう。しかし、それを最初から全ての事業、プロダクト、システム、そして課題をカバーする必要はありません。たとえば、パイロットプロジェクトを見つけ、まずは彼らが必要とする支援から小さく始めて良いのです。そして徐々にリソースを拡充し、タスクの深さと範囲を調整していきます。場合によっては、既存組織に役割を委譲することも有効な手立てです。

クラウド活用推進組織(CCoE)が機能する3つの環境条件

クラウドがビジネスにもたらす経済的価値を享受するため、全体最適の視点で施策を立案/推進し、現場を支えるのが CCoE であると説明しました。ここから、CCoE がうまく機能するための3つの環境条件が見えてきます。

  1. 会社/組織としてクラウド活用の意思を持つ:
    • 会社/組織の IT 戦略は、クラウド活用を進めることでどのようなビジネス成果を実現したいのか、その重要性と期待を明確に述べている。
    • 当該 IT 戦略は経営戦略と整合しており、オーナーシップを持つ意思決定層/トップマネジメントが存在する。
  2. クラウド活用において、組織横断かつ構造上の課題を有する:
    • 特定のプロダクトや部門だけでなく、複数のプロダクトや会社全体に影響を与える課題がある。例えば:
      • セキュリティとコンプライアンスを維持するためのリスク統制機構が整備されていない。
      • 閉域網接続、従業員や顧客の認証と認可、ログ集約、監査機能など共通サービスが整備されていない。
      • キャパシティプランニング、クラウド型の財務管理など従量課金型サービスの活用ノウハウが少ない。
      • 縦割り構造の組織、細分化された機能と役割など変化に対応する組織文化が成熟していない。
    • 前項課題の達成で得られるメリットを前記意思決定層/トップマネジメントが理解していて、その達成を支援している。
    • CCoE は自らの提供価値と、提供先である現場(プロダクトや部門)とを明確にし、サービス仕様を言語化している。
  3. クラウド活用スキルの不足やリソースの偏りがある:
    • 前記課題を達成するために必要な知識と経験を持ったリソース(人的資本)が、特定のプロダクトや部門にのみ存在している、またはいずこにも存在しない。
    • 「クラウド活用スキル」は、クラウドの使い方などの技術的スキルに限定されない。ビジネスへの活用方法を探るヒアリング(傾聴、引き出し)スキル、専門知識なしに理解できるように課題を可視化するコンセプチュアル(概念化)スキル、ステークホルダーを巻き込んで仮説検証を回し続けるコミュニケーションスキルなど非技術的スキルも必要になる。

まず、会社/組織としてクラウド活用の意思を持っていることが大切です。これがあることにより、CCoE が検討し発布するガイダンスが効力を持ちます。もし意思がない状態であれば、CCoE がガイダンスを取りまとめても現場が活用することはないでしょう。

次に、組織横断かつ組織構造上の課題が存在していることです。例えば、複数のプロダクトで使われる可能性のある顧客認証システム、メンテナーが使用する閉域網や名前解決機能などのバックオフィス機能、内部統制対応のためにログを収集する機能などは、プロダクト個別に開発はせず共通機能群として整備する方が全社最適が期待できます。もし単一のプロダクトを担当する組織や部門内でのみ、クラウド活用の課題が生じているだけであれば問題解決のテーマは限定されて、その知見を外部に展開する動機付けが薄くなります。この場合は、部門を跨って専門家が集まり解決する必要がありません。ここで言う「課題」は、技術領域に留まりません。従量課金型であるクラウドサービスを経済合理的に活用するノウハウであったり、部門間で業務要件含めたトレードオフを解決するなど、非技術領域の課題も含まれます。

最後に、上記のような課題が生まれたときに解決できるリソース(人的、コスト)が特定の場所に偏っていたり、存在していない場合です。そうでなく、いずれの組織にも充分なスキルレベルを持つ人員が、充分な数(と工数)存在するならば、当該課題に対応する役割を持つ部門が通常業務として達成すればよく、集団として集まって推進する必要はありません。特に忘れられがちなのは、非技術的スキルです。クラウドのサービス仕様に精通し、課題に対する的確なソリューションを導き出す技術的スキルは重要です。しかし、解決すべき問題や達成すべき課題は何かを探り出す、問題/課題を設定する能力はより重要です。顕在化していないそれらを現場(業務、IT)から抽出し、取り組むべき対象(問題、課題)としてまとめ、取り組む仲間を集めて推進するスキルも CCoE には必要になってきます。

CCoE の活躍にはこれらの条件が強く影響します。CCoE のミッションやタスクは、時が進むにつれて、クラウドジャーニーが進むにつれて変化します。しかし、これらの条件が変わることはありません。ぜひ、定期的に振り返ってみてください。

CCoE のリーダーやメンバーは、どんな心構えを持って臨むべきか?

では、CCoE はどのようなメンバーで構成されるべきでしょうか?
パブリッククラウドの知識/スキルが豊富な人材を集めるべきか?ベテランが良いのか?若手メンバーで構成すべきか?
いろいろな悩みポイントがあろうかと思います。

しかしながら、CCoE に必要な立場や役割、それに応じたスキル、役職、年次などの表面的な要素だけでリーダーやメンバーを選定することがベストプラクティスなのでしょうか?答えは “No” です。

では、何を重視すべきか?それは「心構え」です。

思い出してください。なぜ、何のために CCoE を立ち上げる(立ち上げた)のか?

心構え其 1 – クラウドを使って、会社、組織をもっと良くしたい –

みなさまが CCoE を立ち上げる理由は何でしょうか?「クラウド利用のためのセキュリティルールを作成するため」でも、「クラウド利用のための手順書作成」でもないはずです。これらはある目的を達成するための手段でしかありません。
CCoE を立ち上げる理由、それは「クラウドを使って、会社や組織をもっと良くしたい」ということではないでしょうか?そうではなく、手段に目が向いてしまっている場合は、立ち止まって、CCoE がなぜ必要なのかを改めて考える必要があるかもしれません。

CCoE の道なりは決して平坦ではありません。新たなルールやプロセスを作り、既存のものを作り変えたり、時には捨てることも必要です。また、目に見えるものだけでなく、社内の人々のマインドやモチベーションにまで影響を届ける必要があります。そのために、CCoE のスポンサーを獲得したり、CCoE メンバーに対する評価等のインセンティブを準備する事例もよく見られます。ただ、そういった外的要因だけで、人は動くでしょうか?

有名な「マズローの欲求5段階説」にあるとおり、評価等のインセンティブは上から 2 番目の「承認欲求」を満たしたに過ぎません。CCoE のリーダー、メンバーが真に力を発揮し、一丸となって CCoE を強力にドライブしていくためには、CCoE を立ち上げる理由に心から賛同しているメンバーで構成する必要があります。「クラウドを使って、会社、組織をもっと良くしたい」と本気で思っている、このようなメンバーを見つけ出し、CCoE に参画してもらう。これが CCoE を成功させる最初の 1 歩だと私は考えます。

心構え其 2 – 利他的であること –

CCoE のアンチパターンの1つとして、「CCoE がクラウド利用のブロッカーになる」ことです。これは、CCoE が、セキュリティやガバナンスを重視し過ぎて、多くのプロセスとルールを生み出し、煩雑さと混乱が生じてしまい、結果的にクラウド利用にブレーキがかかってしまう状態のことを指します。「会社、組織を良くしたい」という思いから、ルールを整備し、プロセスを作り出すこと自体は間違いではありません。ただ、「現場のために動く」という心構えを忘れてはいけません。

CCoE は「利他的」であるべきです。これが心構え其 2 です。

CCoE は、クラウド利用に関するルールや社内プロセスを作ることがよくあります。
ただ、なぜ CCoE がそれらを実施するのかを考えてください。CCoE は、ルールを作成しないといけないという決まりはありません。CCoE が、社内プロセスを統治しないといけないこともありません。CCoE が目指しているところは「クラウドを使用する現場がより良くなる」ことです。そのためには、「CCoE はこうあるべき」や「CCoE をどのように成長させるか」だけに着目するのではなく、「CCoE として、どうすれば、何をすれば、現場や会社はより良くなるのか」というマインドを持つ必要があります。

心構え其 3 – 変化を楽しむこと –

CCoE の活動は、既存の枠組みで収まらないケースがほとんどです。既存のルールやプロセス、時には組織までも変革させる必要があります。しかし、そのような変革を起こすには、とても大変です。CCoE は、「イケてる」仕事をしているように見られがちですが、実は、非常に大変な泥臭い仕事をする必要もあります。

想像してみてください。クラウドを活用を推進するために、既存のルールでは足りていないことを指摘し、従来の慣行に疑問を投げかけ、歴史が作り上げてきた組織構造にメスを入れる。とても一筋縄では進みません。辛抱強く、根気強く、粘り強く進めていく必要があります。

こういった仕事、状況を「辛い」と感じるようであれば、もしかすると CCoE メンバーに向いていないかもしれません。
新しいことを考えるとワクワクする、新しいもののために古いものを捨てる勇気を持つことができる、変化のプロセスも含めてエンジョイできる、こういった「変化を楽しむ」気概を持つことができるかどうかが重要なポイントになります。

ここまで、「クラウドを使って、会社、組織をより良くしたい」、「利他的であること」、「変化を楽しむこと」、この 3 つが CCoE のリーダー、メンバーとして必要な心構えとして述べさせていただきました。

スキルや知識は後からでも身に付けることができます。実際に、IT 部門ではなく、ビジネス部門の方が CCoE リーダーとして、メンバーとして Join して活用される例も数多く見られます。荒波の中で CCoE という船を漕ぎ続けるために必要なものは、覚悟と信念なのです。そして、覚悟と信念を支えるものが心構えです。

心構えは「持つ」か「持たないか」です。元来持っている人もいれば、意識して後から持つこともできます。
これから CCoE を立ち上げる方々も、既に CCoE をスタートさせている方々も、ぜひともこの 3 つの心構えを持って、取り組んでいただけることを願っております。

おわりに

いかがでしたでしょうか? CCoE に関わるみなさまに何か1つでもお役に立てる情報がございましたら幸いです。
また、今後も、CCoE やクラウドジャーニーに関するコンテンツを発信していきます。ご期待ください!

著者:
カスタマーソリューションマネージメント統括本部
カスタマーソリューションマネージャー (CSM) 山泉 亘、大東 正和

(2023/2/1) 追記:
本記事の韓国語版をリリースいたしました。
https://aws.amazon.com/ko/blogs/korea/how-to-get-started-your-own-ccoe/