賃貸管理の業務を kintone のサブシステムで仕組み化する

クライアント概要

賃貸管理会社（中小〜中堅、管理戸数 1,000〜5,000 戸規模）。基幹（賃貸管理ソフト）は導入済みで、物件・契約のマスタデータと請求入金・送金の正本はそこで管理できている。一方、退去・契約・督促・更新といった日々の業務は「基幹に機能はあるが、現場の動線に合わず使いにくい」状態で、結局 Excel・紙・電話で回っているのが実態でした。基幹を入れ替えるほどの大改修ではなく、kintone をサブシステムとして並走させ、業務はサブシステム・正本データは基幹という役割分担で解決した実装パターンです。

課題（Before）— 「基幹に機能はある。でも現場は使っていない」

基幹（賃貸管理ソフト）は多機能です。入退去管理も督促管理も更新管理も、機能としては存在します。それでも導入前の現場で起きていたのは:

• 退去受付から原状回復工事までの進捗が、電話・メール・Excel に分散（いま何件がどの工程かは、担当者に聞かないと分からない）
• 新規契約のたびに、申込書 → 基幹への登録 → 契約書の作成で同じ情報を繰り返し入力
• 督促は基幹の画面が現場の動線に合わず、結局 Excel と担当者の記憶で管理
• 更新期限の一覧性が悪く、案内の送付が後手に回る

つまり問題は機能の有無ではなく、画面と動線が現場の仕事の流れに合っているかでした。基幹のカスタマイズで対応しようとすると、1 機能追加で数十万〜数百万円・納期数ヶ月という見積もりが返ってくる構造です。

なぜネクシア・プロパティに依頼したのか（Why NEXIA）

「基幹ベンダーにカスタマイズを発注する」「業務代行（BPO）会社に巻き取らせる」「自社で何とかする」の 3 択で迷っていた状態から、ネクシア・プロパティを選んだ決定打は次の 3 点でした。

• 業務フロー単位で「基幹の使いにくい部分」を即座に整理できた — 退去受付〜原状回復、契約登録〜契約書作成、督促、更新。どこで動線が切れているかを業務側起点で言語化できる
• 「基幹を残す」前提の設計を提示 — 基幹乗り換えを前提にしないため、稟議・予算・現場混乱のリスクが小さい。Phase 1 を 2〜4 週間で立ち上げる現実的なロードマップ
• 正本データを汚さない役割分担の設計 — どのデータの正本が基幹で、どこからが kintone かを最初に線引きするため、経理・送金業務に影響を与えない

施策（How）— 業務はサブシステム、正本データは基幹

役割分担を一行で言うと、日々の業務は kintone のサブシステムで回し、マスタデータと請求入金・送金の正本は基幹に残す。kintone が契約・家賃の本流データを担う必要はありません。基幹のカスタマイズに数百万円・数ヶ月をかける代わりに、kintone なら数十万円・数週間で現場の動線に合った業務画面が作れます。

領域 1: 退去受付〜原状回復工事の半自動化

解約受付から、立会日の調整 → 原状回復の見積・業者手配 → 工事完了確認 → 募集再開までを 1 件のレコードで進捗管理。受付時に立会候補日の案内文や業者への依頼文をデータから自動生成し、工程が進むごとに次のアクションが担当者に通知される「半自動運転」に。全件がボード形式で見えるため、「いまどの部屋がどの工程か」を聞いて回る時間が消え、空室期間の短縮に直結します。

領域 2: 新規契約の登録・契約書作成の半自動化

申込情報を起点に契約レコードを作成し、契約書類のドラフトをデータから自動生成。同じ氏名・物件・条件を申込書 → 基幹 → 契約書へと繰り返し転記する作業をなくします。確定した契約情報は基幹へ登録して正本化。作成時間と転記ミスの両方を減らします。

領域 3: 督促管理

連絡履歴・進捗ステータスを構造化。督促段階（電話 → 文書 → 内容証明 → 法的措置）をステータス管理し、家賃保証会社への代位弁済請求もトレース。滞納者ごとに過去履歴がまとまるため、判断材料が漏れません。

領域 4: 更新管理

更新月の 60 日前に自動通知し、対象契約の一覧と案内送付の進捗をステータス管理。期限切れの放置をゼロに。物件・部屋・契約者ごとに期限を管理し、通知は担当者のチャット / メールに自動で届きます。

ほかにも広げられる周辺領域

トラブル対応・問合せ履歴、修繕・工事履歴、オーナー向け月次レポート、付帯契約（駐車場・収納庫等）なども、同じサブシステム構成で順次アプリ化できます。基幹の「使いにくい」「機能がない」に当たった業務から、優先順位を付けて広げるのが現実的です。

なぜ kintone がこの用途に向くのか

• アプリを実務担当者が増やせる — IT 部門や外部ベンダー発注なしで現場担当が作れる
• アプリ間連携・ルックアップ機能 — 物件・契約・退去・督促アプリを画面操作で紐付け可能
• 標準で外部システムと連携できる — 基幹との連携や、自動通知・書類の自動生成・メール送信を後から追加できる
• モバイル対応 — 退去立会や物件巡回時にスマホからその場で記録可能（写真付き）

詳しくは → なぜ不動産業務で kintone を選ぶのか — 8つの理由 で解説しています。

成果（After）— 「聞かないと分からない」が消え、書類仕事が半自動に

クライアントの声

「基幹に機能があるのは知っていました。でも現場はその画面を開かない。入れ替えるかどうかで悩んでいたときに、"業務はサブシステムで回し、正本データは基幹に残す" という整理を聞いて、初めて『これなら稟議が通る』『現場が混乱しない』という手応えがありました。退去の進捗管理から立ち上げて、いまは契約書作成・督促・更新まで kintone 側で回しています。請求や送金は基幹のままなので、経理は何も変わっていません。」

— 取締役 / 賃貸管理会社（管理戸数 3,000 戸規模）

進化系: 基幹を「DB ＋ 入金送金管理」に絞り、業務本体を kintone で回す

この役割分担をさらに進めた構成も出てきています。基幹システムは「物件・契約のマスタ DB」と「入金・送金の決済処理」だけに絞り、日常業務の主戦場を kintone に置くパターンです。

メリット:

• 業務改善のサイクルが現場主導で回る（基幹ベンダーへの依頼を待たない）
• 自社独自・オーナー単位・地域慣習の差を kintone 側で吸収できる
• 基幹のライセンス費を最小プランに抑えられる場合がある
• 将来の基幹乗り換え時、業務データが kintone 側に残るため移行リスクが低下

すべての会社にこの形を勧めるわけではありません。ただし「基幹を変えずに、できる範囲で業務を整えたい」という段階を超えて、「基幹に縛られない業務基盤を持ちたい」というフェーズに来ている会社にとって、現実的な選択肢になりつつあります。

導入の進め方

基幹を入れ替えないため、PoC のリスクが小さいのが特徴です。

• Phase 1: もっとも痛みの大きい業務を 1 つ選んで kintone アプリ化（多くの場合は「退去〜原状回復の進捗管理」または「督促管理」）
• Phase 2: 並走運用で現場の使い勝手を検証 → アプリを改修
• Phase 3: 隣接業務に展開（契約書作成・更新管理・オーナー報告 等）
• Phase 4: 必要な箇所だけ基幹と自動連携
• Phase 5（任意）: 業務主戦場を kintone 側に移し、基幹を DB ＋ 決済処理に絞る構成へ

弊社では、Phase 1〜2 を 約 2〜4 週間で立ち上げます。すべてを一気に作る必要はありません。

まとめ

「基幹を入れ替える」のは大きな決断です。一方、現場の非効率の多くは基幹の機能不足ではなく、画面と動線が現場に合っていないことから生まれています。これは基幹を入れ替えなくても解消できます。

業務は kintone のサブシステムで回し、マスタデータと請求入金・送金の正本は基幹に残す——この役割分担なら、コスト・リスク・現場負担の 3 つを抑えながら、退去・契約・督促・更新といった日々の業務を現場に合った形で仕組み化できます。

「うちの基幹はそのままで、業務だけ仕組み化したい」「退去の進捗や契約書作成を半自動にしたい」というご相談は、無料診断で具体構成をご提案します。

→ 業務DX無料診断（60分）を申し込む