オウチーノの新たな物件検索インターフェース「マンションデータベース」

くふうカンパニーグループのオウチーノは不動産の購入・売却、住宅情報に関する総合情報サイトを運営しています。 そのオウチーノが運営する「マンションデータベース」は、マンション毎の販売履歴や賃貸履歴、周辺相場などさまざまな情報を閲覧することができるサービスで、今年大きくリニューアルし、地図を中心とした新たなインターフェースを提供開始しました。2022年6月現在は、東京都世田谷区の情報に対応しています。

Da Vinci Studio はオウチーノの開発全般を支援しており、今回のリニューアルプロジェクトではデザインを中心に担当しています。 今回は新しいインターフェースを作り上げるまでのプロセスについて聞いてみました。

吉川 崇倫（インタビュアー）

Da Vinci Studio 代表取締役

結城 綾子

Da Vinci Studio デザイナー

小汀 頌子

オウチーノ エンジニア

山本 亮

オウチーノ エンジニア

Zillowの価格推定表示をきっかけに始動したプロジェクト

―― 今日のメンバーは、このインタビューシリーズ初参戦の方ばかりですよね。
毎回、最初にみなさんに自己紹介からお願いしてるんです。あらためて言われると困るかもしれませんが。誰から行きましょうか。

山本 じゃあ年長者から（笑）。オウチーノのエンジニアの山本といいます。 基本はバックエンドやデータベースまわりをメインに担当しています。Scala が好きです。

―― 不動産の資格も持っていますよね。

山本 はい。宅建士の資格を持っています。不動産会社に就職できますね。

―― 歌って踊れる、ならぬ Scala が書けて不動産がわかるエンジニア、ですね。

結城 じゃあ次は私がいきますね。Da Vinci Studio デザイナーの結城です。山本さんに合わせると、登って踊れるデザイナーです。登って、っていうのは山登りですね。あと、最近はフラメンコをやっています。ってこんな自己紹介でいいんでしょうか？

―― ちょ、ちょっと待ってください、もうすでに色々とツッコミどころが……（笑）。
こんな自己紹介で大丈夫です。むしろありがたいです。
山登りは以前聞いたことがありましたね。ハイキングやトレッキングみたいなやつですよね？

結城 そうです、いろんな山を登ってます。普段は関東近郊で、北アルプスや八ヶ岳、鹿児島の離島まで足を伸ばすこともあります。日帰りのライトなものから、泊りがけで登るものまで難易度もさまざまです。

―― すごい本格的ですよね。

結城 いえいえ、普通に山歩きしているだけですから。 フラメンコは学生のころからずっとやりたいと思っていたものの、なかなか機会がなくて。それがなんと近所にフラメンコスクールができたんです。長年の夢がかないました。 この話、こんなにしててもいいんですか？

―― はい。むしろみんな今、興味しんしんですよ（笑）。

結城 一年前から始めて、最近やっと曲を完走できるようになりました。 まあ、まだまだですね。手も足も可動範囲が広くて、思った以上に体を使うんですよ。 動画では大して動いてないように見えても、実は下半身がとんでもなく動いていて、本当に体幹の強さが必要なんです。

―― すごいすごい。どんどん出てきますね（笑）。

山本 見せて！

結城 インタビューが終わったら披露しますよ。

―― ありがとうございます。なんだかハードルがすごく上がっちゃった気がしますが、小汀（おばま）さんお願いします。

小汀 はい。じゃあ上がりきったハードルの下を、くぐり抜ける感じでいきたいと思います。 オウチーノのエンジニアの小汀です。主にフロントエンドまわりを担当しています。具体的には React、TypeScript、Ruby on Rails まわりを触っています。 特に踊ったり歌ったりはできないんですけど、関西に移住して半年ほど経ちました。

―― もともと関西出身なんでしたっけ？

小汀 地元が島根県なので西は西ですが、移住したのは大阪です。仲の良い友人が住んでいるのと、子どもの頃から身近に感じていた都会ということで、ちょっと憧れの地ではあったんです。コロナ禍でリモートワーク中心になったことがきっかけで移住したいなと悩んでいたところ、まわりの皆さんが行っちゃいなよって背中を押してくれまして。というわけで今日も大阪からお邪魔させてもらってます。

―― まわりの後押しがあると心強いですよね。Da Vinci Studio でも地方在住の人が何人かいますし、増えてきましたよね。

皆さん、ありがとうございました。今日のテーマはオウチーノのマンションデータベースプロジェクトです。確か社内でプロジェクト名は「クオッカ」って言ってましたよね。正式名称としてマンションデータベースになったんですかね。

山本 プロジェクト名は「クオッカワラビー」です。正式名称といえばそうなんですが、マンションデータベース自体はもともとあったんです。クオッカワラビーは別の独立したサービスとして作ろうとしていたんですが、紆余曲折あってマンションデータベースに組み込む形になりました。

―― クオッカワラビーとマンションデータベースって言葉のイメージが直結しないんですが、何か由来があるんですか？

山本 米国に Zillow という不動産サービスがあり、このサービスでは販売中の物件だけではなくて、まだ販売していない物件も探せるようになっています。こうした物件の価格を推定値で表示していたので、 オウチーノでもそういう価格推定をやりたいよねというところから始まったプロジェクトでした。プロジェクト名を考える際、当初は「見積もる」といった意味で Quote にオウチーノの ouc を加えて、Quouc （クオーク）にしようかと思いました。

でも、オウチーノってプロジェクト名には動物名を使うという文化があるんです。なので、末尾に a を加えて Quouca （クオッカ）にしたんです。だから本物のつづりとは違います。結果として Quouca が価格推定などのバックエンド。対になるフロントエンドが Wallaby で、あわせてクオッカワラビーです。

―― 僕はワラビーに詳しくないんですが（笑）。ワラビーっていう動物がいるんですっけ？

山本 ワラビーっていう可愛い生き物がいるんですよ。カンガルーみたいな。クオッカワラビーは、その一種です。

―― なるほど。「見積もる」という Quote からの動物ルールでクオッカか。つながりました。

ワラビー。可愛いです（フリー写真）

マンション購入の決め手となる情報を提供

オウチーノ マンションデータベース

―― 紆余曲折あったということですけど、最終的に今のサービスはどういうサービスになったんですか？

山本 マンションデータベースは、気になるマンションの現在の販売・賃貸状況や、過去の売買価格が分かるサービスです。このサービスの地図の部分を、まるごと置き換えた形です。

まず地図上に、過去オウチーノに掲載したことがある物件の建物を、すべて表示します。 この白地になっているものが販売中で、グレーアウトしているものは今は販売中ではないけれど過去に掲載していたことがある建物です。それをクリックすると詳細を表示します。

結城 あ、スマホで見たほうが良いと思います。詳細を開いて、上にスワイプしてみてください。 ここで物件情報が出てきて、査定結果も表示しています。これが価格を推定した結果ですね。

山本 この地域で面積 120 平米だと、買うときはだいたいこれ位の値段だよ、というのを計算しています。

結城 そもそもの前提から説明させてください。

このサービスのターゲットは「すでにある程度、欲しいマンションに目星をつけているユーザー」で、ゴールは「そのマンションを買うか買わないかを自ら判断できるようになる」です。

一般的な物件閲覧サイトだと、価格が表示してあっても、本当に妥当な値なのかっていうのは判断しづらいですよね。また、そのマンションの周辺情報、例えば学校への通いやすさだったり、災害情報なども一緒に知ることはなかなかできません。

そういった情報をあわせて提供することで、ユーザーが購入を判断できるようにサポートするというコンセプトです。

メインの機能の一つが、自分が探している物件の情報を入れると推定価格を出してくれて、自分がすでに持っているマンションや他で見た価格と比べられるという機能ですね。もう一つの機能が、地図上で災害情報や、子どもたちが通う学校情報が見られるというものです。

このマンションほしいなあと目星をつけているユーザーだから、売出し中の価格が 3,000 万だったり 4,000 万 だったりというのは知っているものの、それが本当に市場価格より高いのか安いのかまでは、ほとんどの人は分かりません。

また、買い時かどうかも不明ですよね。今後、この周辺の物件価格ってどう推移していくんだろう、この地域自体がどうなっていくんだろうといったような。そういった購入の決め手になるような情報を、このサービスを見ればわかるようになることを目指しています。

―― 決め手になるような情報か、なるほど。大きな買い物ですし、踏ん切りをつけるためには最後のひと押しになるものって重要ですよね。

周辺環境も、戸建てとマンションでは重視するポイントが違いそうですね。戸建ては基本まわりも家だけという場所が多いですけど、マンションは駅近かどうかなどで、周辺の施設の充実度が異なってくることもありそうですね。

こだわって作り上げた地図上のインターフェース

―― デザインも完全にモバイルファーストですよね。Web サイトではあるものの、アプリっぽい UI になっていて凝ってますよね。デザイン上、苦労したところや工夫したところはありますか？

結城 拡大縮小したときの地図上の情報の見せ方の工夫ですね。地図って拡大縮小するし、左右にも動くし、それによって乗ってくる情報が常に変わるじゃないですか。私にとっては、地図関連のデザインは初めてで、面白かったですね。

UIのプロトタイプを作ったら、小汀さんがすぐに実装して試してくださったので、一緒に試行錯誤しながら詰めていきました。例えば「ここは一旦データを読み込まなきゃいけないので、こういう動きにしてください」、「これ以上の情報はモーダルにしよう」のように。地図に機能がたくさんあるにも関わらず、表示する領域自体は限られているので、ユーザーに圧迫感を感じさせないようにどう配置するかなどを、一緒に試行錯誤して作っていきました。

物件情報の部分も小汀さんがすごく色々やってくれて、例えばこの地図上で選択すると物件の概要が小さく出るんですけど、ここで上にバッと引っ張ると詳細に遷移して、バッと下げるとまたフォーカスが外れるみたいなのをすごく細かく作り込んでくださってるんですよ。

小汀 これ、最初にデザイン見たときどうやって実装しようって頭を抱えながらやったんですけど（笑）。

実装当初からスプリントを2週間で区切って、かつ、その都度価値があるものがユーザーに提供できるような形でリリースを進めようと考えて実装していったんですが、区切られたそれぞれのスプリントの中で、実際にどうやるかを結城さんと本当に密に話をしながら作ってましたね。

山本 物件を探すインターフェースって、過去にも色々な会社が新しい形に挑戦しては失敗してるんですよ。でも個人的にこのサービスのインターフェースは良いと思ってるんです。

使いやすい。エリアで探してこんな感じでポンポン見られるというのは国内だとあんまりない気がしてます。エリアで探す機能自体は海外だと結構あるんですけどね。Zillow もそうだし、Redfin もそう。あとイギリス最大手の Rightmove も。

結城 そうですね、物件を探すという観点でもそうですし、個人的には学区とかが結構楽しくできたなあと思ってます。この小学校の人はみんなこの中学校に行くと思っていたけれど、実はここのエリアで境界があって分かれているんだなというのを実感を持って見られる場所ってあんまり無いですから。

山本 災害リスクとかね。地図上でリスク高いところがわかるんで、自分のマンションの周囲を確認したらがっつり赤くなってたりとかね（笑）

―― そうですね、良いですね。自分のマンション周辺の災害リスクが高いことを後で知るのは嫌ですけど（笑）それを事前に確認できるのは良いですね。

結城 住みやすさを判断するには、本当は住人の年齢層だったりとか、治安だったりとか、そういう様々な情報が検討には必要だと思います。そういった情報まで含める構想はあったんですけど、MVP（Minimum Viable Product）ではまず一番重要そうな2つに絞っています。

山本 すでに国がいろんな情報を提供してくれてるし、たしか2024年を目処に国土系の情報基盤を作るという計画もあるようなので、そういった情報をどんどんのせていければと思ってます。雪崩とか地すべりが起きやすいとか。緯度経度情報を使って物件と紐づけることもできると思いますし。

―― ネガティブな情報を全て考慮して探すのも難しいですからね。子どもの学校なんかは頭にあるかもしれないけれど、表示項目の選択肢としてあれば、洪水も気にしたほうが良いのかと気づけますしね。今後に期待ですね。

技術的にはどんなものが使われているんですか？

山本 フロントエンドのワラビーの方は Next.js で組まれてますよね。

小汀 はい。データベース接続とかないんでこれ。バックエンドというか、マンションのデータは「ペンギン」さんを使ってるんですけれど。あ、ペンギンさんというのはオウチーノの物件検索バックエンドシステムです。ペンギンさんとは完全に素な関係性になっています。

―― マイクロフロントエンドってやつですね。

小汀 はい。フレームワークとしては React + Next.js を使っていて、ステート管理では Recoil を使っています。 もともとオウチーノでは Redux が使われていたんですが、Hooks を使った状態管理にしようよということで導入してみました。

―― ページやサイト全体は基本 Next.js で、この地図のようにぐりぐり動くようなところは Recoil 中心にという感じですか？

小汀 はい。状態っぽいものは全部Recoilに持たせるようにしていて、何かの状態がオンになったらこのコンポーネントを開くというような。 あと React を関数型っぽく組もうというのは意識していました。

―― 宣言的UIを意識しようってことですかね。Recoil と Hooks はかなり扱いやすいですよね。

小汀 使いやすかったですね。非同期の処理がたくさん絡むとデバッグが大変っていうのはあるんですけど。書きやすかったです。 普段は React + Redux で書くことが多くて、Next.js も Recoil も初挑戦だったので、フロントエンド力が上がりました。

2週間ごとにユーザーに新たな価値を提供するスプリント

―― さっき、最初のフェーズでも2週間でリリースできるような状態を維持するという話がありましたよね。

小汀 はい。このやり方は私自身本当に学びが大きかったです。1回の粒度が揃って無くてもいいから、とにかく2週間である程度形にして出す。その2週間でやるのはボタンひとつだけの変更かもしれないし、ものすごく大きな機能かもしれないけれど、とにかく2週間で一区切りにする。かつ、既にあるものの拡張かもしれないし、全く新規のものかもしれないんだけど、何かしらユーザーにとって新しい体験となるものを、必ず2週間ごとに出していくというのが、プロジェクトの推進力になったという気がします。

―― 素晴らしいですね。初期フェーズってみんな色々と詰め込みたくなるものですよね。でもそれだといつまでもリリースできないってことになりがちだから、すごく良いですね。

小汀 まぁ相当辛かったですけれど（笑）1週間は他のメンバーと話をして、結局実装は1週間しかない！って頭を抱えながらやってましたね。

―― でも、2週間で一旦区切れるっていうのがいいですよね。

小汀 あ、そうですね。確かにそういう区切りがなかったら、もっとズルズル時間がかかっていたと思うし、ここは一旦ここまでで出しましょうという判断もなかなかできなかったと思うので、週間のスプリントというやり方だからこそ走りきれたとも思っています。

ミニマムに仮説検証するために柔軟に軌道修正

―― コンセプトとしても、進め方としてもすごく良いプロジェクトだなと感じるんですが、当初の予定とは紆余曲折あって変わったという話がありましたよね。

山本 最初はまったく別の新規メディアとして立ち上げる予定だったんです。ドメインもオウチーノではなく別にして。

ただ、進めていく上で最初の仮説検証のためのユーザーをどう集めようかとなったんですよね。完全に新規で立ち上げるとなると、まずはユーザーを集めるところから始めないといけないので。ならば、今すでにマンションデータベースというサービスがあるので、そこに組み込んだら早いんじゃないかということで。

―― 最初は完全に別のドメインでやろうとしてたんですね。

山本 そうです。チームで議論して決めた結果ではあるんですが、実は僕は、やっぱり最初から別で作った方が良かったんじゃないかと今では思っています。というのも、もともと考えていたデータと、マンションデータベースのデータって、ちょっと違っていたんですよね。データソースが違うので当然ではあるんですが。

マンションデータベースに組み込むとなって、マンションデータベース側のデータに合うように組み合わせていきましたが、意味合いが徐々に変わってしまうところもあって。また、マンションデータベース自体がまだ公開してからそんなに経っていないので、そこまで人が多くないというのもあって。

結城 そういった齟齬はデザインでもありました。情報として共通のものはあるんですが、そうでない部分もあるので、ユーザーのゴールも、当初クオッカでイメージしていたゴールとは若干違ってきました。プロジェクトの方向性が途中で変わることは、まああり得ることだと思うんですが、やっぱり軌道修正していくのは難しかったですね。

キャッチアップのタイミングとか。変わった後に軌道修正していくタイミングが、私はちょっと遅れてしまったなという反省点もあります。

―― さっき話してもらった、ユーザーの決め手となる情報を提供するというゴールはすごく良いものだと感じるんですが、当初はちょっと違ったんですか？

結城 いえ。「決め手になる」というところは同じです。価格や周辺環境がわかるというのは基本的に変わらなくて。ただ、マンションデータベースの中の「地図コンテンツ」として存在する場合のユーザーの期待値と、別ドメインでこれがメインコンテンツになったときのユーザーの期待値の違いだと思うんです。例えば、もともとは1つのマンションにフォーカスして遷移していく形をイメージしていました。

でも、既存のマンションデータベースは検索して絞り込んでいくので、1つのマンションにフォーカスしていないんです。だから、ユーザーがそのコンテンツにたどり着くときの気持ちが違うんですよね。そういった違いに合わせてUIを設計していきました。

―― なるほど。クオッカでは、気になっているマンションをとにかく見て、それを中心に考えていくんだけれど、マンションデータベースではそもそも色々なマンションを比較していくような構造だったと。

結城 そうです。具体的にどういった違いが出てくるかというと、クオッカではユーザーの行動はすべて地図が中心になる想定だったんです。地図からマンションのコンテンツ面に移動して、また地図から他のマンションに移動するというイメージです。一方のマンションデータベースの主要な導線は物件検索だったんです。検索して、マンションの一覧から移動して地図にやってきます。次のマンションを探そうと思ったらまた一覧に戻って同じように移動します。

こういった違いは、例えば地図上のピンのあり方にも影響を与えます。ピンにどう情報を持たせるか。そういったところを既存のサービスに合わせていきましたが、今回は地図部分を入れ替えたので、主要な検索部分はあまり手を入れていないんです。全体の統一感という意味では、薄くなってしまっている部分があると思います。ただ、プロトタイプの検証と集客のことを考えて、一旦はマンションデータベースに寄せようと考え、軌道修正していきました。

―― ピンのあり方にまで影響するのか。面白いですね。チームで議論して軌道修正したということでしたが、どういう議論があったんですか？

山本 コンセプトから当初の MVP の仕様を考えて、それに対してスケジュールを引いてみたら、ものすごく時間がかかりそうということが分かりました。そんなに時間をかけて完成品に近いものをユーザーに使ってもらうよりは、部分的にでも意味のあるコンテンツを表に出して、少しずつでも使ってもらった方が良いんじゃないか、という議論になったんですよ。

―― オウチーノ取締役の大川さんの哲学ですよね。もし考えた MVP を作るのに 3 か月以上かかるならば、MVP 自体を見直した方が良いという。

山本 そうですね。仮説を検証して一つずつ確認をしていくために、ミニマムで出すにはどうするかを考えました。地図で見せることやサービスの性質として近しかったのがマンションデータベースだったから、できたところからそこに載せていったという感じですね。

―― そういう考え方は結構、重要だと思いますよ。そもそもやってみたら地図を中心とした遷移は難しいってなるかもしれませんしね。
次のステップとして全体的に置き換えるというのが検討に上がってること自体が、進め方として正解である証のように思います。
データのことも考えると、今後また独立させた形にするというのも検討しているんですか？

山本 そうですね。まだ検討段階ではあるんですが。そもそも、今はエリアも絞っていて世田谷区しか対応していないんです。拡充するなら当然、各エリアのデータも用意する必要がありますし、そのときにこのクオッカワラビーを中心に入れ替えるのかどうかは今後の検討ですね。

―― もし今からもう一度はじめから作るとしたら、こういうふうにやりかたを変えたいな、こうしたほうが良かったなというのはありますか？

山本 マンションデータベースに組み込まずに、最初から独立サービスとして構築していきたいです（笑）

―― 検証結果が分かってますからね（笑）。そうですね。

結城さんは何かありますか？

結城 当時の自分にアドバイスしてあげるなら、もっと決断を速くすることと、何をもって決断するかの軸をもっとしっかり持っておきなさいということですね。

今回のプロジェクトは、細かいところの仕様まで決定できて、自分でもそこはやりがいがあったし面白かったです。でも、決断までに時間がかかったり、軸がぶれちゃったりしたところがあったのは反省点ですね。

―― いろいろと今後に期待したいプロジェクトですね。
みなさん今日はどうもありがとうございました！