kintone集計の設計方法｜グラフ・クロス集計・外部BIの使い分け

kintoneでは、アプリに登録されたレコードをもとに、グラフや表を作れます。

売上金額を月別に見る。

案件数を担当者別に見る。

問い合わせ件数を種別別に見る。

作業実績を部門別に見る。

承認待ちの件数をステータス別に見る。

このような集計は、kintoneを業務システムとして使ううえで自然に必要になります。

ただし、実務で崩れるのは、グラフの作り方そのものではありません。

次のような状態が起きます。

• 売上を集計したいが、受注日、請求日、入金日のどれで集計するか決まっていない
• 案件金額を集計したいが、見込み、受注済み、失注が混ざっている
• 問い合わせ件数を集計したいが、同じ顧客の重複問い合わせをどう数えるか決まっていない
• 作業実績を集計したいが、日報テーブルの中に工数が閉じている
• 関連レコードに見えている金額を、そのまま集計できると思っている
• 月次会議で見た数字が、翌週には変わっていて説明できない
• kintoneのグラフ、スプレッドシート、外部BIの数字が合わない

kintone集計は、グラフ機能の操作ではなく、指標設計です。

どの業務判断のために、どのデータを、どの粒度で、どの時点の数字として見るのか。

ここを決める必要があります。

kintone集計で最初に決めるべきなのは、グラフの種類ではなく、「何を判断するための数字か」と「その数字の正本データはどこか」です。

この記事では、kintoneで売上、案件、問い合わせ、作業実績などを集計するときの、指標設計、正本データ、レコード粒度、標準グラフ・表・クロス集計、テーブルや関連レコードの注意点、定期レポート、DataCollect、スプレッドシート、外部BIの使い分けを整理します。

kintoneテーブル集計の設計方法はこちら
kintone予実管理の設計方法はこちら

先に結論：集計はグラフ作成ではなく指標設計

kintone公式ヘルプでは、アプリに登録されたレコードをもとに、グラフや表を作成してデータを集計できると説明されています。

kintoneヘルプ：グラフと集計

また、集計結果は表、棒グラフ、折れ線グラフ、円グラフ、クロス集計表などの形式で表示できます。

kintoneヘルプ：グラフを作成する

これらは便利です。

ただし、グラフを作れることと、業務判断に使える集計ができることは別です。

集計で最初に決めるのは、表示形式ではありません。

次の4つです。

決めること	例
指標	売上、粗利、案件数、問い合わせ件数、作業時間
正本データ	売上アプリ、案件アプリ、問い合わせアプリ、作業実績アプリ
粒度	1案件、1請求、1問い合わせ、1作業、1明細
更新頻度	リアルタイム、日次、週次、月次、会議前

たとえば「売上を集計したい」と言っても、意味はいくつもあります。

売上指標	正本になりやすいデータ
見込み売上	案件アプリの予定金額
受注売上	受注アプリ、案件の受注ステータス
請求売上	請求アプリ、帳票発行済みデータ
入金売上	入金管理、会計ソフト
月次売上	請求日、売上計上日、入金日などの定義が必要

同じ「売上」でも、使う日付と状態が違えば数字は変わります。

この定義を決めずにグラフを作ると、会議で「この売上は何の数字か」を説明できなくなります。

kintoneのグラフは表示方法です。集計の正しさは、指標名、対象レコード、日付、状態、除外条件を定義しているかで決まります。

集計したい業務判断を決める

集計は、見た目のためではなく判断のために作ります。

誰が、何を判断するために見るのかを決めます。

見る人	判断したいこと	指標例
経営者	売上見込み、粗利、未回収、部門別状況	月別売上、粗利、未入金額
営業責任者	案件進捗、担当者別活動、失注傾向	案件数、受注率、活動件数
サポート責任者	問い合わせ量、未対応、対応遅延	未対応件数、平均対応時間
現場責任者	作業実績、遅延、稼働負荷	作業時間、遅延件数、担当別件数
経理	請求、入金、差し戻し、締め処理	請求額、入金額、未入金額

たとえば、営業責任者が見るなら、案件ステータス別の件数や金額が重要です。

経営者が見るなら、月次売上、粗利、着地見込みが重要です。

サポート責任者が見るなら、未対応件数や対応遅延が重要です。

同じ案件アプリでも、見る人によって集計軸が変わります。

業務	集計軸の例
売上	月、部門、担当者、商品、顧客、請求状態
案件	ステータス、確度、担当者、流入経路、予定月
問い合わせ	種別、優先度、担当、対応状態、受付日
作業実績	作業日、担当者、案件、作業種別、請求対象
在庫	商品、倉庫、入出庫区分、棚卸差異

集計軸は増やしすぎない方がよいです。

最初からすべての切り口を作ると、画面が読みにくくなります。

毎週見る指標、月次で見る指標、必要なときだけ見る指標を分けます。

正本データとレコード粒度を確認する

集計が合わない原因の多くは、正本データとレコード粒度のずれです。

正本データとは、その数字の根拠になる正式なデータです。

レコード粒度とは、1レコードが何を表すかです。

集計したい数字	正本データ	1レコードの粒度
案件数	案件アプリ	1案件
問い合わせ件数	問い合わせアプリ	1問い合わせ
作業時間	作業実績アプリ	1作業、または1日報
請求額	請求アプリ	1請求
商品別売上	売上明細アプリ	1商品明細

ここで問題になりやすいのが、テーブルと関連レコードです。

テーブル内の明細を商品別や月別に集計したい場合、親レコード単位のグラフでは足りないことがあります。

kintoneテーブル集計の記事でも整理している通り、親レコード内の合計ならテーブル集計で足りますが、明細行を横断して見るなら明細アプリ化を検討します。

関連レコードも同じです。

関連レコード一覧は、別アプリのレコードを画面上に表示する機能です。

標準機能では、関連レコード一覧の値をそのまま集計・自動計算・検索の対象にはできません。

kintone関連レコード集計の設計方法はこちら

kintone集計が合わないときは、グラフ設定より先に「1レコードが何を表すか」と「集計したい数字の正本はどのアプリか」を確認します。

標準グラフ・表・クロス集計の使い分け

kintoneの標準グラフは、アプリ内のレコードを集計して表示する用途に向いています。

まずは標準機能で足りるかを確認します。

表示形式	向いている用途
表	数字を一覧で確認する
棒グラフ	担当者別、商品別、部門別などを比較する
折れ線グラフ	月別推移、週別推移を見る
円グラフ	構成比を見る
クロス集計表	2軸で件数や金額を見る

標準グラフで足りるのは、正本データが1つのアプリにあり、レコード粒度が集計したい粒度と合っている場合です。

たとえば、問い合わせアプリで、1レコードが1問い合わせなら、種別別・月別の問い合わせ件数は標準グラフで見やすいです。

案件アプリで、1レコードが1案件なら、担当者別の案件数やステータス別の金額も見やすいです。

一方で、次のような場合は標準グラフだけでは苦しくなります。

状況	見直すこと
複数アプリをまたいで集計したい	集計アプリ、DataCollect、外部BI
テーブル内明細を横断集計したい	明細アプリ化、テーブル展開
関連レコードの合計を使いたい	集計値保存、集計アプリ
月次会議時点の数字を固定したい	定期レポート、集計結果アプリ
複雑な条件や計算が必要	集計用フィールド、連携サービス

クロス集計は、2軸で見るときに便利です。

たとえば、月別×担当者別の案件数。

商品カテゴリ×商品名の売上。

問い合わせ種別×ステータスの件数。

ただし、クロス集計も元データが整っていることが前提です。

軸に使うフィールドが自由入力だと、表記ゆれで集計が割れます。

担当者、商品、部門、種別、ステータスは、選択肢やマスタ参照で揃えます。

テーブル・関連レコード・アプリ間集計の注意点

kintone集計でよく詰まるのは、テーブル、関連レコード、アプリ間集計です。

対象	注意点
テーブル	親レコード内の合計には向くが、明細横断集計は難しくなりやすい
関連レコード	表示であって、標準では集計値として扱いにくい
複数アプリ	正本、更新タイミング、重複、キー設計が必要
外部連携	どの時点の数字を渡すかを決める

テーブル内明細を集計したい場合は、まず親レコード内で完結する集計か、明細行を横断する集計かを分けます。

見積1件の合計なら、親レコード内の計算で足ります。

商品別売上や月別工数なら、明細アプリ化した方がよいことがあります。

関連レコード集計では、親レコードに集計値を保存するか、集計アプリを作るかを決めます。

たとえば、顧客ごとの累計受注額は顧客レコードに保存してもよいです。

月別・担当者別・商品別の売上は、集計アプリや外部BIに分けた方が扱いやすいです。

複数アプリをまたぐ場合は、キー設計が重要です。

顧客コード。

案件番号。

商品コード。

部門コード。

期間。

これらが揃っていないと、集計時に名寄せや手修正が発生します。

定期レポートとダッシュボード設計

集計は、作ったら終わりではありません。

誰が、いつ、どの画面を見るのかを決めます。

画面	役割
日次確認一覧	未対応、遅延、異常値を見る
週次ダッシュボード	案件、問い合わせ、作業量の変化を見る
月次レポート	売上、請求、予実、部門別状況を見る
会議用レポート	会議時点の数字とコメントを残す
詳細ドリルダウン	数字の根拠レコードに戻る

kintoneのグラフは、アプリ内で集計を確認するには便利です。

ただし、会議で使う数字は、時点を固定したいことがあります。

月次会議で見た売上金額。

締め時点の未入金額。

週次時点の未対応件数。

これらは、翌日にレコードが更新されると数字が変わる可能性があります。

そのため、定期レポートや集計結果アプリを作り、会議時点の数字を保存することがあります。

保存するもの	理由
集計対象期間	いつからいつまでの数字か
集計日時	いつ計算したか
集計条件	どの状態や部門を含めたか
集計結果	金額、件数、達成率など
コメント	数字の背景、判断、次の対応
担当アクション	誰がいつまでに動くか

ダッシュボードは、数字を並べる場所ではありません。

見る人が判断しやすい順に配置します。

上に全体指標。

次に異常値や未対応。

その下に部門別や担当者別の内訳。

最後に詳細一覧への導線。

このように整理すると、毎回どこを見るかが揃います。

DataCollect・スプレッドシート・外部BIへ分ける判断

標準グラフで足りない場合は、DataCollect、スプレッドシート、外部BIを検討します。

トヨクモの記事では、kintoneの標準集計機能に加えて、アプリ間をまたいだ集計やDataCollectを使った集計方法が紹介されています。

トヨクモ：kintoneのデータ集計機能とアプリ間を跨いだ集計方法

DataCollectの機能ページでは、複数アプリに散らばる情報を集計対象にできるフィールド式、集計実行、ピボットテーブル、テーブル展開などが紹介されています。

DataCollect：機能一覧

選び方は、次のように考えます。

方法	向いているケース	注意点
標準グラフ	1アプリ内の単純集計	複数アプリ横断や明細展開は弱い
集計アプリ	月次や担当者別の結果を保存したい	集計処理と再計算ルールが必要
DataCollect	複数アプリ、テーブル展開、ピボット集計	設定変更時の管理者を決める
スプレッドシート	外部共有、手元分析、軽い加工	kintone側の正本と同期条件を決める
外部BI	複数システム横断、経営ダッシュボード	データ基盤、権限、更新頻度が必要

スプレッドシートは、短期的には便利です。

ただし、手修正が増えると、kintoneの数字と合わなくなります。

外部BIは、複数システムの数字を横断して見たい場合に向きます。

ただし、BIへ渡す前に、kintone側のデータ定義を固めます。

どのアプリを正本にするか。

どの項目をキーにするか。

どのタイミングで更新するか。

集計条件をどこで管理するか。

ここを決めずに外部へ出すと、BI側で補正だらけになります。

外部BIやスプレッドシートへ出す前に、kintone側で正本アプリ、キー、対象期間、除外条件、更新頻度を決めます。外に出してから定義を直すと数字が割れます。

よくある失敗

kintone集計でよくある失敗は、次の通りです。

失敗	起きること	修正の方向
グラフから作る	何を判断する数字か分からない	指標と利用者を先に決める
日付定義を決めない	月別売上が人によって変わる	受注日、請求日、入金日を分ける
ステータスを混ぜる	見込み、受注、失注が混ざる	集計対象ステータスを定義する
テーブル明細を横断集計する	商品別や月別が扱いづらい	明細アプリ化を検討する
関連レコードを正本にする	表示と集計値の意味がずれる	集計値保存や集計アプリを使う
自由入力を軸にする	表記ゆれで集計が割れる	選択肢やマスタを使う
会議時点の数字を残さない	後から同じ数字を再現できない	定期レポートや集計結果を保存する
外部集計で手修正する	kintoneと外部表の数字が合わない	正本と同期条件を決める

特に多いのは、標準グラフを作ってから、あとで「この数字は何を含んでいるのか」と聞かれるケースです。

グラフは見た目が整っている分、定義が曖昧でも正しそうに見えます。

しかし、集計対象や除外条件が曖昧なら、意思決定には使いにくいです。

設計時に決めるチェックリスト

kintone集計を作る前に、次を決めます。

確認項目	決めること
利用者	経営、部門長、現場、経理など
判断	何を決めるための数字か
指標	売上、件数、工数、未対応、達成率など
正本アプリ	どのアプリのどのレコードを根拠にするか
粒度	1案件、1問い合わせ、1明細、1作業など
日付	受注日、請求日、入金日、対応日など
状態	対象に含めるステータス、除外するステータス
軸	部門、担当者、商品、顧客、種別など
更新頻度	リアルタイム、日次、週次、月次
表示方法	表、棒グラフ、折れ線、クロス集計、ダッシュボード
保存要否	会議時点の数字を残すか
外部連携	DataCollect、スプレッドシート、外部BIへ出すか

この表を埋めると、標準グラフで足りるのか、集計アプリが必要なのか、DataCollectや外部BIへ分けるべきかが見えます。

1アプリ内で、レコード粒度が合っていて、表示するだけなら標準グラフで足ります。

複数アプリをまたぐ、明細を展開する、会議時点の数字を保存する、外部へ共有するなら、別の構成を検討します。

Bitlightに相談できること

Bitlightでは、kintone集計を、グラフ設定ではなく業務判断のための指標設計として整理できます。

たとえば、次のような支援ができます。

• 売上、案件、問い合わせ、作業実績、予実の指標定義
• 正本アプリ、レコード粒度、集計対象、除外条件の整理
• 標準グラフ、表、クロス集計、定期レポートの設計
• テーブル明細や関連レコードを集計に使う場合の構成整理
• 集計アプリ、DataCollect、スプレッドシート、外部BIの使い分け
• 会議時点の数字を残す集計結果アプリの設計
• ダッシュボードから根拠レコードへ戻れる導線設計

kintone集計は、機能としてはすぐ始められます。

しかし、集計を業務判断に使うなら、指標の定義と正本データの設計が必要です。

グラフを作る前に、何を判断する数字か。

どのアプリのどのレコードを根拠にするか。

いつ時点の数字として見るか。

ここを決めることで、kintoneの集計は見た目のグラフではなく、会議と現場判断に使える数字になります。

kintone売上管理の設計方法はこちら
kintone帳票管理の設計方法はこちら