昨年冬にY Combinatorに参加したサンフランシスコ発のスタートアップ「Release」は、EaaS（Environment-as-a-Service）と称する、ちょっと新しいDevOps系サービスです。2019年創業ながら2021年10月にSequoia Capitalなどから$20M（約23億円）のシリーズA資金調達を発表したことで開発者の目に留まるようになっているようです。
Environment（環境）といっても自然環境のことではなく、多数の設定項目があるサーバやネットワークの設定状態のことを指す、主にDevOpsやインフラエンジニアが使う言葉です。日本語でも「環境」（または実行環境）と言います。
Releaseは、単にソフトウェアエンジニアやDevOpsのツールとして新機軸ということだけでなく、ソフトウェアビジネスを作って継続していくことを考えたとき、今の時代の変化を象徴しているように思えて興味深いので、ちょっとご紹介してみたいと思います。
関連ツール類が増えたとき統合プラットフォームが現れる
モバイルアプリは違いますが、今のソフトウェアは機能ごとに別々の実行環境にデプロイされて、それが組み合わさって1つのプロダクトやプラットフォームを構成するようになってきています。
ずっと以前はソフトウェアを稼働させる環境は1つの物理サーバ上で完結していました。実行するために必要な環境設定は手作業で行い、作業手順書やスクリプトと呼ばれる自動化プログラムを用意していました。
クラウド時代になって仮想的に何台でもサーバを使えるようになると、機能ごとにソフトウェアを切り分けて異なるサーバで稼働するようになりました。そのほうが1枚岩で全体を作るよりも複雑性をモジュール単位に封じ込められたり、柔軟なリソース管理ができるからです。特に「コンテナ」と呼ばれる仮想化技術によって、より手軽にサーバを環境ごと生成できるようになると、その傾向が加速しました。
コンテナ技術のデファクトはDocker/Kubernetesで、日本のスタートアップ企業でも皆さんお使いだと思います。ただ、Kubernetesを使ってコンテナを管理するのは、それはそれで面倒な問題になりつつあります。多数のコンテナを有機的に組み合わせて使うためのツールや設定が煩雑化したからです。
EaaSを名乗るReleaseは、まさにこの問題を解決するスタートアップです。「それはKubernetesや関連ツールを使えばできるのでは？」というのがReleaseを見たエンジニアが最初に持つ疑問（例えば、HackerNewsの議論を見ると分かります）で、この問いに対してReleaseは「KubernetesはエンジンでEaaSはクルマ（完成車）だ」という説明をしています。自分でKubernetesを使って作れば、いろいろ自動化もできるものの、それをやり続けたいですか、そのためのエンジニアのコストは高くありませんか、ということです。ツールを組み合わせて設定すればできるものの、Kubernetesのエコシステムや利用形態が高度化してしまった、ということかと思います。
「ソフトウェアこそビジネス」の時代に必要なこと
EaaSは現代的なバックエンド（サーバ・クラウド上）のソフトウェアを実行するために必要な下準備を再現性のある形で何度でも手軽に実行できる、というのがポイントです。Releaseのブログから、そのメリットの意味するところを考えてみます。
クッキーを焼くとき、型抜きを使えば同じ形のクッキーをいくらでも作れるのと同じで、事前に設定済みの環境であればエンジニアの介在なしに、いくらでも同じ環境が生成ができます。複雑化してしまったコンテナ環境であっても再現できます。すると、これまで準備にひと手間かふた手間かかっていた実行環境を任意のタイミングで生成し、その上でソフトウェアを実行し、終わったらその環境をその場で捨てる（消す）ことができるようになります。
すると、これまで「ステージング環境」「テスト環境」と呼ばれていた本番リリース前の実行環境について、普段から立ち上げておく必要がなくなります。いつでも生成・実行できるのでステージング環境での確認が必要なときだけクラウドのリソースを割り当てられ、クラウドの利用コストが下がります。
ちょっとバグを修正したとか、ごく小さな機能を実装したなど、何か少しでも変更を加える（コードをコミットした）たびに、環境を生成して統合テストやパフォーマンス計測、品質テストができるようになります。新機能を実装するとき、バージョンを分岐させて新機能の含まれるソースコードをブランチ（枝）として扱い、いわゆるマスターのソースコードと並行して開発、メンテするかと思います。このとき、開発ブランチにおける今日の最新版を動かすとなると、エンジニアがいくつか呪文を画面に入れるか、そうしたことを自動化するツールを導入しておくことになります。Releaseは、この辺を全部パッケージ化して自動化しています。微妙に異なるバージョンを同時に2つ、3つと立ち上げて横並びで比較するようなこともできるでしょう。これはステージング環境が1つしかないと、できないことです。開発者が何か1人で実験してみたいといったときにも、そのために「環境を用意する」という手間がなくなります。
開発者以外もソフトウェア開発のサイクルに巻き込む
いくらでも実行環境が作れるので、例えば特定の顧客に向けて何か機能を少し変えてデモをするようなことも簡単にできます。これまで以上に実行環境の生成と削除が気軽なので、環境というものが「用意して一定期間、動かしておくもの」から「必要なときに生成され、用が終われば消えて当然のもの」になる、ということです。
何かの新機能を2カ月かけて開発するようなシナリオで考えると、開発初期からプロダクトマネージャーやカスタマーサクセスにも動く状態のものを常に見れるようにしておきたいかもしれません。あるいは異なる開発版をいくつか、いつでも実行できるようにしておきたいかもしれません。そうしたときもReleaseのようなツールがあれば助かるでしょう。経営陣に新機能をプレゼンする当日になって最新版がバグで動かないと慌てる事態になっても、3日前のバージョンのものを実行することも、特に追加手作業が発生することもなく一発でできると便利です。繰り返しますが、いまのソフトウェアが動くサーバ環境というのは複雑すぎて、スマホアプリのように単に削除して再インストールするように簡単には違うバージョンを動かせないという現実があります。
Releaseは開発サイクルを速めたり、クラウドの利用コストを下げる効果をうたっています。それに加えて、開発中のさまざまなバージョンのプロダクトを、社内のビジネス側の人たち、あるいは潜在顧客に見てもらうことの重要性が増していることが背景にありそうです。それはピュアソフトウェアのSaaSスタートアップはもちろん、DXが進むビジネスにおいて「ソフトウェア（プロダクト）こそがビジネスの根幹」であるという時代が到来していることを象徴しているのではないかと思えるのです。
Partner @ Coral Capital
