Skip to main content Skip to Footer

Blog - Cloud ComputingCommentary from our cloud experts around the globeBLOG アクセンチュア・ クラウド・ ダイアリーズ

May 09, 2018
クラウドCoEとクラウドEA
By: 青柳 雅之

クラウド推進事業本部 シニア・マネジャーの青柳雅之と申します。私はAWSやAzure、GCPといった主要なパブリッククラウドを使用したIT Modernizationを担当しています。

クラウドの導入に際して、クラウドへの移行アセスメントや利用ガイドラインの標準化を行う組織は多いと思いますが、さらにクラウドを組織内で広めるために、クラウドCoE(Center of Excellence)の設立を考えるケースも昨今多くなってきていると実感しています。今回は、このクラウドCoEについて直近の事例を踏まえつつ私の考えを述べたいと思います。


クラウドCoEに潜む課題
ここ最近では大規模なエンタープライズ企業を中心に自社内にクラウドの専門家集団(クラウドCoE)を設立し、組織内のクラウドに関する問い合わせを一身に受ける役割を担うケースが増加しているように感じます。
※クラウドベンダー側としても、技術Q&Aや社内伝道師的な活動を担うであろうクラウドCoEの設立には積極的ではないかと推察します

一方、専門家集団と言えば聞こえはいいですが、実際にそこまでのスキルを有した人材をまとまった単位で集約することは容易いことではなく、CoEのメンバーの中には負荷が集中し疲労してしまう人も多いと思います。
際限のない社内からの問い合わせを少ない人的リソースで裁かければならないケース、本来はプロジェクトをリードしたいのに自身は後方支援として多数のプロジェクトのQ&A対応を担わなければならないケースなどが該当します。CoEに選定されるレベルのエンジニアは、新しいことや高度な技術が大好きですが、検索すればわかるような質問を社内から多数投げられると心が消耗してしまいます。彼らのそのワークロードと能力を、些末なQ&A対応ではなく新規ビジネスに投入すれば大きな価値を生みますが、このような状況では、彼らが組織の底上げのために犠牲になってしまいます。中にはこの仕事が好きな人もいると思いますが、単に一番詳しいからというだけで不本意にもCoEをやっている人もいるのではないかと推察します。


クラウドCoEの本質的な価値・役割
私が考えるクラウドCoEの役割とは、上記のケースのように「気軽に聞ける悩み相談室」ではないです。
開発チームは可能な限り自分で課題解決し、クラウドCoEはその手助け(必要な情報へのパス、アセット、レビュープロセス等を提供する)をするだけが望ましい関係であると考えます。クラウドCoEを、「気軽に聞ける悩み相談室」にしてしまうと、本来CoEが対応すべきよりレベルの高い業務に専念できなくなります。また、質問を投げる側は自分で調査をする努力をしないのでいつまでたっても組織のクラウドケイパビリティは向上しません。教える人と教わる人の関係もずっと継続します。
よって、本来的にクラウドCoEとして望ましい姿とは、組織で今後必要とされるクラウドの先端領域(その組織にとって)のプロジェクトを実施し、多くのチームでプロジェクトが実施される前に、先行してその知見を組織に蓄積することではないかと思います。副次的効果として、クラウドCoEが社内の志の高いエンジニアがモチベーションをもって目指す場所となり、彼らが活躍できる場所となります。さらに、もしも多くの事例がパブリックに公開されると、人材採用の面でも有利でしょう。


クラウドCoEの構成
上記の課題を解決しながらどのようにクラウドCoEを構成すればいいでしょうか。
まずコアとなるべき人材は必要です。最も詳しい人がCoEになるケースもありますが、そのような人材がいない場合は、外部から採用する、トレーニングを候補者に受けさせる、弊社のようなコンサルファームを入れて一緒にCoEを設立する、といった形が取れると思います。これらのメンバーでまずは1つ、小さいパイロットプロジェクトを実施して、小さいシステムを構築してみることです。既に利用ガイドラインや設計ガイドラインがある場合はそれを使いながら自社に最適な形に更新していくとよいでしょう。この最初の段階のCoEは2~3人かもしれません。しかし、ここでプロジェクトの最初から最後までを実施して、成果物のアセットができるはずです。このようなプロジェクトを、メンバーを追加しながら複数回繰り返すうち、アセットも増え、スキルを持ったメンバーも組織に増えていきます。ここからが重要です。しばらくパイロットを繰り返した後、順次一定数のメンバーを入れ替えていきます。クラウドCoEの人選としては現時点でのクラウドの知識の有無というよりは、継続して新しい事を学べる人がよいでしょう。その結果、選択されたメンバーが詳しい人でも詳しくない人でも構いませんが、詳しくない人がCoEのメンバーになった場合は、知識をキャッチアップするために懸命に学ばねばならず、CoEを経験することでクラウドのケイパビリティが著しく向上するはずです。メンバーを定期的に入れ替えることで特定のCoEメンバーの疲労といった課題が解決できると同時に、CoE経験者が別のチームに対して、得られた知見をメンバーにナレッジトランスファーすることで、カスケード的に組織内にケイパビリティを持った人材が増加していくというメリットがあります。


クラウドCoEのさらなる役割
クラウドCoEの役割として、「組織で今後必要とされるクラウド領域の知見を蓄積する」、「各開発チームがクラウド上の開発で自立できるように必要な支援をする」旨を記載しました。クラウドの推進に関するタスクは、クラウド移行アセスメントやガイドライン策定、PoCだけでしょうか?クラウドCoEは開発チームへの支援の他、クラウドの導入自体を推進する役割、クラウドの導入がスムーズに進む仕組みと環境の構築も担うべきです。そのための施策を企画し、実行にも深く関与します。

我々は、クラウド導入における施策を9個の視点で分類したフレームワークを持っています(他の企業も同様のものを持っています)。各視点に詳細な検討事項と施策のリストを用意しています。インフラストラクチャーコンサルティングの長い経験から、我々にはクラウドを含む様々なIT施策とその効果についての知見があります。さらに、それらの視点毎に組織が目指すべき成熟度モデルを定義しています。


図:クラウド導入における9個の視点

図:クラウド導入における9個の視点
※図中で"Stream"とは「一連の施策」という意味を指す


組織によって、各視点の成熟度をどこまで目指すかは変わるはずです。例えば、お客様によっては既存のITインフラのEOS(End of Service)コストが多すぎて、新規開発に予算を回せないとします。その場合に最優先すべき施策の1つは、EOSコストの削減のためにクラウド化を進める施策です(ビジネスバリュー視点/インフラストラクチャ視点)。もしかしたらビジネス目標とITサービスのアラインといった施策(ビジネスバリュー視点)の優先度はそれよりも低いかもしれません。代わりに、その浮いた予算をクラウド人材育成に使ったり(ピープル視点)、クラウドネイティブアプリ開発のPoCに使うのかもしれません(インフラストラクチャ視点)。このように施策には優先順位の設定が必要です。各視点でどこまでの成熟度を求めるかは、使える予算に制約を受けます。すべての視点で最高の成熟度を求める必要はないし、そもそも不可能です。どの視点のどの施策にどれくらいの予算をかけると全体として得られる便益は最大になるのか。例えば、中流サラリーマン家庭の例で考えます。はたから見た生活レベルは中の上です。しかし、月に手取りがそれなりにあっても、支出が9割以上に上り、将来の投資である子供の教育や貯蓄にはほとんどお金をかけることができていません。目標は子供の大学の学費とします。最初にやることは何でしょうか。車を手放してレンタカーにする、格安携帯に変える、など固定費を落とすことです。固定費が落ちて初めて未来のためにお金を使えます。旧来のエンタープライズシステムをモダナイズして将来のための原資を得るのは、これと同じ発想です。


AABGの強み

図:各視点への限りある予算と施策への振り分け
予算の制約があるため、全視点で最上位の成熟度を求めることはできず、
優先順位に応じてメリハリのある予算配分を行う。


クラウドEA (Enterprise Architecture)
クラウドEAという言葉に対して、共通的な認識が世間的にあるかどうかは定かではありませんが、弊社にはクラウドEAのアセットがいくつもあります。そのクラウドEAの定義を簡潔に言うと、「ビジネスの目標を満たすためにクラウドを最大限に生かすアーキテクチャ、プロセス、組織形態の集合」だと認識しています。関係部署のコミュニケーションを取り、クラウドEAを策定し、各施策のプロジェクト化と実行を中心になって担うのは、クラウドCoEの役割です。

先に説明したフレームワークの視点の施策群が、アーキテクチャ、プロセス、組織形態に関する将来の状態やそこに至るまでの施策となります。各施策は視点を超えて関連し、依存関係や優先順位が設定されます。また、例えば、下位にあるいくつかの施策のKPIを満たすと、自動的に上位の施策のKPIを満たすようなKPI設定も行えれば、関連チーム間の連携も意識せざるを得ません。


AABGの強み

図:ステークホルダーおよび視点の間の施策の結びつき
ステークホルダーと視点は一致せず、多対多の関係。視点ベースで施策を整理し、その施策に関係するステークホルダーを集めて施策をプロジェクト化する。


繰り返しになりますが、限られた予算の中で、その組織がビジネス目標に至るまで、各視点にどこまでの成熟度を目指し、どのような優先順位で施策を実施していくのか、を検討し、関連部門で共有していきます。その結果、とりあえずクラウドを入れてPoCをやってみましょう、という短絡的な判断をして試行錯誤するのではなく、将来目指すべき姿を認識しながら必要な施策を戦略的に実施していくことができます。


アクセンチュアの強み
クラウドCoEもクラウドEAも、関わる技術が広く、特定のクラウドおよび製品ベンダーの知識に依存することはできません。つまり、この領域の仕事はベンダーに所属するプロフェッショナルサービスでは難しいのではないかと思います(その会社の技術にコミットするなら良いと思います)。我々は製品を持たないコンサルティングファームですが多数のクラウドエンジニアを抱え、あらゆるベンダーとアライアンスを結んでいるため、特定の会社の技術に縛られずにお客様にとって最適な製品を選択したクラウドEAを策定可能です。

Popular Tags

    最新の記事

      アーカイブ