DevOps を進めようという話になると、たいてい最初に出てくるのはツールの名前です。
CI を回す、コンテナに載せる、監視を入れる。
けれど道具をそろえた先で「で、うちは今どのくらい進んでいるのか」と聞かれると、途端に答えづらくなりませんか。
進み具合を測る物差しがないまま、導入したツールの数だけが増えていく。
そこに補助線を引いてくれるのが、DevOps を5つの軸で棚卸しする CALMS という枠組みです。
CALMS は CAMS に L を足したもの
CALMS の出発点は、2010年に開かれた米国初の Devopsdays でした。
考案者のひとりである John Willis は、Damon Edwards とともに Culture・Automation・Measurement・Sharing の頭文字から CAMS という言葉を作ったと自ら書き残しています。
そこへ Jez Humble が Lean の L を足したものが、いま広く使われている CALMS。
DevOps Culture (Part 1)（John Willis・IT Revolution）
由来をたどると分かるのが、5つのうち技術寄りの軸はひとつしかないという事実です。
同記事も DevOps を「人とマネジメントの問題」として扱っており、ツールの導入だけでは前に進まないという立場を取っています。
順番を間違えないための地図、と捉えると腑に落ちますね。
DevOps そのものの定義は別の記事で整理したので、あわせてどうぞ。
5つの軸を1つずつ
それぞれの軸が何を問うているのか、ひとつずつ整理しました。
Culture（文化）
開発と運用が別々の目標を追っている限り、どんな道具を入れても壁は残ります。
ここで問われるのは、障害が起きたときに犯人探しへ向かわないかという一点。
失敗を学びとして扱える空気があるかどうかが、他の4軸すべての土台になるのです。
Automation（自動化）
手作業が残っていると、人はリリースを避けるようになります。
ビルド・テスト・デプロイ・環境構築のうち、どこがまだ人の手で回っているかを洗い出す軸。
すべてを一度に消す必要はなく、頻度の高い作業から順に潰していけば十分です。
Lean（リーン）
大きなリリースを年に数回まとめて出す形は、失敗したときの被害も大きくなります。
Lean の軸が問うのは、仕掛かりを小さく保ち、流れを止めない設計になっているかという点。
在庫を減らす発想を、コードとタスクの側へ持ち込むイメージ。
Measurement（計測）
改善したかどうかを言葉ではなく数字で語れるか、という軸になります。
指標の代表格が DORA の研究で使われているもので、変更のリードタイム・デプロイ頻度・失敗したデプロイからの復旧時間・変更失敗率、そして手戻り率が現行のモデルとして公開されていました。
DORA's software delivery performance metrics
長らく「4つの指標」として知られてきたものが、いまは5指標へ更新されている点は押さえておきたいところ。
Sharing（共有）
最後の軸は、知識が特定の人に閉じていないかを問うものです。
障害対応の記録、設計判断の理由、運用手順。
書かれずに個人の頭の中だけにある情報は、そのままチームの単一障害点になります。
成熟度は「軸ごと」に見る
CALMS を使うときのコツは、全体を一言で採点しないこと。
自動化は進んでいるのに文化が追いついていない、という偏りは珍しくありません。
5つの軸を別々に評価して、いちばん低い軸から手を付けるほうが、投資の効きは良くなります。
とくに Measurement が空欄のまま他を進めると、改善したかどうかを誰も判断できない状態が続く。
まず計測の軸を埋め、次に文化、そこから自動化とリーンへ広げる。
信頼性の側から同じ問題を扱う SRE の考え方も、この Measurement の軸と地続きになっています。
数字が出るようになると、議論が主観のぶつけ合いから抜けられるのが大きいところ。
最後に
CALMS は、Culture・Automation・Lean・Measurement・Sharing の5つで DevOps を棚卸しするための枠組みでした。
由来をたどれば、技術の軸はそのうち1つだけ。
残りの4つは、働き方と情報の流し方の話なので、ツール選定の前に一度この5軸で自チームを眺めてみる価値があります。
まずは Measurement から、いま測れている数字を書き出すところをおすすめしたいですね。
以上です。
コメントを残す