東京ガスの内製化とmyTOKYOGASの開発体制

福田：東京ガスの福田と申します。東京ガスに新卒で入社し、2020年からmyTOKYOGASの担当をしています。当時は外注での開発をメインとしており、要件定義やデザインの設計に携わっていました。2023年にリニューアルした内製開発体制の中で、Web領域のプロダクトオーナーを担当しています。

東京ガスは渋沢栄一が1885年に創立した会社です。東京という名前はついていますが、全国・世界に事業を展開しており、原料の調達からガス・電気をお客さまにお届けする部分はもちろん、エネルギーを効率的に使っていただけるソリューションの提供まで行っています。現在は第3の創業期にあり、エネルギーに閉じない領域へのチャレンジも進めています。



内製化の転機となったのがエネルギー小売り全面自由化です。お客さまが自由にエネルギー会社を選べるようになったことで、デジタル接点におけるお客さまの獲得や体験価値の向上が喫緊の課題となり、内製開発チームを立ち上げることになりました。

ご家庭のお客さま向け会員サービス「myTOKYOGAS」は、ガスや電気の料金・使用量の確認、ポイントの確認・交換などができる無料のサービスで、東京ガスとお客さまとの貴重な接点です。2023年のリニューアルを内製開発体制で実施することになりました。



myTOKYOGASではビジネス、デザイナー、エンジニアが同じ組織に所属して一体となって開発しています。横軸でビジネス・デザイン・エンジニアリングの職能ごとのチーム、縦軸でWeb・モバイル・マイクロサービスといったアプリケーションごとにチームを組んでいます。本日はこの中からプロダクトオーナー、ソフトウェアエンジニア、プラットフォームエンジニアの三名がそれぞれの立場から内製化のリアルをお話しします。

内製開発の目指すところ ─「受発注がなくなっただけ」からの脱却

福田：内製開発をスタートした当初、チーム構成はプロダクトオーナー、スクラムマスター、デベロッパーズ5名の計7名で、スクラムを用いて2週間のスプリントで回していました。すぐに、システムを開発・運用するとはどういうことかという現実に直面することになりました。要件定義、受け入れテスト、リリース、障害対応、すべて自分たちでやらなければなりません。今までどれほど外注先に頼り切っていたのか、ひしひしと感じる日々でした。

加えて、各所からの開発要望やバグ修正にも応えなければなりません。外注先にご協力いただいていた頃は体制を一時的に増やして複数の案件を並行して進めることもできていましたが、内製開発チームではメンバーをすぐに増やしたり減らしたりすることが難しいため、優先順位をきっちりつけていく必要があります。



半年ほど経って開発のリズムには慣れてきましたが、依頼されたものをリリースして、また次の依頼が来てリリースして、という状況にだんだん違和感を覚えるようになります。開発する組織がただ内部になって、受発注の手続きがなくなっただけではないか、と。

転機となった体験があります。ある手続きをWeb上でできるようにして、お客さまのお問い合わせ対応コストを削減したいという開発案件に着手した時のことです。ビジネス側からは「ワンタイムパスワードが有効になっている場合は、手続きの中で解除できるようにしたい」という要望がありました。それに対してあるエンジニアから「ワンタイムパスワードを有効にしているお客さまはとても少ないので、新規開発せずに既存の画面を活用してはどうですか。そのほうが少しリリースを早く出せます」という提案がありました。実際にリリースしても、お問い合わせコスト削減の事業効果は十分に得られ、開発量を減らすことができました。一つあたりは小さな内容でもリリースごとに積み重なれば大きな差になりますし、他のリリースではもっと大きな過剰実装が隠れているかもしれません。

この体験を通して、内製開発の目指すところが見えてきました。依頼通りに早くリリースすることではなく、価値の仮説検証に必要十分な内容を早くリリースして、検証の機会をできるだけ多く得ること。そしてそれを考えるにあたっては、事業に対する深い理解があり受発注関係がない内製化のエンジニアの協力が不可欠だと考えるようになりました。

開発依頼プロセスの改善と「作りすぎない勇気」

福田：目指すところに向けて2つの改善を行いました。1つ目は開発依頼プロセスの改善です。今まではビジネス・デザインのメンバーが詳細に画面仕様を検討してから開発チームに相談を持ち込む形でしたが、エンジニアからの提案がしづらい要因になっていました。そこで「何か開発をやりたい」という段階から開発チームに相談してもらう形に変更しました。エンジニアから実現確率を上げるような提案を得やすくなり、ビジネス・デザイン側の検討の手戻りコスト削減にもつながっています。

2つ目は「必要十分に留める」ということです。たくさんの機能を一つのリリースに詰め込もうとすると、リードタイムは長くなりシステムも複雑化します。一生懸命考えた仕様が本当にお客さまに必要とされ事業価値を生むのかは、実際にリリースしてお客さまに使っていただかないとわかりません。長い時間をかけて開発して失敗する可能性もあります。機能を制限することに怖さを感じるかもしれませんが、次のスプリントで足りなかったら足すという判断ができるのが内製開発の柔軟性です。作りすぎない勇気を持つことが大切だと考えています。

これらの取り組みにより、開発チームからの提案でスコープの縮小・変更を行い、ある機能のデリバリータイムを4スプリント（1ヶ月）から2スプリント（2週間）に短縮できたという成果も得られました。



まだまだ小さな成果ですが、ビジネス・デザイン・エンジニアそれぞれの知見を結集して「必要十分とは何か」を考え抜けるのが内製開発のいいところだと思っています。改善点はまだまだたくさんありますが、1年前・2年前の自分を振り返ると、当時は見えていなかった課題がたくさん見えています。進めば違う世界が見えてくると信じて、一歩ずつ目の前の課題に向き合っていきたいと考えています。

フロントエンド内製化の限界とバックエンド領域への拡大

迫田：ここからソフトウェアエンジニアの視点でお話しします。迫田賀章と申します。福田と同じくリビング戦略部デジタルプロダクト推進グループに所属しており、ソフトウェアエンジニアリングチームでマイクロサービスの推進をしています。新卒でSIerに入社し、事業会社でのPM職を経て、2024年1月より現職です。

内製エンジニアとして最も重視しているのは、プロダクトエンジニアとして事業価値を創出することです。技術力は当然重要ですが、事業価値を最大化するために必要な技術を柔軟に選択すること、そして固有の業務構造やドメイン知識を理解・整理して組織知に昇華することを大切にしています。



内製化当初、改修頻度が多くお客さまに近いフロントエンド領域を最優先として内製化し、バックエンドや基幹システムは東京ガスiネットに開発をお願いしていました。しかし開発・運用を進める中で2つの課題に直面しました。

1つ目は、フロントエンドだけの内製化では開発の柔軟性が高まりきらなかったことです。料金情報を取得するだけでも複数のAPIを呼び出す必要があり、BFF内にドメイン変換層を構築していましたが、バックエンドの改修が発生するたびに組織をまたいだコミュニケーションコストが生じていました。

2つ目は、myTOKYOGASのBFF自体が他のBtoCサービスの共通基盤として機能してしまっていたことです。myTOKYOGASで扱っているエネルギー使用量や料金、ポイントといったデータは他サービスでも利用価値が高く、過去の経緯からBFFにデータ提供の役割を持たせていました。本来はmyTOKYOGASのサービス提供に専念したいところが、他サービスからどれくらいアクセスが来るのか、どういう要件があるのかを気にしながら設計・開発・運用しなければならない状況でした。東京ガスが全社的にDXを推進する中で、データを必要とするサービスは今後さらに増えることが予想されました。

フロントエンド領域の内製化だけでは真の意味で内製化のメリットを享受できないと判断し、BFFに構築されていたドメイン層をマイクロサービスとして切り出して共通基盤化し、バックエンド領域も内製化していくことを決断しました。少人数での運用を考慮してモノレポで進めるなど、ちょうどよい塩梅を日々見極めながら取り組んでいます。

TiDB導入の検証と採用

迫田：マイクロサービスを構築するにあたって課題がありました。myTOKYOGASは数百万のお客さまにご利用いただいており、将来的には1,000万以上のユーザーになる可能性があります。膨大なデータ量と料金確認やポイント獲得などによるアクセスのスパイクに対応できるデータベースが必要でした。

一方で内製チームの状況としては、デジタルネイティブ企業ではないためエンジニアを多く抱えているわけではなく、組織もまだ成長途中です。それでも事業は待ってくれませんし、障害対応やライブラリのアップデートといった保守運用も自分たちで担っています。事業会社でエンジニアをやる以上、単に作って終わりではなく、ビジネスに深く関わってプロダクトが生み出す価値を最大化することに力を注ぎたいと考えています。そうした中でTiDBの導入検証を行うことになりました。



TiDBはスケーラビリティと高可用性を備えた分散型SQLデータベースで、MySQLとの互換性を維持しており、フルマネージドサービスも提供しています。導入にあたって特に気にした点が2つあります。1つ目はMySQLとの互換性が本当にあるのか。過去に互換性を謳う製品で痛い目に遭った経験があり、特定プロダクトへの依存は避けたいと考えていました。2つ目は膨大なレコードの蓄積とスパイクのあるアクセスをさばけるかどうかです。

検証の結果、互換性についてはTiDBであることを意識した実装が一部必要ではあったものの許容範囲内でした。パフォーマンスについても、外部キー制約などの問題をクリアすれば、十分な性能を発揮できることが確認できました。本番プロダクトでTiDBの採用を決定し、現在もTiDBを活用したサービスが稼働しています。

ドメイン知識の整理とフィーチャーチームへの展望

迫田：技術の柔軟な選択と並んでもう一つ重要なのが、ドメイン知識の深い理解と整理です。マイクロサービスにおいてはドメイン境界の見極めが何よりも重要で、見極めを誤ると逆に事業を阻害するシステムになりかねません。ソフトウェアエンジニアチームのメンバーは9割以上が中途採用で、ソフトウェアエンジニアリングの経験はあるものの、ドメイン知識はまだまだ不足しています。そこで重要になるのがビジネスメンバーであるプロパー社員、そして既存システムに精通している東京ガスiネットのメンバーとの共創です。実際にチームにはiネットから出向しているメンバーもおり、ドメインの整理に多大な貢献をしていただいています。



今後の課題としては2つあります。1つ目は、現在技術領域でチームが分かれていますが、フロントエンド・バックエンド・モバイルの垣根を越えたフィーチャーチームを目指していきたいということです。チーム全員が今最優先の課題に集中できる体制を作りたいと考えています。エンジニアの領域を飛び出してビジネスやデザインにも染み出していくのが最終的なゴールかもしれませんが、まずはエンジニアの領域で広く対応できるようになることを目指しています。

2つ目は、myTOKYOGAS以外も含め、より多くのデジタルプロダクトで事業を加速させていくことです。きちんとアウトカムとして成果を出して社内で信頼を積み重ね、内製化の領域を広げていきたいと考えています。

プラットフォームチームの運用負荷削減と基盤強化

荒井：続きまして、荒井から発表させていただきます。荒井亮汰と申します。2025年4月に東京ガスに中途入社し、それまではIT企業でBtoB向けの自社製品の開発に携わっていました。現在はプラットフォームチームに所属しています。

プラットフォームチームはmyTOKYOGASシステムのインフラ関連業務を行うチームで、主にマイクロサービスが稼働するプラットフォームの構築と運用に携わっています。マイクロサービスは現在AWSのECS上で動いており、データベースはTiDBを使用しています。私たちは「サービスの安定」と「開発者の幸せ」を創ることを重視しています。事業に直接価値を届けられるのはソフトウェアエンジニアだと考えており、彼らが最大限の力を発揮できる基盤を作り続けています。



TiDBについてプラットフォームチームとして嬉しいポイントは、無停止でバージョンアップが可能なことと高い可用性・スケーラビリティです。運用コストはほぼゼロで、大きな問題も発生していません。

マイクロサービスのプラットフォームに関しては、昨年アーキテクチャの見直しを行い、EKSからECSに移行しました。当初EKSを選定していたのはマイクロサービス増加による通信の複雑化への対応とチームの学習目的でしたが、実際に運用してみると管理対象が多くバージョンアップ作業も大変で、日々の運用にリソースを取られて他の作業が進まない状況でした。ECSでも要件が満たせることを確認し移行した結果、運用コストを大きく下げることができました。アーキテクチャは一度構築したら終わりではなく、状況に応じて継続的に見直し変化に柔軟に対応することが大事だと考えています。



運用負荷が削減できたことで、インフラコードのIaC推進やAIを活用したインフラコーディングへの挑戦など、基盤強化に時間を費やせるようになりました。

チーム協働と組織のスケールに向けて

荒井：ソフトウェアエンジニアが自律的に動ける環境の整備も進めています。マイクロサービスのリリース作業はソフトウェアエンジニアチーム内で完結するようになっていますし、Datadogを使ったモニタリングでも必要なモニターやダッシュボードはそれぞれのチームで作成してもらい、柔軟に最適な運用を決めています。

組織内での対話と発信も重視しています。プロダクトマネジメントチームが主催する「ワイガヤ会」では、エンジニアだけでなく事業部メンバーやデザイナーも交えて、全員の認識や視点をアップデートしています。プラットフォームチームとしても、自分たちが何をしているチームかを紹介し、他チームからの相談が生まれやすい関係を築くよう心がけています。



現状の課題としては、ソフトウェアエンジニアチームとの役割の線引きが曖昧な部分があります。たとえばECSタスク定義やTerraformコード、GitHub Actionsをどちらのチームが作成するのか、といったことが度々生じます。現在はチームも少なくmyTOKYOGASのみを扱っているため、定例での密な連携で柔軟に対応できていますが、プラットフォームチームが取り扱うプロダクトが増えたり組織がスケールしたりした際には、セルフサービス化など最適な形を定義していく必要があると考えています。

技術選択の柔軟性、他チームとの密な連携、継続的な改善サイクルを回せるのは内製開発だからこそです。技術はあくまでも手段であり、お客さまに素早く価値を提供し続けることが目的だということを忘れずに日々取り組んでいきます。

私たち全員が当事者意識を持って顧客価値・事業価値を追い求めています。私たちと一緒に内製開発で挑戦していきたいという方を募集しておりますので、ご興味のある方はぜひご確認いただけますと幸いです。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
内製開発Summit 2026
※動画の視聴にはFindyへのログインが必要です。