円滑なコミュニケーションや決済を支えるスマホアプリ「いい生活Home/Owner/Pay」について、プロダクトオーナーとCTOに語ってもらいました #3
こんにちは！いい生活エンジニア採用・広報担当の黒江です🎈
今回も、前回に引き続き、いい生活のプロダクトを支えるメンバーと、CTO松崎さんとの対談をお届けします！
CTO対談第3回の今回は、いい生活Home/Owner/Pay（以下：Home/Owner/Pay）のプロダクトオーナーの稲葉さんと松崎さんに、Home/Owner/Payについて語ってもらいました！
今回の対談は3つの記事に分けてご紹介させていただきます！
こちらの記事は後編です！
前編、中編は以下の記事をご覧ください👀
【前回の対談のおさらい】
スマホアプリであるHome/Owner/Payの開発では、 ウェブアプリは異なる動作やデザインを必要とするため、専門性が高い技術やフレームワークを使って開発する必要があります。
また、ストア配信のガイドラインや、OSごとのインターフェースの違いへの対応など、スマホアプリ特有の開発の大変さもあります。
使用技術の刷新や、今のプロダクトにより合う技術がないか、常に探すことで、ユーザーへの提供価値を高めています。
幅広いユーザーが利用している、いい生活Home/Owner/Pay
一般生活者の方も使用するいい生活唯一のプロダクト
松崎さん（以下 松崎）：
Home/Owner/Pay は、当社のプロダクトだと他と比べても珍しいポイントがいくつかあるよね。
まず、利用者の観点で見ると、一般生活者の人と不動産会社の人、両サイドに機能として提供している点。
かつ、スマホアプリの形で提供しているので、toC、一般生活者に対してダイレクトにサービスを届けているっていうのは、当社のサービスラインナップの中で今のところここだけ。
僕らのサービスに対して、お金を払っていただいてるカスタマーは不動産会社。
一方で、ユーザーっていう観点で見ると、コンシューマーサイドとカスタマーサイドの両方を考えなければいけない。
この関係ってなかなかバランス難しいんじゃないかと思うんだけど、どうかな。
稲葉さん（以下 稲葉）：
ユーザーの種類が多いなと感じています。
管理会社が推している機能を作るだけだと、アプリとしては魅力的にならないということがあります。
コンシューマー、一般生活者の方々が使いたいと思えるものじゃないと、どうしてもアプリを使うのが面倒と思われてしまい、そもそもこのサービスが成り立たない。
いわゆるコミュニケーションアプリは相手がいて成立するものだと思うので、「アプリを使う価値がある」と一般生活者に理解してもらうためにも、一般生活者のニーズも拾い上げて開発をしていく必要もあります。
両方のユーザーが欲している機能であれば、開発の優先順位を高めて進めていきやすいです。
ですが、片方だけが欲しい機能は、「もう片方からすると要らないんじゃないか」「今それは本当に必要なのか」というように誰も答えを持ってないので自問自答します。
どちらかというと、管理会社向けの機能を作ると、それによっていわゆるカスタマーが増えるなっていうところは紐付けしやすいです。
ですが、コンシューマー向けの機能を作っているときは、果たしてこれが費用対効果に合うのかみたいなところを考え、結構いつも悶々としています。
松崎：
でも、おかげさまで入居者利用数が累計で12万人に届いたじゃない。
管理会社からすると、全ての入居者がサービスを利用してくれればいいんだけど、100%の利用率はなかなかどの会社も達成できないよね。
でも、ある程度の利用率があれば、自分の管理している物件の入居者にもサービスを利用してほしいと思う管理会社もいるだろうね。
管理会社ごとに、自分たちの管理している物件で実際にサービスを利用してくれている入居者の割合を増やしていく方向性があると思う。
それに加えて、新しくこのサービスを利用してくれる管理会社を増やすことも重要だよね。
だから、この二つの軸を考えながら成長させなきゃいけない。
入居者にとって魅力のあるサービスを提供し、使ってくれる入居者数を増やすこと。他方で、多くの管理会社に利用してもらうためには、やはり管理会社の要望も考慮する必要があること。
機能を開発する上で、この二つの要素を考えながら進めるのは大変だよね。
稲葉：
そうですね。しかも、Home/Owner/Pay の3つのプロダクトを1つのチームで作るので、より大変な部分もあります。
1つのプロダクトだけ作るチームがあると、頭の切り替えをする必要がなくなるのでやりやすいだろうなとは思います。
でも、1つのチームでやっているからこそ、プロダクト間の繋がりも考えることもでき、バランスが取れているとも思います。
オーナーさんのペルソナを考える大変さ
松崎：
開発者、デベロッパーのみんなからすると、比較的入居者サイドのペルソナはイメージしやすいと思う。
でも、例えばオーナーさんサイドは、なかなかペルソナを自分の中に憑依させることが難しいんじゃないかなと思うんだけど、その辺の悩みとかあったりする？
稲葉：
ありますね。
業務知識がもっと必要になると思います。
良いプロダクトを作るためには、お客さんがどういう仕事をしているかを考える必要があるし、そのためには業務知識も大切だと思います。
ですが僕らの開発チームでは、管理会社の業務については開発中に入ってくる情報が中心で、まだ表面的なことしか知られていない。
実際は入居者対応だけでなく、入金処理などの裏方業務や、オーナーさんに対して報告や物件管理もしており、そちらの業務が中心です。
このような理解を得るためには、どうすればいいか考えるのは難しいですね。
僕は元々「いい物件One」という管理会社向けのプロダクトの開発にも携わっていたので、その経験が役立ちました。今のチームには「いい物件One」を触ったことのない人もいて、そのコンテキストが欠けている状態です。
これからは、僕も口頭で補足しながら、そういった知識をインプットしていく必要があると思います。
松崎：
そういう意味でいくとさ、ユーザーヒアリングも大事になってくるかな。
利用してるお客さん、入居者サイドも聞きたいんだろうけど、そこはなかなかインタビューするのは難しいじゃない。
一方で管理会社に関しては、入居者サイドと比較的してもインタビューしやすいと思うんだけど、何か今やってたりするの？
稲葉：
今は定期的にはやってないんですが、必要になったときにお客さんのヒアリングを行ってます。
実際に導入して、「期待してた通りの動きになっていますか」や「なんか良かった点ありますか」とか、そういったヒアリングをすることはあります。
それによって、お客さんがどういうところで困ってるか理解を深めることができるので、プロダクト開発を始めてから行うようにしています。
松崎：
さっきチームメンバーの業務解像度や顧客解像度がなかなか上がらないという話があったと思うんだけど、やっぱり生の利用者の声を聞く機会も大事だよね。
そのユーザーヒアリングは実際には誰が参加したの？
稲葉：
僕ですね。
松崎：
そこで他のチームメンバーも参加する機会をあげることが大事なんじゃないかと思うんだよね。
最近は他のプロダクトだと、チームみんなでお客さんの話を聞く機会を設けていることが多いので。
稲葉：
もちろん今になって、お客さんの声を実際に聞くことは重要だと思うようになりました。
ですが正直開発メンバーのときは、「いや、そんなの後からまとめテキスト見ればわかるしな…」って考えていましたね…。
松崎：
そんな時代が僕にもありました…ってやつだよね。
稲葉くん自体が開発メンバー出身のプロダクトオーナーだからこそ、今になって思う大事なことがあるっていうことを、開発メンバーの目線で、チームのみんなに伝えてあげられるんじゃないかな。
稲葉：
そうですね。
業務で開発することに対して一生懸命なのが大事ですし、それを疎かにしろっていう意味では全くないです。
ふと思った疑問とかをお客さんに聞けるっていうのはとても貴重な機会です。
そういった疑問とかはそのままにしないで、ヒアリングしたいっていう声を上げてもらいたいと思います。
開発メンバーとしても参加してもらうことはむしろウェルカムなので、そういう風にしていきたいですね。
松崎：
やっぱり想像だけでなく体験しないと、その本質に関して理解できないことって人間だからあるよね。
だから最初は「え…」って思うかもしれないけど、意味があるんじゃないかなと。
その場にいないと、声のトーンやニュアンスとか、その顔つきや空気は感じられないから。
ビデオで録画してもさ、なかなか伝わらないところもあるし、経験したほうがいいんじゃないかなと思うよね。
稲葉：
そうですね、実際に相対して話すことで分かることもありますね。
松崎：
だから別に「その場で積極的に発言しよう」というわけではないけれど、やっぱりその場に出てくるという体験が一番大事だと思う。
それをビジネス職系出身の人が伝えるのではなく、エンジニア出身のプロダクトオーナー、稲葉くんがそう言ってあげるっていうのが大事だと思うな。
ユーザーからのレビューを聞いて
松崎：
また、先ほど話にも挙げたけど、配信しているストアなどから実際に使っているお客さんの声を聴くことができるのはこのプロダクトの特徴だよね。
アプリ内のレビュー評価が上がってから、開発してるメンバーのモチベーションとかにも目に見えて変化とかあったりする？
稲葉：
モチベーションは上がっていると思いますね。
ユーザーがどんなことに困ってるのか、何が嬉しいのかといった解像度が上がってきてるので、そこに対してどうすべきかアイディアを出し合うというような機会ができたこともメリットとしてありましたね。
松崎：
あとはそうだな。
これを応用して、ドッグフーディングとして、当社のカスタマーサポートが不動産会社向けのチャットサポート用に Home を使っているじゃない。こっちはどう？
稲葉：
思った以上にお客さんに使っていただいているので、びっくりしています。
チャットで当社のお客さんから問い合わせをいただいて、それを当社のカスタマーサポートの方がテキストで返したり、FAQ を補足情報として送っていたりして、ちゃんと使われてるなって思います。
松崎：
そうだよね、全顧客の約20〜30%には使ってもらってるね。
ちなみに当社のカスタマーサポートの人に、チャットで問い合わせを受けるのってどうですか？とか聞くことある？
稲葉：
ありますね。
基本的にやりやすいという意見をいただきます。
やっぱり電話だとタイミングによっては繋がらないこともどうしてもありますし。
そういう方々にもチャットで対応できると、「そんなに急ぎじゃないのでチャットで対応します」みたいに案内できやすくなります。
またお客さんとしては、質問をチャットに送っておけば、他の作業をしている間にいつのまにか返信が来るので、そういうやり取りが楽になって嬉しいみたいな声もありますね。
社内の意見の反映
松崎：
自社の中で別の形だけどね、製品を使うことによって不具合の発見や改善のヒントになるじゃない。
実際社内で使われていて出てきた意見が、お客様向けの製品開発にフィードバックされたことってある？
稲葉：
これから対応したいこととして、お客様対応のステータスを追加したいと考えています。
例えばお客様対応の中で、クローズしていない案件の中で、現在対応中の未解決案件と、お客さんからの回答待ちの案件を区別するために、ステータスを追加することでより管理しやすくしたいですね。
あとは、Home を使っている入居者対応で修繕業者を手配した状況など、一旦は管理会社としての対応が終わっているけれども、まだ案件自体は終了していない場合があります。
そういった場合に、その案件が終了するまでクローズせずに適切なステータスを設定しておくことで、両方の解決に対応できるようになると考えています。
松崎：
なるほどね。やっぱりヒントにはなるんだね。
稲葉：
なりますし、ラベルとかの機能をこう使うんだみたいな気づきもあります。
お客さんのデータは直接お客さんに了承を得ていれば見られるんですけど、そうでない場合は見られる機会は少ないです。
実際に顧客対応している当社メンバーが、Home をどのようにうまく活用してるのかを見て、サービスがより使いやすくなる事例やヒントをお客さんへ提供しています。
開発に限らず、お客さんに提供できる価値が増えていると感じています。
プロダクト間のコードベースの検討
松崎：
なるほどね。
あとはそうだな、少し技術的なところだと、Home と Owner でチャット的な部分でいうと、コードベースは一応一緒にしてるよね。
でも提供機能そのものは目的やユースケース、使われる頻度、タイミングとかは異なるよね。
Home はもちろんスムーズな入居体験をしていただくために、簡潔にコミュニケーションを取りたいと考えられていると思う。
一方でOwner に関しては、基本的に定期的な連絡があって、管理会社にとってオーナーさんは本質的にお客さんなので、より丁寧なコミュニケーションをとりたいなとも考えているのかなと。
ソフトウェア機能として見るユーザーストーリーやユースケースが結構違う。
でもコードベースは部分的に近いところもある。
この2つのバランスを考えながら、開発をどうモジュールとして切り出すかや、その辺の機能差を減らすべきところ、ちゃんと機能差をつけた方がいいところをバランスをとる必要があるよね。
ソフトウェアコードとしてのコードベースの管理という意味で、ユーザーストーリーの関係を分けることはなかなか難しそうな気がするな。
何か実際に大変なことってあったりする？
稲葉：
まず、コードベースの共通化はまだそんなにされていないです。
松崎：
なるほどね。逆に二重実装が発生したりするんだ。
稲葉：
そういうところもありますし、両方を開発していて、どちらにも必要な機能は実装するんですけど、これは片方だけでいいなという機能はもう片方だけで実装しています。
でも、効率的にコミュニケーションを取りたいという狙いが根本的にはあります。
時間的な効率面については、Home は入居者対応をいかに短時間でクローズまで持っていくか、やり取りを減らすかを考えていきます。
Owner の方は、どちらかというと問い合わせが来たものに対しては、情報をまとめて送るためにどう効率化するかです。
松崎：
そのユースケースの違いで、コードベースをどういう風にするのがベストなのか考える必要があるよね。
いっそのこと全部 monorepo にするって方法もあると思うし、最初にビルドの成果物が結構違うので、分けた方がいいみたいなこともきっとあるよね。
あんまりそこら辺についてはチームで議論がまだない感じかな？
稲葉：
これから行いたいと思っています。
どうしたら効率的な開発、同じ実装をしなくてよいかなどは課題です。
プロダクトとチームがより成長するために
チーム規模の変化
松崎：
チーム人数は、チーム発足当初はもともと3人で、そこから5年間ぐらいは3-4人ぐらいだったよね。
近年顧客数も増えてきて、利用者さんも増えてきて、今年度は急増したよね。
稲葉：
はい。昨年の年度末から2人増えて、今年の6月に4人増えて、今は9人います。
松崎：
倍どころから3倍ぐらいになってるけど、そうするとやれることも当然増えてくるね。
だから今言ったような課題をこれから解決して、より良いアプリにしていきたいよね。
チームのメンバーが増えたので、プロダクトとして今まで経験のない規模になってるわけだけどどうかな？
稲葉：
今までは人数的に開発できる限られたところを中心にやってきました。
この人数になったので、何からやるべきか、個人の役割を考え直すタイミングだと思います。
そのためには、「実装に長けてる人」や「どのような要件を使用するかを考える人」など、今いるメンバーのロール、誰が何をするかを考える必要がありますね。
ただ人数が増えたことによって、アウトプットも増やす必要があることにプレッシャーもあります。コミュニケーションパスも増えるので、進みがかえって遅くなることも。
なので、どう効率良くコミュニケーションをするかを意識して開発をすることが重要かと思いますね。
松崎：
そうね。メンバーが開発しやすくするために、仕組みをもう少し考えなきゃいけないだろうし。
知識をうまく平準化していくために、レビュー体制はペアプロをもう少しやらなきゃいけないし、 two-pizza ルールで考えると MAX に近いので、もうHome/Owner/Pay でチームは割っちゃうみたいな戦略も当然あるから悩ましいよね。
稲葉：
ただチームを割るには最終的に自立した3つの組織を作る必要があります。
まずは、周りを引っ張るポジションに立てるようなメンバーを育てていきたいですし、僕も一緒に成長していきたいなと思います。
One API Platform から独立しているプロダクト
※当社のプロダクトの1つである One API Platform についてはこちらの記事をご覧ください！
松崎：
あともう1つ、いい生活のプロダクト群では珍しく、One API Platform と若干独立したところにこのプロダクトはあるよね。
これはプロダクト発足当時の MVP の観点で、API から用意すると大変だからなるべく小さくスタートするっていうところと、開発を取り巻く環境面みたいなものを考慮した結果だよね。
ただ昨今のトレンドとして、やっぱりそのプロダクト間の連携性を高めなきゃいけないみたいなコンテクストもあって。
独立してるからやりやすいことと、独立してるから自分たちで作らなきゃいけないものが、実は根本的にかなり多いよね。
他のプロダクトとの連携を考えると、例えば先ほども出てきたようなオーナーさんへの報告に行くとき、One API Platform と連携して重要なデータがあれば、そこから情報を持ってきて見やすい形でオーナーさんにに報告することができる。
そういったデータを作って渡す時の連携性の関係と、自前で作る必要のあるものの量といったアジリティを考えて、今のアーキテクチャだと大変なのか、独立して良かったのか、どう思う？
稲葉：
販売面では分かれていて良かったという面が大きいなって思います。
当社の商品を使っていなくても、Home/Owner/Pay のそれぞれ単体で、小さく使えるので、当社の商品を初めて使うお客さんにも取り入れやすいです。
独立して動けるアプリケーションであること自体は結構メリットであるし、強みになってるなと思います。
ですが、データ連携に関してはやっぱり、One API Platform が持っているデータをお客さんの使える状態で提供し、より効率的に業務を回すことで価値を提供できるんじゃないかと思います。
データ連携も長期のニーズとして高まっているので、ハイブリッドになるかなと思いますね。
松崎：
One API Platform も API なので、呼び出すこともできるもんね。
稲葉：
そうなんですよ。
他社のデータを使うよりは、One API Platform を使った方が圧倒的に使いやすい。One API Platform を使ったものにも今後取り組んでいきたいですね。
松崎：
なるほどな。個人の情報やお金の情報、物件情報などいろんなものが One API Platform にあるしね。
なるべくそのような当社が持ってるデータをうまく活用して、より使いやすいアプリを目指していくことを、メンバーも増えたのでうまくやってほしいなと。
稲葉：
そうですね。
チームの編成に関しては、スキルスタックのバランスが重要ですね。
例えば、いい生活社内にあるスキルを考慮して、特定の目的やニーズ対応ができる人たちが集まったチームを組む方法。
逆に、「こういうことをしたい」という目的を設定してから、それに応じたチーム構成を考えるという逆引きをすることで、チームメンバーは目的に向けて進んでいけるのではないかとも思いましたね。
松崎：
なるほどね。
あとは、今後は人数も増えてきたので、新しい機能の開発だけでなく、ライブラリのバージョンアップとかここのところやれてなかった技術的負債の解消を今後進めていく必要があるよね。進められるメンバーも増えつつあるんだろうなと思うので。
稲葉：
その通りですね。
新しいメンバーが入ってきたので、今までできなかったバージョンアップとかも積極的にやっていきたいです。
チームメンバーにはもっと自由に提案してほしい
黒江：
今後 Home/Owner/Pay のメンバーにはどのようなことに期待していますか？
稲葉：
僕をどんどん超えていってほしいですね。
あとは、もっと積極的に提案してほしいなと思います。
自分が作るサービスという意識を持って、思っている以上に好きなことをやっていいんだよと思っています。
メンバーはみんな「そこから先はやっちゃいけないのかな…？」みたいな遠慮してる感じがありますが、もっと自由にやってアクセルを踏んでほしいですね。もしブレーキを踏まなきゃいけないところがあれば僕が止めていくので。
松崎：
多分自分自身の経験だと、若いときが一番アグレッシブだよね。
新しいライブラリが出てきたらすぐ使おうみたいな。
これはもう気質として、新しいことに対して好奇心の塊みたいな人もいますからね。
それぐらいの好奇心を持ってくれると嬉しいね。
黒江：
ありがとうございました！
ここまで読んでいただき、ありがとうございました。
以下から気軽にご応募ください！
また、これからもCTO対談などのインタビュー記事を発信していきますので、いい生活公式noteの「いいnote」のフォローもお願いいたします！
それでは今回はこちらで失礼します！
次回の記事もお楽しみに！🥰
撮影：杉山 泰之