こんにちは！ソフトウェアエンジニア (SWE) の安東です。このたび正式リリースされることになった estie 物件売買 というプロダクトを普段は開発しています。その中でも特に、ユーザーに提供するデータの管理システムを中心に実装していることが多いです。
さて、この度この estie 物件売買で、なんと estie 第1号となる特許を取得できました！
estie 物件売買のプロジェクトの開始から約1年、特許査定も製品公開も無事迎えられたということで、今回は特許取得について振り返ってみようと思います！
estie 物件売買の紹介
inside blog 初登場！まずは estie 物件売買の簡単な紹介です！
estie 物件売買を平たく言うと、不動産の売買取引相手を見つけたい企業を主な対象にした、建物の所有者情報と、募集賃料や空室率などの estie 独自の建物データとを組み合わせて検索できるプロダクトです。売買取引をするにはまず交渉相手となる所有者が誰か知る必要があります。しかし、せっかく建物の所有者がわかっても、取引交渉にはなかなか進めないものです。そこで、建物の保有期間、募集賃料、直近の売買事例などの条件で所有者を検索することで、「この会社は似たような規模のオフィスビルを最近買っているから、こっちのビルも買ってくれそう」などといった戦略を立てて取引相手の候補を見つけられるわけです。
そして、estie の掲げている Whole Product 構想（詳しくは、久保のブログ を参照ください）の中での立ち位置でいうと、estie として初めて売買領域に進出したプロダクトになります！
プロダクトの技術的な構成を大きく分けると、サービスを提供する Web のフロントエンドとバックエンドと、所有者情報などのデータ管理の2つに分かれます。言語・フレームワークは、Web のフロントエンドとバックエンドが TypeScript (NestJS + Next.js + Prisma)、データ管理が Rust + Python という組み合わせになっています。私が主に担当しているのは、ユーザーに届けるデータを作る、後者のデータ管理の部分です。
どんな特許？
それでは、今回取得した特許はどんな内容なのでしょうか？一般的に、一つの特許には請求項といって発明の内容が複数含まれますが、今回の特許の中から一番重要な発明の部分を抜き出すと、
- 建物の登記簿を自動で読み取ってデータベース化したよ
- 登記簿には載っていない賃料情報などを組み合わせて、より情報がリッチなデータベースを作ったよ
- このデータベースを使うと、売買取引に適した検索ができるようになるよ
以上の3点がセットになった特許になっています。
estie 物件売買は建物の所有者情報のデータソースの一つとして建物の登記簿を使っているのですが、今回の特許は、所有者情報を登記簿から集めて建物データと一緒にユーザーに提供する、というまさにプロダクトそのものを表した特許なんです！組み合わせたデータを作成する、という一番重要な箇所を作ったので、今回の特許の筆頭発明者は私になっています。
実際の特許にはこのほかに、データベースとして抽出したり紐づけたりする情報の範囲や、登記簿の更新の方法などが盛り込まれていて、全体像はもっともっと複雑になっています。
ところで、不動産への関わりがこれまで薄かった方にとっては登記簿にどんな情報が載っているかイメージしづらいと思います。そこで、架空の建物の登記簿を作ってみました。
┏━━━━━━━━━━━━━━━━━━━━━┯━━┯━━━━━━━━━━━┯━━━━━┯━━━━━━━━━━━━━┓ ┃ 表 題 部 （主である建物の表示）│調製│余 白 │不動産番号│９８７６５４３２１０９８７┃ ┠─────┬───────────────┴──┴───────────┴─────┴─────────────┨ ┃所在図番号│余 白 ┃ ┠─────┼──────────────────────────────┬───────────────────┨ ┃所 在│Ａ市Ｂ町一丁目 ２番地 │余 白 ┃ ┠─────┼──────────────────────────────┼───────────────────┨ ┃家屋番号 │２番の３ │余 白 ┃ ┠─────┼────────────┬─────────────────┼───────────────────┨ ┃１ 種 類│ ２ 構 造 │ ３ 床 面 積 ㎡ │ 原因及びその日付〔登記の日付〕 ┃ ┠─────┼────────────┼─────────────────┼───────────────────┨ ┃共同住宅 │鉄骨造陸屋根地下１階付４│ １階 １２３：４５│令和３年２月１日新築 ┃ ┃車庫 │階建 │ ２階 １２３：４５│ ┃ ┃店舗 │ │ ３階 １２３：４５│ ┃ ┃ │ │ ４階 １２３：４５│ ┃ ┃ │ │ 地下１階 １２３：４５│ ┃ ┗━━━━━┷━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━┛ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ 権 利 部 （ 甲 区 ） （所 有 権 に 関 す る 事 項） ┃ ┠─────┬────────────────┬───────────┬─────────────────────┨ ┃順位番号 │ 登 記 の 目 的 │受付年月日・受付番号 │ 権 利 者 そ の 他 の 事 項 ┃ ┠─────┼────────────────┼───────────┼─────────────────────┨ ┃１ │所有権保存 │令和３年３月３日 │所有者 東京都Ａ区Ｂ町一丁目１番１号 ┃ ┃ │ │第１２３４５号 │ 株 式 会 社 Ａ 不 動 産 ┃ ┠─────┼────────────────┼───────────┼─────────────────────┨ ┃２ │所有権移転 │令和４年５月６日 │原因 令和４年４月３１日売買 ┃ ┃ │ │第２３４５６号 │所有者 ┃ ┃ │ │ │ 東京都Ｃ区Ｄ町二丁目３番Ｅビル４０５号室┃ ┃ │ │ │ Ｂ 建 物 株 式 会 社 ┃ ┗━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━┛
この登記簿からは、例えばこのようなことがわかります。
- この建物はA市B町にあって、令和3年2月1日竣工、地上4階/地下1階建て、どの階も広さが123.45㎡
- 最初の所有者は株式会社A不動産
- 約1年後にB建物株式会社に売却
こういった情報をデータベース化して、賃料情報などと組み合わせて estie 物件売買として提供しているわけです！
特許・リリースまでの壁
ここからは、今回の特許を取得して estie 物件売買の正式リリースに至るまでの個人的難所を振り返ってみようと思います！
表組みの読み取り
上に載せた登記簿のサンプルは、罫線文字や全角空白などを組み合わせて桁数合わせされた、いわゆるアスキーアートになっています。これは記事中に表組みを挿入できなかったからアスキーアートで書いたというのではなく、登記簿PDFをオンラインで取得すると本当にPDFの中身がこのようなアスキーアートになっているのです。セル結合を多用したいわゆるネ申エクセルですらなく、最初の所有者東京都A区B町一丁目1番1号 株式会社A不動産というテキストをコピーするだけでも一苦労です（しかも、株式会社A不動産の間には丁寧に1文字ずつ全角空白が織り交ぜられています）。
ということで、最初の難所は、アスキーアートを解釈して表としてデータ抽出する実装そのものでした。特に最初の頃はどんな表組みがやってくるのかよくわからなかったので、想定外のパターンが来てもすぐ対応できるように汎用性を持たせた実装にするのが大変でした。
ところで、実はこの架空の登記簿、他にもいくつかツッコミどころがあります。一つ一つの対処は大変ではなくても、全体を通してみると対処すべき箇所が大量にあった、というのも読み取りの上での大変なポイントでした。例えば、所在欄にあるA市B町は何県にあるのでしょう？同じ名前の市区町村があったときに区別できるでしょうか？ここではツッコミどころの全部の正解は書きませんので、他にどんなツッコミどころがあるか、ぜひご自身で探してみてください！
ドメイン理解
2番目の難所、それがシステムとして作り込める程度に不動産取引に関して理解することでした。人間が実務として取り扱うのに必要な理解と、システムとして作り込むのに必要な理解とでは方向性や深さが違うのです。
例えば、建物の売買取引を平たく言うと「お金を払うかわりに建物を所有する」ことですね。しかし、この「建物を所有する」という概念だけでも実はかなり曲者です。
まず、建物を所有する手段として、所有権そのものを獲得する以外に、建物から得られる利益（賃料収入など）を受け取る権利を獲得することで建物を実質的に所有する、という方法があります。次に、建物一棟まるごと所有する以外に、建物の一部分だけ所有する、という方法があります。最後に、所有権は一社（一人）で独占しても構いませんし、複数社（複数人）で共有しても構いません。これらをすべてあわせると、「建物を所有する」だけで実は 23 = 8通り の方法をひとまとめにした表現になっています。これら8通りの所有のしかたは登記上すべて異なる書き方になりますし、不動産取引の際の扱いも微妙に異なります。
このように、日常用語では同じ言葉で表されるにもかかわらず実態の異なる用語が、不動産取引や登記簿にはいくつも出てきます。言葉の実態も含めて深掘りする必要があったのは本当に大きな壁でした。
スキーマ管理
データマネジメントあるあるなのですが、データをたくさん集めてみると今までのモデルに合わないものに必ず遭遇します。1つしかデータの入らないカラムだと思っていたら実は複数入ったり、稀にしか起こらない書き方のパターンが紛れ込んでいたりします。これは特に登記簿など実世界の事象を記録したデータを扱う上でどうしても発生してしまうことです。
登記簿でいうと、登記簿をたくさん集めて調べると、新しい種類の権利移転が見つかることがかなりよくありました。例えば、記事の前半に挙げた架空の登記簿には「誰々が所有権を獲得した」ということしか書かれていませんが、時々「建物が差押された」ということが書かれていたりします（なお、厳密には差押された時点では所有権は移転していません）。
登記簿は不動産の売買取引だけではない様々な権利の移転履歴を法律の世界の言葉で記録した帳簿です。実世界のありとあらゆる不動産の権利移転を扱ってるので、中には稀にしか起こらないような取引も当然紛れ込んできます。このような状況だと、伝統的な RDB だけでデータ管理しようとすると、カラムを文字列から文字列の配列にしたり稀にしか起こらない新しい種類のイベントを取り扱ったりするためだけに新しいテーブルを次々作り、その度にマイグレーションすることになりかなり大変です。
開発初期のデータベーススキーマのごく一部。アプリケーションから使いやすいようにマスターデータを加工したあとでも図の中央部分などで細かいテーブルが発生する状況なので、マスターデータをすべて RDB で管理するのは絶望的。 そういう理由で、estie 物件売買のマスターデータ管理は RDB による管理を完全に諦めています。マスターデータのスキーマを Rust の struct や enum で管理し、データ加工も Rust で実装するようにしています。
実は最初は estie の既存のデータパイプラインと揃えてすべて Python で実装していました。しかし、Python は型の表現力が弱くパターンマッチの網羅性チェックもなく実装が破綻したので、これらの欠点を克服できる Rust に移行しました。このような背景から、Rust に移行する恩恵が少ない部分や外部ライブラリ的に仕方のない部分を中心に Python のコードが残っている、というのが Rust と Python のハイブリッドになっている理由です。
このように、estie では王道になっている RDB でのマスターデータ管理を早々に諦めたり、データ加工処理の実装言語を途中で変える必要があったりと、現実世界の出来事を正確に反映できるデータスキーマの管理には大変苦労させられました。
おわりに
思い返せばあっという間に時間が過ぎ去ってしまいましたが、この1年間の estie 物件売買の開発はとても楽しく充実したものでした。登記簿のアスキーアートをなんとか読み取ったり技術選定をやり直してでも実装を進めるような技術的腕力、言葉の意味を深掘りして追いかけていくような技術以外の力、そしてスキーマを現実に合わせて変えていくすり合わせ力、どれが欠けても成り立たなかった、まさに総合格闘技のような開発でした。
今日の記事は特許を取ったことがきっかけのものでしたが、特許取得はゴールではなく単なる通過点でしかありません。ということで、これからも今までの1年間と変わらず、いや、さらに加速して、ユーザーの皆様の嬉しさを最大限増やせるよう製品開発と機能提供を続けていきますのでよろしくお願いします！
そして少しでも estie 面白そう！と思ったなら、下のリンクからカジュアル面談を気軽に申し込んじゃってください！
