APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

Cloud Native成熟度モデルがWeb公開されました

一部メディアでも取り上げられていますが、これまでに何度か取り上げてきました「Cloud Native成熟度モデル (CNCF Cloud Native Maturity Model 2.0) が2023年1月、CNCFのWebサイトで公開されました。今まではGitHub上での公開でした。

maturitymodel.cncf.io

Web上に公開をすることは2022年10月のKubeCon + CloudNativeCon 2023 NA Detroitのセッションでも話されていたことなのですが、春のKubeCon EUで発表かなと思っていたので割と早かったというのが印象です。

ちなみに今まで取り上げてきた記事はこれらになります。

techblog.ap-com.co.jp

techblog.ap-com.co.jp

techblog.ap-com.co.jp

techblog.ap-com.co.jp

さて、今回のWeb公開ではこれまでGitHub上で公開されていたものから大きく変更になった部分があります。それは(内容ではなく)構成です。

この成熟度モデルでは「Peaple」「Process」「Policy」「Technology」「Business Outcome」の5つの領域に対して、Level 1 〜 Level 5の成熟度を設定するものです。

これまでのGitHub上での構成は 各領域ごとに Level 1 - Level 5 の内容を記述していました。(この構成はGitHub上でもまだ残されています

今回のWebサイト上での構成は、各Levelごとにそれぞれの領域で求められる内容を記述しています

内容そのものは大きく違わないのですが、見え方が変わってきます。
成熟度というものは、「TechnologyはLevel 3だけどProcessはまだLevel 2かな」と領域ごとに変わってくるものです。また同じ領域内でも「この点はLevel 4に進んでいるけど、こちらの点はまだLevel 3としても十分じゃないな」などばらつきがあるものです。領域ごとにまとめている場合、こうした違いを見定めながら自分たちの強みと弱点を確認していくことができると思います。

それに対してLevelを先にすると、「このレベルではこの内容が求められている」というのが見渡せるようになります。これは全領域を総合的にみた成熟度を見定めるにはわかりやすいやり方になります。また、レベルを中心に次に到達すべき内容を定めるには都合がよい構成です。

どちらの構成がいいというものではないとは思いますが、「成熟度」と言われたときにイメージしやすいのは後者(今回のWebの構成)なのかもしれません。 (贅沢を言うならば「Level優先のView」「領域優先のView」というものを切り替えられるといいですね)

いずれにしましても、これまで注目してきたものがまた一歩進んだというのはなんだか嬉しいものです。引き続き内容をおいかけつつ、実際にこの成熟度モデルを適用して成長できるような仕組みを考えていきたいと思います。

最後に

私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。ご相談等ありましたらぜひご連絡ください。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp