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

「テーブル定義書がない」から始まった ある日、古い販売管理システムを 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からの 自動差し込み で最終化。 結果、現場のスピードは落とさずに“紙リレー”から卒業できました。 設計原則：依頼をすると、業務が次の状態になる 僕の設計は、 「依頼」が発火点になって業務の“状態”が進む という考え方です。だからこそ、 ボールを渡す瞬間 を「 アクション＝依頼 」と「 ステータス＝状態 」のセットで明示しました。 だれが →

kintoneをご利用の中で、こんな場面に遭遇したことはありませんか？ 「サブテーブルに入力した明細を、別アプリからも確認したい」 「関連レコードで、誰が・何を・いくらで登録したのかを一覧で見られたら便利なのに…」 実は、少し工夫するだけで 「サブテーブルの内容を関連レコードでも確認できる」 ようにすることができるんです。 サブテーブルは関連レコードに「表示できない」のが通常 kintoneの「関連レコード」機能はとても便利ですが、 サブテーブル（明細・履歴・内訳など）はそのままでは表示できません。 関連レコード一覧に出せるのは、通常フィールドのみ。そのため、サブテーブルに保存された詳細な明細はわざわざレコードを開かないと確認できないのが現状でした。 解決策：リッチエディタを「明細サマリー」として活用 この課題を解決する方法が、 リッチエディタフィールドを「サブテーブルのサマリー表示」として使う という発想です。 たとえば、こんなふうに👇 この「明細サマリー」はサブテーブルそのものではなく、 リッチエディタフィールドに自動生成されたHTML表

こんにちは、こん太ぱぱです。今日は「AppInsight」のAI+の開発進捗を少しご紹介します。 AI＋とは？ AppInsightは、kintoneアプリの設計データを収集・整理するプラグインです。 AI＋では、その設計情報をもとに「AIが具体的な提案やコード生成を行う」機能を追加しています。単なるAIチャットではなく、 アプリ設計情報を渡しながら相談できる のが最大の特徴です。 実装中の機能 現在、以下の機能を開発中です。 アプリ分析レポート アプリ全体をAIが分析し、良い点・悪い点・改善アクションを提示。 セクション別AI評価 A〜Eの観点（入力設計、レイアウト、関連設定など）で自動評価。 改善アクションプラン生成 分析結果をもとに、すぐ実行できる改善アクションを提案。 JavaScriptコード生成 例：「REST APIを使ってルックアップを更新したい」と指示すると、アプリのフィールド名やキーを推定しながら実用レベルのコードを自動生成。 JavaScriptコード解析 カスタマイズに使われているJSファイルを解析。 API連携／外部シス

kintoneのアプリ構成を見える化する「 AppInsight for kintone 」。 現在、試しにAppInsightで AIでアプリを分析する機能を実験しています。 そうしたら、思っていた以上に“良い相棒”になりそうな気配がありまして──...

「業務改善にJavaScript」ってどういうこと？ 業務改善にJavaScript？ プログラミングって、ちょっと難しそう…──そう思う方にこそ、伝えたいことがあります。 実は、あなたが毎日使っている業務ツール、 そのほとんどは「ブラウザの中で動くSaaS」 なんです。...

「これ、kintoneでできませんか？」 そんな相談をよく受けます。僕自身、これまでいくつものプラグインを開発してきました。 関連レコードをネスト表示するプラグイン ルックアップでコピーされた項目を色で可視化するプラグイン...