🐈

SRE チーム向けに Maturity Model を適用してみた

2024/02/16に公開

ここ数年、海外のIT系の情報を読んでると、「Maturity Model」 という文字を目にすることが多くなった気がします。
Maturity Model は 「成熟度モデル」 と日本語では訳される事が多いようです。概ね、組織やチームの成熟度を診断するための一つの指標として定義されることが多い印象です。

先日別の記事で「品質」について書いた記事でも、一つの参考として Google の Technical Debt Maturity Model を紹介させていただきました。

https://qiita.com/moaikids/items/7bd404617b7636ea0a43

私は現在 SRE チームに所属しているので、SRE チームについても Maturity Model を適用し、どの程度達成できているかを診断してみました。
この1年どの程度進化したのか、どこまで達成できたのか、の一つの指標として、年末の振り返りコンテンツの一つとして実施しました。

Datadog: DevSecOps 成熟度モデル

https://www.datadoghq.com/ja/resources/devsecops-maturity-model/

今回、実際に参考にしたのはこちらです。
Datadog が提供しているホワイトペーパーで、一応ターゲットは「DevSecOps」となっていますが一般的な SRE 活動においてもとても参考になる記述が多いため、こちらをベースにしました。

image.png
(表紙だけ引用させてもらいました)

ホワイトペーパーはメールアドレスや会社名などを登録した上でダウンロードできるものなので、この記事では詳らかに内容を記載することをしませんが、以下の項目に基づいて診断指標がまとめられています。

  • 人材とカルチャー
  • 計画と開発
  • ビルドとテスト
  • リリースとデプロイ
  • 運用
  • 観察と応答

前半2つは組織づくりに関する話、真ん中の2つはCI/CD・デプロイパイプライン周りの話、最後の2つはサービスの運用やObservability についての話。という形にまとめられています。

各項目には細分化された中項目が記載されており(SLOについて、等)、それぞれについて等級が定められています。初級が最低ライン、エキスパートが最高ライン。

  • 初級
  • 中級
  • 上級
  • エキスパート

それぞれの項目について、どこまで達成できているかを自己診断することで、自社の SRE 組織の Maturity Model が診断できる、というのがこちらの DevSecOps 成熟度モデルになっています。

個人的には、項目がわかりやすいですし、各等級の達成レベルについても各項目ごとにきれいに整理されているため、初見でも理解しやすい Maturity Model になっていると思います。

実施してみた結果

詳細について記載するのは小恥ずかしいので記載はしませんが、以下のようなルールで診断をしてみました。

  • 各項目、の中項目について、どの等級に達しているかを診断
  • 等級ごとに点数を付与。以下のような形で実施
    • 初級: 0点
    • 中級: 1点
    • 上級: 2点
    • エキスパート: 3点
  • 項目ごとに点数を合算し、平均値を算出。小数点以下を四捨五入
    • たとえば、4つの中項目の平均値が 0.75 点の場合は、四捨五入して 1点 = 中級

結果として、 「観察と応答」 については、ここ1年以上 Datadog を活用して Observability には力を入れてきているため、自己診断では 「上級」 となりました。

ただし、 「ビルドとテスト」「リリースとデプロイ」 については、結果的にやりたいことがほぼ達成できず、整備も進化もなかなか思うようにいかなかったため、かなり低い点数となりました。チーム計画としては優先度をつけてやっていたのでやむを得ないのですが、正直あまり良い状況ではないので、CI/CD などの改善についても2024年の継続課題として実施をしていきたいと思っています。


みたいな形で、組織の現状について、主観や思い込みではなく一定の基準で診断・可視化することができるため、こういった Maturity Model を用いた組織分析を行うことは良いプラクティスだと思います。

NewRelic: 可観測性成熟度モデル

https://docs.newrelic.com/jp/docs/new-relic-solutions/observability-maturity/introduction/

ここからは、実際に組織に適用はしませんでしたが、諸々参考にさせてもらったものを簡単に列挙していきます。

NewRelic の Observability Maturity Model は Observability に特化しているのが特徴的で、成熟度が上がるごとに必要となる環境・プラクティスについても変化していくのが特徴かなと思います。

image.png
(画像は以下資料から引用)

https://speakerdeck.com/newrelic2023/20230523-findy-newrelic-o11y1?slide=30

基本的に、NewRelic の製品を使用することが前提のものなので、その辺は注意が必要です。

Elastic: Observability Maturity Assessment

https://elastic.eu.qualtrics.com/jfe/form/SV_3pAbmejn9ZOMV26

Elastic の提供しているコンテンツは、34 の質問に答えていくことによって組織の Maturity Model の診断を行ってくれる、というものです。

image.png

以下は適当にポチポチした結果で組織の実情を反映していないですが、質問に答えきるとこのような形で診断結果を表示してくれます。

image.png

CNCF: Cloud Native Maturity Model

https://www.cncf.io/blog/2022/05/18/cloud-native-maturity-model-2-0/

インフラ界隈で仕事をしている人にとって、「Maturity Model」 と聞いて一番最初に連想するのが、CNCF が公開している Cloud Native Maturity Model かなと思います。
以下5つの項目を軸に、組織の Cloud Native 成熟度を診断するモデルです。

  • People
  • Process
  • Policy
  • Technology
  • Business Outcomes

詳しい内容はネット上にも記事が溢れているので、この記事では割愛します。

https://findy-code.io/engineer-lab/dev-productivity-con-3shake

Discussion