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