こんにちは、東京ガスのCX推進部デジタルマーケティンググループでテックリードをしております中島です。
東京ガスでは「myTOKYOGAS」のリニューアルプロジェクトにおいて、事業組織内に内製開発チームを立ち上げ、2023年11月にサービスインまでやり遂げました。今では自動テストやCI/CDの稼働はもちろんのこと、内製開発チームにて２週間1スプリントでのアジャイル開発と保守運用までを責任を持って行うことができるようになりました。
今回は我々が初めて内製化に挑んだプロジェクトであるmyTOKYOGASのリプレイスと並行して立ち上げを進めた内製開発チームについてお話ししたいと思います。
内製開発チームの立ち上げ
私は2022年5月に、今の組織で初めてのエンジニアとしてジョインしました。しかし、内製化を思い立ち、チームを立ち上げたのは私ではありません。以下の記事を書いた東京ガスに新卒からずっと勤めているマネージャーの及川です。
もちろん及川はエンジニアではありません。しかし、私がジョインする前から、この及川によってデザインの内製化や外部の方に開発はお願いするものの「自分たちで開発をコントロールできるようにするぞ」という取り組みが行われていました。まさに、開発のことはわからないなりに「本気で内製をやるんだ」という当事者意識や熱量を持って組織変革をしようと試みている最中でした。
私は東京ガスが５社目でさまざまな大企業で内製化に取り組んできました。その中で、うまくいったと感じる開発は、エンジニアとビジネスの距離が近く、何より現場に「当事者意識」と「熱量」があるのです。エンジニアも「ただ作る」だけでなく、「こういう機能どうですか？」と一緒にサービスのことを考える。そんなエンジニアが事業に溶け込んだ職場です。それができる空気が東京ガスにはあるのではないか。そう考えて、面接を受けてみることにしました。
マネージャーの及川との面接は、多くの事業会社で内製化に挑戦してきた私にとって、衝撃的なものでした。「本気で内製化する。DXするんだ。このままではダメなんだ！」という熱量はもちろん、エンジニアではない及川がGraphQLやNestJSなど技術の話を自分からしてくるのです。DXや内製化をマネージャーとして進めるべく、少しでもエンジニアの気持ちを理解し対等に話すために、システム開発の本を読んだり、プログラミングの学習をしたりしていたのでした。この姿に圧倒的な当事者意識と熱量を感じました*1。それが決め手となり、私はエンジニアとして東京ガスに入社することを決め、本格的に内製化をスタートさせることになるのでした。
開発環境の構築
入社してまず問題になるであろうと考えていたのが、エンジニアが開発を行える環境です。まずここが整備されていなければ、開発者体験が悪くなり、エンジニアは東京ガスに来てくれない。何より私も開発ができません。しかし、エンジニアがほとんど勤務していない日系の大企業において、過去の経験からそれらの環境整備が容易ではないと感じており、最初は厳しい環境でも開発を進めていかないといけないことを覚悟していました。しかし、その予想は覆されます。
現在、内製開発チームでは以下のような開発環境で開発を行っています。
| 開発環境 | |
|---|---|
| 開発端末 | Macbook Pro, Windows端末 |
| コード管理 | Github |
| ドキュメント | Notion |
| プロジェクト管理 | Linear |
| デザイン | Figma, Miro |
| コミュニケーション | Slack |
この中で入社後、私が導入を進言したのは、開発端末だけです。それ以外は、元からいるメンバーが自分たちで導入まで進めていました。偶然か必然か、(クリーンアーキテクチャの本を読んでいたり)自ら趣味でシステム開発の勉強をしている社員がおり、「開発にVPNいるよね」や「CIを回すにはGitHub Actions使いたいよね」などを考えて、導入まで済ませてくれていたのです。それだけではありません。開発端末を揃えるのに必要な社内の手続きはすべて巻き取ってくれたのです。エンジニアは開発に集中してもらえるようにしたいと。すでに内製化を進めようとしてくれていたメンバーのバックアップもあり、私はすぐに開発に着手することができました。
開発スコープを決める
「myTOKYOGAS」はざっくりと次のような構成になっています。
| 技術スタック | |
|---|---|
| フロントエンド | React, TypeScript, Next.js, Apollo Client, Tailwind CSS |
| BFF | TypeScript, NetsJS, GraphQL, Redis, MongoDB, PostgresDB |
| テスト | Jest, Playwright |
| インフラ | Azure, AWS |
| その他 | Docker, Github Actions, Terraform, Datadog, PagerDuty, Trivy |
技術スタックは異なるものの、この構成は内製化前も同様であり、このプロジェクトではよりユーザに近いフロントエンドとBFFをまず内製化することでプロダクトの改善をいち早くユーザに届けることができる体制を構築するという判断がされていました。一方で、バックエンドについてはレガシーな基幹システムとのプロキシの役割を果たしていることや東京ガスのドメイン知識が詰め込まれており、一旦内製化は見送られました。しかしながら、バックエンドについては、新機能のためのAPI開発や速度改善のための改修、老朽化したオンプレミスからクラウド環境への移行がシステム子会社の東京ガスiネットにより実施される計画となっていました。
この計画において、内製開発チームが担当する領域はアジャイルでの開発を実施することとなっており、東京ガスiネットが担当する領域においてはウォータフォールで開発を実施することとなっていました。そのため、サービスインは2023年11月と定められていました。開発面以外でも多方面で多くの人たちが動くことになっており、この予定は容易にずらせるものではありませんでした。
みなさん、お気づきでしょうか。そうです。アジャイル開発だけど、ウォータフォールに合わせて「お尻」が決まっているのです。お尻の決まったアジャイル、私はこれを「尻ジャイル」と読んでいます。この状況に対して、以下を行いました。
- 機能の全量をざっくりでも良いので、まず出すこと。
- MVPを定義し、現時点で完全に的外れな開発スケジュールとなっていないことを確認すること。
- スプリント毎にベロシティを計測し、開発が間に合わないと判断されるものはROIに基づいて優先度を判断し、優先度が低いと判断された機能の開発はサービスイン後とすること。
そして、もう一つ。我々がやりたいことは、ユーザに柔軟かつ迅速に価値を届けることです。サービスイン後のチームで、アジャイル開発を行うためには、DevOpsの実現は必須。その根幹となる自動テストは必ず実現する必要があると考えていました。
内製をしている以上、無尽蔵にエンジニアを増やして、スケジュールの問題を解決することはできません。東京ガスには、これらを論理的に説明することで、理解してくれる文化がありました。これらの話をした時、「何とかしろ！」ではなく、「今取れる最善策は何か？」を一緒に考えてくれる文化がありました。開発の話だからといって、その解決をエンジニアに丸投げしてくることはありませんでした。プロジェクトの状態を常に可視化して現状を把握をできるようにしてくれたメンバー、サービスインに間に合わない機能が出てきた時、関係各所に迅速に調整に動いてくれたメンバーなど、開発以外のところで多くの人たちが力を貸してくれました。彼らの支援もあり、私はフルスロットルで開発のことに集中することができました。結果的には、開発を進めながら適宜状況判断を行い、いくつかの機能をサービスイン時は実装しないと判断することで、スケジュールに収まりそうな形で開発を進めていくことができました。
開発体制の構築とサービスインへ
ある程度開発規模が見えてきた時点で開発メンバーは、私と東京ガスiネットから出向してきてくれたメンバー、フリーランスの数名という状況でした。開発体制においては、以下の課題が見えてきました。
- インフラを構築できる人材がいない
私自身もAWSで環境構築の経験はあるのですが、主戦場はアプリケーション開発です。加えて、すぐに使えそうなクラウド環境がAzureしかなく、Azureの勉強を今から始めながら、アプリの開発をしていては、インフラ構築が間に合いそうにありませんでした。そこで、当時AWSに勤務していた杉山*2を勧誘しました。「私は会社の外からDXは起こすのは難しいと考えている。東京ガスに面白いマネージャーがいる。ここであれば、内製化を成功させられると確信している。」と。マネージャーの及川とも会ってもらい、その熱量に触れて杉山が東京ガスに来てくれることになりました。それ以来、彼の口癖は「これからはGAFAもいいけど、GASの時代だ！」になっています。
- 既存のシステム知識やドメイン知識が足りない
当然ですが、リプレイスには既存のシステムの知識、ドメイン知識が必須でした。私のような中途のエンジニアには、それらの知見がありません。そこで、既存のシステムに詳しい方に声をかけ、チームに参画してもらいました。そこに加え、すでに参画してくれていた東京ガスiネットのエンジニアにも追加で参画していただきました。彼らの知識や人脈によって、既存システムを少しずつ解きほぐしていきました。特に東京ガスiネットのエンジニアが内製開発チームにも参画し、既存システムとの接続のためのコミュニケーションをとってくれたこと、日々のシステムエンジニアとしての業務で獲得していたドメイン知識を使ってそれをコードに落としてくれたこと、そして内製化という急進的な取り組みにも関わらず惜しみなく既存のシステムの情報やドメイン知識を提供してくれたバックエンドの開発メンバーの協力は今回の内製化成功の一つのキーポイントになっています。
- そもそもエンジニアが足りない
開発当初、我々が作るのはBFFとフロントエンドの領域であり、BFFは画面描画などのための薄いロジックだけがのっていることを想定していました。しかし、実際に見てみると、長い歴史の中でBFFと呼ぶには画面描画などに関係ないロジックをあまりに持ちすぎていることに加え、BFFから呼び出すバックエンドAPIそのものが画面と密結合してしまっているものなどもあり、「料金」などのようなエンティティに相当するような情報を構成することも難しい状況でした。引き続きファットBFFになることは泣く泣く受け入れたものの、これをそのまま別言語に置き換えるようなリプレイスをしてしまっては、何かをやりたいと思った時、その改修がウォータフォールで開発を行うバックエンドにも及んでしまう。ウォーターフォールとアジャイル開発が混在するシステム開発において、その２つの結合度が高くなると、アジャイル開発はできない。完全には防ぐことはできなくても、それは緩和しないといけないと思いました。しかし、それらの改修もするとなると、それなりの工数になることが想定されました。そこで、社員のエンジニア採用を進めるとともに、フリーランスのエンジニアにもご参画いただき、開発体制を増強していきました。
こうして内製化へのピースが揃い、2023年11月のサービスインに向けて開発が加速していきました。
サービスインと組織に起きた変化
その後、新しいmyTOKYOGASは2023年11月に予定通りサービスインし、自動テストやCI/CDの稼働はもちろんのこと、内製開発チームにて２週間1スプリントでのアジャイル開発と保守運用までを責任を持って行うことができるようになりました。
しかし、一番の成果は内製化に成功したことではなく、プロジェクトを通して、「エンジニア以外のメンバーがシステム開発を他人事と捉えないようになった」こと。そして、「エンジニアがただ作るだけではなくて、プロダクトがこうすればよくなるのでは？と、ビジネスのメンバーと対等に議論し、チーム全体で良いプロダクトを作っていく」というエンジニアとビジネスメンバーが溶け合った文化ができたことだと思っています。私は「エンジニアが事業に溶け込み、プロダクトが今までにない速度で柔軟に価値提供できるようになり、その結果現場に熱量が生まれ、働き方や文化が変わる。そして、そこから生まれるプロダクトも変わる。そして、顧客体験も変わっていく。」これが巷でいうDXではないのか？と思うのです。文化や働き方を変えなくてはDXなんてできないのではないかと。
プロジェクトと並行して進めていた採用活動で、最初は私しかいなかったエンジニアも徐々に増え開発チームも大きくなってきました。現在は優秀なエンジニアが参画してくれたことで、myTOKYOGASの開発チームを彼らに任せるようにしています。しかし、時折開発チームのプランニングやレトロスペクティブを覗き見することがあります。今もプロジェクトを通して生まれた文化は失われておらず、全員がプロダクトをよくするには？チームがよくなるには？ということを議論し、改善を進めています。そこにはやはり当事者意識と熱量があります。その文化がある限りmyTOKYOGAS開発チームは、これからどんどんユーザの体験を変えていってくれるはずです。
さいごに
myTOKYOGASの内製化で、Terraformによってインフラ構築はコード化され、CI/CDで自動テストや脆弱性診断が動き、デプロイも自動化されました。Datadogにアプリケーションは常に監視され、何かあればPagerDutyですぐにエンジニアに通知がきます。これらのテクノロジーは、我々がユーザに迅速かつ柔軟に価値を届けることのできる環境を提供してくれました。しかし、結局はそれらの環境があっても、プロダクトに関わる人たち全員が当事者意識を持って「どうすれば顧客体験がよくなるか」を考え、これらを使いこなせるようにマインドセットと働き方を変えなければ、意味がありません。そして、それはビジネスを行う自分たち次第であり、「外からDXが必要ですよ。」と言われて変われるものではないと思っています。なぜなら、その「DXが必要」という言葉には熱と当事者意識がない。それを持てるのは当事者である自分たちだけです。技術の導入やエンジニアの採用だけでは、DXも内製化も上手く行かない。DXも内製化も成功させるには、エンジニアもビジネスメンバーもデザイナーも、全員が当事者意識を持って、同じ方向を向ける文化を作らなくちゃならないのだということを私自身改めて感じさせられました。
東京ガスには及川というマネージャーがいました。ここから生まれた「このままじゃダメだ。変わらなくてはならない。」という当事者意識と熱量。これが杉山の参画、ドメイン知識を持ったiネットメンバーの参画、その後の続々と参画してくれたエンジニア、そして現場への当事者意識と熱量の伝播につながっていきました。これらが全部繋がったからこそ、東京ガスの内製化の取り組みは成功させることができました。この熱量と当事者意識がなければ、どこかで成功へのピースが欠けて内製化は失敗していたのではないかと思います。
我々はまだまだ小さな組織で、myTOKYOGAS内製化は、東京ガスがデジタルの世界でも選ばれる会社であるための、はじめの一歩です。しかし、大きな一歩だと思っています。
入社後わかったことですが、アジャイル開発や内製化の取り組みは我々のチームだけでなく、他の部などでも取り組まれているところもあるようです。東京ガスのいろいろなところで、開発を「手の内化」しようという動きが生まれてきているのではないかなと思います。我々も現場から生まれた熱量と当事者意思を絶やさぬよう、東京ガスのDXを進めていきたいと思います。
