こんにちは、プレックスの石塚です。

プレックスではエンジニア組織の立ち上げ時、最初のプロダクトのインフラとしてHerokuを採用しました。現在はメインサービスのインフラはGoogle Cloudに移行しており、インフラの柔軟性や可用性の観点が重要となるプロダクトではHerokuを使用しなくなっています。

※移行に関する記事もあるので、興味のある方はぜひご覧ください。 product.plex.co.jp

しかし、Herokuのシンプルさや使いやすさは依然として魅力的であり、適切な用途であれば非常に有用なプラットフォームだと感じています。今回の記事では、プレックスで現在もHerokuを活用している3つの事例を紹介します。

プレビュー環境としてのHeroku

Review Appsとは

HerokuにはReview Appsという機能があります。これはプルリクエストから新たに環境を作成できる機能で、エンジニアが専用の環境を立ち上げて動作確認やテストを実行するのにとても便利です。

devcenter.heroku.com

プレックスでは本番やステージング環境のインフラはGoogle Cloudへ移行しましたが、プレビュー環境としてのHerokuの利用はまだ続いています。

活用方法

プレビュー環境はエンジニアの動作確認やレビューはもちろんのこと、プロダクトマネージャーへの機能チェックにも使用しています。プルリクエストを作成した段階で実際に動くものを触ってもらえるため、認識齟齬を早期に発見できる、細かい修正や改善が効きやすいといったメリットがあります。

運用の工夫

運用をラクにするためには、シードデータをしっかり用意しておくことが重要です。プレックスでもこの点は注力しており、プレビュー環境を立ち上げたらすぐに機能確認ができるようなデータセットの整備を進めています。最近だと生成AIなどを活用すれば、低コストで実データに近いシードデータを保つことも実現できそうです。

また、新しく環境を立ち上げる際にHerokuのウェブ画面をぽちぽちするのが面倒だということで、社内にはCLIでReviewAppsを使ってプレビュー環境を作成するgemを作ったメンバーもいます。プレックスではフロントエンドにVercelを利用しており、最終的にはVercelのプレビュー環境と連携して、コマンド一発でバックエンドからフロントエンドまでのプレビュー環境立ち上げを目指しているとのことでした。

社内システムのインフラとしてのHeroku

コーポレートチームの役割

プレックスはユーザー向けのtoC・toBプロダクト以外にも人材紹介事業やM&A仲介事業など、人の手が介在する余地の大きいビジネスに取り組んでいます。

その生産性を最大化するために、社内システムの開発に取り組んでいるのがコーポレートチームです。以前の記事でも紹介したように、社内業務を効率化するためのツールやシステムを開発しています。

product.plex.co.jp

Herokuを選ぶ理由

社内システムの場合、利用ユーザーが社内に閉じられており、比較的規模が小さいケースが多いため、Herokuのような管理コストの低いプラットフォームが適しています。また、コーポレートチームでは少人数で複数のシステムをメンテナンスしていく必要性があるため、インフラの冗長性や高可用性よりも、迅速な開発とメンテナンスのしやすさを重視しています。

もちろん、一部のシステムでは機能的な要求がありGoogle Cloudなどのインフラを利用している箇所もありますが、基本的にはHerokuを選択することが多くなっています。

新規事業のインフラとしてのHeroku

立ち上げ期の技術選定

プレックスでは新規事業の立ち上げ期のインフラとして、開発スピードを高める、技術的な不確実性を減らすという目的でHerokuを利用しています。

これは個人的な意見ですが、プロダクトや事業の立ち上げフェーズでは、ビジネスニーズの検証を最優先とした方が上手くいくことが多いと思っています。立ち上げ期はそもそもビジネス的な不確実性が高いため、新しい技術やチームにとって不慣れな技術を採用してしまうと、ビジネスサイドの要求に応えられなくなってしまったり、開発スピードが遅くなってしまい、プロジェクト自体の失敗に繋がってしまうというリスクがあります。

新規事業では状況によってピボットしたり撤退することもあるため、早い段階での作り込みを避けるという意味合いもあります。Herokuはインフラ層が抽象化されていてアプリケーションとそのデータの管理のみに集中することができるため、スケールが必要になった段階での移行や撤退時のクローズ作業も簡略化することができます。