東京ガス、「myTOKYOGAS」の開発内製化をTiDBで加速　エンジニアが事業を動かす環境へ

「ビジネスとデジタルが分離してしまう」　内製化への挑戦とTiDBという救世主

　「myTOKYOGAS」は、電気やガスの料金、使用量、ポイントなどを確認できるアプリケーション。東京ガスにとっては顧客との重要な接点であるが、アプリケーションの開発・運用は、長らく外部に委託されてきた。転換点となったのは2022年頃、外部委託のままでは顧客ニーズへの迅速な対応、フィードバック・サイクルの高速化などが困難になるという課題を長く抱えていた。

　同社 リビング戦略部の中島潤耶氏は、「開発者もビジネス担当者も、『プロダクトをただ作るのではなく、プロダクトを通じて事業に貢献する』という共通目的を持つことこそが、DX成功の秘訣だと感じていた」と当時を振り返る。この課題解消に向けて、東京ガスが着手したのは内製開発チームの発足だ。

　エンジニアがほぼゼロの状態からスタートすると、中島氏がソフトウェアエンジニアとして参画。その後、徐々にエンジニアも増えていき、現在はデザイナーやスクラムマスターを含めて数十人規模にまで成長している。

　手始めに取り組んだのは、主力アプリケーションであるmyTOKYOGASの内製化だ。決済や料金管理といった基幹システムに関わるバックエンド領域は安定稼働を優先させるため、基本的に従来からの開発体制を継続。まずは顧客体験に直結するUI周辺など、基幹システムに影響の少ない領域から着手された。

　当時のアプリケーションは、いわゆるモノリシックなアーキテクチャで構築されており、サービス画面ごとに強い依存関係が生じていた形だ。この状況を解消するため、まずはバックエンドからデータを取得し、アプリケーション向けにデータを加工するBFF（Backends For Frontends）に抽象化レイヤーを設け、ドメインを整理しながらシステム改修を進めていった。現在は、そこで整理されたドメインを少しずつマイクロサービスとして切り出しており、新たな機能追加にともなって生じるドメインについても、マイクロサービスとして構築している。このマイクロサービス化を進めるためのデータベースとして検討されたのが、TiDBだった。

　myTOKYOGASのユーザー数は数百万、潜在的には一千万近い契約者がいるため、「（将来的には）一瞬で何千万ものデータが溜まる可能性が予測できた」とリビング戦略部 迫田賀章氏は述べる。シャーディングやログのパーティショニング、大規模なログデータのAmazon S3へのアップロードといった、パフォーマンス維持のために複雑な対策が必要になることが見えていた。「当時、既にパフォーマンスに関するチケット（タスク）が積まれており、いずれ壁にぶつかることが見えていました。そこに救世主のように現れたのが『TiDB』です。結果的には、課題となっていたタスクがすべて消えました」と迫田氏。このときプラットフォーム側でも、運用面で課題を感じていたという。

　少人数のチームで既存サービスの運用と新規基盤構築を並行して行う必要があったため、データベースの運用にかかる工数を少しでも削減したかったからだ。同部 青木翔平氏は「運用負荷が大きく下がるならば、専門のDBAのようなメンバーを置かなくとも運用できるのでは」と考えていたという。たとえば、パブリッククラウドのマネージドサービスを利用することも一つの方策ではあるが、運用負荷を軽減できても、バージョンアップやメンテナンスには依然として時間と手間をかける必要があるだろう。

　そこで青木氏が参加したのは、TiDBのユーザーイベント。TiDB導入により専任の担当者がいなくても、PingCAPからのサポートを得ながら運用ができているという他社事例を聞いたことで、本格的な検討に乗り出す。