なぜアプリ設計が重要なのか
kintoneは手軽にアプリを作成できる反面、設計を疎かにすると後から大きな問題が発生します。よくあるのは「アプリが増えすぎて管理できない」「データの整合性が取れない」「改修に手間がかかる」といったトラブルです。
最初の設計をしっかり行うことで、長期的に使いやすいシステムを構築できます。
設計の基本原則
原則1: マスタとトランザクションを分ける
マスタアプリ: 頻繁に変わらない基本データ
- 顧客マスタ、商品マスタ、社員マスタ
トランザクションアプリ: 日々発生する業務データ
- 案件管理、受注管理、日報
顧客マスタ（マスタ）
↓ ルックアップ
案件管理（トランザクション）
↓ ルックアップ
請求管理（トランザクション）
原則2: 1アプリ1目的
1つのアプリに複数の目的を持たせない。「顧客管理と案件管理を1つのアプリでやりたい」という要望が出がちですが、別々のアプリにしてルックアップで連携するのが正解です。
原則3: 正規化を意識する
同じデータを複数のアプリに持たない。顧客の住所が変わった場合、マスタを1箇所更新するだけで済むようにします。
フィールド設計のコツ
フィールド名の命名規則
| ルール | 良い例 | 悪い例 |
|---|---|---|
| 具体的に | 「契約開始日」 | 「日付」 |
| 統一的に | 「顧客名」「商品名」 | 「お客様」「商品」 |
| 短すぎない | 「月額利用料」 | 「料金」 |
フィールドタイプの選び方
- ドロップダウン/ラジオボタン: 選択肢が決まっている場合（ステータスなど）
- 文字列1行: 短いテキスト（名前、コードなど）
- 文字列複数行: 長いテキスト（備考、説明など）
- 数値: 計算に使う数値（金額、数量）
- 日付: 日付データ
- チェックボックス: 複数選択が必要な場合
テーブルの使いどころ
kintoneのテーブル（サブテーブル）は、1レコード内に複数の明細を持たせたい場合に使います。
- 見積書の明細行
- 出張の経費明細
- 作業報告の工数明細
注意: テーブル内のフィールドでは集計やルックアップに制限があります。
アプリ構成の設計パターン
パターン1: 営業管理
顧客マスタ → 案件管理 → 見積管理 → 受注管理 → 請求管理
パターン2: プロジェクト管理
顧客マスタ → プロジェクト管理 → タスク管理 → 工数管理
パターン3: 問い合わせ管理
顧客マスタ → 問い合わせ管理 → 対応履歴
よくある設計ミス
ミス1: アプリの増殖
「〇〇管理」「〇〇管理_v2」「〇〇管理_新」のようにアプリが増殖する問題。最初の設計をしっかり行い、安易にアプリを複製しないルールを設けましょう。
ミス2: 全てを1つのアプリに詰め込む
フィールドが50個以上あるアプリは、分割を検討すべきサインです。
ミス3: ルックアップの方向ミス
ルックアップはマスタからトランザクションの方向に設定するのが基本です。逆方向のルックアップは設計の見直しが必要です。
設計レビューのチェックリスト
- マスタとトランザクションが分離されているか
- 1アプリ1目的になっているか
- フィールド名が統一的で具体的か
- ルックアップの方向が正しいか
- 必須フィールドが適切に設定されているか
- アクセス権限が設計されているか
- 将来のデータ量を考慮しているか
まとめ
kintoneのアプリ設計は、後から修正が効きにくい部分もあるため、最初にしっかり時間をかけることが大切です。COTSUBUでは、業務分析からアプリ設計、構築まで一貫してサポートしています。正しい設計で、長く使えるkintone環境を構築しましょう。