CI/CD成熟度を複雑にせず評価する方法

CI/CD成熟度モデルについて聞いたことがあるでしょう。5段階レベル、4つの次元、さまざまなフレームワークについて読んだこともあるかもしれません。しかし、実際に自組織の現状を把握しようとすると、行き詰まりがちです。コンサルタントを雇うべきか？3日間のワークショップを開催すべきか？50ものメトリクスを詰め込んだスプレッドシートを作るべきか？

そんな必要はありません。実用的な成熟度評価は、数時間と正直な回答が得られる数個の質問で十分です。目的は洗練されたスコアカードを作ることではありません。本当のボトルネックがどこにあるのかを明確にし、何を最初に修正すべきかを把握することです。

複雑なフレームワークではなく、シンプルな質問から始める

CI/CD成熟度を評価する最も実用的な方法は、デリバリープロセスの主要な次元ごとに1～2の質問をすることです。各質問には1～4のスケールで回答します。

• 1（アドホック）: 各人が独自のやり方で進めている。標準的なプロセスは存在しない。
• 2（標準化）: 定義されたプロセスはあるが、手動のステップや調整が必要。
• 3（セルフサービス）: チームが他チームに依存したりチケットを発行したりせずに、プロセスを自分たちで処理できる。
• 4（最適化）: プロセスが測定され、データが収集され、そのデータに基づいて改善が行われている。

質問は完璧である必要はありません。重要なのは、プロセス文書を書いた人ではなく、実際に作業を行う人が正直に答えられることです。

4つのレベルは、カオスからデータ駆動型への明確な進化を示しています。以下がその視覚的な概要です。

デリバリー：変更は実際にどのように本番環境に届くのか？

次の質問をしてみてください。すべてのチームが同じ方法で変更を本番環境に送信していますか？

各チームが独自のスクリプト、手動ステップ、デプロイタイミングの判断基準を持っている場合、レベル1です。標準的なパイプラインはあるが、特定のステップを手動で承認またはトリガーする必要がある場合、レベル2です。チームが他チームの助けを借りずに自分たちでデプロイできる場合、レベル3です。チームがデプロイの頻度と速度を追跡し、そのデータをプロセス改善に活用している場合、レベル4です。

この次元は通常、最も目に見えやすいため、チームが最初に改善するものです。ただし、パイプラインが動いているからといって、レベル3や4だと決めつけないでください。多くのチームは自動化されているように見えるパイプラインを持っていますが、実際にはチーム間の手動の引き継ぎが必要です。

プラットフォーム：チームはチケットを発行せずに必要なものを得られるか？

次の質問をしてみてください。チームはチケットを発行せずに、必要な環境やインフラをプロビジョニングできますか？

レベル1はすべてが手動です。誰かが特定の人にサーバー設定を依頼しなければならず、その人が数日から数週間かかる可能性があります。レベル2は標準的なプロセスはあるが、依然としてチケットキューを経由します。レベル3はチームが内部プラットフォームやツールを通じて自分たちの環境をプロビジョニングできます。レベル4はプラットフォームが使用パターンやチームからのフィードバックに基づいて継続的に改善されています。

この次元は、優れたアプリケーションパイプラインを持ちながらも、環境セットアップの遅さに悩む組織にとって、しばしばボトルネックとなります。デリバリーパイプラインが高速でも、プロビジョニングに2週間かかるなら、実効的なデリバリー速度は依然として2週間です。

ガバナンス：セキュリティとコンプライアンスのルールは自動化されているか？

次の質問をしてみてください。セキュリティとコンプライアンスのルールはパイプライン内で自動的に適用されていますか？それとも手動でチェックされていますか？

レベル1は明確なルールがないか、ルールが人々の頭の中にしか存在しません。レベル2はリリース前に誰かが確認する手動のチェックリストがあります。レベル3はルールがパイプラインにプログラムされ、違反を自動的にブロックします。レベル4はルールが定期的に見直され、理論上の脅威ではなく実際のリスクに基づいて調整されます。

多くの組織は、手動のチェックリストで十分だと考えてレベル2で停滞します。問題は、手動のチェックリストは納期が迫るとスキップされがちで、チームが成長してもスケールしないことです。

データベース：スキーマ変更はアプリケーション変更と一緒にリリースできるか？

次の質問をしてみてください。データベーススキーマの変更は、追加の手動ステップなしでアプリケーション変更と一緒にリリースできますか？

レベル1はデータベース変更がDBAによって手動で行われます。レベル2は標準的な手順はあるが、調整とスケジューリングが必要です。レベル3はデータベースマイグレーションがパイプラインに統合されています。レベル4はデータベース変更が自動テストされ、安全にロールバックできます。

この次元は、しばしばチームを驚かせます。アプリケーションパイプラインは成熟していても、データベース変更ごとに別途手動プロセスが必要な場合があります。これにより、スキーマ変更が本番インシデントを引き起こしたときに初めて可視化される隠れたボトルネックが生まれます。

インフラストラクチャ：サーバーとネットワークの変更はパイプラインを通じて行われるか？

次の質問をしてみてください。インフラストラクチャの設定変更はパイプラインを通じて行われていますか？それともサーバーに直接ログインして行われていますか？

レベル1はすべてが手動で変更されます。レベル2は標準的なスクリプトはあるが、依然として手動で実行されます。レベル3はインフラがコードとして管理され、変更がパイプラインを通じて行われます。レベル4は設定変更に問題が発生した場合の自動検証と復旧メカニズムが存在します。

この次元はプラットフォームの次元と密接に関連していますが、新しい環境のプロビジョニング方法ではなく、既存のインフラがどのように変更されるかに焦点を当てています。

成果：デプロイの失敗頻度を把握しているか？

次の質問をしてみてください。チームはデプロイの失敗頻度や問題からの復旧速度を把握していますか？

レベル1はデータがなく、推測のみです。レベル2は手動のログはあるが、定期的に分析されていません。レベル3はメトリクスが自動収集され、チームから可視化されています。レベル4はそれらのメトリクスが次に何を改善すべきかの判断に使われています。

この次元は、単にプロセスをこなしているだけのチームと、実際に改善しているチームを分けるものです。デプロイ頻度、変更失敗率、復旧時間を測定しなければ、変更が状況を良くしているのか悪くしているのかを知ることはできません。

実用的な評価チェックリスト

以下はチームで使用できるシンプルなチェックリストです。願望ではなく、各質問に正直に回答してください。

結果をどう活用するか

この評価はプロファイルを示すものであり、成績をつけるものではありません。すべての次元をレベル4にする必要はありません。必要なのは、他のすべてを妨げている次元を見つけることです。

デリバリーがレベル3でもデータベースがレベル1なら、真のボトルネックはデータベース変更です。すべてのデータベース変更に手動のDBAプロセスが必要なら、パイプラインをさらに改善しても意味がありません。変更を安全かつ迅速にリリースする能力に直接影響する、最もスコアの低い次元に焦点を当ててください。

次のステップは、これらのボトルネックに基づいたロードマップを作成することです。しかしその前に、チームで評価を実施してください。多くの場合、スコアそのものよりも、評価の過程での対話自体がより価値があります。