「テーブル定義書がない」から始まった ある日、古い販売管理システムを kintone にリプレイス 案件をすることになりました。 ところが開発元はすでに存在せず、残っていたのはデータベースのテーブルだけ。 KOKNM, DENNO, URIKIN, ZEIKN01 …。 見るからに何かの略語ではありますが、設計書もコメントもないため、 何を意味するのか確信が持てない 。 唯一の手がかりは「命名のクセ」だけでした。 なんとなく分かる。でも“全部調べる”のは非効率… たとえば:  KOKNM → 顧客名（KOK＝顧客？） ZEIKIN → 税金？ DENNO → 伝票No. CRTDT → 作成日（Create Date？） こうやって一つずつ推測していけば意味は分かる。でもテーブルが十数個、項目が数百もあるとなると、画面と見比べながら 一人で手作業で調べるのは現実的じゃない 。 しかも略語は統一されているようで、微妙に揺れています。 ZEIKIN と ZEIKN の両方がある UPDDT と UPDTDT が混在 KOKNM が2回出てくる（カナ名

こんにちは、こん太ぱぱです。 不動産会社でのkintone開発事例をご紹介します。 営業の現場はずっと「Excel＋声掛け＋紙の回覧」という“紙リレー”で動いていて、申込→承認→準備→契約のどこかで情報が散らばり、手戻りが起きがちでした。 しかも不動産は多筆・別紙・特約など情報量が多く、フォームを欲張ると 入力UIが重くなる ——ここが最大のネックでした。 そこで僕は、 Excelを捨てずに役割を変える というやり方を取りました。 運用の“母艦”はkintoneに集約して、 依頼で動き（アクション）／状態で迷わない（ステータス） 。 そして帳票は Excelのまま出力専用 にして、ドラフト先行＋kintoneからの 自動差し込み で最終化。 結果、現場のスピードは落とさずに“紙リレー”から卒業できました。 設計原則：依頼をすると、業務が次の状態になる 僕の設計は、 「依頼」が発火点になって業務の“状態”が進む という考え方です。だからこそ、 ボールを渡す瞬間 を「 アクション＝依頼 」と「 ステータス＝状態 」のセットで明示しました。 だれが →