Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

CAFのCCoEでよく頂く質問

雨めっちゃ降るなーと思ってた矢先、ずーっとどピーカンな福岡です。

雨が降ったり、降らなかったり、天気の神様って気まぐれで昔の人は天候で生きるか死ぬかが決まってしまう世の中に生きてたってすごい大変だなと思いました。

ちなみに今日もどピーカンでございます。こじまです。

CAF(Cloud Adoption Framework)の話を結構書いているのですがこれからもまだまだ続きます。(ネタに困ることはないくらいのボリューム)

さて、今回はCCoEでよく聞く質問に対して、僕なりのアンサーを書きます。 f:id:koji_kchc:20210621194347j:plain

CAFでは当たり前?CCoEとは何か

最近なにかと話題になりますね。CCoEまたはCoEという人もいますが、Cloud Center of Excellenceの略ですね。 CAFでは冒頭に必ず説明が入るやつです。 CCoEについてのおおまかな説明は前々回のブログに書きました。

aadojo.alterbooth.com

CCoEはクラウドを中心としたコラボレーション戦略であり、CCoEを導入することでクラウドによる変革のサイクルを進めることができます。

ここで重要なことは何度も書くのですが(前々回のブログでも書いた)CCoEは巨大なナレッジセンターを作ることではなく、各チームの横串を円滑にするためのコラボレーションを促進することが目的です。

クラウドのスペシャリストだけを集めてCCoEを形成したところでコラボレーションがうまくできないのであれば意味がないのです。

CCoEが実際に実現できると何が変わるか。

詳しくはMicrosoftのCAFドキュメントを読んでほしいのですが、自走式の組織カルチャーが生まれるということです。

f:id:koji_kchc:20210621182154p:plain

docs.microsoft.com

公式Docにとても分かりやすい例が書かれています。

CCoE アプローチがないと、IT 部門はコントロールと一元的な責任の提供に重点を置き、交差点の信号のように振る舞う傾向があります。 CCoE が成功している場合は、自由度と委任された責任に重点が置かれ、これはむしろ環状交差点に似ています。

CCoEとは何かが理解いただけたでしょうか?

最小チームを作るとはどういうことですか?

よくある質問なわけですが、クラウド導入に対してまずどのような役割が必要かを考えます。

一番わかりやすいのはクラウドを実際に設計、構築する役割ですね。

この役割を "クラウド導入チーム" とします。

クラウド導入チームがいなければそもそも導入ができない=アクション出来ないので必ず必要です。

まずはこのチームを作ってクラウドを設計していきましょう!!

と、言いたいところですが実はもう一つ役割が必要です。

それはガバナンス、クラウドに対して必要なルールを決め、運用するチームになります。

この役割を ”クラウドガバナンスチーム” とします。

クラウド導入においてその企業のサービスや文化を継承していくには、クラウド導入チームだけでなく統制をするためのガバナンスチームが必要になります。

なので、最小チームとはクラウド導入とクラウドガバナンスの2つの役割を持ったチームと言えます。

詳しくは公式Docを見ましょう。

docs.microsoft.com

組織の成熟度とは?

組織が育っていくことで役割が変化する、ではありません。

そうではなく、ビジネスの進歩により組織がその進歩と共に変化します。

その変化に応じて責任が変わるということです。ビジネスの変化に応じて変わるということがとても重要です。

成熟度に応じた責任は変化するのですが、それらを表すためにRACIマトリックスを使います。

docs.microsoft.com

RACIマトリックスではビジネスの成熟度と各チームの責任をマトリックスで示したものです。

組織の成熟度ではなく、ビジネスの進歩による変化と考え、その中で責任が変化してくるんだということを理解してください。

戦略におけるOKRとは?

OKRとはObjectives and Key Resultsの略で、目標管理手法の一つとされておりGoogleやFacebookといった巨大IT企業が導入していることで注目を集めている方法です。

このOKRについてもCAFで言及があります。

docs.microsoft.com

CAFにおけるKRはクラウド導入にかかる数値になりますが、定性的なものを無理して定量化しても指標となるKRは作れません。

ここはあえてテクニカルな方法として、例えばAzure Cost Managementと連動したコストの数値化であったり、GitHub ActionsやAzure DevOps Pipelinesでのデプロイ値(回数、リードタイム、インテグレーション成功数など)を設定します。

ビジネス的観点でいえば、実装したサービスによる顧客満足度を計測するとし、ログイン数や実際に顧客にヒアリングしたり、セールスパイプラインの中でクラウド導入に関するリードタイムなどの計測するなど、現実的に取得できるKRから作成し、そのKRに対して個人アクション目標を作る形が良いかもしれません。

いずれにせよ、OKRの導入にはまずはすぐに計測できるものを対象とし、そのKRを中心にボトムアップさせると良いと思います。

またOKRのツールに関しては様々なツールがありますが、どのツールでも組織にマッチしないのであれば意味がありません。

ちなみに私がおすすめするOKRツールは2つです。

Goalous

組織の中でもコミュニケーションや個の特性を重視し、チーム全体のKRを追いかけるようなOKRの場合はGoalousがおすすめです。

各メンバーは専用のSNS内でKRを設定し、画像を添えてKRを積み上げていきます。

Goalousは独自のGKA(Goal,Keyresult,Action)を展開しており、より個人の内発性を意識したものになっています。

www.goalous.com

Ally

Allyは比較的有名なOKRツールです。Allyの特徴はKRを様々なサービスと連携することで自動で取得することです。

例えばGithubやAzure DevOpsのような開発パイプライン、TeamsやSlackのようなチャット、JIRAやSalesforceのようなSaaSと連携してエンタープライズな組織でも導入することが可能です。

ally.io

他にも細かいご質問は多いのですが、よくある質問を書いてみました。

CCoEの最大の難しさはまだ誰も正解を知らないということだと、僕は思っています。

正解を知らないので失敗しまくる。その失敗を糧にし、チャレンジするか、従来の中央集権型のマネジメントに戻るかはあなた次第です。

次回はCCoEについて実際に導入して、失敗して、そして再チャレンジしている例をご紹介します。

CAF、CCoEめちゃくちゃ奥深いです・・・