こんにちは！いい生活エンジニア採用・広報担当の黒江です🐿️

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

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

前編・中編の記事は以下よりご覧ください💁‍♀️

高いサービス品質を保つために

安定性や可用性の担保

松崎：
現状の当社の各サービスの利用者数ベースや売上ベースで見ると、全体の8割ぐらいはいい生活アカウントベースで認証されるものになったよね。
そうすると必然的に、安定性や可用性という観点がより大事になる。

仮にいい生活アカウントがサービスダウンしちゃうとそもそも認証ができないので、当社の全てのサービスが使えないのとほぼ同義だから、控え目に言っても地獄のような状態になってしまうよね。

さっきも話した 「Rust は正解だったのか？」みたいな観点の別の評価軸として安定性の側面を見た場合、Rust で書かれた Cloud Run 上で動いている API が大きくダウンしたことは今のところないよね。

多田：
ないですね。
バグによるものなどは一旦置いておくとして、例えばキャパシティ的な意味では、とても小さいインスタンスで今のところ十分に捌いています。

松崎：
応答スループットとかも期待通り？

多田：
そうですね。我々の責務の範囲ではこれぐらい出ていればそんなに不満はないだろうと思います。
もちろんもっと早くできる分には早くするべきなんですけど、十分なものが出ています。
そういう面だと、ここまで問題なく動いているサービスができました。

あとは、サーバーレスにできたのも大きいのかなと思いますね。
Rust のプログラムの出来がよくて十分に高速で十分にリソース効率もいいので、Cloud Run は基本的には1インスタンスで捌けちゃうんですが、実際オートスケーリングを1日に数回することもあって、たまに2インスタンスにスケールアウトして一時的に稼働してることもあります。

松崎：
なるほどね。ただオートスケーリングになるとさ、起動速度が課題になったりするじゃない？
その場面でもシングルバイナリであることで、起動が高速になるみたいなメリットがあるのかな？

多田：
その点について厳密に確認は行っていないんですが、あると思います。
シングルバイナリであることや、モノリスにしたところも起因していると思いますが。

松崎：
ちなみに単純な興味で聞くんだけど、実行バイナリって何MBぐらいかな。

多田：
61MBくらいありますね。バイナリの割には大きいと思います。

松崎：
それなりのサイズだね。その辺は起動する速度にも直接影響するよね。
コンテナイメージもそのサイズに引っ張られるし、単一バイナリだとレイヤー分割が難しいから高速化が難しいモデルになるものね。

SLA の達成

松崎：
ところで少し話変わるんだけど、Auth0 そのものの安定性はどう？
Auth0 を批判したいわけではないけれど、今の使い方を見てると純粋に認証する部分は全く問題なさそうに見える反面、Hooks みたいな処理や何かイベントがあったときの処理など付随して動くところが不安定な時がある気がするんだよね。

多田：
そうですね。
でも IDaaS として、アカウント情報のデータベースとして見ると普通に使えるものだなと思います。

松崎：
ついこの前の話だけど、いい生活アカウントを2年間運用してきて始めて、Auth0 側が提供してくれている基盤の上で動いてるフック系の処理基盤で障害が起きてしまったじゃない？
自社開発のアプリと Auth0 の機能をインテグレートする上で、どうしてもその間に挟まる処理が必要で利用してたんだけど、そこで障害が発生してしまったよね。

多田：
そうですね…。

松崎：
あのときのダウンタイムは2時間弱ぐらい。
当社としての SLA は基本的に99％にしてるけど、社内的な SLO は99.9%を目指したいというラインがある。
2時間弱のダウンだと、1ヶ月の稼働率は 99.73% ぐらいだから目標を下回っちゃったよね。
ただ、2年間で初めてなので、確かにロングスパンで見れば99.99％ぐらいは達成できているとも言える。

この観点はやっぱり重要だよね。
以前、対談で話題にした One API Platform も含めてデータプラットフォーム本部のプロダクト群は、基本的にダウンすると他のプロダクトも使えなくなってしまうので。
ここは常に意識して戦わなきゃいけないよね。

多田：
ある意味で一番大事なところを専門の SaaS に委譲しているから、ある程度安心して導入してこういう結果になってるので、そんなに間違いじゃなかったんじゃないかなと思います。

認証基盤として多くのユースケースを支える

松崎：
いろんなアプリを繋いでいく中で、認証基盤としてもユースケースが増えるじゃない。
「なるほど、そういう使い方か…」みたいな。
設計としてどうやってちゃんと一貫性を持たせるかや、アドホックな設計にしないようにするかって悩ましいと思うんだけど、どうかな？

多田：
そこが一番大変ですね。
多くの場合「そのケースは採用しません！」が通用しないので何とか実現しないといけないんですけど…。

松崎：
メジャーなケースはおおよそ問題ないんだけど、一部のマイナーケースをどのようにうまく機能として取り込んでいくかが、大変なところだよね、きっと。

あとは「他のアプリの挙動を変えてください」とか「使い方も変えてください」というような、認証基盤の利用者でもある各プロダクトチームの人たちとの綱引き的な調整もきっとあると思うんだけど、プロダクトオーナーとしてはその調整も大変じゃないかな？

多田：
そこは腹を割って話すしかないかなと思います。
「本来はこうあるべきですよね」という話をまずは僕からして、その後相手に「とはいえこういう事情が…」という部分を聞くようにしています。

松崎：
それで着地点を探るんだ。なるほどね。

多田：
そういうことが多いですね。

松崎：
多田くんが当社に入ってからやってることとして、他のプロダクトにも繋がるプロダクト、当社の共用のバックエンドに携わっているという意味では、実は本質は変わってない感じなのかもね。

多田：
2019年ぐらいから変わってないかもしれないですね。

安全・安心してアカウントを開設してもらうために

松崎：
セキュリティ面で考えると、IdP を作る上では情報漏えいの観点も考える必要があるよね？
例えば、自分たちが作ったものに脆弱性があると他人のなりすましやアカウントの乗っ取りが発生することはリスクとして頭に置いておかないといけない、みたいな。
技術面では、パスワードのハッシュ化をどうするかといった話のような、セキュリティ的な意味での堅牢性をどう担保するかって結構難しい話だけど、そこを Auth0 に任せていることによって楽になっている面はありそうかな？

多田：
そこは意識してますし、Auth0 に任せられているのは大きいと思いますね。
あとは、ビジネスロジックを考慮してそういうことが起きないようにするという思考もありますね。

松崎：
本当にその会社の人かどうかの確認、あるいは eKYC みたいな本人かどうかの確認という、ビジネスロジックだよね。
いい生活アカウントでいうと、そういうところは、宅建免許証の番号などで照合したり、登録電話にコールバックして実在確認をしたりするなどの仕組みを作っていたよね？

多田：
そうですね。基本的には承認制です。

松崎：
不動産会社の人が自分でアカウントを開設できるようにしつつ、違う不動産会社の人がなりすましでアカウントを作成できてしまわないように、ちゃんと保護している、と。
そういうあまり IT 的な部分ではない、ちょっとソーシャル的な部分で本人であることを確認することが、実は肝だったりするよね。
それって結構大変じゃなかった？

多田：
大変ですし、そこはまだ発展途上だと思っていますね。

使い勝手とのトレードオフなので、厳しくすればするほど、使ってくれるはずだったユーザーが離れていってしまう、使い始めるのを諦めてしまう要因になりかねません。
でも僕らとしては、確認をきちんとしないと、お客様にとっての問題になってしまいます。
身元がはっきりしてるところじゃないと取引をしたくないのは当然のことなので。

松崎：
そういう意味では、なりすましが一番怖いよね。

多田：
現在の店舗確認の基本フローとしては、まずオフィシャルに登録されている不動産事業者はインターネットからデータとして取得することができるので、そこで照合します。
また、僕らは国に登録されている宅建免許番号のマスターデータベースを持っているので、各不動産会社や事業所の登録電話番号も分かっているので、その電話番号を店舗確認に使います。

松崎：
店舗確認の際にはこちらから電話を鳴らすんじゃなくて、ユーザーから特定の電話番号にかけてもらうことで、認証が完了するんだよね。
でも、例えば「登録した電話番号は受付専用になっているから、この番号では電話できない」みたいに言われるケースってあったりしない？

多田：
受付専用番号だからかはわかりませんが、でも結果的に「この番号で電話できないんだけど…」と稀に聞きますね。

松崎：
そういう時は別の方法で確認をしているの？

多田：
そうですね。例えば管理者が招待することでユーザーを手動で追加することは可能です。
もう少し便利なフローが思いつけばいいなと思ってますが…。
今は Passkeys など色々新しい技術が出てきてますけど、結局どれも個人の認証の仕組みなので、法人や店舗の本人確認はあまりないんですよね。

松崎：
その個人がその会社に所属してることを正しく確かめるのはやっぱり難しいんだね。

多田：
toB で利用するためのいい方法はいろいろ考えていますが、なかなか思いつかないですね。

プロダクト開発の楽しさややりがい

プロダクトの発展のための新たなスタート地点

松崎：
いい生活アカウントとしては、今は開設済みで5万強、MAUで1.4万弱ぐらいのアカウントがあるけど、ここから先このアカウントをどう活用していくか、どう増やしていくかが大事になってきているよね？

多田：
そうですね。
今は自分たちの力で間違いなく増やせると予測していた数のユーザーがいるので、次はその人たちにたくさん使ってもらうにはどうしたらいいか考えるフェーズなのかなと思います。

松崎：
今までは連携するアプリを増やすことによってユーザー数を増やしてきたけど、さっきも言った通り8割がた接続できたので、ここからその方法でユーザーを増やすことは難しくなってくる。
だからこれからは、いい生活アカウントそのものの品質の向上や、より情報を活用しやすくすることや、認証/認可を楽にする方法を考えていくフェーズになったのかなと思う。

多田：
そうですね。今は新たなスタート地点ではあると思います。

松崎：
とはいえ、プロダクトとしてもちゃんとした形にしていて、各アプリと繋いである程度ユーザー数も増えたので、フェーズとしては順調に進んでるよね。

過去の経験を活かしたプロダクトづくり

松崎：
多田くんが仕事をしていて一番楽しい瞬間ってどんなときかな。

多田：
楽しいというより、プロダクトオーナーとしてほっとしたのは、1年強取り組んでいた当社の既存プロダクトといい生活アカウントのアカウント統合の山場を越えたことですね。既に世に出ていて、稼働しているので安心しています。

松崎：
なるほど、何かをやりきったときに一番やりがいを感じるんだね。

多田：
あと個人的に楽しいことは、PoC のような実験してるフェーズが僕は好きです。
例えば、とりあえず CD は作ったからマージしたらデプロイされるよみたいな。

松崎：
そういう感じは、見ててわかる気がする（笑）
ちょっと話が変わるけど、今のいい生活アカウントの構成は自分の中で何点だと思う？

多田：
今の構成は、及第点より上だと思います。80点ぐらいですかね。
部分的には趣味の要素、ちょっとエッジーでエクスペリメンタルなものも使ってみていますが、結構クラシックで王道なものを作っています。
構成としてもそこまで変わったものではないのかなと思いますね。

松崎：
実際に今の構成で安定してるし、チームで開発も進められているしね。
今ってちなみにチームメンバーって何人だっけ？

多田：
デベロッパーで言うと5-6人です。

松崎：
チームにはデザイナーもいて、画面周りのビジュアルデザインだけじゃなく UX も考えて提案してくれるよね。
他にもプロダクトマネージャーもいるし、全体で言うと8名ぐらいか。
僕が言うのも辺だけど、結構人数の多いチームで開発をしているんだね。

あとは、多田くんがいい生活アカウントに携わる前に dejima や One API Platform の開発をしていたことによって、そこで培った知見や知識が活きていることって、どれぐらいある？

多田：
インフラ関連はある程度予測ができますね。

あとは、フロントエンドや認証はいい生活アカウントで初めての経験でしたが、2019年にも Kubernetes を初めて使った経験があるのでなんとかなるかなと思いました。

松崎：
知らないことが多くても、やればできるだろうと思って挑戦して、実際に何とかした経験がここにきてある意味 活きているのかもね。

多田：
そうですね。過去の経験は間違いなく糧になりましたね。

実際に使いながら技術を身に着けていく

松崎：
ただ、認証/認可の仕組みやセキュリティ周りって、改めて勉強しなきゃいけないことが多かったんじゃないかと思うんだけどどうだろう？
例えば OAuth や OIDC が、どういう仕組みで外部のアプリを安全に認証/認可しているのかなどの話ね。
結構大変じゃなかった？

多田：
僕自身はやりながら理解していきましたね。
新しく入るメンバーは特に大変だなと思います。
その場合は初めに教科書レベルのことをインプットしてから、少しずつやりながら覚えてもらっていますね。

松崎：
ちなみにメンバー向けチュートリアルやオンボーディングとして、「いい生活アカウントを認証基盤として動く Hello World アプリみたいなものを作ってどう使われるかを知る」みたいなことをやっていたりはするのかな？

多田：
まだしてないですね。

もし作るならログイン機能と、モジュールの取得や認証/認可の何かを試してみるのが良いかなと思っています。

松崎：
認証周りは自分で組み込んでみて、認証時に何とどういう通信をして何の情報が行き交った結果、実際に認証されるのかを理解するのが重要だよね。
それを学ぶのに、プロバイダ側から見るより、クライアントつまり利用する側から見た方が理解しやすいと僕は思うんだけど、どうかな？

多田：
そう思います。
いい生活アカウントは元々 Firebase Authentication を経由して IDプロバイダ として Auth0 を間接的に利用していました。ですが、僕がいい生活アカウントに入って3ヶ月目ぐらいから、直接 Auth0 を利用する形に変更していきました。

この部分の仕事を通じてだいぶ理解が進んだところがあります。

松崎：
なるほどね。
実際に使ってみると「この情報はどこからどうやって持ってくるのか」や「どういう通信しているのか」ってのを必然的に見るものね。

他プロダクトチームのメンバーへの技術の理解の促進

松崎：
これと全く同じような話で「いい生活アカウントにアプリケーション統合してもらうにあたって、他のプロダクトを作ってる人たちにも同様に認証認可フローを理解してもらう」必要があると思うんだけど、それってちょっと大変じゃなかった？
もちろん内容としては、OAuth と OIDC だから技術的にはスタンダードなものではあると思うんだけど。

多田：
実際、難しいし大変だと思いますね。

松崎：
なるほどね。OAuth や OIDC を初めて触る場合にはなかなか難しいか。

多田：
ただ、他のプロダクトでは基本的に最初の組み込み時に1回だけ触ったらほぼ変えることはないものでもあるので、普段はあまり意識されない気もします。

一方で、一般的に見られるシングルサインオンのような、複数のプロダクトをもう少しシームレスな形で結合していくことは、まだまだ発展途上中なので、今の状態が最適なのかを疑問に持てるようになって欲しいな、とは思いますね。

そうなった時、今の状態を改善したい場合に、何をしなければいけないかを完全に理解している人は恐らく少ないので、そこはまだまだだな、と思います。

松崎：
デベロッパーだけでなく、プロダクトに関わるより多くの人に理解を深めてもらえるといいよね。

フルスタックであるいい生活アカウントに求めるメンバー

黒江：
最後に、いい生活アカウントチームにはどのような人に入ってきてほしいですか？

多田：
Rust が書ける人はもちろん歓迎しています。
あとは、今できることに閉じこもってしまう人だとちょっと困るかもなというプロダクトではありますね。

Rust を書くチームかというとそうではないし、だからと言って React を書くチームなのかというと React を書くのが仕事でもやっぱりないんですよね。
よく知らないものを理解して、何とか他のものと繋ぎ込むような作業を自分で工夫してやっていくことを何回も繰り返した先に、何が見えるのかということに対して意欲的にできる人。
「それはやったことはないですけど、まずやってみます」ぐらいのことが言える人がいいなと思います。

松崎：
つまり新しいことに取り組むことに対して、フットワークが軽い人だよね。

多田：
あと、いい生活アカウントはフルスタックであることも特徴だと思います。
端から端まで自分の手で作るチームは当社だと他には Home/Owner/Pay ぐらいですかね。

松崎：
そうだね。One API Platform という強力なバックエンドがあることによって、他のプロダクトの多くはそこにバックエンド機能を寄せている。
それはそれでそういう思想で作っているので、問題はないんだけど。
その点いい生活アカウントに関しては、One API Platform からも独立している必要もあって、結果としてフロントエンドもバックエンドも全部やれる状態だよね。

黒江：
フルスタックでやれるからこそ、どのようなことが楽しいですか？

多田：
僕が楽しいのは、何かを成し遂げたいと思ったときに、自分で手段が想像できることですね。
他にもやり方はあるかもしれないけど、とりあえず自分の手札から、これらを出せばとりあえずゴールへの道筋は想像できるし、そこから実際に手を動かすことが楽しいですね。

松崎：
これはもう価値観の話だよね、それを楽しいと思うか、大変と思うかは人次第なので。

多田：
そうですね。　　　　　　　　　　　　　　　　
僕としてはフルスタックにできるチームだからといって、「フルスタックにやらねばならない」ということではないと思っていて。
「フィーチャーチームであれ！」みたいな話はありますが、やっぱりやりたいことや得意なことをやれる方がいい、というタイプの人もいるでしょうし。

松崎：
細く深く掘るのが好き、広く浅く好きな人もいるだろうし、広く深くという強欲な人もいるだろうからね（笑）

多田：
あとは、「俺は Rust でアルゴリズムを書くんだ！他はやらん！」みたいに言われると困ってしまうので、「これをやってほしい」と言われたら、チャレンジしてくれる人がいいなと思います。

松崎：
ある程度興味のグラデーションがあるといいよね。
得意、不得意もきっとあるだろうしね。
メンバー間で足りない領域を補いあって、より良いプロダクトづくりを進めていきたいよね。

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

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

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

それでは今回はこちらで失礼します！
次回の記事もお楽しみに！

撮影：杉山 泰之