日本のクラウド市場は3年後の2025年には約6兆3,000億円に到達すると言われており、企業のクラウド活用は今後も加速していくことが予想されます。

一方、組織内でクラウド導入がなかなか進まないケースや、クラウド活用が高度化・複雑化する中で、逆に負荷が増えてしまっているケースも起きています。
こうした課題を解決する手段として、今注目を集めているのが「CCoE（Cloud Center of Excellence）」。クラウドの社内利用拡大に必要な活動を主導する、組織の組成です。

2022年9月27日、KDDI株式会社（以下 KDDI）とアイレットによる Web セミナー「『CCoE』が担う組織のクラウド戦略推進」が開催されました。登壇したのは、KDDI株式会社 ソシューション事業本部 DX推進本部 ソフトウェア技術部 エキスパートの大橋 衛氏と、アイレット株式会社 執行役員 エバンジェリスト の後藤 和貴。

実際に CCoE によってクラウド活用を大幅拡大させた KDDI の取り組みや、クラウド推進において抑えておきたい勘どころ、高度化するクラウド活用に対応するマネージドサービスの活用事例などを紹介しました。

KDDI の AWS アカウント数13倍、利用料を28倍に引き上げた「CCoE」の戦略

最初に登壇したのは KDDI の大橋氏。クラウド導入の壁を打破する手段として CCoE が果たす役割を、KDDI の事例を交えながら紹介します。
大橋氏が CCoE を語る上でよく参照しているのが、アマゾン ウェブ サービス（AWS）が発表している「クラウド導入の2つの道と4つのステージ」という図です。

クラウド導入は4つのステージを推移しながら、SoE 領域（IoT、ビッグデータ、ML/AI、IT 駆動のビジネス革新）から SoR 領域（基幹システムを中心としたレガシー設備、クラウドへの移行と最適化）へと進んでいくことを表した図なのですが、「これを進めていく中で、停滞してしまうことも起こります。よくあるのは導入期から創設期へと移行できずに頓挫したり、創設期でルールは作れたのに次のステップに進むフェーズで足踏みしてしまうケース。SoR 領域に移行したけれど全体に広がっていかないというケースもあります」と述べ、具体的には創設期から移行期に移る段階での「キャズムの壁」と、移行期から最適化/再開発期に進んでいく際に「レイトマジョリティ勢をリードできるか？」という壁を越える必要があると説きます。

この2つの壁を越えるための3つの柱として大橋氏が挙げたのが、「障壁排除」「情報発信」「人材教育」です。「まずは活動の障壁となっているブロッカーを特定して排除し、推進していくための組織を作ります。次に、継続的な情報発信によりムードを作り、内部の認識を変えていきます。最後に、クラウドを扱えるエンジニアの育成や、クラウド活用を進めていく人材の育成を行ないます。こうした活動を通じて、クラウド導入を推進していくことが可能になります」と大橋氏。

今回はその中でも「障壁排除」と「人材教育」について、実際に KDDI が行なった事例を交えながら紹介がありました。

まず「障壁排除」に関しては、KDDI におけるクラウド導入の障壁は現行のセキュリティールールにあると特定。CCoE を立ち上げた上で、①セキュリティ設計書の作成、②監査運用体制の構築、③クラウドガバナンスツールの作成、④全社システムセキュリティ管理要領の改定、という4つのステップを通じてクラウド統制最適化を図ったそうです。各ステップの実施内容は下記の通りです。

①セキュリティ設計書の作成
長年の電気通信設備開発で鍛え上げられた開発・運用の厳格なセキュリティ要件リストを要素分解し、クラウド開発・運用に必要な要件に落とし込み、AWS 版のセキュリティ設計書を作成した。

②監査運用体制の構築
従来は事業部門が監査部門にセキュリティ設計を提出して監査を依頼していたが、監査部門にはクラウドに関する知見がないため利用がなかなか進まず、必要なセキュリティ対策は事業部門が自前で実装する必要があった。そこで CCoE が間に入って統制ツールの整備や運用、クラウド設計支援を行うことで、クラウド利用を後押しした。

③クラウドガバナンスツールの作成
アカウント配布の総元締めを掌握し、最低限のセキュリティガバナンスを事前に適用した上で子アカウント（IAM）を配布。セキュリティガバナンスは子アカウント側からは更新／削除できない仕様にすることで、ガバナンス統制を実現した。

④全社システムセキュリティ管理要領の改定
AWS 版のセキュリティ設計書とクラウドガバナンスツールをセットにし、これらを運用するための監査運用体制も盛り込んだ形で「全社システムセキュリティ管理要領」を改定。AWS を KDDI 内で唯一使うことができるパブリッククラウドとして、「認定 AWS」と名付ける（認定 AWS の保守運用はアイレットが担当）。

もう一つのポイントである「人材教育」に関しては、まずは社内外におけるコミュニティ文化の醸成に取り組んだと言います。具体的には「Tech-on」という KDDI 初の技術コミュニティを立ち上げてメンバーを募りました。「Tech-on」はその後、社外向けのコミュニティとして社外技術者も参加するようになり、さらに「Tech-in」という社内向けコミュニティを立ち上げて2つの軸でコミュニティ活動を運用。コミュニティは人数の増加とともに分社会が次々と生まれていき、新たに設立された全社横断型コミュニティ「KDDI Cloud User Group」の参加者は1,200人以上、社内最大の技術ユーザーコミュニティへと成長しました。

「こうした活動の結果、2016年の認定 AWS 開始から2022年7月には AWS のアカウント数13倍、利用料28倍の規模に拡大し、さまざまな部門で AWS が導入されています」と大橋氏は述べます。

急速な浸透の弊害としては「AWS が神格化され過ぎてしまう」という課題が生じたため、2021年にはあえて「認定」という冠を外して、AWS だけでなく Google Cloud や Microsoft Azure、Oracle Cloud も利用可能にした上でセキュリティ設計書を改定。アイレットとともに AWS のクラウド統制機能「AMATERATH」を開発し、“新認定 AWS”として運用しています。

最後に大橋氏は、9年以上の CCoE 活動経験から得たクラウド活用推進の勘どころとして、①自社にとって最大のブロッカーを見極める、②CCoE は複数人構成かつ社員を必ず1人専任につける、③カルチャー変革は人の心の変容が欠かせない、という3つのポイントを挙げ、「クラウド導入は非常に長い年月がかかることを覚悟した上でスタートする必要があると思います」と述べて締めくくりました。

高度化するクラウド利用や、マルチクラウド環境の課題を解決するフルマネージドサービス

続いて、高度化するクラウド利用やマルチクラウド環境で起きている課題と、その課題解決に導くマネージドサービスの活用事例について、当社の後藤から紹介がありました。

昨今、大企業においてもクラウド活用が盛んになりつつありますが、一方で「ビジネス部門はすでに AWS を活用しているけれど、IT 部門や情報システム部門では活用が進まない」「基幹系システムのクラウド化をどう進めればよいのかわからない」といった課題も生じています。後藤はその背景にある問題点として、「お客様ごとに用途や必要な機能が異なるため、発注先が多くなってしまい、結果的に煩雑でコスト増になっているのではないかと考えます」と述べます。

さらに企業のクラウドジャーニーを4段階に分けた上で、フェーズが進むにつれて直面することが多い課題を指摘。「よくあるのが、従来のオンプレミス環境を残しながらクラウド環境を試すために両方を管理する負荷が生じてしまったり、クラウドに本格移行する段階でオンプレミス時代に培ったスキルやノウハウとは異なるものが必要になったり。どんどん進化する新しいサービスを自社に組み込んで、最適化する必要が出てくるケースです」と、よく起こりがちな課題を解説しました。

こうした課題に対して、まず運用の負荷対策に関してはマルチクラウド対応のプラットフォームマネジメント機能を選ぶことで負荷を下げたり、運用の自動化を進めることが可能になります。また、最適化に関しては KDDI DIGITAL GATE のように PoC ができる現場を活用することで俊敏性の高いアプリケーション開発を実現したり、カスタマーサクセス機能を有するサービスを選ぶことで最新化・最適化につなげることができます。

「当社のようにマネージドサービスを提供している事業者や、複数のクラウドを提供できる外部パートナーを選ぶことで煩雑さがなくなり、窓口の統一が図れます。最終的に、皆様の負担を軽減できるのではないかと思います」と後藤。

ここで実際にマネージドサービスを活用して成果が得られた事例として、店舗や事業所、オフィスなどに Wi-Fi ネットワーク環境を提供する株式会社ナビック様とのプロジェクトについて紹介がありました。

ナビック様は「サービス利用者の増加に伴って増え続けている管理負荷を軽減し、エンジニアをコア業務に集中させたい」というニーズがありました。そこでアイレットは「Rackspace Service Blocks for AWS」の導入を提案。セキュアなエリアにあるサーバーへの、直接アクセスを実現しました。これにより AWS 運用にかかっていた人件費を4割削減。加えてセキュリティ対策の負荷軽減にもつながり、ナビック様は自分たちの技術を“選択と集中”することで、運用管理業務ではなく事業のコア業務に注力できるようになりました。

このようにアイレットでは、クラウドの導入設計から構築・保守・運用をトータルでサポートする「cloudpack」およびクラウドマネージドサービス「Rackspace」と、システム設計・開発・デザインをワンストップで行なう開発サービスを提供しています。

昨今増えている複数のクラウドサービスを使うケースや、クラウドとオンプレミスの双方をハイブリッドで運用するケースなど、クラウド活用の複雑化・煩雑化に対応するマネージドサービスの提供にも定評があります。「我々の知見を生かしてお客様にどんどん推進していきたいと思いますので、ぜひ興味がある方はご連絡いただければと思います」と後藤は述べました。

Q&A

2人のセッション終了後、参加者から寄せられた質問をいくつか紹介します。

Q. 今2人が注目しているクラウドのトレンドは？
後藤：日本でも複数のクラウドを使う企業が増えてきているので、そこに対応したツールやサービスをずっと探しています。マネージドサービス以外にも、モニタリングサービス、アプリケーションをモニタリングするものやセキュリティのチェックツールなどは、複数のクラウド、複数のアカウントに対応するものが増えてきているので、僕は結構好きでチェックしています。

大橋：クラウドから少し軸がズレてしまうかもしれませんが、ノーコード／ローコードの発展に注目しています。プラットフォーム上に直接アプリを作り込んでいる、しかもプログラマーではなくても簡単に作っているという事例が増えてきているので、ものづくりが Web サービスを作る観点からシステムを作る観点に移行するんじゃないかと感じています。

Q. マネージドサービスはどのベンダーも同じ内容に見えてしまうのですが、自社にあったサービスを選定するポイントは？
後藤：アイレットを含めてMSP（マネージドサービスプロバイダ）はさまざまな企業があり、最近はお客様側の理解度や期待値も高くなっていると感じています。その中で自分たちがマネージドサービスを提供しながら「これがあって良かった」と思うのは、実際にシステム開発やサービス運用のお手伝いもしているので、お客様目線で困ったことに対するアプローチが提案できるという点です。例えばスマホゲームのトラフィックのピークを実際に体感したことがあるからこそ「それをインフラに落とし込むならこんな機能やスケーリングが必要だよね、こんなアーキテクチャが良いよね」という話を、実体験ベースで展開できます。インフラ以外も扱っている MSP であるところは、ポイントなのかなと思います。

Q. エンジニアとして、特定のクラウドを使い倒した方がいいのか、マルチクラウドを志向したほうがいいのか、どちらを優先すべきでしょうか？
大橋：クラウドを使っていく上で非常に重要なのは、クラウドそのものの機能を理解することではなく「クラウドとは何なのか？」という本質を理解することです。そう考えると、いきなりマルチクラウドを志向するよりも、1つのクラウドを徹底的に使い倒してクラウドの本質を捉えた上で、他のクラウドに広げていくほうが良いのかなと思います。

後藤：同意見です。クラウドの新しい概念や、それがビジネスのどこに役立つのかというポイントを理解するために、1つのクラウドを集中して使い込み、自分なりの型を1つ作ることが大切だと思っています。

Q. CCoE を立ち上げる場合と、外部のサービスを頼る場合と、TCO（Total Cost of Ownership）で見ると、どちらにメリットがあるでしょうか？
大橋：CCoE を立ち上げずに完全に外部に頼ってしまうと、クラウドを扱う上でのノウハウをリードする役割がいなくなり、パートナー企業さんにおんぶに抱っこになってしまいます。リソースをどこに集中すべきなのかという議論はあるにせよ、やはりクラウドを引っ張っていく役割の人間は必ず内部に立てる必要があると思っています。外部に出すとコストはかかるけど立ち上げは早いというメリットはあるかもしれませんが、ゆくゆく大きくしていくのであればいずれにせよ CCoE は必要になってくるので、CCoE を立ち上げる前提で一部外部サービスを活用しながら進めていくのはアリだと思います。

後藤：クラウドは概念的なものと言いますか、企業変革に使えるツールでもあるので、やはり組織に定着しないことには活用が進みません。その意味では、社内にいる人がしっかりとノウハウを蓄積しながら、外部の優れたツールや会社を活用していくのが理想的な方法だと思います。

Q. CCoE組織の場合、最終的なゴールはどこになるんでしょうか？クラウドネイティブな企業に変化したあとも、CCoEは組織として残り続けるのでしょうか？
大橋：CCoE は最初から解散を前提に作っていくべきだと思っています。社内のクラウド活用が当たり前になって、牽引する組織がなくても大丈夫であれば必要ありません。ただし、CCoE が受け持っていたアクティビティを社内に移した上で解散するべきだとは思います。

Q.クラウド利用の拡大に向けて、共通化したツール類やテンプレートなどは多数つくられたのでしょうか？
大橋：多数は作っておらずむしろ最低限にとどめています。
これは KDDI が提供するサービス領域が非常に広い（トラフィック重視、スマホ領域、ACID なデータトランザクション重視、オンプレネットワークとの絶対的親和性、等）ことと、システム開発の体制上の問題（殆どが外注であり余計な制約条件は外注先からの提案の妨げになったりコスト増の原因になるが、守るべきセキュリティ要件は全社統一で完全に明文化されている）からあえてそうしています。
事業領域が限定的で、またクラウド化を進める範囲も広くない場合であれば、そこに集中してツール、テンプレート、フレームワーク、プラットフォームを整備していくことはクラウド活用推進に非常に効果的と思います。

Q. 社内で CCoE 組織を組成しようと思っております。担当するメンバーのクラウドの知識・知見は必須と考えておりますが、その他に必要なスキルセットや経験等あればご教示いただけないでしょうか？
大橋：これは、御社がどこに課題を抱えているかに依存します。
たとえば我々の場合、情報セキュリティ統制が最も大きなブロッカーだったために、卓越したクラウド設計能力よりも、最低限のクラウド知見をもつセキュリティスペシャリストが必要でした。テクニカルスキル以外においては、社内のシステム構築におけるイロハ（構築時に必要となるネットワークの手配、各種ルールの準拠等）を押さえた社員と、あとは組織的な課題解決にあたり部門間交渉を行う必要があるため、それらに長けた社員もメンバーに必要となります。

Q. 社内の大量のアカウントを集中運営する上で、Organizations 以外にどのような管理がよいでしょうか？
大橋：クラウドネイティブなアーキテクチャを想定すると、ベースラインとなる IaaS の構成はどんどん進化してしまうので、ここに制約をかけるような予防的統制はナンセンス（自分自身で維持できなくなり破綻する）といえます。
この部分は最小限にとどめ、外部から脆弱性を検知検出する発見的統制を強化する形が理想的です。
なお当社は iret というリセラー経由で社内アカウントを手配していたため、最近になるまで Organizations を使っていませんでした。大量のアカウントを集中管理するという点においては当社でもまだ実現できておらず大きな課題として改善に取り組んでいる最中です。やるべき内容としては、利用費の管理、利用サービスの推移といった傾向監視と、利用部門とアカウントおよびシステムの紐づけがシームレスに行われ、何らかの異常が起きた際に利用部門と CCoE とですぐに現状の共有と原因究明に取り組めること。と考えています。

最後までお読みいただきありがとうございました。
本 Web セミナーは、2022年12月8日(木) 14:00～15:00より再演いたします。下記フォームよりお申し込みいただき、ぜひこの機会にご視聴ください。

「『CCoE』が担う組織のクラウド戦略推進」 お申し込みフォーム：
https://kddi-l.jp/dIG