なぜ組織にCI/CD成熟度モデルが必要なのか
CI/CDに数ヶ月取り組んできた。チームはビルドを自動化し、パイプラインを構築し、テストを実行し始めている。しかし、「実際どこまで進んだのか？」と聞かれたとき、誰も明確な答えを持っていない。チームは順調だと言う人もいれば、デプロイが頻繁に失敗していると指摘する人もいる。次に何を直すべきかについて、全員が異なる意見を持っている。
こうした状況こそ、組織が自分たちの本当の立ち位置を評価する方法を必要としている瞬間だ。評価がなければ、チームはまだ必要でないものを作ることに時間を浪費する。あるいはもっと悪いことに、とっくに解決できたはずの基本的な問題に延々と苦しみ続けることになる。
成熟度モデルが実際にやること
成熟度モデルとは、他社と比較するためのスコアカードではない。何か立派なレベルに到達するために完了しなければならないチェックリストでもない。その目的はもっと実用的だ：現状を明確に把握し、次に取り組むべき改善が何かを示してくれる。
これが重要なのは、すべての問題の重みが同じではないからだ。手動でサーバーにログインしてデプロイしている組織と、パイプラインは自動化されているがテストが不十分で失敗し続けている組織とでは、ボトルネックがまったく異なる。成熟度モデルがなければ、チームは方向性を見失う。ビルドプロセスが誰かのラップトップに依存しているのにKubernetesの議論を始めたり、デプロイが深夜に祈りながら行われているのにガバナンスポリシーを議論したりする。
成熟度モデルは、どのボトルネックが本物かを見極める手助けをする。修正すると聞こえが良いものではなく、実際にユーザーへのデリバリーを遅らせているものだ。トロフィーではなく、診断ツールとして考えてほしい。
仕組み
このモデルは、組織を複数の次元にわたって評価する。各次元には最も基本的なものから最も成熟したものまでの複数のレベルがある。基本的なレベルは、手動プロセスが文書化されておらず、特定の個人に大きく依存していることが特徴だ。上位レベルでは、自動化、標準化、そしてチームが独立して作業できる状態を示す。
ここが重要なポイントだ：すべての次元が同じレベルである必要はない。プラットフォームエンジニアリングは成熟しており、チームが自分たちで環境をプロビジョニングできるかもしれない。しかし、明確な監査メカニズムがないため、ガバナンスは依然として弱いかもしれない。その不均衡は正常だ。モデルはそれを特定し、実際に足かせとなっている領域に集中できるようにする。
評価の6つの次元
このモデルは、組織がソフトウェアをどれだけうまくデリバリーしているかを決定する6つの次元をカバーしている：
デリバリープロセスは、変更がコミットから本番環境にどのように移行するかを扱う。デプロイは手動か自動か？どれくらい時間がかかるか？どれくらい頻繁に壊れるか？
プラットフォームとインフラストラクチャは、環境がどのように管理されているかに注目する。チームは必要なものをすぐに立ち上げられるか？インフラはコードとして扱われているか、それともスノーフレークサーバーか？
データベースとデータ管理は、スキーマ変更やデータマイグレーションがどのように処理されるかを検証する。それらはパイプラインの一部か、それとも別の手動儀式か？
テストと品質は、何がいつテストされるかを評価する。テストはデプロイ前のゲートか、それとも後付けか？テストは信頼できるか、それとも不安定か？
セキュリティとコンプライアンスは、セキュリティチェックがデリバリーにどのように組み込まれているかを評価する。スキャンは自動化されているか？変更の監査証跡はあるか？
文化と組織は、チームがどのように協力しているかに注目する。問題が発生したとき、非難か学習か？チームはサービスをエンドツーエンドで所有しているか？
4つの成熟度レベル
各次元には4つのレベルがある：
以下のマトリックスは、各次元と各レベルでの典型的な特性を示している。
レベル1: Initial（初期）。すべてが手動。デプロイは特定の人物が正しい手順を知っていることに依存する。ドキュメントは誰かの頭の中か、古びたWikiページにある。障害はヒーロー的な対応で処理される。
レベル2: Repeatable（反復可能）。一部のプロセスがスクリプト化されている。基本的なパイプラインはあるが、頻繁に壊れる。チームは標準化を始めているが、例外は多い。デプロイにはまだ見張りが必要。
レベル3: Defined（定義済み）。プロセスは文書化、自動化され、一貫して実行される。パイプラインにはテスト、セキュリティスキャン、承認ゲートが含まれる。チームは他のチームに依存せずにデプロイできる。
レベル4: Optimized（最適化）。組織は継続的に改善する。メトリクスが意思決定を推進する。チームはデリバリープラクティスを実験する。自動化がほとんどの運用上の懸念を処理する。人々は構築に集中し、見張りにはならない。
成熟度が意味しないもの
目標はすべての次元でレベル4に達することではない。これはよくある誤解で、 burnout と無駄な努力につながる。本当の目標は、組織の実際のニーズとキャパシティを考慮した上で、より速く、より安全に、より制御された状態で変更をユーザーに届けることだ。
シンプルなWebアプリを出荷するスタートアップは、数百万のトランザクションを処理する銀行と同じ成熟度レベルを必要としない。5人のチームは50人のチームと同じプロセスを必要としない。モデルはあなたの次のステップを見つける手助けをするものであり、他人の目的地ではない。
評価のための実践的チェックリスト
詳細な評価に入る前に、以下の質問をして現在地を素早く把握しよう：
- どのチームメンバーでも本番環境にデプロイできるか、それとも一人の人間に依存しているか？
- デプロイは文書化されているか、それとも暗黙知に頼っているか？
- パイプラインには実際の問題をキャッチする自動テストが含まれているか？
- デプロイを迅速かつ安全にロールバックできるか？
- 誰がいつ何を変更したかの明確な監査証跡があるか？
- チームは機能構築よりもパイプライン修正に多くの時間を費やしていないか？
- セキュリティチェックは自動化されているか、それともリリース前に手動で行われているか？
- データベースの変更はアプリケーションコードと同じパイプラインを通じてデプロイできるか？
ほとんどの答えが手動プロセスと個人への依存を指しているなら、あなたはレベル1または2にいる。それで構わない。重要なのはそれを認識し、それに応じて計画することだ。
まとめ
成熟度モデルとは完璧を目指すことではない。自分がどこにいるのかを知り、次にどこへ行くべきかを決めることだ。最も痛みを引き起こしている次元から始めよう。一度に1レベルずつ上がっていく。最も高いレベルに飛びつく組織ではなく、一貫して改善する組織こそが、ユーザーに真の価値を届ける。