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

今回は前回に引き続き、いい生活 賃貸/売買クラウド 営業支援（以下：営業支援）のプロダクトオーナーの上屋さんと松崎さんに、営業支援について語ってもらいました！

営業支援の対談は、3つの記事に分けてご紹介させていただきます！

こちらの記事は中編ですが、
前編をまだ見られていない方は以下よりご覧ください🐇

適切な頻度でリリースを行い、ユーザーに価値を届ける

どのように作るか工夫したところ

松崎さん（以下 松崎）：
「何を」作るかもプロダクト開発の文脈ではとても大事だけど、一方で「どう」作るかみたいなところで考えたときに、工夫したところってどんなところかな？

上屋さん（以下 上屋）：
どう作るかという点だと、先ほどの話にも挙がりましたが、ユーザーとの会話を大事にしてます。
どんな機能であっても小さくリリースし、まずはユーザーに使っていただいて感想をしっかりと聞いた上で、その次のステップに進むようにしています。

あとはモビリティというか「いつでも、どこでも、誰でも、使える」をかなり意識しています。

ESいい物件Oneの頃にいただいていた要望として多かったのは、一般生活者からの問い合わせにタイムリーに対応することでした。
当然、問い合わせを受ける先は、いい生活のプロダクトを使ってくれている不動産会社だけでなく、その他の不動産会社も含まれることになります。

そのため、不動産会社としては、どの会社よりも早く問い合わせへの対応を行いたいわけですね。
そのような状況で、パソコンがないと問い合わせへの対応ができない、となっては、他社に勝つのが難しいです。
ですので、出先でも対応できるようにするため、パソコンでもスマートフォンでも使えることが重要と考え、アーキテクチャを決めました。

Web アプリを作るためのフレームワーク・開発言語・アーキテクチャはいろいろありますが、上記の理由から SPA（Single Page Application）にしたいというのがまず最初にありました。

また、それなりのコード規模になることが予想されたので、型システムは必須だがTypeScript を使いたい。
となると、Vue.js か React か、という話になったんですが、最終的に TypeScriptとの親和性が高いという点を重視して React を採用することにしました。

松崎：
Vue.js は 例えば入力フォームみたいな、比較的単方向に情報が流れていくタイプのアプリを開発する上では、楽だしハマりやすいイメージかなぁ。

対して、 React はやっぱり Hooks がパワフル。
加えて SWR に代表される Hooks の支援ライブラリも充実してるから、単一画面に留まったまま、並列に複数の要素を更新するようなケースに強いよね。

特に営業支援みたいに、リアルタイムに最新の情報を部分的に更新したいとか、ユーザーに対してプッシュ通知をしたいとか、そういう要件があるとこの特徴が活きてくる。

わかりやすい例で言えば、特定の一般生活者に向けてメッセージを書いてる途中に、何か差し込みで新着通知があるようなケースとかね。
その際に、メッセージを書き終わるまで、新着通知がされないと困るし、かといって通知がきて、文章作成が中断されても困る。

ユーザーから見ると単一の画面に留まってるように見えてても、裏でいろんな通信をしていて、必要に応じて画面のあちこちが更新されてるイメージ、と言えばいいかな。

そういうことを考えると、Vue.js よりも React の方がハマる、というのはわかりやすいね。

上屋：
あとは、当時は少し Vue.js の開発の体験のしにくさがありました。
せっかく TypeScript を使っていても、コンポーネント部分でそれが生かせないっていうのが…

松崎：
Vue 2 時代の話だよね？

上屋：
比較検討していた頃は、まだ Vue 2 の時代だったので、そこが決め手でしたね。

松崎：
時期的に言うと、Vue 3 が出た直後ぐらいでまだ安定するかしないかぐらいかな。
それを考えると、React の方が後方互換性や成熟度も高いよね。

Vue.js は Vue 2 と Vue 3 でプログラミングパラダイムが結構変わっているからね。
長く開発・運用を続けていくこと考えると、ブレイキングチェンジが大きいフレームワークよりは、きちんとアップデートされ続けながらも、後方互換性の意識が高いフレームワークを使いたくなるのはわかるなぁ。

上屋：
あとは、当社の Vue.js を採用したプロダクトでよく利用されてる Vuetify という UIライブラリも、その時はまだ Vue 3 の対応が終わってなかったんですよね。

松崎：
タイミング的にそうか。いろいろこれからって時期だったもんね。
そういう意味でも、比較的エコシステムの充実と安定感でいうと React がいいんじゃないか、みたいなね。

上屋：
SWR も含めやっぱり充実度が、違いましたね。

松崎：
ところで、営業支援には、さっきも説明した「いつでも、どこでも、誰でも、使える」という特徴、要は、不動産会社の顧客接点の密度を上げてクイックに対応できるようにすると言う観点があると思う。
その観点からブラウザアプリではなく、スマホのネイティブアプリを作るか、アーキテクチャ選択の際に考えたりしたのかな？

上屋：
考えましたね。
元々いい生活のプロダクトの中に、入居者向けの BtoC 向けのスマホネイティブアプリがあって、結構苦労してるなっていうのを眺めていました。
それを踏まえて、改めて「ネイティブアプリじゃないと実現できないことってなんだろう？」と考えました。
結果として、「プッシュ通知を出したい」ぐらいしか思い浮かびませんでした。

プッシュ通知は大事なので、ブラウザアプリにした場合どうしても引っかかるのが iOS の対応でした。
ですが、iOS でも Webプッシュを 2023年 からサポートする予定という情報が出たことで、ネイティブアプリ化はしないという判断に至りましたね。

松崎：
Webプッシュは、ようやく状況が整ってきたよね。
PWA (Progressive Web Apps) という観点で見ても、年々整備されてきているし、ブラウザベースのアプリでやれることは増えてるよね。

そういう意味でも、あえて専用のスマホアプリを作る部分に力を割くよりは、機能の充実を図る、ブラウザで扱ってもスマホで扱っても同じ体験を届ける、といった価値提供の部分にエネルギーを割いているんだね。
そして、継続的にアップデートをちゃんとしていくために、今の開発体制の中でできる工夫をしているって感じかな。

チーム規模とリリース頻度

松崎：
今って営業支援のチームメンバーって全員で何人なんだっけ？
営業支援ってメンバーが増えたり減ったり、結構いろいろ形を変えてきてるじゃない。

上屋：
正社員のメンバーと、インターン生など一時的なメンバーも含めると、全員で10人ですね。

松崎：
スクラム開発のチームとしてみると10人はそこそこの大所帯だけど、結構大変じゃなかった？
Amazon の two-pizza ルールとかで考えると、上限に近い感じ。

上屋：
徐々に人数が増えたので、それに適応していくっていう感じでした。
立ち上げの段階はデザイナーも含めて6人だったんですが、ロードマップに積んでいく案件もどんどん増えてきて、応援も必要になり、人数を増やしていきました。

松崎：
初期リリースからだんだん機能が追加されてきて、ユーザー数も増えてくる中で少しずつ人員も拡大し、今に至るみたいな感じか。

上屋：
今はバックエンドとフロントエンドで担当が分かれてしまっているのが課題かなと思っています。

例えば、フロントエンドメインのエンジニアはバックエンドの実装まで目が届かないことあります。また、フロントエンドメンバーの手は空いてるんだけど、バックエンドのタスクが結構積み上がっていて、分担できないみたいなことも増えており...
うまく組み合わせて、一つ一つのストーリーを良いペースで完成させていくところが難しいですね。

松崎：
フロントエンドとバックエンドの垣根を超えていくのは、理想だけど確かに難しいよね。
ところで、いいベースで完成させるのが難しいという話だけど、今はリリースってどれぐらいの頻度でやってるんだっけ？

上屋：
リリースは1週間に1回ですね。

松崎：
ちなみにそれって何週連続達成とかやってる？

上屋：
年末年始やゴールデンウィークなどを除いて60週ほどですね。
ファーストリリースの去年の3月からずっと続いています。

松崎：
せっかくだし、100週連続リリース目指さない？

上屋：
そうですね！目指していきたいなと思います。

松崎：
スクラム的な話で言うと、適切なサイクルでペースを作って開発をするのが重要だから、まずはそこがベースラインになるよね。

もちろん、世の中には毎日リリースどころか、一日に何回もデプロイをするチームやプロダクトもあると思う。
でも、少なくともユーザーに対する価値提供って観点で見たときに、60週連続でちゃんとリリースを続けて、意味のあるアップデートをできているっていうのは素晴らしいね。

上屋：
実際のユーザーの皆さんの声としても「毎週のリリースのお知らせが楽しみだ」と言っていただけることもあります。
ですので、定期的に更新できることは、ユーザーの皆さんにとっても価値があることなのかなと思ってます。

メンバーの年齢層と社歴

松崎：
チームメンバーの年齢層や社歴とかっていう観点で見るとどうなんだっけ？

上屋：
初期メンバーは、新プロダクトの立ち上げで結構パワーを必要とするので、ベテラン勢が揃っていました。
今のメンバーは新卒のメンバーが3人でインターン生が1人で、かなり若手のメンバーが多いかなと思っています。

プロダクトの特徴として、結構仕様がとっつきやすいところがあって、どのようなところで使えるか、すごくイメージしやすいプロダクトです。
なので、そういう意味では若手のメンバーにとっても、入りやすいんじゃないかなと思います。

松崎：
何となく利用シーンや業務のイメージがつくものね。
ある種チャットアプリ的な側面もあるからそう言う部分では想像がつきやすいし、自分が家を借りた経験があれば、その反対側にいる人のことを想像すればいいからね。

上屋：
若手のメンバーは、まだ技術的に卓越した何かがあるわけじゃないですが、「こういうときにこうしたらいいんじゃないか」とか、そういうアイデア出しをすごくやってくれて。
一般生活者目線で意見を出してくれる、という感じですかね。
ユーザーヒアリングでは、どうしても一般生活者にはヒアリングが難しいので、これもまた新しい視点の追加になっています。

新しいツールを積極的に取り入れ、より良いプロダクトを目指す

新しい技術をどのように取り入れるか

松崎：
僕の経験上、開発チームに若手メンバーが多いとありがちな傾向が2つあると思うんだよね。

1つが、比較的先輩方が作った道をそのままひたすら歩くみたいな方向に行くパターンで、温故知新は良いけど冒険がない感じ。
もう1つが、ちょっとまだ海の物とも山の物ともつかないような新しい技術、Twitter のTLやはてブのホットエントリで瞬間盛り上がっている技術を躊躇なく投入したがるっていうパターンで、冒険しまくりな感じ。

本当はうまいこと真ん中というか、バランスをとりつつ進めて欲しいんだけど、どちらかに極端に振れやすい傾向と言えばいいかな。

特に若いうちは、後者の方、新しい技術を使ってみたいという気持ちに溢れて、それを自分が携わるプロダクトに実際に組み込もうとする前のめりな意識・パッションは、エンジニアとしては、そんなに悪いことじゃないんだけどね。
だから、ちゃんと尊重しつつも、シニアとしてガードレールを敷いて、暴走しすぎないようにすることが大事と思うんだけど、その辺って実際やっててどう？

上屋：
前者がやっぱり多いですね。比較的手堅めです。

松崎：
だとすると、新しい技術とかって、チームとしてはどう取り入れてるのかな？
各種ライブラリもそうだし、テストフレームワークや、ビルドツール1つとっても、日々いろいろ出てくるじゃない？

上屋：
この辺は、僕はこういうのが好きなので、「入れよう！」ってチームメンバーに言って、「それいいんじゃないですか！」ってチームメンバーがその良さそうな反応を示したら入れています。

残念ながら、現状はほとんど僕発信になっちゃっている感じです。
ですが、「いいのがあったら入れてもいいんだよ」ってメンバーにもよく言っているので、そのような提案は大歓迎ですね！

松崎：
わかる！そういう意見も欲しいよね（笑）

ところで、TypeScript を使ってるとビルドプロセス自体が結構複雑なツールチェインになるから、アプリケーションの規模が大きくなってくると、どうしてもビルド時間が延びがちみたいな課題って割とあるじゃない？

週1リリースする中で、なるべく迅速に届けるために CI/CD というか、継続的なテスト、デプロイ・リリースのやり方など、工夫しないといけないところが、いろいろあるはず。
最近 Vite を入れたのは見かけたんだけど、他に、例えば Turborepo あたりは使ったりしているの？

上屋：
リポジトリは monorepo で運用していて、用途毎にパッケージを分割しています。
更新頻度が異なるので、更新しなかったところはスキップ、頻度が高いところだけちゃんとチェックする、といったことをやって日々の開発工程を効率化しています。

松崎：
さっきの話からすると、上屋くんが「やろうぜ」って言って、その辺も取り入れている感じなんだね。

上屋：
はい、そういうのが好きなので （笑）
もしかしたら他のメンバーの成長機会を奪っている可能性があって悩ましいんですけど…。

松崎：
でも、普段いろいろ仕事してる中で新しい知識を吸収してガンガン使いたいなって思う子もいれば、そういう情報に触れる機会をなかなか作れないタイプの子も当然いるよね。
だから、いろいろ新しいものを見つけて、世の中でどう使われてるかを見て「そろそろ投入してもいいんじゃないですか？」って言う人が1人でもいると、やっぱり刺激にはなるんじゃないかな。

次の段階としては、その結果として「僕がなんかそういうの調べてきたんで、今度入れてみたいです！」みたいな人が、もうちょっと出てくるといいのだろうけど。

上屋：
そうですね。
必ずしもずっと同じ体制でやるわけじゃないので、もし異動などで僕がいなくなったときに、「ああそういえば、こういうことしてたな」って思い出してそういうことしてくれるといいなって思ってますね。

データの扱い

松崎：
バックエンドは One API Platform に依存してるっていうところもあって、そこに営業支援の中でビジネス的な機能を追加機能するメンバーがいるよね。

比較的 One API Platform で扱うデータのモデルって数が多いじゃない？
営業支援だけで見ても、人の情報、物件の情報、一般生活者とやり取りしているメッセージ、店舗の情報など、扱うデータを整理・分解していくと、そこそこの数のデータモデルが存在している。

一方、フロントエンドは TypeScript という、厳格な静的型付けとまでは言えないけど型を強く意識した JavaScript みたいな言語でできてる。

型システムってことを考えると、このデータとそのスキーマを整備していくのって、結構大変じゃないのかなと思ったりするんだけど、今そのあたりは何か手当してるのかな？

上屋：
今はフロントエンドもバックエンドも OpenAPI を使っています。
OpenAPI で型スキーマを整備・定義していて、その中でレスポンスデータという形でデータモデルの定義が全部入っているので、そこから自動生成できますね。

あとは、TypeScript のデータバリデーションには、Zod を使ってますね。

松崎：
Zod を使うことによるメリットとしては、型の制約があるのでバックエンドとの通信も安定すること。
さらに、フロントエンド内部の処理系としても比較的入力項目が多いものに対してちゃんとした型制御や基本的なバリデーションが効くので比較的プログラミングしやすくなってることかな、と思うよね。

あとは、例えば機能追加する際に、自分たちで定義・設計してるデータモデルの変更とかは当然として、別のプロダクトで同様の理由で変更が入った際に、そこにも追従する必要があるケースはよくあると思う。

その際に、型システムがあることによって、自分たち起因ではないデータモデル変更であっても、開発体験を損なうことなく、うまくやれるようにしてるって感じなんだろうね。

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

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

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

それでははCTO対談第2弾の中編はこちらで失礼します。

対談の最終回、後編は以下からご覧ください😉

撮影：杉山 泰之