プロダクトの価値を届ける、最前線。「エネチェンジ」のフロントエンド開発
ENECHANGEは、「エネルギーの未来をつくる」をミッションに掲げ、エネルギー領域において多数のプロダクトを展開しています。
今回は、その中でも電力・ガス切替に関わるプロダクトのフロントエンド開発に携わる3名に、ENECHANGEのフロントエンド開発の面白さや、技術的な工夫、そして今後の挑戦について語ってもらいました。
プロフィール
SI業界からキャリアをスタートし、事業会社でのリードエンジニアやCTOを歴任。2021年にENECHANGEへ入社。現在はCTOとして全社の技術戦略の策定を担う傍ら、電力・ガス切替プラットフォーム「エネチェンジ」の開発責任者としても活躍。
フロントエンド領域をメインに開発経験を積み、2023年よりフリーランスとしてENECHANGEにジョイン。ENECHANGEでは主に「エネチェンジ・マイエネルギー」の立ち上げと、電気切替申し込みフォームの改善などを担当。
前職ではリードエンジニアとして活躍。2022年よりフリーランスとしてENECHANGEにジョイン。ENECHANGEではガス開栓診断機能の新規開発に携わる。
エネチェンジ・マイエネルギーにガス診断、複数のサービスを支える開発現場
── まず、お二人が関わってきたプロダクトやプロジェクトについて教えてください。
U：印象に残っているプロジェクトは家庭の電力使用量が増えたときや使いかたが変わったときにアラートを届けたり、現在のプランが最適でない場合は料金プランの切替を提案したりする「エネチェンジ・マイエネルギー」というプロダクトの立ち上げです。新しいプロダクトの開発に携われて、アーキテクチャから検討できたのが良い経験です。
直近では、「エネチェンジ」で電力会社を切替る際に利用する申し込みフォームの改善に携わっています。
「エネチェンジ」は10年ほど運用されているサービスなので、複雑かつレガシーなところも多くあります。アプローチに悩むこともありますが、技術負債の返済や今後の拡張を意識しながら新機能開発や改修を行っています。
O：私は、「エネチェンジ・マイエネルギー」の画面実装や、細部の改修など比較的小さいプロジェクトを担当することが多いです。
大きなプロジェクトでは「エネチェンジ」の引越し時のガスの料金シミュレーションと開栓申込の新機能開発に携わりました。
ENECHANGEではこれまで電気の切替を中心に提供してきましたが、引越しに伴うライフライン手続きの際に、ガスも一緒に申し込める機能を追加しました。
── それぞれの開発には、どういった背景があったのでしょうか？
亀田：まず「引越し×ガス開栓診断」についてです。これまで「エネチェンジ」では、電気の切替や引越し時の申し込みをサポートしており、ガスに関しては切替機能と診断機能を提供してきました。
長年に渡り「エネチェンジ」を運営し、継続的な成長を実現してきましたが、より飛躍的に成長するためには新たな市場を開拓する必要があると考えました。
これまでは、電気の引越しと違ってガスは開栓時に人が立ち会う必要があり、ガスの小売事業に参入している事業者が少ないため、ENECHANGEとしてもこの領域にはあまり力を入れていませんでした。
しかし従来より、引越し時に電気とガスの両方の手続きを同時に進めたい、という要望をこれまでも多くいただいていました。また引越しには安定的なニーズがあることも踏まえ、開発に取り組むことに決めました。
フォーム改善については、切替申し込みのCVR改善のため取り組みました。特にフォームは申し込みプロセスの中で最も重要な接点であるにもかかわらず、UXの最適化が遅れていたのが課題でした。フロントエンドの力で改善余地がある領域だったので、そこに本腰を入れることになりました。
責務の整理、可読性の確保──技術的な工夫と苦労
── 実際に開発を進める中で、技術的に工夫したことや苦労したことはありますか？
U：「エネチェンジ・マイエネルギー」は新しいプロダクトだったので、コードの構造やアーキテクチャを一から考えました。
既存プロダクトのフロントエンドコードにはあまりテストが入っていなかったので、Reactでの新規実装と並行してテストコードの整備にもチャレンジしました。
またフォーム改善のプロジェクトでは責務の分離を意識しました。
「エネチェンジ」では様々な事業者に申し込みができますが、事業者ごとにフォームの要件が異なることがあります。サービスが長年運用されていることもあり、1つのファイルに複数のロジックや処理が混在していることがあったので、機能や事業者ごとのロジックなどをファイルを分けて整理するようにしました。
また作りが複雑になっているところを作り直すにあたって、バグが起こらないように可読性の高いコードを書くことも心がけました。
O：私も似たような事例を経験しています。これまでも運用されてきたガス料金のシミュレーションについては、既存のコードベースが長年の運用を経て“アドオンの塊”のような状態になっていて、当時の開発者もいないので意図もわからないような状態になってしまっています。
またシミュレーション結果の情報がエネチェンジのサービスの至る所で使われていて、実装もバラバラなのでメンテナンスが大変な状況でした。そこでガス料金のシミュレーションについては共通のコンポーネントを作成することで可読性向上に取り組みました。
また現在はバックエンド側でのデータ整形が不十分で、フロントに複雑なロジックが残ってしまっているのですが、将来的なバックエンド改修を見据えて、フロントエンド側で取得・表示ロジックを責務ごとに整理して実装しています。
全てを一気に変えることは難しいので、今の制約を受け入れつつ、いずれ最適化できるよう布石を打っておくという感覚です。
亀田：お二人が取り組んでいただいているように、ENECHANGEのサービスは長年の運用の結果、制約になってしまっている構造もあるのが率直な状況です。
そのため技術的な課題を解くことと同時に、運用や事業の方向性も含めて「最適解を考えられる力」が問われるのがENECHANGEのフロントエンド開発の特徴かもしれません。
開発・改修において、ただ書く・直すだけでなく「将来的にどういう状態が理想か」を見据えた設計をしてくれているのがUさん・Oさんのようなメンバーのすごくありがたいところです。
React移行の背景と方針、このフェーズの面白さ
── フロントエンドの技術スタックや今後の方針について教えてください。
亀田：現在フロントエンドはVue.jsからReactへの移行を進めています。元々ENECHANGEのフロントエンドは、Vue 2を使いつつも一部はRails側に直接ロジックが記述されており、またコンポーネント化されていない画面も多く、保守性や再利用性の面で課題がありました。
Vue 3への移行も検討しましたが、各社の移行事例や当時の社内状況を踏まえて、Reactを選択し、段階的に移行する方針をとりました。
もちろん、全体を一気にReactに置き換えることは現実的ではありません。そこで、新機能追加や大規模改修のタイミングに合わせてReact化を進めていくスタイルをとっています。現在、全体の約5割がReactで実装されており、2026年中には概ねの移行が完了する見込みです。
この技術移行は単なるフレームワークの差し替えではなく、プロダクトや事業の方向性を見据えた「最適な構造」を再設計する機会だと捉えています。
古いコードとの共存や、Railsとの依存関係、診断ロジックの分散など、技術的負債が残る箇所はまだありますが、そこに対してどう向き合い、どう整理していくかはまさに今後の重要なチャレンジです。
エンジニアにとって、スキルを伸ばすポイントは「作ったものをどう育てていくか」というフェーズにおいて、リファクタリング、パフォーマンス改善などに継続的に取り組むことだと考えています。そういう意味では今のENECHANGEは成長を後押しし、やりがいのあるフェーズにあると考えています。
CTOからのメッセージ
── 最後に、この記事を読んでいる方へメッセージをお願いします。
亀田：ENECHANGEでは、電気やガスといった生活に欠かせないインフラ領域で、誰もが触れるWebのフロント部分を担っています。「エネチェンジ・マイエネルギー」や引越し・切替手続き、料金シミュレーションのような機能において、「わかりやすく」「使いやすい」体験を設計することは、サービス全体の価値に直結する重要な役割です。
日本中の誰かが使うかもしれないサービスの“体験の入口”を一緒につくっていける仲間を、私たちは探しています。
興味を持っていただけた方は、ぜひ一度、カジュアルにお話ししましょう。