こんにちわ、とうとう始まってしまいましたアドベントカレンダー。
2日目は小島が担当します。
実はここ数日副鼻腔炎症状で体調崩してまして、冬の到来を感じますね。
さて、今回はエモいです。
なぜCCoEなのか
CCoEとはここ最近使われているキーワードですね。Cloud Center of Excellenceの略です。
元々Center of Excellenceという組織横断の継続的な取り組みを行うための専門チームがあるのですが、さらにそれに加えて”クラウド”を中心とした横断的チームをCCoEと言います。
CCoEが生まれた背景はWebビジネスが一般的になり、Webを通じた様々なサービスを素早く展開できるような仕組みとしてクラウドが使われるようになると、そのクラウドをいかにしてフル活用させるかということが課題になります。さらにその課題は単なるシステムの課題ではなく、サービスを提供するプロセス全体に分散されているので組織全体で取り組む必要が出てきます。
近年はさらにDevOpsやオペレーショナルエクセレンスといった組織文化そのものを変革するような取り組みが推進されていることから、経営戦略の一つとしてクラウドを使うことからCCoEが生まれました。
CCoEの背景としてもう一つ重要なキーワードがあります。それがDXです。
正直僕はDXというキーワードは好きではありませんが非常に言いやすく簡単にものごとをまとめる力がありますので、敢えてDXというキーワードを使っていきます。
DXはデジタルによる変革といわれていますが、そのデジタルによる変革を支える基盤はクラウドになります。 ですから、DXに取り組むということはクラウドを使うということになります。経営戦略をクラウドを中心としたものに変えていく必要があるのです。
CCoEを簡単なキーワードでまとめるとDXを推進するための組織戦略です。（非常にまとめやすいですね）
CCoEを実際にやっている組織はあるのか
日本におけるCCoEはまだまだ過渡期です。というよりも、まだ始まってもないかもしれません。
しかし少しずつ取り組みに対する事例も出てきました。
上記書籍にはいくつか事例が掲載されていますが、注目したいのはどのような課題があるからCCoEに取り組んだ、ということが書かれていることです。
課題を解決するための最短ルートがCCoEであった、ということなんですよね。
またCCoEとは他力で取り組むべきことではありません。ソフトウェア開発と違うのは他者へ受託させて成功できるものではないということです。
ここは非常に重要なことです。
そういえばDevOpsに絡んだ話で、S&P500の50％が2026年にはソフトウェア企業に入れ替わるといわれています。
これはS&P500の企業がリアルビジネスからネットビジネスへ変革するということであり、その変革においてDevOpsという取り組みが非常に重要な役割を持っているということです。
この変革において、他者から提案を受けて、他者に任せて成り立つ、というのはほぼなく、自ら変革に取り組むということなのです。
CCoEが困難な理由
実は何社かCCoEの失敗談をヒアリングさせて頂きました。すべての行動が成功するということはなく失敗も含んだ行動そのものが成功に導くわけですから生々しい失敗ですら本来は財産なのです。
その財産について、少しばかりお聞きしたところによるとこんな回答がありました。
各部署のエキスパートを集めたCCoEチームを作ったが、CCoEとしての役割よりもその所属する部署の仕事の大部分を担っているためエキスパートへの依存が多くあり機能しなかった。
集合知としてのナレッジベースを作ろうとしたが、部署間のブラックボックスを紐解くことができなかった。
CCoEを作っても決裁権者はCCoE以外であり、コストセンター化してしまっている。
その他色々ありますが、実はこれらって組織文化に起因しているんじゃないかと思うんです。（あくまでも私の考えでは、です）
組織文化において、ヒエラルキーが強い、密結合な状態でCCoEのような横断組織をいれてもあまり変化がない、ということなのだと感じました、
ではどうするか、なのです。
やっぱりDevOpsなんだよ
組織にヒエラルキーが強いことへの弊害は、Webサービス開発に反映されます。ここら辺はコンウェイの法則として非常に有名ですよね。
コンウェイの法則とは、ヒエラルキーが強い組織が作るシステムは、その組織構造を反映した設計になってしまうというものです。
もうこれはいくつも見てきましたが密結合なシステムがもたらす悪影響は今も昔も変わらずにあるので、なるべく疎結合な仕組みを作ることが推奨されます。（マイクロサービスとは言いません）
ヒエラルキーを解消した組織を作らなければいつまでも密結合のままなのです。
ですから、その解消に取り組むことが最初にやることなんです。
マーケティング、リーン開発、ビジネスの継続すべてにおいてなんらかの取り組みを変えていかないといけない。
そこでDevOpsが出てくるのです。
DevOpsとはエンジニアだけのキーワードではないのです。もはや組織文化の変革を促す”行動”そのものであり、ここからすべて始まります。
なんだかんだDevOpsなんだよ。。。。
DevOpsに取り組む前に？？？？
DevOps導入っていうのもなんだかおかしな話なのですが、ここもわかりやすいので敢えて導入って言っておきます。（たぶん本質は違いますが）
何からやればいいの、というのは今まで何百回と聞かれたのですが毎回同じこと話すので端的にいうと、まずは開発プロセスを変えましょう。
アジャイルやってみませんか？というか、やってください。
アジャイルと称してミニウォーターフォールをやるパターンもいくつも見てきていますが、それをやらざるを得ない状況も理解できなくはないです（笑）
小さいビジネスを大きく育てる、という意味でアジャイルにまずは少数チームで良いので取り組むと良いです。
出来ることは最初は少ないです。開発も思っていたほどうまくいきません。
それでも愚直にやって半年やってみてください。
半年に何回イテレーション回せるかわかりませんが、少なくとも2週間のスプリントでやれば12回回せるので、それなりに課題も理解できるんじゃないでしょうか？
経営者においては、半年間アジャイルに集中できるメンバーを2～3人作るだけです。すごい簡単です。
まずはここからやってみませんか？
それとこれは宣伝ですがCCoEと関連するところでCloud Adoption Frameworkというものがあります。
そのトレーニングを弊社で提供しておりますので、もしご興味あればどうぞ。
最後になりましたが、おすすめの書籍を紹介しておきます。
どの書籍も力になると思います。
それではまだまだオルターブースアドベントカレンダーを続きます！お楽しみに！！
