【開発事例】kintone×Excelで“紙リレー”を卒業した話
- 祐斗 河合
- 3 日前
- 読了時間: 5分
こんにちは、こん太ぱぱです。
不動産会社でのkintone開発事例をご紹介します。
営業の現場はずっと「Excel＋声掛け＋紙の回覧」という“紙リレー”で動いていて、申込→承認→準備→契約のどこかで情報が散らばり、手戻りが起きがちでした。
しかも不動産は多筆・別紙・特約など情報量が多く、フォームを欲張ると入力UIが重くなる
——ここが最大のネックでした。
そこで僕は、Excelを捨てずに役割を変えるというやり方を取りました。
運用の“母艦”はkintoneに集約して、依頼で動き（アクション）／状態で迷わない（ステータス）。
そして帳票はExcelのまま出力専用にして、ドラフト先行＋kintoneからの自動差し込みで最終化。
結果、現場のスピードは落とさずに“紙リレー”から卒業できました。
設計原則：依頼をすると、業務が次の状態になる
僕の設計は、「依頼」が発火点になって業務の“状態”が進むという考え方です。だからこそ、ボールを渡す瞬間を「アクション＝依頼」と「ステータス＝状態」のセットで明示しました。
だれが → だれに → なにを依頼するか
完了条件はなにか（チェック項目）
差戻し先と理由の書式はなにか
期限と通知はどうするか
ねらい（ゴール設定）
転記ゼロ：顧客・物件はマスタをルックアップ。Excel→紙→Excelの再入力を廃止
承認の見える化：だれが・いつ・なにを承認／差戻ししたかを履歴化
準備漏れ防止：チェックリスト＋ステータスで“止まり”を可視化
後工程のラク化：締結実績の集計・検索・再利用を簡単に
アプリ全体像
中心に販売契約管理アプリ。必要情報はマスタからルックアップします。
顧客マスタ：顧客ID、氏名／名称、連絡先、属性
販売物件マスタ：物件ID、所在地、価格、仕様／プラン
元々の業務フロー
kintoneを活用した業務フロー
差分サマリー（時系列でサクッと）
手入力のExcel
Before：4回（事務のドラフト固定欄／営業の打ち込み依頼書／事務の契約情報再入力／契約報告書）
After：1回（事務のドラフト固定欄のみ。顧客情報と契約条件は自動差し込み）
物理ハンドオフ（紙の受け渡し）
Before：2回（上長へ紙提出／事務へ紙提出）
After：0回（すべて通知でハンドオフ）
起点の分散 → 一本化
Before：Excel と 紙 が起点
After：kintone の申込レコードが起点（ルックアップで整合）
承認の証跡
Before：印鑑・口頭ベース
After：アクション履歴と差し戻し理由を記録（通知付き）
帳票作成のやり方
Before：依頼書→再入力→報告書まで全文字打ち
After：Excelテンプレを維持しつつ、自動差し込み→PDF出力
ステータス設計（プロセス管理）
申込（営業）：申込登録／顧客・物件をルックアップ → 承認依頼
承認中（上長）：内容確認（属性・値引き・リスク） → 承認／差し戻し
契約準備中（営業事務）：契約書／合意書の準備、日程調整 → 準備完了
契約締結中（営業）：契約を実施、最終条件を確定 → 締結の報告
締結：履歴・集計へ反映
使ったkintone機能（最小で効かせる）
ルックアップ（顧客・物件）で転記を廃止
プロセス管理（ステータス／アクション）で役割と順序を固定
アクセス権／レコード権限で編集できる人とタイミングを制御
通知／コメントで差戻し・補足依頼を履歴化
関連レコードで顧客・物件の他案件履歴を参照
一覧／グラフで承認待ち・準備中・締結中を可視化
代表フィールド（“最低限で回る”設計）
基本：契約No、申込日、営業担当、上長、営業事務
参照：顧客ID（ルックアップ）、物件ID（ルックアップ）
条件：価格、値引き額・理由、支払条件、オプション、特約
準備：契約書、合意書、本人確認、収入証明、スケジュール
承認：承認結果、差し戻し理由
締結：署名日、最終条件、添付（契約書控・合意書）
運用ルール（小さく決める）
承認依頼の後は金額を編集しない（修正は差し戻しで）
準備完了の前にチェック完了（抜け漏れ検知）
締結報告は当日中（次工程への受け渡しを早く）
口頭・紙のやり取りはコメントで残す（あとから追える）
Excel連携のキモ（なぜ残すか／どう繋ぐか）
現場の手癖を変えない契約書は従来のExcelテンプレを継続。見た目・印刷レイアウト・余白調整をそのまま活かす。
ドラフト先行 → 自動差し込みで最終化事務が固定欄・物件欄を先行入力し、締結直前にkintoneの契約情報を取得して自動差し込み。通常運用は軽く、最終化の瞬間だけ“濃い処理”にする。
マッピングを表に切り出すExcelに「kintoneフィールドコード → 名前付き範囲」の表を同梱。テンプレ差し替えや項目追加にも強い。
なぜExcelを残したか（不動産ならでは＋DXしやすさ）
不動産は情報量と可変要素が多い。
地目・地積・接道・私道負担・上下水・建ぺい率・容積率・越境・特約……に加え、多筆や別紙も日常茶飯事。これをそのままkintoneのフォームに詰めると、UIが重く長くなり現場の入力負荷が跳ね上がります。
そこで僕は、運用＝kintone／出力＝Excelと役割を分け、出力（ドラフト～最終化）を“独立したモジュール”として扱う設計にしました。この独立性こそが、言い換えればDXしやすさです。
独立性が生む「検討しやすさ」
選択肢を持てる：出力はA. Excelテンプレ継続／B. kintone帳票／C. 電子契約サービスのどれにも差し替え可能。土台（kintoneのデータ構造）はそのまま。
波及が小さい：出力を変えても、アプリ本体の画面・フィールドは不変。修正はテンプレ or スクリプト側で完結。
段階導入できる：Excel出力と新方式を並行運用→比較→切替が可能。現場の納得を得ながら移行できる。
ロールバックが容易：不具合時は前版テンプレに戻すだけ。運用停止リスクが低い。
小さく試せる：一部案件・一部書式だけ試してみて、良ければ拡大。DXの実験コストが下がる。
将来、帳票をkintone直出しや電子契約直結にしても、kintone上の契約データがあるため、出力モジュールを差し替えるだけで検討できます。いまExcelで回しているからといって、道が塞がることはありません。
むしろ“次の一手”を打ちやすくする、というのがExcelを残した狙いです。
まとめ
僕がやったのは、Excelと紙のリレーをやめて、「だれが・いつ・なにを」の道筋をkintoneに置くことだけ。それだけで、人に依存していた仕事がチームの仕事になりました。
大事にしたのは、最小の設計と迷わない画面。
帳票はExcelに任せて出力専用、運用の真実はkintoneに集約。現場の声を吸い上げながら、小さく回して育ていく。僕はそのやり方がいちばん好きです。
コメント