【開発生産性カンファレンス 2025】スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略

enechainのプラットフォームエンジニアリング戦略の始まり

須藤：株式会社enechainでCTOを務めている須藤です。私はグリーやBCGでエンジニアとして働いたあと、2021年にenechainに入社しました。

本日お話しするのは、スタートアップにおける3年間のプラットフォームエンジニアリング実践についてです。取り組みの結果や組織戦略についてもお話しします。後半では、スリーシェイクの岩崎さんより具体的な取り組み内容をご紹介いただきます。

最初に事業についてお話しします。enechainはエネルギーマーケットプレイスを運営するスタートアップです。簡単に言うと、東京証券取引所のような市場の中で電力を取引するシステムをつくっています。
電力の発電事業者と小売事業者、トレーダーに向けてサービスを提供しており、取引をサポートするSaaSプロダクトも複数展開しています。取り扱う商品は電力だけでなく、燃料や環境価値まで、さまざまです。電力の取扱高は年間約1兆円で、スタートアップとしては大きな額を取り扱っています。

事業の背景にあるのは、電力の小売自由化です。日本では2016年に小売自由化され、多くの事業者が小売業に参入し、発電と小売の間に卸取引市場ができました。小売事業者は付加価値をつけて卸市場での仕入れ価格よりも高く売ることで利益を得ますが、電力の価格は安定していません。電力卸取引価格は乱高下を繰り返しており、ビットコインの6倍ほどのボラティリティーがあると言われています。

そこで私たちは、将来の電力の価格を売主と買主で合意してから契約することで価格変動リスクを低減するべく、ヘッジ取引の場を提供しています。

・複数プロダクトを一気通貫で提供している（同一アカウントから複数プロダクトが利用される）
・政府や大手企業が関わる事業であり、高いレベルの可用性・セキュリティが求められる
・スタートアップとしてアジリティも求められる
以上の三点が、我々の事業における重要なポイントです。

プラットフォームについてもお話しします。こちらがenechainのプラットフォームの全体像です。



プラットフォームエンジニアリングというと、インフラ寄りの話が出ることが多いと思いますが、enechainでは複数のレイヤーに分けてプラットフォームを定義しています。

Design Systemの後ろにあるGolden Pathには、BFFやバックエンドのコード、Manifestのボイラープレートが含まれます。Application Platformでは、共通のマイクロサービスとして、認証・認可や請求書管理などのサービスを提供しています。Data Platformでは、ログ収集のための共通フォーマットを定義したり、データベースと連携してログが取りやすい仕組みをプロダクト側に提供したりしています。Monitoringの部分では、SREチームが仕組みを整えてくれています。

このように、enechainでは複数のソリューションを複数チームで提供しています。

開発組織をどのようにつくってきたのかについてもお話しします。私が入社した2021年9月時点では、インターン生を含めて10人程度の開発組織で、二つのプロダクトチームとSRE Deskができたばかりの状態でした。また、SREと言いつつ、当時は主にインフラ構築を担当していました。

そこから4年ほど経ち、現在の組織構造はこのようになっています。


本日お話しするのは、一番右の「Platform Development Dept.」についてです。

組織変遷としては、2021年にSRE Deskが設立されて1年半ほど経ってから、Design Systemが誕生し、フロントエンドから共通化が始まりました。その数ヶ月後にはApplication Platform Deskが設立され、認証・認可系のサービスやユーザー管理、企業管理のような部分を受け持つようになりました。そして同年の12月に、データチームをData Platform DeskとData Science Deskに分割しました。時間の経過に伴いSRE Deskの機能が膨れ上がってきたため、2024年5月にSRE Desk、Security Desk、Platform Engineering Deskに分割しました。

各チームの役割はこちらです。

プラットフォームエンジニアリングの成功・苦労話

須藤：この取り組みで良かったのは、プラットフォームエンジニアリングを導入した「タイミング」と「採用」の2点です。

タイミングという点においては、早い段階でApplication Platform Deskを設立したことで、共通機能はプラットフォーム化するという意識が組織全体に生まれ、チームの存在が負債の生成抑止力につながりました。また、アプリケーションとプラットフォームの関係性は難しいところもあると思うのですが、Application Platform Deskが自らテストを実施してプロダクトチームが導入しやすい環境を整えるなど、橋渡し役としても機能してくれました。

早すぎなかったのも良かったと思います。以前の技術スタックはNode.js/とVue.jsでしたが、今ではどちらもほとんど使っていません。Go/Reactへの移行が終わった段階でプラットフォームに着手して、現時点ではうまくいっていると思います。当時は「VueにコンポーネントがあるのにReactを使うのか」という意見も出ていましたし、その時にDesign Systemまでできていたら、Reactは使えていなかったかもしれません。基盤づくりを早期に行うと、カルチャーによっては挑戦ができない環境になってしまう可能性もあると思います。

採用面では、コミュニケーション能力の高いメンバーを迎え入れることができたのが良かったと思っています。プロダクトチームとのコミュニケーションがうまくいかないと、プラットフォームはPDCAが回せません。コミュニケーション能力の高いメンバーが入ってくれたことで、良いサイクルを回せるようになりました。また、大規模サービスを運用してきたシニアメンバーが加わってくれたのも大きいです。経験豊富なメンバーがいると、将来像を描いた上で適切に判断できるようになります。あとは、プラットフォームに理解のある優秀なプロダクトエンジニアも採用できました。プロダクトとプラットフォームの関係性が良くないという話を聞くこともありますが、enechainでは良い関係性が構築できています。

反対に大変だったのは、SREがインフラチームとして存在していたことです。多数のプロダクトからSREへの依頼が集中してしまい、組織の拡大に伴ってボトルネック化していました。もう少し早い段階で切り替えられたら良かったと反省しています。
また、採用面にも良い影響があったと言っていたのですが、SREとプラットフォームエンジニアについては採用がうまくいっていませんでした。業務委託で乗り切ろうとしたのですが、週2～3日の稼働では対応しきれず、プロダクトチームからの信頼を失う要因だったと思います。

大変だったことへの対応として行ったのは下記の3つです。

①SRE/Platform Engineerへの組織分割
②適切に外部に頼った
③SRE/Platform Engineerカルチャーの理解

①については、プラットフォームエンジニアリング的な思想を強めるため、あえて組織を分割しました。役割を文書化してミーティングも分けるなど、プラットフォームエンジニアリングにフォーカスして働きかけました。現在では、かなりうまく回っていると思います。

②については、業務委託で回すのが難しかったため、スリーシェイクさんに協力を依頼しました。人員が安定していて、Kubernetesの知識もあるため、かなり助けられましたね。協力いただいたおかげで、採用にもフォーカスできました。

③は個人的な話でもあるのですが、採用に関わる人間がSRE/Platform Engineeringを学び、コミュニティにも入ってエンジニアがどういうことを望んでいるかを知ることで、スカウトや面接・面談の質を上げることができました。これには効果がありましたし、採用がうまくいき始めています。

「取り組んで良かった」プラットフォームエンジニアリングの事業的効果

須藤：最後に事業的な効果についてもお話しします。

enechainのような政府や大手企業が関わる会社では、事業拡大に伴い、セキュリティや可用性の要件が高まっていきます。その際にガバナンスが効いていればスピーディに対応できますし、求められることに対応するのではなく、自分たちがやりたいことにフォーカスして開発を進められるのはとても良かったです。

コストの面においても、統一された環境で実装できているため、効率的に削減できています。

チーム異動時のキャッチアップのスピード感も重要なポイントです。スタートアップは事業の状況によってチーム異動が必要な場面が多いのですが、設計や技術基盤が統一されているためスピーディにキャッチアップできています。
CTO目線で言うと、全体向けの戦略が立てやすいのもありがたいです。個々のプロダクトの技術スタックを気にしなくて良いため、全社戦略を考えやすいですし、反映までのコストも低い。プラットフォームがあることで、更なるプラットフォーム開発を加速することができています。

ここまで、スタートアップのプラットフォームエンジニアリングについてお話しさせていただいたことをまとめます。

enechainでは、早い段階からプラットフォームエンジニアリングに投資してきたことで、すぐに効果が得られました。事業内容によって結果は変わるかもしれませんが、私たちの場合は組織が大きくなるにつれて「早めに取り組んで良かった」という思いが増していっています。
ただ、やはり採用が重要で、経験のある人が考えて作っていくものでないと、プラットフォームが長く機能しないかもしれません。プロダクトと一緒に回していく上では、コミュニケーション能力も重要だと思います。

スリーシェイクが考えるSRE/Platform Engineeringの重要性と現実

岩崎：ここからは、株式会社スリーシェイクのSreake事業部でSREとして働いている岩崎からお話しします。私は、先ほど須藤様からお話しのあったPlatform Engineering Deskの支援に参加しています。

本日は、下記の三点についてお話しいたします。

・スリーシェイクとSreake事業部の紹介
・スタートアップにおけるSRE/Platform Engineeringの重要性と現実
・支援内容の紹介

それでは本題に入ります。スリーシェイクは「インフラをシンプルにしてイノベーションが起こりやすい世界を作る」というミッションを掲げている会社です。私が所属しているSreake事業部では、SREやDevOpsの内製化支援を中心に活動しています。それ以外にも、Geminiを用いた生成AIの活用支援やクラウドネイティブアプリケーションの開発支援、今回のようなベストプラクティスの普及活動のお手伝いもしています。

続けて、スタートアップにおけるSRE/Platform Engineeringの重要性と現実についてもお話しします。簡単に言うと「スタートアップにおいて、SRE/Platform Engineeringは重要なのか？」というお話ですね。

言うまでもないことだと思いますが、スタートアップに求められる急速な成長と開発スピードを支える基盤の維持と進化は、当然必要です。また、サービスの信頼性担保も必要であるため、SRE/Platform Engineeringの強化は、スタートアップにとっても重要だと言えます。




しかし、現実では、SRE/Platform Engineeringが後回しになっていることが多いのではないでしょうか。マネージドサービスの力を使って、開発メンバーが片手間で対応しているようなケースも少なくないと思います。そして、事業規模が拡大していくと、どこかのタイミングでインフラやプラットフォーム関連の負荷が増し、開発メンバーの片手間による対応ではいずれ限界がきます。限界がきたタイミングで必要な人材を探したとしても、必ず採用できるとは限りません。

enechain様への支援が始まったのは、同社が「必要なタイミングで必要な人材を採用できるとは限らない」という問題を抱えている時でした。

実践事例に学ぶ！スリーシェイクがenechainを支援した具体的アプローチ

岩崎：具体的な支援内容についてもご紹介いたします。主な支援内容はこちらです。


いくつかの取り組みについて、もう少し詳しくお話しさせてください。

まず、コスト最適化については、Terraform CloudからGitHub Actionsへの移行を行いました。Terraform Cloudの料金体系がRUM数に応じた従量課金に変更されたことで、コストが増大していたからです。enechain様では各チームがリソースを無秩序に作成した結果、RUM数が2万近くにまで膨れ上がっていました。この課題を解決するため、GitHub Actionsへの移行を提案しました。約半年間の移行作業を経て、RUM数を3000程度まで削減することに成功し、大幅なコスト削減を実現しました。

最新技術の活用については、Devinのトライアルに参加しました。具体的には、enechain様の取り組みにスリーシェイクのメンバーが参加して、実際の業務の中でどのように活用できるのかを検証しました。

開発者体験の最適化として、TerraformリポジトリへのTFLintやTrivy、Renovateの導入も推進しました。TerraformのCIにてvalidateなどの最低限のチェックしか行われていなかったため、コードの品質、組織統制、セキュリティ向上などの観点も踏まえて導入を提案させていただきました。また、ADRにまとめて、仕様について議論させていただきました。その上で、ドリフトチェックとマージをするためのslashコマンドも必要だと判断し、Pull Requestで「/merge」とコメントを打つと必要なメインブランチへの連携を行いつつマージする機能も実装しました。

Terraformリポジトリのモノレポ化も行いました。enechain様には多くのプロダクトがあり、プロダクト系とインフラ系で各20以上、モジュールは100以上のTerraformリポジトリがありました。そのため、開発者がインフラに関心を持ってコミットしようとしても、どのリポジトリを見ていいか分からないという課題がありました。そこで、適宜必要な粒度に応じてモノレポ化していっています。

最後に紹介するのは、Terraform運用ガイドラインの作成です。enechain様はTerraformを非常に活用されているのですが、様々なチームがオーナーシップを持って運用していて、全体としての共通認識が持てていない状況でした。そのため、その辺りをガイドラインとしてまとめて提案させていただきました。

事業成長を止めないための「外部活用のすすめ」

岩崎：まとめます。特にスタートアップでは、急速な成長に伴い、開発スピードと並行してサービスの安定稼働やインフラの整備が必要不可欠です。

しかし、多くの場合は、開発や日々の問い合わせ対応に追われ、SRE/Platform Engineeringの領域そのものが後回しになってしまうことが非常に多いと思います。初期段階ではマネージドサービスの力で乗り切れることもありますが、事業が拡大するにつれて、徐々に限界がきてしまいます。

とはいえ、事業成長は止めたくありませんよね。そのためには、SRE/Platform Engineeringの専門知識と体制を適切なタイミングで構築・強化していくことが重要です。理想は早期に専門のメンバーが入ってチームを立ち上げることですが、現実的には採用が難しく、採用できたとしても開発にコミットすることが優先されるケースが少なくないと思います。

このような状況では、スリーシェイクが提供するようなSRE/Platform Engineeringの支援、あるいは同様の外部サービスに頼ることが、有効な選択肢になるのではないでしょうか。

本日はご清聴ありがとうございました！

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です