事業譲渡とシステムリプレイス - 複雑な状況から最適解を見出すための事例集 -

2014年にアユダンテ社により提供を開始されたEVsmartブランドは、2022年9月にENECHANGEに事業譲渡されました。 ENECHANGEは、多岐にわたるサービスで構成されるEVsmartを自社のサービスに統合しつつ、同時にインフラ・ソフトウェアの両面で老朽化したシステムの継続性の確保やビジネス価値向上に取り組まなければなりませんでした。 このような複雑な状況においては、様々なファクターやビジネスニーズを考慮して適切な手法を選択することが重要です。 今回は、インテグレーション型、新設型、フルリプレイス型、マイグレーション型の4つのアプローチとその実際の適用事例を紹介します。

Transcript

1. 事業譲渡とシステムリプレイス - 複雑な状況から最適解を見出すための事例集 - リプレイスメント・デイ - システム刷新の最前線 - Sansan、カミナシ、ENECHANGE。テックベン チャー3社のエンジニアがリプレイスの現場を語る
2. Copyright © ENECHANGE Ltd. All Rights Reserved. | 2 自己紹介 Ryuya Ishibashi SES企業にて大小様々なプロジェクトに参画 • Ruby on Rails / Vue.js / PHP / C# / .NET / AWS / Azureなどの技術に触れてきました ↓ ENECHANGE株式会社 • 2022/04 - 2023/03 ◦ Railsエンジニアとして、電気料金シミュレーションのAPI開 発を中心にお仕事していました • 2023/04 - ←いまここ ◦ Go・インフラエンジニアとして、EV充電器のスポット情報 API開発やAWS環境構築を中心にお仕事しています (@RubyKaigi2022) X / GitHub
3. システムリプレイスの定義
4. Copyright © ENECHANGE Ltd. All Rights Reserved. | 4 本資料におけるシステムリプレイスの定義 • 本資料では、システムリプレイスを以下のように定義します “既存のシステムやサブシステムを 新規のものに置換え・統合していく 一連のプロセス” • 一般的な認識より広義の意味で解釈します • スタートアップの現実は、事業譲渡された複雑なシステムを フルリプレイスのみで統合・最適化できるほど単純ではない（なかった）です • リプレイスの類型と、状況に応じたその選択を重視します
5. Copyright © ENECHANGE Ltd. All Rights Reserved. | 5 本資料におけるシステムリプレイスの類型 • インテグレーション型 ◦ 既存システムを自社の別システムと統合する方式 • 新設型 ◦ 新たなビジネスニーズを新システムによって実現する方式 • フルリプレイス型 ◦ 既存システムを新システムに完全に置き換える方式 • マイグレーション型 ◦ 既存システムをバージョンアップや別のクラウドプラットフォームに 移行する方式
6. Copyright © ENECHANGE Ltd. All Rights Reserved. | 6 類型のマトリクス分析 実装コスト サービスの価値向上 インテグレ ーション型 マイグレーション型 新設型 フルリプレイス型 • 類型毎の実装コスト/サービスの価値向上を以下のように整理します
7. 事業譲渡時のEVsmartを取り巻く状況
8. Copyright © ENECHANGE Ltd. All Rights Reserved. | 8 EVsmartの事業譲渡 • 2022年9月 EVsmart事業がアユダンテより譲渡される
9. Copyright © ENECHANGE Ltd. All Rights Reserved. | 9 EVsmartとは？ • 2014年より開発・運用されたEVドライバー向けの先駆けとなるサービス ◦ 日本全国18,000箇所※のEV充電スポットデータベース ◦ Webメディアの月間PV数: 100万件※ ◦ アプリの累計ダウンロード数: 20万件※ ※いずれも2022年8月時点の数値です
10. Copyright © ENECHANGE Ltd. All Rights Reserved. | 10 歴史あるサービスの課題 EVsmartは10年以上の運用実績があるサービスであり、 • 多くのサービス群により構成され、 • 徐々に蓄積された問題を抱えるアーキテクチャによって支えられている サービス構成 • 自社サービス ◦ EVsmartアプリ ◦ EVsmartウェブサイト ◦ EVsmartブログ • ビジネスパートナーへの展開 ◦ EVsmart OEMアプリ×2社 ◦ EVsmartデータ提供 （充電スポットデータ・口コミ情報）×3社
11. Copyright © ENECHANGE Ltd. All Rights Reserved. | 11 問題を抱えたアーキテクチャ VM メンテナンス ツール データ同期ツール VM ⚠老朽化⚠ ・OS, PHPのEOL ・Azure VMの各種サービス 　の廃止（2025/09） ⚠高い改修コスト ⚠ ・スパゲッティコード ・杜撰なブランチ戦略 ⚠老朽化・サービス廃止 ⚠ ・OS, PHPのEOL ・Azure CloudService 　の廃止（2024/08） ⚠複雑なアーキテクチャ ⚠ ・ソースコード管理のない 　ツールによるデータ同期 メンテツール用DB 商用環境用DB （その1） 商用環境用DB （その2） EVsmart Web / API / バッチ処理 ⚠複雑なアーキテクチャ ⚠ ・SQL Trigger + PHPスクリプト 　によるオレオレ同期機構 Web/API用 VM 2台 ⚠老朽化・サービス廃止 ⚠ ・OS, PHPのEOL ・Azure VMの各種サービスの廃止 　(2025/09) ⚠高い改修コスト ⚠ ・スパゲッティコード ・杜撰なブランチ戦略 ⚠複雑なアーキテクチャ ⚠ ・VirtualHostによる 　複数ドメイン・複数サービスの提供 バッチ用 VM 1台 EVsmart 経路検索 （Web View） ⚠老朽化・サービス廃止 ⚠ ・MySQLのEOL ・Azure 単一サーバーの廃止（2024/09） VM EVsmart アプリ ⚠複雑なアーキテクチャ ⚠ ・複数のDB参照（設計の失敗） ⚠老朽化・サービス廃止 ⚠ ・OS, PHPのEOL ・Azure CloudService 　の廃止（2024/08） ⚠不得意な言語 ⚠ ・Swift, Kotlinの利用 ⚠不得意なプラットフォーム ⚠ ・Azureの利用 EVsmart OEM アプリ
12. Copyright © ENECHANGE Ltd. All Rights Reserved. | 12 問題点の整理 • 複雑なアーキテクチャ ◦ 1つのサービスが複数のDBの似たようなスキーマを参照する ◦ DB間の複雑な同期機構によるブラックボックス化 ◦ VirtualHostによる複数ドメイン・複数サービスの提供 • 高い改修コスト ◦ スパゲッティコード ◦ 杜撰なブランチ戦略 • 老朽化・サービス廃止 ◦ ソフトウェア、OSのEOL ◦ プラットフォームのサービス廃止 • 不得意な言語・プラットフォーム ◦ Swift/Kotlinの利用 （Flutterを得意とする） ◦ Azureの利用 （AWSを得意とする）
13. Copyright © ENECHANGE Ltd. All Rights Reserved. | 13 ビジネス上の主なニーズ • EV充電エネチェンジアプリとの統合 ◦ EVsmartユーザーをEV充電エネチェンジに取り込みたい ◦ EV充電エネチェンジにEVsmartの充実した機能を提供したい • ビジネスパートナーへの新サービス提供 ◦ ビジネスパートナーの新しいニーズに機動的に答えたい • 既存サービスの継続的提供 ◦ すでに提供している既存サービスを安定的に提供し続けたい • データ構造の改善・国際規格対応による新たな価値創出 ◦ データの根幹を改善し、サービスに新しい価値を提供したい
14. インテグレーション型 事例
15. Copyright © ENECHANGE Ltd. All Rights Reserved. | 15 • 事例 ◦ 2022/09-2023/06 ▪ EV充電エネチェンジとEVsmartアプリの統合 • EV充電エネチェンジとは？ ◦ 2022年5月にローンチしたアプリ ◦ エネチェンジ設置の充電器の検索、充電、決済機能 ◦ エネチェンジ以外の充電スポットも検索可能 EV充電エネチェンジとEVsmartアプリの統合
16. Copyright © ENECHANGE Ltd. All Rights Reserved. | 16 • EVsmartユーザーをEV充電エネチェンジに取り込みたい ◦ 累計20万DLを誇るEVsmartユーザー • EV充電エネチェンジにEVsmartの充実した情報・機能を提供したい ビジネス上のニーズ 引用：「事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで」 （情報量・精度 ⭕）
17. Copyright © ENECHANGE Ltd. All Rights Reserved. | 17 • EVsmart側のバックエンドは極力変更しない方針 ◦ EVsmart側のバックエンドは多くの問題を抱えていて改修が難しい • 充電器スポット情報 ◦ 定期的なデータ同期によって、EV充電エネチェンジの検索機能と統合 • 口コミ情報・お気に入り機能など ◦ EVsmartAPIをそのまま利用することによる機能追加 実現方法 引用：「事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで」
18. Copyright © ENECHANGE Ltd. All Rights Reserved. | 18 • Pros ◦ 既存システムが抱える複雑な問題に対処不要 ◦ 開発スピードの向上によるビジネスニーズの早期実現 ◦ 既存システム (Swift/Kotlin)の廃止による管理コスト低減 • Cons ◦ リプレイス機能の実質的ダウングレードのリスク ▪ 基幹機能である充電スポット検索のUXのレベル差が吸収できず • 統合当時はEVsmartの方が大きく優れていた • 統合を急ぐあまり、上記の認識が甘かった • 結果、ストア評価の著しい低下につながった （⭐3→⭐1 😱） → ストア評価回復のための悪戦苦闘の歴史は、 　　事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで 　　をぜひご覧ください （⭐1→⭐4 🎉） Pros And Cons
19. 新設型 事例
20. Copyright © ENECHANGE Ltd. All Rights Reserved. | 20 • 事例 ◦ 2023/06-12 ▪ OCPI形式のAPIによる充電スポット情報の提供 • OCPIとは？ ◦ OCPI（Open Charge Point Interface）は、 電気自動車（EV）の充電インフラを相互運用するためのオープンなプロトコルです ◦ 充電スタンドの位置、空き状況などのリアルタイム情報を交換可能 OCPI形式の充電スポット情報の提供
21. Copyright © ENECHANGE Ltd. All Rights Reserved. | 21 • EVsmartの充実した充電スポット情報を国際規格で提供したい ◦ 国際的な規格であるOCPIに準拠することで、グローバルカンパニーの日本市場参入を 支援する ビジネス上のニーズ 引用： https://www.evoltsoft.com/
22. Copyright © ENECHANGE Ltd. All Rights Reserved. | 22 • AWS上に新たにGo API/バッチ機能を構築する ◦ API機能： ECS on Fargateを利用 ▪ 充電スポット情報 (Locations Module)の提供 ▪ 認証機構 (Credentials Module)の提供 ◦ バッチ機能: Scheduled Taskを利用 ▪ 日次バッチ： 静的情報のOCPI形式へのスキーマ変換 ▪ 毎分バッチ: リアルタイム満空情報のOCPI形式へのスキーマ変換 実現方法
23. Copyright © ENECHANGE Ltd. All Rights Reserved. | 23 • Pros ◦ 既存システムのバックエンドが抱える複雑な問題に対処不要 ◦ 高速で保守性の高い言語やアーキテクチャを選択できる ◦ 自分たちの得意なクラウドプラットフォームを選択できる ◦ 既存サービスを漸次的に移行するための足がかりにできる ▪ これを完遂すれば、実質的にフルリプレイスと同義になる • Cons ◦ 初期の実装コストが比較的高い ◦ 既存システムとの二重管理の問題を抱える ▪ 既存サービスは引き続き運用しなければならない Pros And Cons
24. フルリプレイス型 事例
25. Copyright © ENECHANGE Ltd. All Rights Reserved. | 25 • 事例 ◦ 2022/03-2024/07 ▪ メンテナンスツールのフルリプレイス • メンテナンスツールとは？ ◦ EV充電スポットデータを編集するツール ◦ 社内のデータ管理チームが使用し、日々メンテナンスを実施する メンテナンスツールのフルリプレイス メンテツール 反映
26. Copyright © ENECHANGE Ltd. All Rights Reserved. | 26 ビジネス上のニーズ VM メンテナンス ツール データ同期ツール VM ⚠老朽化・サービス廃止 ⚠ ・OS, PHPのEOL ・Azure VMの各種サービス 　の廃止（2025/09） ⚠高い改修コスト ⚠ ・スパゲッティコード ・杜撰なブランチ戦略 ⚠老朽化・サービス廃止 ⚠ ・OS, PHPのEOL ・Azure CloudService 　の廃止（2024/08） ⚠複雑なアーキテクチャ ⚠ ・ソースコード管理のない 　ツールによるデータ同期 メンテツール用DB 商用環境用DB （その1） 商用環境用DB （その2） EVsmart Web / API / バッチ処理 ⚠複雑なアーキテクチャ ⚠ ・SQL Trigger + PHPスクリプト 　によるオレオレ同期機構 Web/API用 VM 2台 バッチ用 VM 1台 ⚠老朽化・サービス廃止 ⚠ ・MySQLのEOL ・Azure 単一サーバーの廃止（2024/09） ⚠複雑なアーキテクチャ ⚠ ・複数のDB参照（設計の失敗） • POI (Point of Interest) のデータ価値を最大化したい ◦ 長年運用していく中で、データ構造がビジネスニーズに即さなくなっていた ◦ 新システムにより改修容易性を確保し、そのための足がかりを作る • 蓄積した老朽化問題を一挙に解決し、サービス継続性を担保したい
27. Copyright © ENECHANGE Ltd. All Rights Reserved. | 27 問題点の整理 • 複雑なアーキテクチャ ◦ 1つのサービスが複数のDBの似たようなスキーマを参照する ◦ DB間の複雑な同期機構によるブラックボックス化 • 高い改修コスト ◦ スパゲッティコード ◦ 杜撰なブランチ戦略 • 老朽化・サービス廃止 ◦ ソフトウェア、OSのEOL ◦ プラットフォームのサービス終了 • 不得意なプラットフォーム ◦ Azureの利用 （AWSを得意とする）
28. Copyright © ENECHANGE Ltd. All Rights Reserved. | 28 実現方法 • AWS ECS on Fargate / Next.js / Go によるアプリを一から構築 → クリーンなコードによる改修容易性の向上 → サーバレスコンテナによる保守性の向上 • データの保存・参照用DBを1つに集約 ◦ メンテナンス用テーブルのスキーマ再設計 （構造化） ◦ メンテナンス用テーブルを商用テーブルがあるDBに統合 （Embulk利用） → シンプルなDB構成による今後の改修コストの低減 fargate 商用環境用DB （その1） 商用環境用DB （その2） EVsmart Web / API / バッチ処理 Web/API用 VM 2台 バッチ用 VM 1台 メンテナンス ツール 🟢 得意なプラットフォーム 🟢 ・AWSの利用 🟢 シンプルなDB構成 🟢 ・リアルタイム満空情報用の 　DBとしてのみ存続 🟢 シンプルなDB構成 🟢 ・複雑な同期機構の廃止 🟢 改修容易性の向上 🟢 ・クリーンなコード 🟢 保守性の向上 🟢 ・サーバレスコンテナ
29. Copyright © ENECHANGE Ltd. All Rights Reserved. | 29 • Pros ◦ 古いコードを捨てることで、改修容易性を高め、サービス価値向上に繋げられる ◦ コンテナ化等のインフラ技術を採用することで、保守性を高めることができる ◦ シンプルなアーキテクチャに再設計できることで、今後の改修コストを低減できる ◦ 自分たちの得意なクラウドプラットフォームを選択できる • Cons ◦ 初期の実装コストが極めて高い ◦ 全面的なリプレイスとなるため、考慮漏れによる事故が起こりやすい ▪ 必要な視点： 既存機能を完全に移植できているか？ • 既存のメンテナンス機能を全て網羅できているか？ • メンテナンステーブルのスキーマ移行は完全か？ • 本番テーブルへの反映ロジックは既存と同等か？ • DB同期機構の廃止で、廃止テーブルは全て適切な参照先に切り替えられているか？ • Web/APIの全ての既存機能に影響はないか？ ✱ 機能のリプレイス以外には手を出さない方が無難 Pros And Cons
30. マイグレーション型 事例
31. Copyright © ENECHANGE Ltd. All Rights Reserved. | 31 • 事例 ◦ 2024/08 MySQLのAzure SQL Database → AWS RDS移行 ◦ 2025/01 MSSQLのAzure SQL Database → AWS RDS移行 ◦ 2025/08 PHPサーバーのAzure VM → AWS EC2移行 • それぞれの用途 ◦ MySQL ▪ 商用環境用DB その2 （旧メインDB) • リアルタイム満空情報の保存先テーブル • 経路検索サービス用の各種データ保存先テーブル ◦ MSSQL ▪ 商用環境用DB その1 （現メインDB) ◦ VM ▪ EVsmart Web / API / バッチ処理用 ▪ EVsmart 経路検索 （Web View） Azure → AWS へのプラットフォームマイグレーション
32. Copyright © ENECHANGE Ltd. All Rights Reserved. | 32 ビジネス上のニーズ ⚠老朽化・サービス廃止 ⚠ ・OS, PHPのEOL ・Azure VMの各種サービスの廃止 　(2025/09) ⚠高い改修コスト ⚠ ・スパゲッティコード ・杜撰なブランチ戦略 ⚠複雑なアーキテクチャ ⚠ ・VirtualHostによる 　複数ドメイン・複数サービスの提供 EVsmart 経路検索 （Web View） ⚠老朽化・サービス廃止 ⚠ ・MySQLのEOL ・Azure 単一サーバーの廃止（2024/09） VM ⚠老朽化・サービス廃止 ⚠ ・OS, PHPのEOL ・Azure VMの 　各種サービスの廃止 　(2025/09) 商用環境用DB （その1） 商用環境用DB （その2） EVsmart Web / API / バッチ処理 Web/API用 VM 2台 バッチ用 VM 1台 ⚠不得意なプラットフォーム ⚠ ・Azureの利用 • 老朽化・サービス廃止を乗り越えて、サービスを継続提供したい ◦ OS, PHPのEOL状況を改善したい ◦ クラウドプラットフォーム都合の廃止前にサービスを移行したい • 不得意なプラットフォームから得意なプラットフォームに移行したい ◦ Azureの知見が社内になく、プラットフォーム内の移行にノウハウがない ◦ 得意とするAWSに移行し、最適化の難易度を下げたい
33. Copyright © ENECHANGE Ltd. All Rights Reserved. | 33 実現方法 • サービス廃止スケジュールに間に合うように、順次AWSに移行していく ◦ 大幅なリファクタは時間的に厳しいため、同等のサービスに代替する ▪ VM → EC2 ▪ SQL Database → RDS • 得意なプラットフォームで最適化を図る ◦ Auto Scalingの構成 ◦ CloudWatchLogsによるログの中央管理 ◦ インフラのIaC化（Terraform） EVsmart 経路検索 （Web View） EC2 商用環境用DB （その1） 商用環境用DB （その2） EVsmart Web / API / バッチ処理 Web/API用 VM バッチ用 VM 1台 Auto Scaling 🟢 得意なプラットフォーム 🟢 ・AWSの利用 🟢 最適化 🟢 ・Auto Scalingの構成 ・crontab, VirtualHostの 　ソースコード管理 ・CloudWatchLogsによる 　ログの中央管理 Cloud Watch Logs
34. Copyright © ENECHANGE Ltd. All Rights Reserved. | 34 • Pros ◦ 緊急性の高い状況で、速やかにサービス継続を実現できる ▪ アプリケーション側の大幅なリファクタリングは不要 ◦ 得意なクラウドプラットフォームで、最適化を容易に実現できる • Cons ◦ 提供サービスそのものの価値向上にはつながらない ▪ SRE的な改善はあるが、提供サービスそのものの改善にはつながらない • スパゲッティコードがなくなるわけでないので、改修コストは高いまま ◦ クラウドプラットフォームの移行を伴うので、一定の難易度・工数は生じる ▪ 新しいクラウドプラットフォームでのインフラの再設計 ▪ 移行時のデータ整合性やダウンタイムの最小化の考慮 Pros And Cons
35. まとめ
36. Copyright © ENECHANGE Ltd. All Rights Reserved. | 36 • 複雑で老朽化したシステムを事業譲渡されるという状況において、 システムリプレイスは容易でない • 様々なファクターやビジネスニーズを考慮し、 適切な類型のリプレイス方法を選択していく • フルリプレイスという理想論に拘りすぎず、 サービスの継続性を担保していく姿勢が重要 まとめ
37. 最後に
38. Copyright © ENECHANGE Ltd. All Rights Reserved. | 38 エンジニアを募集しています！ We are currently hiring GREEN ENGINEERS !!!