kintoneは誰でもアプリを作れるのが魅力ですが、その「アプリの単位」は企業ごとに大きく異なります。 ある会社では「契約管理」のように業務全体をカバーするアプリ、別の会社では「製本依頼」のように作業に特化したアプリ、といった具合です。 業務フォーカス型（基幹型） 契約管理、案件管理、請求管理など、業務全体を担うアプリ。 台帳としての役割を持ち、会社の資産データを集約する。 強み：全体を俯瞰できる、一元管理しやすい 弱み：スコープが広くなり、複雑化しやすい 作業フォーカス型（タスク型） 製本依頼、承認申請、検収など、個別の作業に特化したアプリ。 業務の一部の動きを切り出すイメージ。 強み：シンプルで運用しやすい、分業に向く 弱み：点在しやすく、全体像を把握しづらい 混在するのが現実 多くの企業では業務型と作業型が混在しています。 ただし「業務型アプリを綺麗に回す」のは難易度が高く、例外対応や権限分岐が増えて複雑になりがち。 そのため、台帳（業務型）はシンプルに保ち、作業は別アプリに切り出して連携させると運用しやすくなります。 ベンダーごとのアプリ

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

この記事で扱う範囲：JavaScriptによる画面操作の基本と、業務改善への活用イメージを紹介します。ブラウザで動くすべてのサービスが自由なカスタマイズに対応しているわけではありません。実際の業務に組み込む際は、利用するサービスの公式なカスタマイズ方法に沿って進めてください。 「業務改善にJavaScript」ってどういうこと？ 業務改善にJavaScript？ プログラミングって、ちょっと難しそう…──そう思う方にこそ、伝えたいことがあります。 実は、あなたが毎日使っている業務ツール、そのほとんどは「ブラウザの中で動くSaaS」なんです。 勤怠管理や経費精算のシステム 顧客管理（CRM）ツール そして kintoneのような業務アプリ作成プラットフォーム こうしたSaaSは、基本的に ブラウザ上で動いていて、JavaScriptでカスタマイズできる構造になっています。 だからこそ、JavaScriptを少しでも理解しておくと── 自分でちょっとした業務改善ができる kintoneのカスタマイズにも応用できる 外部の開発者に依頼するときも「何をど

「これ、kintoneでできませんか？」 そんな相談をよく受けます。僕自身、これまでいくつものプラグインを開発してきました。 関連レコードをネスト表示するプラグイン ルックアップでコピーされた項目を色で可視化するプラグイン 入力フォームにヒントやツールチップを表示するプラグイン でも、僕がプラグイン開発で一番意識しているのは、「それ、本当に業務で使える？」という視点です。 kintoneには、“得意なこと”と“不得意なこと”がある kintoneは、リレーショナルデータベースとは違う、“カード型”のデータベース。 つまり、1件1件の業務レコードが主役になる構造です。 そのため、 一覧表示・分析・検索の柔軟性 → 弱め 人から人へ業務をつなぐプロセス管理 → 強い という“向き・不向き”がハッキリしています。 だからこそ、僕が開発するプラグインは、「kintoneに足りないものを補う」のではなく、「kintoneの得意分野を、もっと活かす」方向を大切にしています。 仕様上の限界を、どう“味方”につけるか たとえば、kintoneでは「関連レコード一