[集計できる設計と、集計できない設計]
なぜ項目設計が効いてくるのか
データを貯める目的は、たいてい「あとで使うため」です。今月の商談件数を知りたい、担当者ごとの状況を比べたい、地域別の傾向を見たい。そういう場面で初めて、設計の良し悪しが表に出ます。
そして厄介なのは、設計の失敗はデータが貯まってから発覚することです。100件貯まったあとで「この項目、集計できない形だった」と気づいても、100件を手作業で直すことになります。
だからこそ、最初の設計に少しだけ時間をかける価値があります。
原則1 — 選べるものは、選ばせる
もっとも効果が大きいのがこれです。選択肢が決まっているものを自由入力にしない。
自由入力にすると、同じ意味の値が違う表記で入ります。「商談中」「商談中です」「交渉中」が混在すると、集計したときに別々の項目として数えられてしまいます。ドロップダウンやラジオボタンにしておけば、この問題は最初から起きません。
ただし、選択肢を増やしすぎるのも逆効果です。選択肢が多すぎると現場が選ぶのを面倒がり、結局いちばん上か「その他」ばかりが選ばれるようになります。目安として10個を超えるようなら、分類のしかた自体を見直すか、項目を2つに分けることを検討してください（この「10個」は本記事での目安です。厳密な上限があるわけではありません）。
原則2 — 種類に合った部品を使う
見た目が同じでも、部品の種類が違うとできることが変わります。
[入れたいものに、合った部品を使う]
入れたいもの | 使う部品 | 理由 |
|---|---|---|
契約日・訪問日 | 日付 | 「今月分だけ」のような期間での絞り込みができる |
金額・数量 | 数値 | 合計・平均が出せる |
電話番号・郵便番号 | 文字列（1行） | 計算しない。先頭の0が消えるのを防ぐ |
長い経緯・メモ | 文字列（複数行） | 改行して書ける |
とくに間違えやすいのが日付です。日付を文字列で入れてしまうと、「2026/8/1」「2026-08-01」「8月1日」が混ざり、期間で絞り込むことができなくなります。日付は必ず日付フィールドを使ってください。
逆に、電話番号を数値にするのもよくある失敗です。数値にするとハイフンが入らず、先頭が 0 の番号は0が落ちます。見た目が数字でも、計算しないものは文字列が原則です。
原則3 — 1つの項目に、1つの情報だけ
「担当者（営業部）」のように、1つの項目に2つの情報を詰め込まないでください。
こうすると、部署ごとの集計ができなくなります。「営業部の案件だけ見たい」と思っても、文字列の中に部署名が埋まっているだけなので、絞り込めません。担当者名と部署を別の項目に分けておけば、どちらの軸でも集計できます。
住所も同じです。1行の住所欄しかないと都道府県別に集計できません。都道府県だけドロップダウンで別に持たせておくと、あとが楽になります。
原則4 — 分類したい軸を、最初に項目にする
これがいちばん見落とされがちな原則です。
「あとで地域別に見たい」と思っていても、住所しか持っていなければ集計できません。「業種別に比べたい」なら、業種のドロップダウンが最初から必要です。分類の軸は、データを貯め始める前に項目として用意しておく必要があります。
とはいえ、思いつく軸をすべて項目にすると入力が重くなります。判断の目安はこうです。
- 経営会議や月次報告で使う軸 → 最初から項目にする
- 年に数回しか使わない軸 → 備考に書いておき、必要になったら項目を追加する
原則5 — 必須項目は、本当に必要なものだけに
必須項目を増やすと、入力漏れは確かに減ります。ただし増やしすぎると別の問題が起きます。
現場が「とりあえず何か入れないと保存できない」状態になり、適当な値やダミーの値が入るようになるのです。こうなると、入力漏れよりたちが悪い状態になります。空欄なら「未入力」とわかりますが、適当な値は正しいデータと見分けがつきません。
必須にするのは「これが無いとレコードとして意味をなさない」項目だけにしてください。顧客管理なら会社名、案件管理なら案件名と顧客名、といった具合です。
実際に集計してみる
ここまでの原則が効いているか、実際に確かめてみます。前回作った顧客管理アプリで、「顧客ランク」と「取引状況」の集計をグラフにしてみましょう。
kintoneではグラフの設定画面で、分類する項目と集計方法を選ぶだけでグラフができます。関数を組む必要はありません。設定していくそばから、右側に結果のプレビューが表示されます。
[グラフの設定画面。分類する項目に「顧客ランク」、集計方法に「レコード数」を選んだ状態]
このとき選んでいるのは「分類する項目：顧客ランク」と「集計方法：レコード数」の2つだけです。それだけで、A（重点顧客）3件・B（通常顧客）4件・C（見込み）2件という集計が出ています。
きれいに分類されているのは、顧客ランクをドロップダウンにしておいたからです。もしこれを自由入力にしていたら、表記ゆれの数だけ棒が並び、集計として使いものになりませんでした。
原則1の効果が、そのままこのグラフに出ているということです。
よくある設計の失敗
最後に、実際によく見かける失敗をまとめます。
よくある形 | 直したい形 | 何が変わるか |
|---|---|---|
ステータスを文字列で自由入力 | ドロップダウン／ラジオボタン | 表記ゆれが消え、集計できる |
日付を文字列で入力 | 日付フィールド | 期間で絞り込める |
金額を文字列で入力 | 数値フィールド | 合計・平均が出せる |
「担当者（部署）」を1項目に | 担当者と部署を別項目に | 部署別に集計できる |
住所1行だけ | 都道府県を別項目に | 地域別に集計できる |
必須項目だらけ | 必須は最小限に | ダミー入力が減り、データが汚れない |
まとめ
- - 項目設計は「入力しやすいか」ではなく「あとで集計できるか」で決める
- - 選択肢が決まっているものは、必ずドロップダウンかラジオボタンにする
- - 日付は日付、金額は数値、電話番号は文字列。種類に合った部品を使う
- - 1つの項目に2つの情報を詰め込まない。分ければ両方の軸で集計できる
- - 分類したい軸は、データを貯め始める前に項目として用意しておく
- - 必須項目は増やしすぎない。適当な値が入るとかえってデータが汚れる
次回は、ここで整えたデータを実際に見える化する回です。一覧の絞り込みとグラフ機能を使って、現場の状況をひと目でつかめる形にしていきます。
同じ100件のデータでも、設計次第で「すぐ集計できるデータ」にも「手作業で整え直さないと使えないデータ」にもなります。そしてその差は、入力する人の手間ではほとんど変わりません。ドロップダウンにするか文字列にするかを、最初に決めるかどうかだけの違いです。
貯め方が整っているデータは、kintone上の集計だけでなく、その先の分析にもそのまま使えます。表記が揃っていて、項目の意味が定義されているデータは、Power BIに取り込んで経営指標に落とし込むのも簡単です。逆に、表記がばらばらのまま貯まったデータは、分析に入る前の整形作業に多くの時間を取られます。
実際、データ分析の現場では、作業時間の大半が「分析」ではなく「データを整えること」に費やされます。その整形作業の大部分は、最初の設計次第で発生させずに済むものです。
つまり項目設計とは、入力画面を決める作業であると同時に、将来の分析コストを先に払っておく作業でもあります。
UDATAでは、kintoneの導入サポートを行っています。どの業務からアプリ化すべきかの選定、後の分析まで見据えた項目設計、現場への定着支援、そして蓄積したデータのPower BIによる可視化まで、一貫してご支援しています。
「この項目設計で問題ないか見てほしい」「すでに貯まったデータを整理したい」といったご相談も歓迎です。お気軽にこちらからお問い合わせください▶ UDATAへのお問い合わせ