Forbes JAPANによる次世代スタートアップ100選1にも選出されたFaciloは、創業CEOである市川紘（こう）さんが長年取り組んできた不動産テックの事業領域において、既存の不動産仲介会社の営業活動を支援するビジネスモデルを選び、顧客への物件紹介や内見といったプロセスでDX（デジタルトランスフォーメーション）を支援しています。
アプリケーション開発においては当初からマルチプロダクト展開を想定し、どのエンジニアでも扱えるようなインフラ環境の設計、保守運用のしやすさを重視したアプリケーションフレームワークの選択、そしてエンジニアの自律性と自主性を重視した開発プロセスを採用するなど、CTOである梅林泰孝さんの思考は一貫したシンプルさを保っています。
この開発姿勢はスピードが重視されるスタートアップにとって有用ですが、実際に徹底するのは簡単なことではないでしょう。Faciloではなぜこのような開発を行うのか、また行うことができているのか？ 梅林さんに聞きました。
※ この記事は株式会社Faciloによるタイアップ広告です。
- 物件情報のPDFをメール添付で受け取る購入体験を変えよう
- B2BのSaaSにはマルチプロダクト戦略が必要だ
- 開発スピードと保守運用のためRails Wayに乗る
- バックエンドエンジニアで保守運用できるインフラ設計
- エンジニアは自分の仕事を自分で決めたい
- プロダクトにコミットしていることを感じられる組織
- 🚀 Faciloではソフトウェアエンジニアを積極募集中 💡
物件情報のPDFをメール添付で受け取る購入体験を変えよう
── Faciloは不動産テックの領域で、仲介会社を支援するSaaSを提供しています。なぜこのビジネスモデルなのでしょうか。
梅林 不動産を買いたい人は、まず希望エリアの不動産屋の店頭で相談したり、物件情報サイトを検索したりします。でも、不動産の購入は人生で何度も経験することがないかもしれない高額な買い物なので、間取りを見ただけで「買います」とはならないですよね。
物件が条件に合っているか、他にもっと良い物件はないか、時間を掛けて吟味します。物件が見つかったら内見して、さらに他の物件と比較検討して、ようやく契約に至るわけです。
この長い購買ライフサイクルにおいて、仲介会社の営業担当と顧客のコミュニケーションの多くが、現状では電子メールやLINE、電話になっており、その中で物件情報はPDFファイルで送られてきます。個別のやりとりに分散したPDFを見比べるのも大変ですし、検討済みかどうかも分からなくなる。似た名前の物件が近くにあれば内見の調整で混乱もします。
梅林 泰孝（うめばやし・やすたか）
株式会社Facilo 共同創業者 CTO。新卒でGoogleに入社し、検索品質向上チームに従事。その後、サイバーエージェントで「AirTrack」を開発責任者として国内最大の位置情報プラットフォームに成長させる。米国シリコンバレーでスマートニュースのテックリードを務めたのち、2021年に米国在住のままFaciloを共同創業し現職。事業に注力するため2月に帰国し、次の住まいをFaciloで探している。
── 確かに大きな買い物の割には、あまり快適な購入体験ではなさそうですね。
梅林 こうした一連の作業は買い手にとって大きなペインですが、不動産を仲介する事業者にとっても快適というわけではありません。私たちが提供しているのは、そういう不動産仲介会社の営業担当者を支援し、その先の顧客体験を向上するためのプロダクトです。
不動産業界では、物件検索サイトなどで集客した顧客に物件を提案し、内見を調整し、最終的に成約につなげるまでのフェーズを「接客」と呼びますが、今私たちがサポートしているのはこの接客領域です。
営業担当者は、接客の中で国土交通省が不動産会社に提供している物件検索システム「レインズ（REINS）2」で物件を探し、顧客に提案します。レインズの検索は複雑で、担当者は顧客ごとに異なる条件を手動で入力し、検索結果で表示された物件が過去に提案済みではないかを目視で確認して、新規の物件情報をPDF化してメールやLINEで顧客に送信する作業を繰り返しています。
Faciloを使うことで営業担当者は顧客ごとの希望条件や提案済み物件を保存でき、物件の検索と確認をこれまでより大幅に効率的に実施できます。また情報共有や内見の調整など、顧客とのコミュニケーションもFaciloで一元化でき、煩雑な事務処理から解放され、より顧客のニーズの確認や物件検討の対応に時間を割くことができるようになります。
一方、顧客には専用のマイページが用意されて、提案された物件を一元的に閲覧できます。必要な情報が文字・画像・ファイル・地図など最適なフォーマットで提供されるため、これまでと比べて大幅に快適かつ効率的に物件を比較したり、価格などの条件でソートしたり、またここから内見の予約申し込みもできます。
B2BのSaaSにはマルチプロダクト戦略が必要だ
── Faciloは、不動産仲介会社にサービスを提供し、仲介会社がFaciloを使って顧客とやりとりするというB2B2CのSaaSで、営業担当者と顧客それぞれの体験を改善するわけですね。
梅林 不動産仲介会社にとってもうれしいことがあります。例えば、提案した物件情報の閲覧状況から顧客の好みをより深く知ることができ、次の物件提案につなげることができます。そうした営業活動が全てFacilo上で行われるため、組織全体で営業プロセスが可視化され、よりよい営業ノウハウを社内で共有できます。
── 今後もこのプロダクトに集中して開発を進めていくのでしょうか。
梅林 いえ、私たちはマルチプロダクト展開を考えています。ここまでお話したのは2023年にリリースした「Facilo物件購入クラウド3」の機能ですが、2024年末には物件を売りたい方と仲介会社をつなぐ「Facilo物件売却クラウド4」のサービスも開始しました。
── 1つの大きなプロダクトではなく、売買それぞれを順にリリースしているわけですね。
梅林 こういったマルチプロダクト戦略は2021年の創業時点でCEOの市川と一緒に考えていたもので、この戦略があったからこそFaciloの起業を決めたところもあります。
基本的に2BのSaaSビジネスには、マルチプロダクト化が必須なんです。特に特定の業種に特化したバーティカルSaaSでは、そうでないと売り上げがすぐ頭打ちになりますから。
開発スピードと保守運用のためRails Wayに乗る
── ここからサービスを構成している技術要素について伺いますが、Faciloではどういった技術スタックを選択していますか。
梅林 アプリケーションは、基本的にRuby on Railsで構築しています。
フロントエンドの作り方には大きく2種類あり、顧客が使うマイページはやはりワクワクしないとアクセスしてくれませんから、先ほどマップビューで紹介したようにUI/UXには気を使っています。直感的に扱えるように、ReactのSPA（シングルページアプリケーション）でページ遷移することないよう構築しているところもあります。
一方、仲介会社向けの管理画面は毎日使うことが前提であり、マニュアルを整備した上で導入プロセスでカスタマーサクセスがしっかりオンボーディングするので、マイページと比較すると直感性についてはそこまで重きを置いていません。それよりもエラーが発生したらすぐ修正できることが大切ですから、Rails Wayに則ったRESTfulな設計にしています。
── 2021年の創業時点でRuby on Railsというのはそれなりに枯れた技術を選択されたように思いますが、どういった理由があるのでしょうか。
梅林 私自身はずっとJavaを扱ってきたこともあり、Faciloを創業するにあたってはいろいろな言語を検討しました。GoやPHPのSymfonyや、もちろんJavaも。
そこからRuby on Railsを選んだのは、フレームワークとして本当によくできているからです。Railsには規約が多いという特徴がありますが、そのため誰が書いても同じようなコードになります。コードを追加するときも、どこに書けばよいか迷うことが少ない。
また、Active Recordの仕組みが優秀で、ORマッパーが非常に便利なんです。マルチプロダクト展開を進める上で、この2つの点は絶対に必要ですから。
── この技術選定にマルチプロダクト展開が関係してくるのですね。
梅林 バーティカルSaaSでビジネスを成長させるには、つまり複数のプロダクトを垂直に立ち上げて売り上げを積み重ねるには、いかに盤石なエコシステムを作れるかにかかっています。そのためエンジニアは複数のプロダクトを横断して開発できる必要があります。
Aというプロダクトを開発していたエンジニアに「明日からBプロダクトを担当してください」というときに、規約が多いRailsはとてもマッチします。新しいプロダクトを担当するときに、レポジトリをクローンしてローカルで立ち上げてプルリクエストを投げる一連の開発作業がオンボーディングなしでできてしまうような、その思想にはすごくひかれます。
デバッグする際もActive Recordが強力なので、本番のデータやステージングのデータを気にせずに、簡単に手元でデバッグできます。
── Rubyの実行速度などに懸念はなかったのでしょうか。
梅林 マルチプロダクト化すると、1つのプロダクトが大量のユーザートラフィックをさばく必要はそれほどないんです。インスタンスが100にも200にもなってオーケストレーションするようなサービスにはならない。むしろ開発速度の方が大切です。
もちろん、エンジニア自身が新しい開発言語に挑戦したり、技術選定の自由があることをメリットだと捉えたりすることは理解しますが、いかに属人性をなくすかを考えるとアンチパターンですね。複数のプロダクトチームがそれぞれ自走できる自立した分散組織を作る上では、強いエコシステムが土台になりますから。
バックエンドエンジニアで保守運用できるインフラ設計
── インフラはAWS（Amazon Web Services）でしょうか。
梅林 そうですね。コンテナのオーケストレーションをマネージドに任せたかったこともあり、AWS FargateとAmazon ECS（Elastic Container Service）を採用しています。私がずっとAWSを使ってきて知見があるので、わざわざ時間をかけて別のクラウドサービスに挑戦するより、開発を加速できた方がよいですから。
とはいえ、Amazon EKS（Elastic Kubernetes Service）は少し検討しました。前職ではEKSを採用していたので知識もありましたし、触ってみたいというエンジニアも多かったので、技術選定した後にも葛藤がなくはなかったです。
ただ、先ほども言ったように1つのサービスが数百台のインスタンスを使うようなことにはならないので、できるだけシンプルにプロダクト間で共通化させることを優先しました。ここ数年「やっぱりECSでしょ」という意見も見かけるようになりましたし、選択は間違ってなかったなと思います。とにかくEKSはアップデートが大変なんですよ。
── ここでも「シンプルにプロダクト間で共通化」することを重視されていますね。
梅林 Faciloでは「インフラチーム」のような横断組織を置かないと決めていて、全てのバックエンドエンジニアがインシデントに対応できるようにしています。フルマネージドである分だけコストは多少かかるかもしれませんが、それよりもバックエンドのエンジニアがインフラを理解できていることのベネフィットが大きいですね。
今は10名近いバックエンドエンジニアがいますが、全員がCI/CDのパイプラインやリリースフローを理解し、ログの集計基盤も把握していて、何でもメンテナンスできる状態になっているのは素晴らしいことだと思います。とはいえ、現在までインシデントもなく安定運用できていますが。
── 開発言語やインフラ環境をシンプルに保っている方針や理由は分かりましたが、それだと新しい技術に挑戦したいエンジニアが満足できないのではという気もするのですが。
梅林 いえ、むしろ技術の深度は、複数のプログラミング言語やAWS以外のクラウドで開発するといったところとは別にあるような気がします。このエコシステムをどうやったらより盤石に大きくできるかであったり、抽象化のレベルを設計することも技術力ですし。
もっと言うなら、技術はフィーチャーを作るためのもので、何のためにフィーチャーを作るのかというと、お客様の課題を解決するためであり、売り上げを作るためである。Faciloには、技術そのものより技術を使って目的を達成することが好きで、手段と目的をあべこべにしない、そういうエンジニアが多いと思っています。
エンジニアは自分の仕事を自分で決めたい
── 働き方についてお聞きしますが、採用情報などを見るとフルリモート可ですよね。フレックスタイム制のようですがコアタイムなどは……。
梅林 はい。フルリモートですね。（同席した人事に）補足してもらえますか。
人事 勤務時間はコアタイムのないスーパーフレックスです。小さな子どものいる社員も多いので、朝夕、例えば保育園の送り迎えにあたるような時間帯はSlackから一時的に人が減りますね。逆に朝早く仕事を始めたり、寝かしつけた後で戻ってくる方もいます。
── そうすると勤務時間帯も含めてコミュニケーションは非同期になりますね。
梅林 たしかに「メンションの即レスを期待しない」という標語が全社的に使われていますが、それは仕事のコンテキストスイッチを入れないためでもありますね。集中してタスクにあたっているときにレビューやCSのサポートを依頼されますが、そのとき手掛けている仕事の切りのよいタイミングでやってほしいと考えているので。
逆に非同期のコミュニケーションが中心になると、いかにお互いのビジビリティを高めるかが課題になります。例えば開発においては、分からないことがあったら「分からない」と自分で発信できる方がいいんですよ。
コードを書くときに「何か分かんないけど、他のコードではこうなってるな」という状況があったら、黙ってコピーするよりも「何でこうなってるんでしたっけ？」って聞いてくれればその人の理解度も分かるし、なぜそう実装しているかもきちんと説明できます。
そのためには「何でそんなことが分かんないの？」という空気は絶対に作っちゃいけない。会社全体のバリューとして「100回同じことを聞かれても、100回笑顔で答える」というカルチャーでいこうと全員が本気で思っていますし、だからセールスやカスタマーサクセスの人もエンジニアにどんどん質問や相談をしてきます。
── なるほど。非同期でもどんどん発言をする一方で、即レスはしないものの手が空いたときにきちんと対応するというカルチャーが両立しているのですね。
── さらにエンジニアの開発スタイルは「マルチタスクアサイン」「セルフサインアップ」「チケットに納期を設定しない」だということですが、これはどうしてでしょうか。
梅林 エンジニアは基本的に管理されたくないんですよ。朝会なんて誰もやりたくないですし、僕自身も管理したくない。僕自身が過去にICとして働いてきた経験から、これは不要だなと感じたマネジメント要素を取り除いた結果、このスタイルになっています5。
── プロダクトの成長には、必要な開発タスクをマネージャーが適切なメンバーにアサインしてゴールを決めた方がよいのではないかと思いますが？
梅林 もちろんガチガチに管理したら、短期的にゴールが達成しやすくはなると思います。ある機能をいついつまでに絶対リリースするとして、マネージャーがタスクの依存関係を整理してエンジニアをアサインして毎日進捗確認すれば計画は達成できるでしょう。
でも、その裏ではリリースに関わること以外に、レビュー依頼やサポートからの問い合わせや、セールスからの相談があったはずです。そうしたタスクの優先度が下がってしまいますよね。それは開発組織として違うと思っているんです。
売り上げを増やす要素は、フィーチャーを作るだけではない。セールスの質問に答えた結果として商談が取れたなら、その方が売り上げに寄与しています。だから開発だけがコアジョブじゃないし、社内の手助けをすることもエンジニアの仕事だから、チケットの消化速度も競っていない。全てがコアジョブだと皆には言っています。
── たしかにプロダクト開発だけが事業価値につながるわけではありませんね。
梅林 ちなみにチケットは納期こそ決めていませんが、プロダクトマネージャーが状況に応じてソートしていますから、基本的にタスクを上から取っていけばプロダクトにプラスになるようになっています。
その上でレビュー依頼だったり、開発以外のメンバーの相談だったりにはエンジニア個人の裁量で自由に対応できる方がいいですね。要望の本当のペインを確認した上で解決方法を考えるため、エンジニアが直接お客様とのミーティングに参加することもよくあります。
そうして使っているのは誰で、開発すれば誰がよろこぶかということが分かると開発しがいがあります。そうじゃないと何のために開発しているのかが分からなくなりますね。マネージャーのために開発しているんじゃないので。
プロダクトにコミットしていることを感じられる組織
── プロダクトに対する考え方が技術選定や開発プロセスだけでなく、カルチャーや働き方まで筋が通っているようですが、これは梅林さんが経験から学んだものでしょうか。
梅林 私の経験で言うと、過去に所属したサイバーエージェントではプロダクトをゼロから立ち上げました。次に所属したスマートニュースでは、すでにリリースされたプロダクトをより大きくすることがミッションでした。
プロダクトについて、0から1を生み出すこと、その1を100まで成長させること、その両方を学んできました。だから0から100まで、どうやってエンジニア組織を大きくしていけばよいのかは理解できているつもりです。
大切なことは、いかに個々の社員が「プロダクトにコミットしているか」を感じられるかだと思います。会社が拡大してエンジニア組織の規模が大きくなっても、マネージャーのためにプロダクトを作っている感覚にならないようにする。そのためには、例えば組織の階層はできるだけ浅い方がいいですね。
これからもプロダクトという共通言語を全員が持ち、誰もが気兼ねなく声を掛けられるカルチャーを維持し続けたいと考えています。それによって「みんなで1つのプロダクトを作ってる」という実感が生まれるし、大きな結束力になると思います。
── そういった方が集まるとかなり強い組織になりそうですね。興味深いお話をありがとうございました。
🚀 Faciloではソフトウェアエンジニアを積極募集中 💡
ビジネスモデルからプロダクト・エンジニアリング・働き方まで一貫したFaciloの考え方に共感した方は、ぜひ採用サイトで詳細をチェックしてください！ 🔍✨
募集中のポジションや職務内容に興味のある方は求人詳細をご確認ください 📃
[タイアップ広告] 企画・制作：はてな
取材・構成：青山 祐輔（@buru）
撮影：小野 奈那子（nanakoono_）
- 参照：Forbes JAPAN「次代を担う新星たち 2024年注目の日本発スタートアップ100選｜後編」↩
- 不動産流通標準情報システム（Real Estate Information Network System）の略。参考：国土交通省「建設産業・不動産業：＜消費者の皆様向け＞不動産取引に関するお知らせ」など↩
- 参考：「Facilo（ファシロ）｜不動産仲介業務のためのコミュニケーションクラウド」↩
- 参考：株式会社Faciloのプレスリリース「Facilo、「売主体験」を進化させる新プロダクト『Facilo物件売却クラウド』を正式リリース」↩
- 参考：株式会社Facilo「創業CTOならではの信頼と中長期視点。エンジニアの稼働率を最大にする組織と仕組み」↩
