Facilo（ファシロ）は、不動産仲介という業務フローが極めて複雑な領域で、あえて「構成・組織・開発プロセス」をできるだけシンプルに保つ方針を選んできました。
シングルデータベース、削除フラグなし。さらに、Devinを標準ツールとする全社的なAI活用まで。
なぜそこまでシンプルさにこだわるのか。その判断は、マルチプロダクト展開という事業戦略や組織づくり、AI時代のエンジニアの価値とどうつながっているのか——。
今回は、同社CEOの市川紘さんとCTOの梅林泰孝さんに、Faciloのプロダクトの現状と技術・組織に通底する設計思想を伺いました。
※ この記事は株式会社Faciloによるタイアップ広告です。
- 一点突破から「マルチプロダクト戦略」に振り切った理由
- マルチプロダクトになっても開発スピードが落ちないように準備してきた
- データベースは一つ、「外部キー」や「削除フラグ」は設けていない
- ベストプラクティスを前提にしないシンプルな設計
- 会社のカルチャーとエンジニア組織の考え方に通じる「手触り感」
- Devinを全社員に導入して分かったAI時代のエンジニアの価値
- 希有な成長マーケットで先進的なAI活用方法を学べる
- 🚀 Faciloではソフトウェアエンジニアを積極募集中 💡
一点突破から「マルチプロダクト戦略」に振り切った理由
── Faciloは、不動産仲介における煩雑な業務や、顧客とのコミュニケーションを一元化・可視化するSaaSを提供しています。サービスが現場に浸透してくる中で、最近のお客さまの反応などで印象的なものはありますか。
市川 紘（いちかわ・こう）
株式会社Facilo 代表取締役 CEO。新卒でリクルートに入社し、SUUMO（不動産領域）の営業・プロダクト・新規事業開発に携わった後、2016 年にシリコンバレーの不動産テック企業 Movoto に渡りCFOとして経営に参画。企業の成長とM&A（EXIT）に関与した経験を持つ。2021年に梅林泰孝と共にFaciloを共同創業し現職。現在はAIを活用したプロダクト開発や組織づくりにもハンズオンで取り組んでいる。
市川 私たちが挑戦する不動産テックの事業領域、特に不動産仲介というマーケットは非常に複雑です。複数の関係者が絡み、取引が同時並行で進みます。営業担当者は物件情報をPDF化してメールやLINEで送り、内見調整の電話をする……。
このため、不動産業界に携わる経験の浅い方は、自分がどの業務をしているのか整理が付かず、混乱してしまうこともあったといいます。
ところが私たちのプロダクトを導入したことで、業務が改善されて、「ようやく仲介営業としての自信がついた」というお話を伺ったことがあります。
挫折しそうなところをテクノロジーでサポートし、「人生の基盤となる住宅で役に立ちたい」という思いを後押しできているのは、率直にうれしいですね。
「毎朝、仕事を始めるときにOutlookと一緒にFaciloを立ち上げる」という光景が当たり前のようになりつつあり、業務に深く根付いてきている手応えを感じています。
── そうした手応えもある中で、プロダクトの数も増えていますよね？ 現在はどのような状況なのでしょうか。
市川 資金調達の際に思い描いていたプロダクトは二つしかありませんでした。一つは、祖業であり、一番最初に作ったプロダクトである「Facilo物件購入クラウド」です。
同時に、購入と表裏一体の売却を支援する「Facilo物件売却クラウド」もプランとして出していましたが、二つ目ですら当初の予定よりは遅らせ、長らく一点突破型で走ってきました。
現在は「Facilo賃貸仲介クラウド」と「Facilo事業用クラウド」が加わり、結果として4つのプロダクトを擁する「マルチプロダクト」なプラットフォームビジネスになっています。
── 最初からマルチプロダクトを前提にシステムを設計していたのでしょうか。
市川 実は弊社が「マルチプロダクト戦略」を最初から戦略として目的化したことは一度もないんです。私の前職での原体験から、スタートアップとしてはやるべきことを絞るべきだという考え方があり、どちらかといえばマルチプロダクトに対してはアンチパターンという捉え方でした。
ですが、今はマルチプロダクト化に振り切っています。「物件購入クラウド」の導入が進み、顧客との接点が増えるにつれて、「このペイン（課題）も解けるかもしれない」という課題の解像度が一気に上がってきたのが大きな理由です。
── 具体的にはどのような顧客課題があったのでしょうか。
市川 不動産仲介の会社は、「売買」と「賃貸」の両方を手がけているケースが多いのです。「物件購入クラウド」「物件売却クラウド」の「売買」の二つのプロダクトのコンセプトや技術力を評価していただきながらも、ドメインがちょっとずれている「賃貸」には対応できない——。「賃貸でも使いたい」という声をたくさんいただき、「賃貸仲介クラウド」をリリースしました。
同様に、店舗やビル、オフィスといった「事業用」の不動産でもプロダクトを使いたいという声をいただき、生まれたのが「事業用クラウド」です。
── 現場の声に対応していった結果なんですね。
市川 「物件購入クラウド」に集中する一点突破の期間をフェーズ1と位置づけると、お客さまの声に沿ってマルチプロダクト化をしていったのがフェーズ2です。これからのフェーズ3では、より戦略的にプロダクト間をつなげて複合的な課題を解決していきたいという構想を描いています。
段階を経てマルチプロダクト戦略になっていったと言えるかもしれません。ただ、それはあくまでも「手段」です。
マルチプロダクトになっても開発スピードが落ちないように準備してきた
── 一点突破から始まってプロダクトが拡大していく中で、欠かせない技術的要件にはどのようなものがあるのでしょうか。
梅林 泰孝（うめばやし・やすたか）
株式会社Facilo 共同創業者 CTO。新卒でgoogleに入社し、検索品質向上チームに従事。その後、サイバーエージェントで「AirTrack」を開発責任者として国内最大の位置情報プラットフォームに成長させる。米国シリコンバレーでスマートニュースのテックリードを務めたのち、2021年に米国在住のままFaciloを共同創業し現職。帰国後の住まい探しでは、Faciloを通した物件提案をエンドユーザーとして体験した。
梅林 市川から「マルチプロダクトを目的にしたことはない」とお話しましたが、僕自身は「いつかはマルチプロダクトになっていくんだろうな」という思いが創業時からありました。
というのも、バーティカルSaaSにとって、マルチプロダクト戦略でいろいろなプロダクトを作っていくことはベストプラクティスだからです。ただ、プロダクトが増えるタイミングで人・構成・運用が一気に複雑化しがちです。そこに耐えられる“共通の型”を先につくっておく必要がある。
「もしそうなったときに、開発スピードが落ちる構成だけは絶対に避けたい」と、ずっと考えてきました。Ruby on Railsというフレームワークを選んだのもそうした前提で、「誰が触っても同じ構造で、すぐに次を作れる」ことを重視した結果です。創業時としては最適な技術選定だったと思います。
── Railsにはどのようなメリットがありましたか？
梅林 普通の会社だと、オンボーディングした新しいエンジニアが最初にリリースをするまでには、早くても1週間程度はかかります。
ですが、Faciloでは、ライトなチケットであれば、オンボーディング初日にリリースができるくらい手軽です。ローカル開発環境のセットアップが非常に単純化されており、インフラもシンプルに保たれていることが特徴です。
データベースは一つ、「外部キー」や「削除フラグ」は設けていない
── 現在4つのプロダクトを展開しているFaciloですが、一般的にはプロダクトごとにデータベースを分けるケースが多いと思います。Faciloでは、どのようにデータを管理しているのでしょうか？
梅林 教科書的な設計であれば、プロダクトごとにデータベースを構築するのが当たり前ですが、Faciloではデータベースは一つなんです。
物理的にはシングルデータベースクラスタで複数のプロダクトを運用し、論理的にネームスペースをプロダクトごとに分けています。
── データベースを一つにまとめている場合、ユーザー数やデータ量が増えたときは、どのように対応しているのでしょうか。
梅林 データベースはまず縦にスケールさせる戦略を取っています。
10年前、20年前のインフラであれば、一つのサイズを大きくするにも一定の限界があったため、横にスケールさせる戦略しか取れませんでした。ですが、現在のデータベースの性能は昔に比べてはるかにアップしているため、サイズ自体を限界まで大きくしたいと思っています。
僕たちのプロダクトはBtoBのサービスがメインで、数千万ユーザーを相手にするような大規模なBtoCサービスとは前提が異なりますからね。
── 保守運用体制はどうなっていますか。
梅林 「この人じゃないと管理できない」というような、属人化しやすい専門の人を作らないようにしたいんです。だからFaciloにはSREもいません。逆に言えば、エンジニア全員にインフラやCI/CDパイプラインの流れを理解してほしいと考えています。
例えば、ソフトウェア開発とSREというように組織を分けて、インフラ側が「バックエンドエンジニアがインフラのことを何も気にせずに触れるような環境を作ったよ」とやってしまうと、ブラックボックス化してしまいます。
そうではなく、バックエンドエンジニアがインフラのことを常に理解し、その上でいかに監視コストを減らしていくかを考えるべきです。
── データベース設計について教えてください。Faciloでは外部キー制約を設けていないと伺いましたが、どのような判断だったのでしょうか。
梅林 外部キーを入れないと聞くと、少し過激に感じる方もいるかもしれません。ただ僕らが重視しているのは、「認知コストを下げること」と「スケールしにくい書き込み処理をできるだけ早くすること」です。
もちろん、銀行のシステムのように整合性が非常に大切なドメインであれば、トランザクションをしっかり組み、データベースの整合性を厳密に管理すべきでしょう。
削除フラグも同様で、とりあえず入れてしまうと、「このテーブルには削除フラグがあるか」「このクエリでは考慮が必要か」といった判断があらゆる場所で発生します。開発時の認知コストがどんどん上がってしまうのです。
Faciloの場合は「そもそもなぜ削除フラグが必要なのか？」から考えます。
誤操作から復元したいのであれば、まず誤操作が起きにくいUXにしよう。それでも誤操作が起きるとしたら年に何件なのか、その確率と設計の複雑さのトレードオフで考えます。実は削除フラグではなく、更新履歴として違うものをつくるべきかもしれません。問題の本質を常に考えながら、設計が開発効率に与える影響を吟味しています。
復元が必要なケースについても、今のAI時代はCloudWatchのログをAIエージェントにgrepさせることで、人力でも十分対応できます。
ベストプラクティスを前提にしないシンプルな設計
── 組織設計にしろ、データベース設計にしろ、教科書的には「アンチパターン」とされる手法を選択し、結構定石に反している印象を受けます。
梅林 ベストプラクティス自体は、過去の経験や教科書を通して一通り学んできました。
ただ、Faciloのビジネスや規模を前提に考えると、「本当にそこまで必要なのか」を毎回問い直しています。教科書的には正しいとされる構成でも、運用や組織まで含めて見ると、かえって複雑さを招くこともあります。
以前、僕が大きな組織で働いていたとき、インフラが強く抽象化され過ぎていて、「裏側で何が起きているのか分からない」ことに強い違和感を持ちました。
本来は開発しやすくなるはずの仕組みなのに、実際にはインフラエンジニアへの問い合わせが増え、承認フローもどんどん複雑になっていく。これでは開発側も運用側も幸せになっていないのではないかと思ったんです。
実際には、インフラとアプリケーションは密接に結びついています。それなら、バックエンドエンジニア自身がインフラを理解し、自分の操作とシステムの挙動が結びつく「手触り感」を持った方が自然です。
一見すると、「何も知らないエンジニアが作った構成」に見えるかもしれませんが、それはベストプラクティスとしてある分散構成や、ハイパフォーマンスなシステム構築をすぐに候補から外したわけではありません。
例えばRedisを使えば、キャッシュやセッション管理、キューなどを高い性能で処理できます。しかし、その性能がオーバーエンジニアリングではないのかと、期待されるスループット量から逆算し、どの程度ちゃんと作るべきなのかを常に見極めています。
そうした判断の積み重ねが、システムと組織のスケーラビリティを支える「シンプルさ」につながっています。
この考え方は組織も同じです。エンジニア職種が20人程度という今の規模であれば、横断組織を作るよりも、チームを小さく保ち、全員が同じ設計思想を共有している方が、スピードを落とさずに済みます。
── チーム作りにもシンプルさを適用しているんですね。
梅林 これも規模の問題だと思います。エンジニアだけで100人、200人を超えたり、世界中で分散して開発を進めているような組織であれば、縦割りにしたり、横断組織を作ったりする必要があるでしょう。
組織構造のベストプラクティスも理解していますが、それがどんな規模の企業での前提で語られているのかを見た上で、現在のFaciloにとって本当に必要かどうかを見ています。
会社のカルチャーとエンジニア組織の考え方に通じる「手触り感」
── ビジネス戦略とのつながりという点では、市川さんはどう見ていますか。
市川 会社として大事にしていることと、エンジニア組織の考え方がきれいにリンクしているのが、Faciloの強みだと感じました。大きく分けると、二つあります。
一つは、手段と目的を逆転させないことです。私たちの目的は、クライアント企業の課題解決や事業成長であり、そのためにプロダクトがあり、技術があります。この順番を組織全体で共有しています。
ですから、モノ作りが好きで、そのプロダクトを通してお客さまやその接点となるカスタマーサクセスやセールスに「ありがとう」と言ってもらえる「手触り感」が好きというカルチャーが、会社全体に共通しています。
もう一つは、定石を理解した上で、あえて型を外すという姿勢です。一見するとセオリーから外れているように見える部分も、基礎を押さえた上で、事業や組織にとって最適だと考えて選んでいます。
これはエンジニアに限らず、セールスやカスタマーサクセスなど、全職種に共通する考え方です。
梅林 もちろん、常に型を破ることが目的ではありません。アプリケーションのコード自体はRailsのレールに乗って定石通りに作る。一方で、インフラやDB設計はビジネスの速度を優先してあえて定石を外す。このように「どこは定石通りに作り、どこであえて外すか」を常に見極めています。
例えばRailsの良さを生かせる場面では、あえてサーバサイドレンダリングを採用し、フレームワークの王道から外れない使い方をしています。
一方で、よりインタラクティブな体験が求められる部分では、Reactを使ったSPA構成を選ぶこともあります。全てを最新技術で固めるのではなく、「標準的な作りで十分なところはシンプルに」という方針で、敬遠されがちなStimulusも普通に使っています。
── 本当に是々非々で選択しているんですね。
市川 型から外れること自体を目的にしてしまうと、それもまた手段の目的化になってしまいますから、それぞれの局面において最適なものを選んでいます。
Faciloの急成長を支えているのは、こうしたカルチャーによる開発のスピードです。セールスやCSが現場接点の中でいただいた要望やフィードバックは、1営業日以内にSlackのフォームから投稿するルールにしています。それをプロダクトマネージャー（PdM）がチケット化してエンジニアにつなぐサイクルを通して、週に10件から20件の機能をリリースしてきました。
お客さまからは「見たことのないスピードで対応してもらえている」と高く評価していただいています。
Devinを全社員に導入して分かったAI時代のエンジニアの価値
── 全社的に生成AIを活用されていると伺いました。現在はどのように使われているのでしょうか。
市川 まず2024年の12月に、「ChatGPT Pro」を全エンジニアに配布しました。当時シリコンバレーに住んでいた梅林が「生成AIに対応しないといけない」と危機感を抱き、挑戦することになりました。梅林が「コードを書いたら負け」と宣言し、生成AIだけで開発する期間を2カ月ほど設けました。
梅林 エンジニアに「AIはまだ微妙でしょ」という意識があると、AIの能力を過小評価したままコードを書き続けてしまい、AIフレンドリーになれません。
そうではなく、AIをしっかり信頼し、「一度エディタを捨ててみよう」と提案して開発してもらいました。AI自体の進化もありますが、みんながAIをどう活用すべきかを真剣に考えるようになり、開発組織においてはAIが相棒のようになってきました。
その後、2025年2月に標準ツールとして全エンジニアに「Devin」アカウントを作成し、段階的に全社員へ活用範囲を広げました。最初は試行錯誤でしたが、この数カ月で実運用に耐えるレベルまで安定してきました。
市川 組織としてのAI活用は、結果的に3段階で広がってきました。
最初の段階は、エンジニアの開発での活用です。各自が最適な使い方を見出したことで、開発生産性は体感で3倍ほどに向上しました。
次の段階が、PdM業務への展開です。エンジニアが、PdMでも自然言語で安全に開発できる環境を整えてくれたおかげで、PdM自身が「自分でできるかどうか」を判断し、軽微な修正であれば自ら実装からデプロイまで行うようになっています。
そして3つ目が、セールスやCSへの展開です。仕様確認や簡単な分析をSlack上で自然言語で尋ねると即座に返ってくる仕組みを整えたことで、エンジニアへの問い合わせが減り、現場のスピードが大きく向上しています。
特に第2段階と第3段階では、単なる効率化ではなく、業務の進め方や役割そのものが変わる「変革」レベルの変化を感じています。
── そうなると、エンジニアの役割や価値はどうなるんでしょう。
梅林 「ゼロからこういうものを作りたい」という程度ならば、Devinに依頼すれば作れると思います。
ただ、要求を満たす複数の解法の中から、それぞれの善し悪しについても、何度も尋ねて往復を重ねればたどり着けますが、こうしたプロセス自体が大きなロスになります。一方でエンジニア相手であれば往復の回数は絶対に減ります。
やはり、今までの技術の蓄積や知識を使って、いかに最少のラリーで最適なものを導けるかがエンジニアに求められていくと思います。
市川 私自身もDevinを使ってハンズオンで開発するようになっていますが、エンジニアがどれだけ複雑で高度なことを、さまざまなプレッシャーの中でやってくれているのか、よく分かるようになりました。広い視野を持って、依存関係なども意識しながら課題を解いてくれている。
ですから、PdMがハンズオンで開発できるようになって「エンジニア不要論者」になっているかというと、むしろ逆で、エンジニアの価値を再認識した感覚があります。
希有な成長マーケットで先進的なAI活用方法を学べる
── エンジニアにとっても新しい働き方ができそうですね。
市川 Faciloはエンジニアにとってもエキサイティングな環境だと思っています。
不動産仲介という分野が扱う「住まい」は、あらゆる人の人生の根幹です。人口減少で多くの市場が縮小する中でも、中古不動産流通など成長分野があり、なおかつデジタル化の余地が大きい、希有なマーケットだと思います。
そんな市場に向き合いながら、プロダクトを通してやりがいや手触り感を得られるのは、エンジニアにとっても大きな魅力だと思います。
梅林 僕はCTOとして、いかにエンジニアが快適にプロダクトの開発にコミットできるか、ということだけを常に考えています。
その考え方は、無駄なコミュニケーションを省き、必要なコミュニケーションをしっかり取るという組織のあり方や、インフラの思想にも表れていると思います。
AI時代になり、ぶっちゃけてしまうと、技術選定そのものの重要性は相対的に下がってきています。
Faciloでは、その前提に立った上で、AIの活用にフルベットしています。他社と比べても非常に高い割合で活用しており、今後はエンジニアの人材戦略においても、AIを使いこなせるかどうかが重要な指標になると考えています。
その意味で、Faciloではより先進的なAIの活用方法を学べると思います。
🚀 Faciloではソフトウェアエンジニアを積極募集中 💡
必要なものを見極め続ける設計思想。AIとともに働く前提で、役割や仕事の進め方そのものを更新していく開発環境。
こうしたFaciloの考え方に共感した方は、ぜひ採用サイトで詳細をご覧ください。 🔍✨
募集中のポジションや職務内容に興味のある方は求人詳細をご確認ください 📃
[タイアップ広告] 企画・制作：はてな
取材・構成：高橋 睦美
