スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略

開発生産性カンファレンス2025 enechainの発表資料になります。
enechainの開発組織が、10人規模から90人規模に拡大してく3年間の中でどのようにプラットフォーム開発に取り組んできたか、また、そこからどのような学びを得たかを発表します。

Transcript

1. スタートアップの急成長を支える プラットフォームエンジニアリングと組織戦略 2025/07/04(Fri) @開発生産性カンファレンス2025
2. 2 自己紹介 須藤 優介 @sutochin26 株式会社enechain 執行役員 CTO（兼 プラットフォーム開発部部長） 2013-2018 グリー株式会社 - Backend Engineer / Engineering Manager 2018-2020 ボストンコンサルティンググループ - Engineer 2020-2021 LIDDELL株式会社 – 執行役員CTO 2021- 株式会社enechain – 執行役員CTO 趣味：ラーメン二郎、ビール、犬、漫画
3. 3 本日お話すること スタートアップにおける３年間のプラットフォームエンジニアリング実践の話 • 事業フェーズが変化する中でプラットフォームエンジニアリングをどのように実践してきたか • 10人→90人と人が増える中で、どのような組織体制を組んできたか • どのような学びがあったか ※ 後半では、3shake 岩崎さんから、具体的な取り組みについて紹介させていただきます
4. 4 アジェンダ 1. 事業概要 2. プラットフォーム全体像 3. 開発組織の体制と役割 4. プラットフォームと組織作りの成功・失敗 5. プラットフォームエンジニアリングの事業的効果
5. 5 事業概要
6. 6 enechain は、国内最大のエネルギーマーケットプレイスを運営するスタートアップです。 • 電力の発電事業者、小売事業者、トレーダーを主な顧客とし、現物から先物まで あらゆる卸電力商品をリアルタイムに自動約定させるオンラインマーケットを提供 • 取引をサポートする各種SaaSサービスも提供 • 取り扱う商品は電力に限らず、燃料・環境価値まで拡大
7. 7 発電 消費 小売 卸取引市場 小売市場 背景）電力小売自由化 日本では2016年に小売り自由化。2000社近い事業者が参入し業界が大きく変化 ※ 小売り事業者は卸市場での仕入れ価格よりも高い価格で小売市場に出すことで利益を得る
8. 8 ユーザペインとソリューション 電力卸取引における価格の変動リスクを、ヘッジ取引が行えるマーケットにより回避 燃料高騰、猛暑・厳冬や発電所の 計画外停止等の需給要因により変動 （変動幅はBitcoinの約6倍 ※ ） 電力卸取引価格の乱高下 東京エリアの電力スポット価格の推移（円／kWh） 0 50 100 150 200 20/1 20/7 21/1 21/7 22/1 22/7 23/1 23/7 24/1 24/7 25/1 出典：JEPX・帝国データバンクデータ・毎日新聞記事を基にenechainが作成 ※2020.1 - 2024.3 出典：JEPX・Investing.com 将来の電力の価格をあらかじめ 決めて売買することで、将来的な 価格変動のリスクを低減 ヘッジ取引の場を提供
9. 9 プロダクト紹介
10. 10 エ ネ ル ギ ー 事 業 日本最大のオンライン取引の場を提供する 電力トレーディングプラットフォーム ⚫ 大手エネルギー事業者も参加 ⚫ 国内初となる即時約定（自動取引）が可能な アルゴリズムを導入 ⚫ APIによるシステム連携機能も提供 プロダクト
11. 11 エ ネ ル ギ ー 事 業 市場リスクのマネジメントツール、ETRM ※ ⚫ 電力の調達・販売における適切なリスク管理を サポート ⚫ 卸契約・小売契約ポジションの精緻な管理 ⚫ EaR評価や価格シミュレーション、 ストレステスト等を実現。日本電力に特化 ⚫ 大手電力複数社への導入実績 ※ ETRM: Energy Trading Risk Management System プロダクト
12. 12 エ ネ ル ギ ー 事 業 エネルギー取引に必要な情報を集約した データプラットフォーム ⚫ トレードに必要不可欠な情報を提供 ⚫ JEPX価格 ⚫ 燃料・為替フォワード ⚫ 連系線空き容量 ⚫ 欧州の天然ガス在庫量など ⚫ 統計学や機械学習を用いた機能も提供 プロダクト
13. 電力事業者向けのソリューションを複数提供 13 プロダクト エ ネ ル ギ ー 事 業 eSquareを軸として、ユーザーペインを解決する一気通貫のソリューションを提供 リスク量が 定量化されていない ペ イ ン ポ イ ン ト ソ リ ュ シ ョ ン ー 晒されているリスク量が把握 できないので、どのポジションを どうヘッジすべきかわからない 相場・価格が不透明 最新の電力取引に関する 相場情報にアクセスできないため 収支予測や確定が難しい 与信リスクが大きい 相対取引時の買い手の信用力を 低減する仕組みがない 規制対応コストが高い 電力・ガス取引監視等委員会に 取引公平性を証明するための 負担が大きい ヘッジニーズの可視化 価格透明性の担保 クリアリングの提供 市場を通じた規制対応 自社ポジションとリスク量の定量化 適切な取引価格の提供 取引時の与信リスクの低減 取引を市場で行い即レポーティング 流動性の向上 規制へのレポーティング 取引執行 相場情報の収集 ポートフォリオの見える化
14. 14 ※ 他にも複数のプロダクトを開発・運営中 • 環境価値を取り扱うプロダクト • 燃料を取り扱うプロダクト • 社内向けのプロダクト • etc
15. 15 enechainの事業の特性 • 複数プロダクトを一気通貫で提供している • 同一アカウントから複数プロダクトが利用される • 社会インフラとしての性質を持つ • 政府や大手事業者が関わるビジネスであり、高いレベルの可用性、セキュリティが求められる • スタートアップとしてのスピードも求められる • プロダクト・組織が急拡大する アジリティとガバナンスを両立させる事が重要な事業
16. 16 プラットフォーム全体像
17. 17 プラットフォーム全体像 Frontend BFF Backend Product A Frontend BFF Backend Common Service Golden Path （Code, Manifest Template） Application Platform Data Platform Design System Product B Monitoring(SRE) User Auto-generated by CLI 複数レイヤーでプラットフォーム機能を提供。プラットフォーム関連チームも複数存在
18. 18 開発組織の体制と役割
19. 19 開発組織全体像 (2021年9月時点) eSquare Desk (Product) eCompass Desk (Product) SRE Desk Technology Division 入社時は10人程度の開発組織で、プロダクトエンジニア中心。SREは主にインフラ構築の役割を担っていた。
20. 20 開発組織全体像 (2025年7月時点) Product Development Dept. Product Planning Dept. Platform Development Dept. Technology Division eSquare Desk 現在は業務委託を合わせると90人規模の組織。本部 > 部 > デスク の3階層に別れる。 eCompass Desk eScan Desk : : Product Management Desk Product Design Desk Customer Support Desk Prototyping Desk SRE Desk Platform Engineering Desk Security Desk Application Platform Desk Data Platform Desk Data Science Desk :
21. 21 開発組織全体像 (2025年7月時点) Product Development Dept. Product Planning Dept. Platform Development Dept. Technology Division eSquare Desk 今日は主に「プラットフォーム開発部」の話をします。 eCompass Desk eScan Desk : : Product Management Desk Product Design Desk Customer Support Desk Prototyping Desk SRE Desk Platform Engineering Desk Security Desk Application Platform Desk Data Platform Desk Data Science Desk :
22. 22 開発生産性関連の組織変遷 2021.07 2024.05 2023.02 2023.05 2023.12 時期 組織 規模 10人 30人 35人 60人 70人 Design System チーム誕生（有志） Application Platform Desk 設立 データチームを Data Platform Desk と Data Science Desk に分割 SRE Desk を SRE / Security/ Platform Engineering に分割 SRE Desk 設立
23. 23 開発生産性関連の組織の役割 SRE Desk Platform Engineering Desk Security Desk Application Platform Desk Data Platform Desk Design System Team システムの信頼性に責任を持つ。 オブザーバビリティ向上やSLO/SLI設計をサポートする。 クラウド領域を中心とした開発生産性に責任を持つ。 Kubernetes を中心とした技術でプロダクトチームに基盤を提供する。 アプリケーション領域を中心とした開発生産性に責任を持つ。 全プロダクト共通のマイクロサービスやライブラリ、ゴールデンパスを提供する。 アプリケーション、インフラ、データ、コーポレートのセキュリティに責任を持つ。 DevSecOpsや脆弱性診断を始めとしたセキュリティ強化を行う。 データ基盤の提供に責任を持つ。 ログフォーマット策定やデータ権限管理、多様なロギング手段を提供。 全プロダクトで利用するデザインシステムを提供する。 正式なチームではないが、有志で活動。
24. 24 成功・苦労話
25. 25 良かったこと • タイミング • 早い段階でアプリケーションプラットフォームデスクを設立した • 早すぎなかった • 採用 • コミュニケーション能力とドキュメンテーション能力の高いメンバーが プラットフォームエンジニアリングデスクに採用できた • 大規模サービスを経験したシニアメンバーの採用できた • プラットフォームに理解のある優秀なプロダクトエンジニアの採用できた
26. 26 良かったこと：タイミング • 早い段階でアプリケーションプラットフォームデスクを設立した • 「共通機能はプラットフォーム化しよう」という意識が組織全体に生まれ、存在自体が負債の 生成抑止力になった • 「インフラとアプリケーションの間」という立ち位置で、新しい基盤機能を実験する、 プロダクト側との橋渡しのチームとして機能してくれた • 早すぎなかった • 過去の技術スタックは Node.js / Vue.js だったが、今はどちらの利用も限定的 • 少し様子を見たことで、 Go / React という新しい（長く使えそうな）技術で基盤を組むことが出来た − 実はReactの採用時に「Vueで作ったコンポーネントがあるのにReactにするの？」と いう議論があった。デザインシステムまで作っていたらReact導入のネックになった可能性もある − 基盤作りを早期に行うと、カルチャー次第では技術的な挑戦の妨げになったかもしれない
27. 27 良かったこと：採用 • コミュニケーション能力の高いメンバーが採用出来た • プロダクトチームへのヒアリングやオンボーディングを丁寧に実施し、信頼関係が築けた • プロダクトチームからのヒアリング→施策実施→フィードバック というサイクルが回るようになった • 大規模サービスを経験したシニアメンバーの採用できた • 初期にシニアなメンバーが採用出来たことで、基盤の将来像を描いた上で 「今はここまでやる。いずれここまで頑張ろう」という判断を適切におこなえた • プラットフォームに理解のある優秀なプロダクトエンジニアの採用できた • 何をするにも協力的であり、非常にスムーズにプラットフォーム開発が進んだ • 有志のデザインシステムチームも生まれ、大きな成果を出してくれた
28. 28 大変だったこと • SREという名の実質インフラチームを長い間運用してしまった • あらゆるインフラ系の依頼が集中し、組織の拡大に伴いボトルネック化 • Platform Engineering 的な視点で設計されていなかったため、 後々大規模なリファクタが必要に • インフラ → Platform Engineering の思想の移行もスムーズに行かず、 マネジメントにも苦労 • SRE/Platform Engineer の採用がうまくいかなかった • とにかく SRE と Platform Engineer が採用出来なかった • ずっと業務委託でしのいでいたが、稼働が安定せずにプロダクトチームからの依頼に タイムリーに応えられず、どんどん信頼を失っていった
29. 29 大変だったことへの対応 • SRE / Platform Engineer への組織分割 • Platform Engineering 的な思想を強めるため、敢えて組織を分割 • それぞれの役割を明確に文書化。敢えてMTGも分けて、責任の所在を明確にするよう務めた • 適切に外部に頼った • 個別の業務委託採用ではなく、3shakeさんへの協力を依頼 • 継続的に協力体制を改善してくれるため、業務委託のローテーションのような価値がストックされない 状況を回避。同時に安定した稼働とKubernetesのノウハウも獲得 • SRE / Platform Engineer カルチャーの理解 • 採用に関わる人間が、SRE / Platform Engineering を学び、コミュニティにも積極的に関わるようにし た • 候補者がどんなことを大切にしているのか、中に入って学ぶことでスカウトや面談・面接の質を上げた
30. 30 事業的効果
31. 31 事業的効果 • セキュリティ・可用性のガバナンス向上。事業スピードに貢献 • 会社の拡大と共に求められる高いレベルの可用性やセキュリティにスピーディに応えられる • 結果的に事業の成長に必要な開発に集中出来ている • コスト削減の一括実行が可能 • 統一された環境で実装されているため、コストがかさむ箇所も概ね一緒であり、コスト削減も効率的に行える • 各プロダクトに個別に依頼するのではなく、ある程度プラットフォームチームで一括で対応出来た • チーム異動時のキャッチアップコスト削減 • 事業の状況によってチーム異動が必要なシーンが多く発生するが、設計や技術基盤が統一されていることで スピーディにキャッチアップ出来ている • 全体向けの技術戦略が立てやすい • チーム毎のアーキテクチャや技術スタックを気にする必要が少ないので、全社戦略を考えやすい • プラットフォームが存在することにより全体反映のコストも低くなり、さらなるプラットフォーム開発が加速する
32. 32 まとめ・所感 • スタートアップにおけるプラットフォームエンジニアリングの組織作りと 取り組みについて紹介しました • 早い段階からプラットフォームエンジニアリングに投資しても、 意外とすぐに投資効果が得られました • 組織が大きくなるにつれて「やってて良かった」と思えています • 採用が命。経験とコミュニケーション能力は宝