ドメイン未経験PdMは「わからない」を武器にせよ

はじめに

2025年の8月にestieに入社しました高橋です。不動産業界での経験はなく、PdMとしては2社目になります。現在は、すでに一定期間運用され、多くのお客様にご利用いただいている既存プロダクトを引き継いでいます。

当然ながら、既存プロダクトには膨大なコンテキストが存在します。その上、不動産ドメイン未経験の私が、その中でどうキャッチアップしてきたか。コツをお話できれば……とおもうのですが、正直「これをやればうまくいく！」というような魔法のようなtipsはありません。当たり前のことに、体当たりしたり、尻込みしたり……日々悪戦苦闘しているところです。

前提: PdMの仕事は「具体」と「抽象」の往復

PdM（プロダクトマネージャー）は、「なぜ（Why）」と「どうやって（How）」の間をつなぐ仕事だと言われます。
一方では、ユーザーの行動や声といった具体的なデータを観察し、課題やインサイトを掘り下げる。
もう一方では、そこから導かれる本質的な価値仮説やプロダクト戦略を抽象化して、チーム全体の方向性を定義する。この「具体と抽象の往復運動」を通じて、日々の開発判断と長期的なプロダクトのビジョンを接続するのがPdMの役割です。

知らないドメインに飛び込んだPdMが具体側と抽象側、それぞれについて感じていることをお伝えできればと思います。

1. 具体: 社内の共通認識を疑う

既存のBtoB SaaSを引き継ぐPdMにとって、まず大切なのはお客様の実態を理解することです。
ログなどの定量情報も有用ですが、それだけでは見えない部分が多くあります。私はまず、カスタマーサクセス（estieでは「サクセスエキスパート」と呼んでいます）のメンバーに時間をもらい、顧客リストを上から順番に説明してもらいました。

その際、「このお客様は◯◯のセグメントだから、✗✗の業務が多くて、△△機能を気に入って使ってもらっている」と説明を受けました。
浅い知識がない状態の私は「なるほどなぁ、◯◯のセグメントは✗✗の業務が多いんだなぁ」と一旦頷いてしまいます。

ですがPdMは開発リソースの優先順位を判断する立場です。
「その利用方法は◯◯セグメント特有なのか？」「どれくらいの頻度で発生するのか？」「業務時間への影響は？」「そもそも◯◯セグメントとは何を基準に定義されているのか？」──こうした問いを深掘りしていくと、意外と社内でも共通認識があるようでなかったり、あったとしても曖昧なままだったりもします。

曖昧なままでも運用が回っているのだから、実際は問題はないのかもしれません。
それでも商談に同席したり、実際の利用シーンを観察したりして、n=1のリアルな理解を積み重ねることがやはり大切だなと感じています。時間はもちろん限られているのですが「相対している顧客企業の社員が主人公のドラマを描くとしたら、仕事の何に喜んだり何に落ち込んだりしていて、その上でどんな場面で自分のプロダクトが登場するか？」を想像できるくらいまで理解を深められたら、と願わずにはいられません。

とはいえ、具体の掘り下げに時間を使いすぎるとなかなか打ち手は出てきません。ユーザー理解のプロセスを楽しんでしまい、重箱の隅をついつつきたくなってしまうのですが、それだけではアウトカムは得られず、時間だけが過ぎてしまいます。
わからないままでも意思決定し、実行することを求められるのがPdMです。そこで必要になるのが、抽象で捉える姿勢です。

2. 抽象: 他のサービスに喩えてみる

転職をすると、プライベートで会った友人知人に「今どんな仕事してるの？」と訊かれるものでしょう。
私の場合、SaaS業界の友人が多いため、単に「不動産業界のDXをやってる会社だよ」と言うだけでは説明が終わりません。

そこで、相手が不動産に詳しくない前提で、できるだけシンプルに、ホリゾンタルな SaaS プロダクトとのアナロジーを交えながら説明してみることにしました。

例えば、不動産取引には「物件概要書」という書類が必ず登場します。

物件の所在地、価格、面積、構造など、基本的な情報をまとめた書類です。不動産会社が作成し、売主と買主の間で物件情報を共有するために使われ、不動産取引の検討や交渉に不可欠なものです。物件概要書は不動産事業者の間で打ち合わせで紙で渡されたり、PDFファイルをメール添付したりすることで膨大な枚数が日々流通していますが、社内で検索・共有しやすい形で保存されず、資産として有効活用できていないという課題があります。

友人に説明するとして、いきなり「物件概要書というのがあって〜」と話し出してもよいのですが、何かイメージの湧きやすい例えはできないでしょうか。
業界を問わず似たような課題を抱えている書類として、名刺が挙げられるでしょう。名刺をデータ化して社内共有できるサービスなら使ったことがある人が多く、課題感やサービスのイメージもすっと理解してもらいやすいです。
さらにビジネスの文脈から離れると、日々の買い物で受け取るレシートや、スマホで日々撮影される何気ない日常写真もデータとして有効活用されきっているとは言えない状態です。

このように、ドメインについて知らない人に他のサービスに例えて説明していると、かえって自分自身の理解や整理に役立つことに気づきました。
例に挙げたようなサービスの機能や施策、さらに歴史を調べてみると、「具体」のドメイン理解が不十分な状況でも、打ち手に説得力を持たせることができそうです。

ホリゾンタルな BtoB SaaSで考える: 名刺管理サービス

先に例として出した名刺管理ツールの場合、短期的には名刺をデータ化し、社内での共有を促進することが重要です。プロダクトで追うべきKSMや各種KPIも一旦、類似のものを考えてから、業界特有の要素がないかを考えればよさそうです。
さらに中期・長期の戦略として、名刺データはSFAやCRM、MAといった外部システムに連携することで、さらなる活用がなされてきました。データを抽象化してグラフとして見せることで新たな示唆に繋げた例もあれば、ユーザーに許可を取って企業間にデータ公開範囲を広げた例もあるでしょう。

toCサービス: 画像共有サービス

同様の構造は、toC領域にも数多く見られます。
例えば写真整理アプリでは、短期的にはユーザーが膨大な写真を整理・検索できるようにすることが中心的な価値でした。Google Photos や Apple Photos のように、AIを用いて人物や場所を自動で分類・タグ付けすることで、“探せない”“埋もれる”といった非構造データの課題を解消しています。
中期・長期のフェーズでは、単なる整理を超えて、写真を「意味のある文脈」に再構成する方向へ進化しました。自動アルバム生成や思い出のハイライトなど、“データを見返したくなる体験”を設計することで、ユーザーの感情や行動を喚起しています。
不動産の文脈で考えると、物件写真や図面、現場のスクリーンショットなど、これまで蓄積されながら活用されにくかったビジュアル情報にも、同様のアプローチが応用できそうです。単なるファイル共有ではなく、「いつ・どの案件・どの顧客に関する写真か」という文脈を紐づけることで、ナレッジとして再利用できる基盤を作れる可能性があります。

toCサービス: 家計簿サービス

また、家計簿アプリも興味深いアナロジーを提供してくれます。短期的にはレシートや明細といった散在する支出データを自動で集約し、グラフやカテゴリで可視化することが主な価値でした。MoneyForward ME や Zaim などは、銀行口座やクレジットカードを連携して“手入力を不要にする”という明快な課題解決を実現しています。
やがて家計簿は、単なる記録から「行動を変えるツール」へと発展しました。可視化したデータをもとに節約のアドバイスや将来シミュレーションを行い、“気づきから意思決定”を促す設計です。
この構造を不動産業務に重ねると、日々の取引データや顧客行動を集約・可視化することが、提案や意思決定の質を高める手がかりになりそうです。データを記録する段階から、データを解釈し次の一手を導く段階へ──家計簿がたどった進化の道は、不動産領域にも通じるものがあるように感じます。

こうして他業界のアナロジーを引いてみると、Vertical SaaS の文脈でも「構造化 → 文脈化 → 意思決定支援」というパターンが見えてきます。
名刺管理、写真整理、家計簿──いずれも“散在するデータを整理する”ところから出発し、最終的には“人や組織の行動を支える基盤”へと進化してきました。
不動産業界も同じように、紙やPDFに埋もれている情報を再構造化し、活用可能なデータとして循環させていく。その過程に、まだ多くの挑戦と可能性があるのではないでしょうか。