見出し画像

myTOKYOGASの内製開発〜フロント編〜

東京ガス内製開発チーム

はじめに

はじめまして！2023年3月より東京ガスの内製開発チームに参画した中嶋と申します。現在はCX推進部デジタルマーケティンググループで、内製開発チームのフロントエンド開発(Next.js, React)におけるリーダーを務めております。本エントリでは、現在の内製開発チームの体制やフロントエンドチームの開発体験について可能な限り詳細にご紹介できればと思います。なお、内製開発チームの技術スタックの概要などについては、中島のエントリをご覧ください。

myTOKYOGASとは？

myTOKYOGASは、毎月のガスや電気の使用量や料金を確認できる登録無料の会員サービスです。東京ガスが提供する各機能のご利用に応じてたまったポイントを交換したり、省エネにつながる便利な情報や生活に役立つ情報を提供しています。

内製開発チームの体制について

現在、私の所属する内製開発チームは、myTOKYOGASのリプレイスを行っています。内製開発のエンジニアチームは、大きくフロントエンド、BFF、インフラの3つのチームで編成しており、フロントエンドの開発チーム（以降、フロントチーム）は、社員2名と業務委託の方3名、合計5名で構成されています。

内製開発チーム体制

チーム編成は担当領域ごとに分かれていますが、コードベースはモノレポで管理しているため、例えばフロントチームのエンジニアが関連する機能についてBFFやインフラを一時的に対応するといったチーム横断的な連携もしやすい構造にはなっています。最近ではBFFからフロントチームへのメンバー移動も段階的に行なっており、担当領域に縛られない柔軟な体制を目指しています。

補足：プロダクト全体の体制について

⚠️ 上記にて内製開発チームの体制を紹介しましたが、プロダクト全体で見ると非常に規模が大きくなります。内製開発チームでは、主にプロダクトのフロント部分 (Frontend / BFF) を担当しており、その後ろにさらに大きなバックエンドチームがいます。人数では純粋な規模の比較はできませんが、内製開発チームは合計で20名弱なのに対し、バックエンド側には100名程度（！）の方が関わっており、ここは東京ガスグループのTGアイネットが中心となって開発しています。

さて、体制についてご紹介したところで、続いてフロントチームの開発をどのように進めているかについて、深掘りしてご紹介したいと思います。

タスク管理

まず開発のタスク管理については、Linearというツールをメインで利用しています。基本的には各チームごとにタグを切ってイシューを管理するような運用になっていますが、開発する機能によっては複数のチーム間で連携しながら取り組むこともあります。そのような場合は、例えばBFF側の修正が完了しないとフロントチームがそのイシューに対応できないといったような依存関係が発生してしまうこともあります。Linearには個別のイシューごとにBlocked byまたはBlockingといった依存関係の方向性を示す機能が備わっているため、このようなチーム横断的に対応が必要なイシューであってもデフォルトの機能だけで管理することができます。

m+bのショートカットキーを入力すると上記のようなモーダルが表示され、完了待ちの他のイシューと紐づけることができます。

他にもチーム単位ではなく期限に基づいたプロジェクト単位での管理も可能です。また、個別のイシューごとにPriorityを付与して優先度を設定したり、豊富なショートカットキーが用意されていたり、進捗状況を直感的にグラフで可視化する機能などが搭載されており、全体的に使いやすい印象です。今後は内製開発チーム内だけでなく、社外チームとの間で発生するようなタスクについても可能な限りLinearで一元的に管理して、コミュニケーションのコストを減らしながらうまく連携していくことが重要だと考えています。

ドキュメント管理

各チームごとの開発方針や業務フロー、オンボーディング資料などのドキュメント管理については、基本的には全てNotionで一元的に管理するようにしています。社内外問わずチーム間の連携を強化していく上で、属人化させると業務フロー上のボトルネックを生むようなリスクがあるものについては、ドキュメント化して整備することが重要だと考えています。もちろん、ドキュメント化する作業にもそれなりに多くの時間を割く必要があると思います。そのため、例えば、BFFのREST APIの管理にはOpenAPIを使ったり、フロントエンドのコンポーネント管理にはStorybookのアドオンを使うといったように、スキーマやコードベースからドキュメントを自動生成できるものは最大限に活用しつつ、字面だけだと伝わりづらい複雑な要件やサービス固有のドメイン知識などについてはdraw.ioなどの描画ツールを適宜活用してNotionにまとめるような形を模索しています。適材適所で何をドキュメントとして整備しておくべきかは費用対効果を意識してチームのメンバーと相談しながら進めています。

このような長期的なリターンを最大化していくために目の前の短期的なコストの代償を払うような取り組み（技術的負債を減らすリファクタリング、など）についても、チーム内で日々議論されるテーマになります。プロダクトをリリースして終了ではなく、その時点からが本当の意味でのスタートであり、なし崩し的にその場限りの対応をするのではなく、長期的な視野で内製開発の基盤を整えていくことを意識しながら最善の対応を考えていくことが重要だと思います。

フロントチームの開発について

利用している技術の紹介

システムの担当領域は、社外に開発を委託している部分を含めて大きくフロントエンド、BFF、バックエンドに分かれています。我々の内製開発チームが担当する領域は、BFFまで含めてフロントエンドと呼ぶことがある（分かりづらくてすみません！）のですが、ここではあくまでブラウザ上で動くお客さまが直接触れる部分をイメージして頂ければと思います。続いて、フロントチームが利用している技術について触れたいと思います。

利用している技術

フロントチームが利用する土台となるWebフレームワークはNext.jsで、GraphQLのクライアントライブラリはApollo Clientを採用しています。また、アプリケーションレイヤのコードはBFFも含めて全てTypeScriptで書かれています。TypeScriptなどの静的型付け言語を利用する動機としては、一般的にはコーディングする際に型推論が効いて自動補完できることや、コンパイル時の型解析をCIのパイプラインで自動化して未然に型の不整合によるエラーが発生するリスクを最小限に抑えられること、などが挙げられるかと思います。また、本プロジェクト固有の動機としては、GraphQLのスキーマからアプリケーション用のコードを自動生成するライブラリ（graphql-codegen）を利用しているためTypeScriptの型定義も同時に出力できて、APIのインターフェースの型安全を容易に保証できることなども挙げられます。フロントはBFF側で定義されたGraphQLのスキーマをシンボリックリンクで参照し、スキーマの整合性を担保しています。フロントでモックデータを作成して単体テストを作成する際などにも型の不整合があればすぐに気付くことができ、非常に便利です。

Github Actions

CIのジョブは、PR(Pull Request)の作成をトリガーにGithub Actionsで実行しています。またジョブの内容は静的型検査だけでなく、単体テスト、E2Eテスト、スナップショットテストといった各種のテストや、Storybookのビルド、SonarCloudによるコード品質チェック、などが実行されるようになっています。また、Chromaticを導入することで、Storybook上のUI差分を自動検知して、デザインチームのメンバーにレビューを依頼するといった運用を行なっています。フロントのテストコードの詳細については、また別の記事で詳細にご紹介できればと思います。

GraphQL API

従来のRESTとの対比においてGraphQLで着目すべき点としてよく知られているものは、クライアント側でより柔軟なクエリを作成できることだと思います。従来のRESTの方式だとAPIのレスポンスの値に応じて再度HTTPリクエストを複数回投げてページに表示するデータを取得しなければならないことがあります。一方、GraphQLではクエリで階層的な入れ子の構造を表現できるためスキーマの設計次第では異なるエンティティのデータを取得する際にも1回のHTTPリクエストのみで目的のデータを全て取得するすることができます。このようなGraphQLの特性を上手に活用できれば、いわゆるシングルページアプリケーションにおけるクライアントサイド・レンダリング時に発生するAPIの通信回数を減らすことも可能です。ただし、現状ではデータを保有するシステムのAPIにも課題があり、BFFのレイヤで適切なスキーマ設計が難しかったり、BFFの枠を超えてファットな処理を抱えてしまうケースがあります。しかし、この場ではお伝えすることは出来ないのですが、そうした課題をドラスティックに解決するような計画も待っていたり（！）、今後はこのような組織の構造的な課題を根本から解決していくような取り組みにも、エンジニアとして積極的に関わり、挑戦していくことが可能です。エンジニアとしては技術面だけでなく組織的な課題にも向き合いながら成長していけるようなキャリアパスを描けるような環境が用意されていると思います。

技術戦略

フロントチームのメンバーのうち社員は自分も含めて2名でどちらも中途のエンジニアであり、まだまだ社歴も浅く業務に関する知識が十分だとは言えません。そのため、直近で取り組むべき重要な課題の1つとしてプロダクトに関するドメイン知識を整理することが挙げられます。こちらは私が他チームとの窓口となって主体的にドキュメントの整備に取り組んでおります。また、業務委託のエンジニアの方々に関しては、メンバーの入れ替わりが多いといった事情もあるため、新規メンバーが参画した際にはスムーズに開発に着手できるような体制を整えておくことが長期的な観点では重要になります。フロントチームの定例ミーティングは、概ね週2回の頻度で実施しており、その際に現状の課題や共通認識として持っておくべきテーマについて日々メンバーと議論を重ねています。具体的には、コンポーネントの設計（ディレクトリ構成）の話であったり、コンテキストを用いたグローバルな状態管理、不要なレンダリングを削減するためのキャッシュやメモ化の戦略、などを日々議論しています。そのような地道な議論の積み重ねで得られた知見を蓄えていきながら、フロントチームのメンバー間で合意形成した基本的な開発方針を整備していくことで、より良い開発体験を実現していきたいと考えています。

さいごに

本エントリでは、myTOKYOGASの内製開発チームの現状の取り組みについて、フロントチームの活動を中心にご紹介させて頂きました。弊社の内製開発チームでは、現在ソフトウェアエンジニアのポジションにて積極的に採用を行なっています。もしご興味があれば、弊社のWantedlyのページも参考にして頂けれたら幸いです。また、ここでは詳細に書くことができなかった技術的な話や、もう少し本音の部分を踏み込んで聞きたいなどのご関心があれば、ぜひカジュアル面談の機会にてご説明させて頂ければと思います。一緒により良いプロダクトを開発していきましょう！

最後までお読み頂きありがとうございました。