はじめに
モバイルアプリチームのリードを務めている北沢です。
myTOKYOGASは2022年5月から内製化に着手し、Webアプリについては2023年11月に内製化を完了しました。一方、モバイルアプリについては、さまざまな事情により内製化が先送りになっていました。myTOKYOGASの内製化の経緯については、以下の記事をぜひご覧ください。
今回は、Web アプリの内製化以降に取り組んできたモバイルアプリの内製化と、2026年1月のリリースに至るまでの経緯についてお話ししたいと思います。
モバイルアプリ内製化の経緯
モバイルアプリ内製化チームの立ち上げ
先に述べた通り、myTOKYOGAS の Web アプリは 2023 年 11 月に内製化が完了しました。その後、Web アプリチームからのれん分けする形でモバイルアプリの内製化チームが発足し、私がリードエンジニアを務めさせていただくことになりました。
モバイルアプリの開発休止
myTOKYOGAS の開発チームは、「技術力を大事にしながらも自らが携わったプロダクトが事業や会社に貢献することを楽しむ」というプロダクト志向を大事にしています。
その中で、myTOKYOGASの開発チームのリーダーから「マイクロサービスの開発が最重要案件となったため、一度モバイルアプリの開発を停止し、マイクロサービスの開発に参画してほしい」との打診がありました。そのため、モバイルアプリ開発チームは一時解散し、メンバーは別の開発チームに一時移籍することになりました。
マイクロサービスの取り組みについては、以下の記事がございますので、ぜひご覧ください。
設計を進めている最中であったこともあり、一度チームを解散することになるのは残念でしたが、この時マイクロサービスチームに入り、マイクロサービスの開発に関わったことは、技術面の成長はもちろんのこと、このあとお話するモバイルアプリチームの再結成とモバイルアプリ内製化再開時に、システム全体を見通し、設計を行うための貴重な経験となりました。
モバイルアプリチームの再結成とモバイルアプリ内製化の再開
マイクロサービスは2024年度に無事リリースされました。その間に、myTOKYOGASの開発チームに多くのメンバーが参画してくれました。そして、2025年度再度モバイルアプリチームが再結成され、内製化が再開されることになりました。私は、モバイルアプリチームに復帰し、再度チームのリードエンジニアを務めさせていただくことになりました。
新チームでの開発とリリースまで
モバイルアプリチームの人数が増えたため、まず全員が同じ品質基準・設計思想で開発できるよう、アーキテクチャガイドラインやコーディング規約を整備しました。
その中でまとめていたアーキテクチャについて簡単にご紹介します。
ディレクトリ構成や Lint のような設計やコード品質を守る仕組みに関しては機会があれば別ブログで紹介させていただきます。
【システムアーキテクチャ】
システム全体の構成としては、モバイルアプリ（Flutter）が BFF（Backend For Frontend）と通信し、BFF がバックエンドのマイクロサービス群を束ねる形になっています。BFF との通信には主に GraphQL を採用していますが、一部の API では REST も併用しています。
この構成により、アプリ側は BFF が提供するインターフェースのみを意識すればよく、ビジネスロジックをサーバー側に寄せつつ、アプリは UI 表示と状態管理に集中できる設計にしました。
【モバイルアプリのアプリケーションアーキテクチャ】
フレームワークには Flutter を採用しています。アーキテクチャは Store パターンを採用し、単方向データフローによる状態管理を基本としています。
- ローカルな UI 状態（例: トグルの ON/OFF）は Widget 自身が管理
- API から取得するデータなどのアプリケーション状態は Store に集約し、Riverpod で管理
- Store は状態の保持と更新を担い、API 呼び出し等の副作用もこの層で処理（責務を分離し、UI 層は UI 表示とユーザー操作に集中）
加えて先のシステムアーキテクチャで述べた通り、BFF がモバイルに最適化された API を提供してくれるため、アプリ側に持つビジネスロジックを最小限に抑えられ、表示の正しさ（VRT）やユーザー操作フローの検証（シナリオテスト）に注力できる設計としました。
この「設計」と「共通ルールづくり」を整備する際に、マイクロサービス開発へ参画した経験が良い効果をもたらしました。具体例として、アプリ内のスロット機能はマイクロサービス基盤と連携して動作しており、2024年度にマイクロサービスチームへ横断的に所属したことで、API の設計思想やエラー分類の考え方を理解した状態で BFF とアプリ側の設計に臨むことができました。この経験は、アプリと BFF 間のエラーハンドリングの整合性や、Store での状態管理ポリシーを決める際に大きな助けになりました。
こうして共通の土台と設計方針を持てたことで、開発方針も具体性を持って整理でき、規約やガイドラインの整備にもつながりました。その上で、チーム全員が構成を理解し、一丸となって開発に取り組み、無事リリースを迎えることができました。
当然ですが、これは私一人の力で達成できたものではありません。ガイドラインをもとに丁寧にコードを書き、レビューし合い、改善を重ねてくれたチームメンバーの貢献があってこそ実現できたものです。この場をお借りして、チームのみなさんに感謝を申し上げます。
myTOKYOGASモバイルアプリのこれから
無事に内製化が完了しましたが、内製化そのものは目的ではなく、日々変化するビジネス要望に柔軟に対応し、より大きな事業貢献をするためのスタートラインに立った状態だと考えています。Webアプリだけでなくモバイルアプリにおいても、お客さまに役立つ機能を積極的に実装していくことで、myTOKYOGASという東京ガスにとって貴重なお客さまとの接点を有効活用し、より大きな価値を提供していけると考えています。今後は内製化によって得たアジリティを活かし、お客さまに価値を感じていただける機能をスピーディーにリリースしていきたいと考えています。
おわりに
今回、モバイルアプリの内製化が完了したことで、myTOKYOGASというアプリケーション全体で迅速な開発が行える体制が整いました。今後はmyTOKYOGAS全体で、よりお客さまに価値を感じていただける機能を提供していきたいと考えています。 また、今回私自身は、モバイルアプリチームとマイクロサービスチームの両方に所属したことで、幅広い技術スタックやシステム構成を把握しながら、組織にとって最適な構成とは何かを考えて内製化を進めることができました。myTOKYOGASチームとしても、内製化が成熟してきた今、Webやモバイルといった区分けにとらわれず価値提供ができるフィーチャーチームや、全体最適を追求するLeSSのような開発体制への進化を目指しています。myTOKYOGASというプロダクトはもちろんのこと、エンジニア個人として、開発チームとしても、より大きな貢献ができるよう成長していきたいと考えています。
当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！
ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！ tokyo-gas.snar.jp
