不動産 DX を発注する前に、社内で決めておくべき 5 つの判断
不動産 DX のプロジェクトが「途中で止まる」「使われないツールが残る」「何度発注しても要件が合わない」というケースを、20 年の現場と 10 年以上の DX 発注経験で何度も見てきました。
原因の大半は、ベンダーが悪いのではなく、発注する側が決めるべき判断を曖昧にしたまま発注していることです。本記事では、ベンダーに相談する前に社内で言語化しておくべき 5 つの判断軸を整理します。
なぜ「事前判断」が必要なのか
不動産業の DX は、業界外のソフトウェアパッケージで完結しません。地域慣習・自社運用・大口オーナーごとの特殊契約が必ずどこかに存在し、業界の最大公約数を実装した汎用ツールでは穴が残ります。
その「穴」をどう埋めるか、どこまで人が残し、どこから自動化するかは、ベンダーが勝手に決められる範囲ではありません。発注する側で決めずに「お任せします」とすると、ベンダーは安全寄りの提案しかできず、結果として「合っていそうな構成」になります。
これが「動かしてみたら現場で使われない」になる典型パターンです。
判断 1: 基幹システムを「活かす」か「入れ替える」か
最も大きい判断です。基幹（賃貸管理ソフト・販売管理ソフト等）を残すか入れ替えるかで、プロジェクトの規模は 10 倍以上変わります。
「活かす」を選ぶべき条件
- 契約・家賃送金など本流の業務は基幹で回っている
- 不満は「周辺業務」（修繕履歴・オーナー報告・滞納督促など）に集中している
- 入れ替えコスト・現場混乱を取りに行くだけの余力がない
- 基幹データを CSV / API で取り出せる
「入れ替える」を選ぶべき条件
- 基幹自体の運用に大きな不満があり、契約期限が近い
- 数字管理・経営判断の解像度を上げたいが、基幹の出力が貧弱
- 業界標準とズレた独自運用が、基幹のバージョンアップで詰まった
- 経営として「業務基盤の統合」を中期戦略に置いている
入れ替えを選ばない限り、まず周辺業務を kintone のサブシステムで仕組み化する選択肢を検討するのが現実的です（詳細は賃貸管理 kintone サブシステムの 8 領域）。
判断 2: 「標準化」を取るか「個別カスタム」を取るか
DX で必ず出てくる衝突です。
標準化のメリット・デメリット
- メリット: ベンダーロックインが少ない、保守が楽、新人教育が楽
- デメリット: 自社固有の競争優位や業界慣習が落ちる
個別カスタムのメリット・デメリット
- メリット: 業務に完全に合う、独自の差別化が残る
- デメリット: 改修コストが永続的にかかる、属人化、ベンダー依存
判断の起点は「この業務は競争優位の源泉か、そうでないか」です。
| 業務 | 推奨 |
|---|---|
| 経理・会計（月次仕訳・証憑） | 標準化（汎用 SaaS の API + 軽い自動化） |
| オーナー対応・物件巡回 | 個別カスタム（自社独自の関係性が競争優位） |
| 入退去・契約事務 | 半標準化（業界共通フローを残しつつ、地域慣習だけ個別） |
| 経営ダッシュボード | 個別カスタム（経営者の判断軸は会社ごとに違う） |
「全部カスタム」「全部標準」のどちらに振っても失敗します。業務ごとに標準度を決めるのが原則です。
判断 3: 「内製化」を視野に入れるか「外注継続」を前提にするか
導入後の保守・改修体制をどう持つか。
内製化を視野に入れる場合
- 社内に DX 担当者または DX を学ぶ意思のある社員がいる
- 改修サイクルが速い（月単位で要件が変わる）
- 長期的にベンダー費用を圧縮したい
- マニュアル・自動化資産を社内ナレッジとして残したい
この場合、最初から「内製化に戻せる設計」で構築する必要があります。具体的には:
- ノーコード優先（kintone / 自動化ツール）
- 設計ドキュメントを社内ナレッジに残す
- 改修可能な単位で機能を分割
外注継続を前提にする場合
- 専任 DX 担当を置く余力がない
- 中長期的にもベンダーが保守する前提で予算を組む
- 改修頻度は四半期単位以下
この場合は、ベンダー固有の最適化を許容できます。
判断 1〜2 と連動しますが、最も悲惨なのは「外注継続前提でカスタム実装したが、ベンダーが廃業 / 撤退して保守不能になる」パターンです。少なくともデータは持ち出せる構造にしておく必要があります。
判断 4: 「段階導入」か「一気」か
PoC → 本格導入の 2 段ロケットを取るか、初手から本格導入するか。
段階導入（推奨）
- Phase 1（2〜4 週間）で痛みの大きい 1 業務だけを仕組み化
- 並走運用で現場の使い勝手を検証 → アプリを改修
- Phase 2 以降で隣接領域に展開
メリット: 撤退コストが低い、現場が新仕組みに慣れる時間が取れる、要件が確定する。
デメリット: 初期効果が小さく、社内の期待値コントロールが必要。
一気導入
- 現状業務の全体マップを引いてから、3〜6 ヶ月で全置換
メリット: 一度の混乱で済む、効果が大きい。
デメリット: 失敗時の損失が大きい、現場の心理的負荷が高い、要件のズレが噴出すると後戻りできない。
私の経験では、不動産業の中小〜中堅で一気導入が成功する例は少ないです。理由は、現場の多忙さで PoC 検証期間を取れず、要件のズレが本格導入後に表面化するためです。
段階導入を強く推奨します。
判断 5: 「業務代行（BPO）」を併用するか単独 DX で完結させるか
DX で解けない（解いても割に合わない）業務は必ず残ります。例:
- 物件オーナーへの個別交渉
- 入居者からのクレーム一次対応
- 業者ごとに微妙に違う見積フォーマットの整理
- 解約立会いの判断系
これらを「人を増やして対応」するか「外部 BPO に巻き取らせる」かの判断です。
BPO 併用が効く条件
- 自動化しても残る業務量が月 30〜100 時間規模
- 不動産業に精通した BPO ベンダーがある
- 「人を増やすほどではないが、ゼロにもできない」中間量の業務が複数ある
単独 DX で完結を目指す条件
- 残業務が定型 / 軽量
- 既存社員のキャパで吸収できる
- BPO ベンダーへの引き継ぎコストが見合わない
弊社では「DX 設計 → 自動化実装 → BPO 運用代行」を同じ会社が一気通貫で受ける設計を提示することが多いです。理由は、設計者本人が運用代行まで見ることで、要件のズレが累積しないためです。詳細は 業務 BPO サービス と DX 推進コンサル を参照ください。
まとめ — 5 つの判断を社内で言語化してから発注する
| 判断 | 影響 |
|---|---|
| 1. 基幹を活かすか入れ替えるか | プロジェクト規模が 10 倍変わる |
| 2. 標準化か個別カスタムか | 中長期保守コストが変わる |
| 3. 内製化か外注継続か | 設計方針が変わる |
| 4. 段階導入か一気か | リスク許容範囲が変わる |
| 5. BPO 併用するか単独 DX か | 人員配置が変わる |
これらを 発注前に社内で言語化できているかどうかで、ベンダーから受け取る提案の質と精度が変わります。「決まっていません」と答えると、ベンダーは安全寄りに振った提案しかできません。
「自社の場合はどう判断すべきか」を、不動産業 20 年の経営者の視点で整理する 業務 DX 無料診断（60 分） を提供しています。社内で意見が割れている判断軸の整理にもお使いいただけます。