こんにちは！いい生活エンジニア採用・広報担当の黒江です🎑
秋めいた季節になり、少し肌寒くなってきましたね🍂
みなさまいかがお過ごしでしょうか？

いい生活のプロダクトを支えるメンバーと、CTO松崎さんとの対談をお届けします！

CTO対談第5回の今回は、データプラットフォーム本部の多田さんとCTOの松崎さんに、いい生活アカウントについて語ってもらいました！

今回の対談は3つの記事に分けてご紹介させていただきます。
こちらの記事は前編です！

いい生活アカウントとは

当社サービスの認証基盤を提供する

黒江：
いい生活アカウントとはどのようなプロダクトか教えてください。

多田さん（以下 多田）：
一言でいえば「いい生活のサービスにおける認証基盤を提供している」プロダクトです。
ユーザーから見える機能だと、いわゆるログイン画面や、ユーザー情報の管理コンソールをサービス横断の形で提供しています。

身近なものだと Googleアカウント などがイメージしやすいかもしれません。
Googleアカウント 1つで Googleカレンダーやスプレッドシート、Meets など色々なアプリにアクセスできるのと同じように、管理を一元化しつつ、いい生活アカウント1つで様々な当社サービスにシングルサインオンできるようにすることが、いい生活アカウントというプロダクトの1つの大きな役割です。

少し特徴的なのは、当社の場合だとユーザー個人のプロフィール以上にユーザーの所属情報が大事、ということだと思います。
当社サービス、というよりは BtoBとしては、どの会社のどの部署の誰なのか、というのがサービスを利用いただくうえでとても大事なので、それを管理する機能もブラウザアプリとして提供しています。

これに関連して、いい生活アカウントにはもう一つ大きな役割があります。
それはいい生活アカウントで管理しているユーザー情報を、当社の各サービスに受け渡すことです。
実際にコードベースで見ても、全体の60％以上はバックエンドのコードが占めていて、これはユーザーが直接見る部分よりもバックエンドの管理機能のほうがボリュームとしては大きい、ということです。

歴史的なところでいえば、いい生活では不動産マーケットの様々なユースケースに対応するために、機能も形態も異なるサービスを個別に提供してきています。
ですが、ユーザー管理やログインという文脈でいうと、※1 従来のプラットフォームを利用しているプロダクト群と、※2全く独立したプロダクト群の2種類に大まかに分かれていました。

これは当社のサービスを横断的にご利用になるユーザーからすると、「いい生活の中でアカウントが分かれている」ので不便ということになり、管理上も手間になってしまうため、これらを一元化すること、統一していくことが今のいい生活アカウントチームの1つの命題でもあります。

当社のプロダクトで共通の ID /パスワードを使えるようにするために

松崎さん（以下 松崎）：
いい生活アカウントを作ろうと決まったのが2020年で、ファーストローンチが2021年の2月頃。
最初は Square の認証基盤だったけど、Square から分離/独立して始まったんだよね。

黒江：
いい生活アカウントって、Square から分かれたものだったんですね。

松崎：
そう、もともとは Square 専用だった。
でもいい生活賃貸クラウド物件広告（以下 物件広告）や、いい生活賃貸クラウド営業支援（以下 営業支援）の Web化 を進めていくうえで、Square にアカウントを持っている人が、当社で提供しているその他のアプリに対して同じ ID/パスワードで使えるようにしたいという案が出てきた。

そのためには、Square そのものの機能と、認証機構を分離させる必要があったんだよね。

物件広告や営業支援のような最近出している Webアプリ だと、その裏側には One API Platform が管理している「○○法人の△△店舗に所属している◎◎さんが使っています」というような不動産会社の組織情報が機能を提供する上で必要になってくる。
一方で、当時 Square は不動産会社向けの物件情報の検索機能がメインだったので、気軽にアカウント登録して使ってもらいたいという思いもあり、そこまで細かな情報登録をしなくても使えるようにしていたんだよね。
そんなわけで、Square 以外のアプリと連携するには当時の認証機構では情報量が不十分だから、しっかり整備するために Square のチームの一角で作るのではなく、別にプロダクトチームを設けていくことになった。

そして2022年の1月頃の、いろんなアプリと連携させていくフェーズに入ったタイミングかつ、当社のブランドリニューアルの話が社内で出始めて「プロダクトを作り直そう」というタイミングで、プロダクトオーナーとして多田くんを任命したんだよね。

黒江：
なぜ多田さんにお任せしようと決めたんですか？

松崎：
多田くんは彼自身や社内にとって新しいものや、まだ解像度が高くないものに対しても、任せられたら受け止めることができるからかな。

多少大変なことがあっても、何とか耐えるんじゃないかなって。
2019年の ※3 dejima 初期の Kubernetes を初めて導入したときがそうだったから、今回もやり遂げてくれるだろうと思ったんだよね。

あとは、多田くんは元々 One API Platform や dejima にも携わっていたので、そのサービスが止まってしまうと他のプロダクトに対しても大きな影響を与えてしまうようなものを扱う環境でやってきた経験もある。
安全性や安定性・可用性といった非機能要件にちゃんと意識を向けて開発をすることの重要性や、それらを担保するためにモニタリングの仕組みも一緒に作り込むことが重要、という感覚は、当社のデータプラットフォーム本部のメンバーは強く持っているからね。

多田くんがプロダクトオーナーになった当時って、ユーザー数はどれぐらいいたんだっけ？

多田：
MAU で7000ぐらいでしたね。

松崎：
それぐらいだね。そこから MAUベース で1年半で2倍弱に増えてるってことだね。

新しい技術の導入

データモデルの整理

松崎：
ちなみに、多田くんが引き継いだ時点で基盤そのものは Auth0 になってたっんだっけ？

多田：
最初の時点からなっていましたね。

松崎：
なるほどね。
そうすると作り替えは、様々なアプリから呼び出すときに、どういうコンポーネントが必要なのかというところから考えて、分解再構成した感じ？

多田：
そうではないですね。

松崎：
そうではないのか……。

多田：
呼び出し元の都合というよりは、どちらかというと、データモデルを整理する必要がありました。
当時の Square 用の比較的単純なデータモデルをそのまま引き継いで、他のアプリケーションに適用するのは無理だと。

松崎：
なるほどね。

多田：
そもそも当時の Key-Value Store では厳しかったですね。

松崎：
バックエンドは、一番最初は Firebase だったよね。

多田：
そうですね。Firebase の Cloud Firestore だったものを RDBである PostgreSQL にしたところが一番大きな転換だったと思います。
PostgreSQLにするのは結構時間かかりましたね。1年ちょっとかかりました。

松崎：
当社のサービス全体の認証基盤として使うために、法人情報や、店舗・組織情報、そこに誰が所属してるかというデータをデータモデルとして扱えるようにするには、RDB の方が良いものね。

認証情報と、プロフィール情報の2種類の機能を提供する必要があるので、データモデルの変更に伴ってそれに合った形に変更していく必要があった感じか。

多田：
そうですね。

松崎：
あと、いわゆる OIDC 的な文脈で言うと、IDトークン やアクセストークンなどを発行する部分は Auth0 に完全に委譲してしまってるものの、トークンには実はあまりたくさんの情報は含まれていないよね。

当初は、IDトークン に情報を埋め込んでしまえば別途API を叩く必要はないという設計で比較的多くの情報をトークンに埋め込んでた。

でも使う側としては、それだと再度トークンを取得しないと最新の情報がとれないので不便、と言う話になり、エンドポイントを準備し公開することにした。
だから今は「プロフィール情報は API を叩いて取りに来てください」というモデルになっているんだよね。

多田：
その方が各サービスに都合が良いので、現状はそうなってます。

開発言語の変更

松崎：
あとは開発言語が大幅に変わっているよね。
引き継いだ当初はどういう構成だった？

多田：
全部 TypeScript でした。
バックエンドは TypeScript で、Express を Cloud Functions for Firebase で動かすというもの。
フロントが、まだ Vue2 で TypeScript でした。

松崎：
当時は、FireBase +サーバーレス系+ SPA みたいな構成だったよね。Typecript で Vue を使っていて。
でも今は、この構成は残ってないよね。

多田：
何も残ってないですね。残っているのは Auth0 だけです。

まず、 Vue2 をフロントで使っていましたが、社内の雰囲気を見ても React 一択でしょうとなりました。
Vue2 を Vue3 にするよりも、React にするモチベーションの方が高かったです。

松崎：
ちなみに今までの Vue で作っていたアプリケーションを React に移植したというよりも、もう1回ユースケースから考えて、React で書かれたアプリを新しく作った感じだよね。

多田：
そうですね。
配置や色味といった見た目は似ていますが、それ以外は何もかも違いますね。
また、KVS のような単純なデータストアでは、当社のお客様のデータを表現することが難しいので RDB を使うことになりました。

松崎：
チューニングのしやすさなどを考慮するとそうなるよね。
とはいえ、将来的なデータの規模としても、件数は恐らく100万レコード程度で止まるだろうけど……。

多田：
BtoB のデータとしてはそうだと思います。シェアが100%になったとしても、日本の宅建免許事業者（法人）数は13万弱なので。

松崎：
もし1000万の大台に行くと、単純計算で国民の12人に1人ぐらい不動産屋さんということになるのでそれは考えにくいよね。
ただ入居者やオーナーなどの個人や、不動産に関連した周辺事業者も視野にいれると、1000万人規模になる可能性はあるかもね。

多田：
あと、バックエンドについては開発言語を Rust にして、Cloud Run 上で動いています。

松崎：
コンテナ化した上で複数のエンドポイントをまとめてデプロイしているよね？

多田：
そうですね、モノリス化しました。

松崎：
CloudFunctions が多数並んでるのは、細かくデプロイできるけど、それはそれで管理が大変だものね。

多田：
そうですね、それで大変な目に遭ってる人をたくさん見ていますし…。

続きが気になるところですが、今回はここまでとさせていただきます！
読んでいただき、ありがとうございました😊

いい生活では新卒/キャリア採用を行っております🧑‍💻
エンジニアとデザイナー職は2025年の新卒採用も始まっております！
以下から気軽にご応募ください！

また、いい生活公式noteの「いいnote」のフォローもお願いいたします！

次回はこちらの対談の続きです！
なぜ開発言語を Rust にしたのか？など熱く語ってもらいました🔥

それでは今回はこちらで失礼します！

撮影：杉山 泰之