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

今回のインタビューは、前回に引き続き、One API Platform のプロダクトオーナーの中山さんとCTOの松崎さんに、One API Platform について語ってもらいました！

One API Platform のCTO対談は3つの記事に分けてご紹介させていただきますが、今回は2つ目の記事です。

1つ目の記事をまだご覧になってない方は、こちらから見てみてください！

チームプレーの大切さ

黒江：
これまで話していただいた部分は、全部中山さんが一人で行ってきたんですか？

中山さん（以下 中山）：
これまで挙げてきたような僕のやってきたことに関して、実は他の人から見ると僕はワンマンでやっているように見えている可能性があるんじゃないかと思ってました(笑)

でも実際僕は、チームプレーが大好きで、僕自身はどちらかというとチームプレーヤーだと思ってます。

僕が1回いい生活を辞めた理由は、実は僕と一緒に作業をするチームメイトがいなくなって、半年ぐらい「全ての作業、俺しかいねー…」みたいな状況に嫌気が差したからなんです。

チームプレーが好きだからこそ、チームで動くための仕組みを、ドキュメントやテストなどで整備する必要があると考えました。

今はチームとして固まって常に動けていて、なかなかいい状態だなと思ってます。

松崎さん（以下 松崎）：
そうだね、やっぱりチームプレーはプロダクトづくりにおいて重要だからね。
その点で、今のチームはとても良いと思ってるよ。

中山：
やっぱりいいチームですよね。

一方で、僕の悩みどころでもあるんですけど、最近は新卒もたくさん入ってきて、上が詰まってきてる感覚があるんですよね。

僕より年次の低い5年目とか6年目のメンバーにも、もっとチームリーダー的な役割になってほしいと思っています。
でも、チームの数が足りてなくて、チームリーダーの席が埋まってる。

例えば、今僕がやってるプロダクトオーナーという席は、僕自身が埋めているという状況があります。

ですが、僕が会社を辞めたとき、僕のポジションを後輩がうまく引き継いで、爆速で成長してレベルアップしてくれたという経験がありました。
なので、当時僕が1回辞めたのは正解だったのでは？とも考えています。

松崎：
まあ、成長機会の提供というのは難しいよね。

昔はいろんなものを全て超中央集権的に管理していた。
その中でプロダクトチーム制を導入した意図は、それらをちょん切って分けていくことで、それぞれが成長していくって狙いもあったんだよね。
その結果、開発部門全体として見ると、ちゃんと成長していくというか。

だから、One API Platform も、もしかしたらどこかでちょん切る日が来るかもしれない。

そういう意味で中山がマネジメントしている中で言うと、dejima っていう塊があって、その塊をどうするか、サブコンポーネントとして扱うかどうかってのもあるんだよね。

dejima というOne API Platformに依存しない存在

黒江：
お！dejima の話ですね。

中山：
One API Platform は、シングルプラットフォーム・マルチテナントという特性や、大規模なデータベースの特性があります。
そのため、メンテナンスの内容によっては、オンラインつまりサービスが動いている状態だとやりにくいものが出てきます。

そのため、月に約1回深夜メンテナンスと言って、完全にサービスが止まる時間を設けています。

ですが、いい生活が提供しているtoCのコンシューマー向けのホームページなど、夜間も動いているべきサービスもあります。

それに対して、24時間365日動くサービスとして、One API Platform に依存しない存在として dejima が生まれました。

dejima という名前は、長崎の出島が由来です。
One API Platform 本体から離れている存在で、そこでやり取りすることができるんです。

そういった外部向けの高い SLO を満たすためのコンポーネントとして、dejima は作られました。

ただ、出来た当時は結構夢があって、もっと進化するんだろうと思われていました。
ですが、現在はどちらかというと One API Platform に回帰した方がいいという意見もあります。

松崎：
そうだね、最近の dejima は、結構用途が限定的で、ホームページサービス専門のようになっているというのが実態だよね。

dejima を大きくしていく方が、API のオープン化につながるかなと思ったんだけど、やっぱり情報を集約したいというニーズが強い。

特にいい生活のサービスは不動産会社向けなので、情報を繋ぎたいという方向にウェイトがかかってくるんだよね。

中山：
2年前にできた いい生活Square というサービスも、実は当初のコンセプトでは「dejima を通じて One API Platform から追加で連動するものを増やしましょう」という話だったんです。

しかし、One API Platform から 一旦 dejima に受け渡すのは、処理コストも実装の手間もかかってしまいます。
そのため、「いきなり One API Platform にアクセスしましょう」という方針に変わったという話がありました。

これが、One API Platform が外に開かれ始めた発端ですね。

松崎：
今まで、というか当初の One API Platform は デスクトップクライアントからしかアクセスされなかったよね。
でもWebアプリ化の流れの中で、様々なアプリからのアクセスも増えているじゃない。
そういう風に変わっていく中で、何か大変だと感じることはある？

中山：
いや、今のところはありませんね。
強いて言えば、もうちょっとスクレイピングが増えるかなと思っていたんですけど、現時点では思ったよりも増えていませんでした。

実際、アクセスに対しての負荷を観測してみると、実は読み取りのような単なるアクセスに対しては One API Platform はめちゃめちゃ強いことがわかっています。
なので、多少増えても全然大丈夫なんですけど。

松崎：
いや、スクレイピング増えたら困るよ(笑)

中山：
ですよね (笑)
ですが今後、更新のようなアクセスの負荷が増えることについては、きちんと対策はしていかなければと思います。

黒江：
更新のようなアクセスが増えるとは、具体的にどのようなことでしょうか？

松崎：
いい生活が提供しているのは主に業務システムです。
そのため、お客様は日々そのデータを眺めているだけではなく、業務を通じて実際にデータを更新や追加する作業が多いんですよ。

だから、一般的な Web サービスの読取/更新の割合とは全然違って、更新の頻度がずっとあるんです。

特に不動産業界の場合、1店舗で千件、万件単位で物件を扱うこともありますし、お金に関する情報も扱っています。
そのため、普通にお使いいただいているだけでも、大量更新が頻繁に起こったりします。

中山：
今は Web化されているのが、まだまだ軽量な部分だけに限られているので、Webアプリ経由では、そこまで更新が来ていません。
ですが、将来的には激しい更新が来るとは思いますね。

松崎：
デスクトップアプリと Webアプリだと設計次第ではあるけど、API のアクセスパターンも変わるしね。
だから、その辺も注目しつつ、必要に応じてうまく対策をしていかないとだね。

いい生活にとってのデータベースそのもの

黒江：
他にも中山さんが主導した改善があると聞いたので、教えていただきたいです！

松崎：
他で言うと、中山が頑張ってきたのは、データベースの分割かなぁ。

中山：
そうですね。
今までアプリケーションの話が多かったですが、僕はデータベースに関してはいい生活の中でも比較的面倒を見る立場にいるんです。
IPAのデータベーススペシャリストの資格も持っています。

新卒で入ってから現場で学んでいて、データベースに関しては今後どうしていくか、どう改善するかなど、かなりコミットしてました。

松崎：
One API Platform って、結局いい生活という会社にとってのデータベースそのものみたいな、とても大事な存在だよね。

お客様が増え、機能が増え、さらに長期間利用いただく中で、データが増えるのは宿命。

だから、増え続けるたくさんのデータを上手く捌く仕組みをどう維持し続けるかっていうのも宿命みたいなものなので、継続的に取り組んでいかなければいけないよね。

中山：
実は松崎さんに聞いてみたかった話がひとつあって。

アプリを開発している各プロダクトチームは、One API Platform のことを、基本的に API として見ている人が多いと思うんです。

ですが、経営や営業の人たちは、どちらかというとデータベースとして捉えていると思っています。
外部にも いい生活はデータベースという言葉を使っていますしね。

なので、「なぜそのデータベースからデータを出せないのか」というのは、特に事業開発部などからはよく言われます。
そのことについて、松崎さんはどう考えてますか？

松崎：
僕らの手元には、お客様から預かったデータがたくさんあります。
近年社内でそれをもっと活用したいというニーズが増えてきて、これはすごくいいことだと思ってます。

データを分析することで、新しいビジネスを発見したいとか、今のお客様の姿をデータから把握したいとか、データから新しくインスピレーションを得たいとか、そういうことがあるんだろうと思いますね。

そこに対して、もっと活用し易く、広げていく必要があるという これからの課題があると思っています。

中山：
そうなんですよね。
プロダクトチームからは API として見えているという話をしたと思います。実装されている API に関して言うと、個別のデータにアクセスする API がメインです。

ですが、分析という話になると、一括で横断的にでデータを取ってくるとか、集計するとか、エクスポートするとか、そういう機能が必要になってきます。
しかし、現状そういった API はほとんど提供されていないです。

松崎：
そうだね。そもそもいい生活のサービスはマルチテナント大規模データベース だからなぁ。

黒江：
マルチテナント大規模データベースとは、どういうことでしょうか？

松崎：
どういうことかと言うと、システムとしては 全てのお客様のデータが一つのプラットフォームの上に入っていますが、API を利用する上では、お客様ごとにデータが分離されている、ということです。

AWS を例にすると、AWS上でデータベースを利用するケースをイメージしてみるとわかりやすいかな。

AWS上でデータベースを動かす、とした時に、じゃあ他の AWS利用者と同じデータベースを共用しているか？と言われればそうじゃないですよね。

裏側にある物理的なマシンは共有しているかもしれないですが、データベースという単位で見たら完全に分離されているはずです。

黒江：
なるほど。

松崎：
だけど、One API Platform の場合、ただ分離されてるだけでもないんです。
いい生活の提供するサービスの中には不動産会社間の情報流通という側面もあります。

API としてはお客様ごとに分離されていつつ、全体としては1つのプラットフォームの上で動いているので、横の情報流通もできるようになっているんです。

これが一つの特徴で、それによって様々なことができるようになりますが、その分難しいことも多い。
それと日々戦っているっていう側面も、中山にはあるんじゃないかなと思います。

また、シングルプラットフォーム・マルチテナントであることにはもう一つのメリットがあります。
それは、プラットフォーム全体にアップデートを展開できるので、改善をすぐに全てのお客様に届けられるということです。

例えば最新バージョンを適用するような場合、個別にお客様に作業を依頼する必要もないし、新しい機能がすべてのお客様に自動で展開されます。

もちろん、Canaryリリースのように順次展開できるような仕組みはそれはそれで必要だったりしますが。
でも、そもそも仕組みとして個別展開せざるを得ないような状況になっちゃってるわけではないですね。

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

いい生活では新卒/キャリア採用を行っております！
下記から気軽にご応募ください！

また、いい生活では現在25卒以降の学生さん向けにサマーインターンの募集を行っております🌞
下記よりご応募お待ちしております！

「対談の続きが気になる！」「いい生活についてもっと知りたい！」と思っていただいた方は、いい生活公式noteの「いいnote」のフォローもお願いいたします🤝

それでは今回はこちらで失礼します！
中山さんと松崎さんの対談は、次回で最終回となります…！
下記よりご覧ください💁‍♀️

撮影：杉山 泰之