【ITニュース解説】CI/CD is Dead. Platform Engineering Killed It.

システムエンジニアを目指す皆さんにとって、ソフトウェア開発の現場でよく耳にする「CI/CD」という言葉は、非常に重要で現代の標準的な手法とされている。CI/CDとは、「継続的インテグレーション（Continuous Integration）」と「継続的デリバリー（Continuous Delivery）」の頭文字を取ったもので、開発者が書いたコードを自動でテストし、本番環境に安全かつ迅速に届けられるようにする一連の自動化された仕組みのことだ。これにより、開発者は安心してコードを書き、ユーザーは新しい機能や改善を早く受け取れるようになる、というのが一般的な理解である。

しかし、このCI/CDの仕組みが、多くの現場で思わぬ問題を生み出している現状がある。システムエンジニアを目指す皆さんも、将来的に「DevOps」という言葉を耳にすることが増えるだろう。DevOpsとは、開発チームと運用チームが協力して、ソフトウェアをより迅速かつ高品質にユーザーに届けるための考え方や文化のことだ。そのDevOpsを実現するための重要な柱の一つがCI/CDとされている。多くの企業が「DevOpsが成熟している」と自負し、複雑なCI/CDパイプライン、つまり自動化された一連のデプロイの流れを構築している。例えば、JenkinsやGitLab、GitHub Actionsといったツールを使って、コードがプッシュされると自動的にテストが走り、Dockerという技術でプログラムをまとめたイメージを作り、Kubernetesという技術でサーバー上で動かすための設定を行い、HelmやArgoCDといったツールで実際のデプロイを管理し、さらに監視ツールやセキュリティチェック、成果物の管理、機密情報の管理など、実に多くの技術とツールを組み合わせて使うのが一般的になっている。

一見すると、これらの仕組みは非常に効率的で、開発者がコードを書くことに集中できる理想的な環境のように見える。実際、多くの企業では「開発速度が上がった」「品質が向上した」といった数値が報告されている。しかし、その裏側で何が起きているかというと、開発チームは顧客に価値を届けるための新しい機能開発よりも、この複雑なCI/CDパイプラインそのものの維持や管理に多くの時間を費やしているのだ。数多くの設定ファイル、特にYAMLという形式で書かれることが非常に多いが、これらの設定は非常に細かく、少し間違えるだけでデプロイが失敗したり、セキュリティ上の問題が発生したりすることもある。この複雑な設定の管理は、もはや「自動化されたパイプライン」というよりも、「フルタイムの仕事」と言っても過言ではないほどの手間がかかっている。つまり、デプロイの仕組みを構築し維持することが、それ自体で目的になってしまい、本来の目的である「顧客に価値を届ける」ことから、かえって遠ざかっているというジレンマに陥っているのだ。

では、本当に成功していると言われる企業、例えば動画配信サービスのNetflixや音楽ストリーミングサービスのSpotifyのような企業は、どうしているのだろうか。彼らが成功しているのは、非常に複雑で洗練されたCI/CDパイプラインを持っているからではない。そうではなく、彼らは開発者がデプロイについてほとんど考える必要がないような「内部プラットフォーム」を構築しているのだ。Netflixでは、コードをデプロイする作業は、まるで設定ファイルを一つ変更するのと同じくらいシンプルに感じるという。Spotifyのエンジニアが驚くほどの速さで新しい機能を開発できるのも、彼らが使っているCI/CDツールが優れているからではなく、インフラの複雑さを完全に隠蔽してくれる開発者向けのプラットフォームがあるからだ。開発者は、自分が作ったビジネスロジック（サービスの核となる機能）に集中でき、裏側のインフラやデプロイの具体的な手順については、ほとんど意識する必要がないのだ。

この「内部プラットフォーム」を意図的に構築する考え方こそが、「Platform Engineering（プラットフォームエンジニアリング）」だ。これは、これまでのCI/CDに対する根本的な考え方の転換を促すものだ。従来のCI/CDは、「開発チームが効率的にコードをデプロイできるようにするにはどうすれば良いか」という問いから出発していた。しかしPlatform Engineeringは、「開発チームがそもそもデプロイという問題を考えなくても済むようにするにはどうすれば良いか」という、より本質的な問いから出発する。つまり、各開発チームがそれぞれ独自のデプロイパイプラインを構築するのではなく、すべてのチームが利用できる共通の「基盤」を提供する。この基盤の上に乗っていれば、デプロイはボタンを押すか、簡単な設定をするだけで完了するように設計される。

Platform Engineeringが実現すると、開発者はインフラの細かな設定やツールの使い方を覚える必要がなくなり、純粋に顧客に提供する機能の開発に集中できるようになる。デプロイの作業は、各チームの責任ではなく、プラットフォームが提供する「機能」の一部となるのだ。そして、複雑なカスタムパイプラインのコードを書く代わりに、プラットフォームが決めた標準的な「設定」を使うだけで済むようになる。これにより、デプロイのプロセスが標準化され、チーム間のばらつきがなくなるだけでなく、プラットフォーム自身がセキュリティや品質に関する標準を自動的に強制できるようになる。実際に、ある組織では、これまでチームごとに47種類も存在したデプロイの設定が、Platform Engineeringの導入により、たった一つのプラットフォームインターフェースで管理できるようになり、大幅な簡素化が実現した事例がある。この結果、開発チームがデプロイ関連の作業に費やしていた時間が、以前の30%から5%未満へと劇的に削減され、代わりに顧客向けの機能開発に時間を割けるようになった。さらに、デプロイの頻度は10倍に増加し、デプロイの失敗率もほぼゼロになったという驚くべき成果が出ている。そして、これらの成果は、既存のCI/CDツールをより複雑にしたり、改善したりすることによって得られたものではなく、むしろそれらの複雑なCI/CDツールを「不要にする」ことで達成されたのだ。

この事例が示す重要な教訓は、「世間で広く使われている一般的なやり方（共通のプラクティス）が、必ずしも最も効果的なやり方（ベストプラクティス）ではない」ということだ。多くの企業は、他社がやっているからという理由で複雑なCI/CDプラクティスを採用してきたが、それは必ずしも彼らが抱える本質的な問題を解決していなかった可能性がある。システムエンジニアを目指す皆さんも、将来のキャリアの中で、ツールや技術の表面的な流行に惑わされず、本当にそれが解決したい問題に貢献しているのか、という問いを常に持ち続けることが重要だ。Platform Engineeringは、これまでのDevOpsの多くの部分が、実は本質的な価値提供を妨げる「無駄」であったという認識に基づいている。チームがデプロイパイプラインの洗練に時間を費やすのではなく、そのデプロイパイプライン自体を不要にするような、より強力なプラットフォームの構築を目指すべきなのだ。