kintoneクロス集計の設計方法｜指標・軸・更新頻度を崩さない構成

kintoneのクロス集計表は、月別×担当者別、商品カテゴリ×商品別、問い合わせ種別×ステータス別のように、2つ以上の切り口で数字を見るときに便利です。

売上を部門別・月別に見る。

案件数を担当者別・ステータス別に見る。

問い合わせ件数を種別別・優先度別に見る。

作業時間を案件別・作業区分別に見る。

在庫数を倉庫別・商品カテゴリ別に見る。

こうした表は、kintone上の業務データを確認するうえでよく使われます。

ただし、クロス集計は、フィールドを行と列に置けば完成するものではありません。

実務では、次のような問題が起きます。

• 月別売上を見たいが、受注日、請求日、入金日のどれで集計するか決まっていない
• 担当者別に集計したいが、担当者が途中で変わった案件をどう扱うか決まっていない
• 商品別に見たいが、商品名が自由入力で表記ゆれしている
• ステータス別に見たいが、完了、失注、保留が同じ表に混ざっている
• 利益率を見たいが、クロス集計表の集計値から割合を出せない
• テーブル内の明細を商品別に見たいが、親レコード単位の集計になってしまう
• 月次会議の数字を後から再現できない
• kintoneのクロス集計、スプレッドシート、外部BIの数字が合わない

これらは、クロス集計表の作り方の問題ではありません。

行軸、列軸、値、集計対象、粒度、更新頻度が決まっていないことが原因です。

kintoneクロス集計で最初に決めるべきなのは、表の見た目ではなく、「何を判断するために、どのレコードを、どの軸で、どの値として集計するか」です。

この記事では、kintoneでクロス集計を作るときの、行軸・列軸・値、標準グラフで作れる範囲、二次計算が必要なケース、DataCollectや別集計アプリを使うケース、外部BIに逃がす判断、更新頻度と保存ルールを整理します。

kintone集計全体の設計方法はこちら
kintoneテーブル集計の設計方法はこちら

先に結論：クロス集計は行軸・列軸・値の設計

クロス集計は、複数の切り口を掛け合わせて数字を見る表です。

最小構成は、行軸、列軸、値です。

要素	意味	例
行軸	縦方向に並べる分類	月、部門、担当者、商品カテゴリ
列軸	横方向に並べる分類	ステータス、商品、地域、優先度
値	セルに表示する数字	件数、合計金額、平均時間、最大値
条件	集計対象を絞る条件	今年、受注済み、未完了、請求対象
粒度	1行の元データが表す単位	1案件、1問い合わせ、1明細、1作業

kintone公式ヘルプでは、グラフ機能でクロス集計表を作成できる例が紹介されています。

kintoneヘルプ：クロス集計表を作成する

また、グラフ作成では、分類する項目を大項目・中項目・小項目まで設定でき、集計方法としてレコード数、合計、平均、最大値、最小値を選べます。

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

つまり、kintoneの標準機能でも、アプリ内のレコードを分類して、表やグラフとして確認できます。

ただし、公式ヘルプが説明しているのは操作方法です。

実務側で決めるべきなのは、どの数字を、どの軸で見ると業務判断に使えるかです。

たとえば「月別×担当者別の案件金額」を作るとしても、次の定義が必要です。

決めること	決めないと起きること
月の基準日	受注予定月、受注日、請求日が混ざる
案件状態	見込み、受注、失注が混ざる
担当者	登録者、営業担当、現在担当が混ざる
金額	見込み金額、受注金額、請求金額が混ざる
除外条件	テスト、重複、キャンセルが混ざる

これを決めずに表だけ作ると、見た目はそれらしいのに、会議で説明できない数字になります。

クロス集計表のセルに入る数字は、元レコードの定義に依存します。行軸と列軸を整える前に、値の意味と対象レコードを固定します。

行軸・列軸・値を決める前に確認すること

クロス集計を作る前に、次の順番で確認します。

1. 何を判断したいか
2. どの指標を見るか
3. その指標の正本データはどのアプリか
4. 1レコードは何を表しているか
5. 行軸と列軸に使うフィールドは表記ゆれしないか
6. 集計結果をいつ時点の数字として扱うか

たとえば、営業会議で使うクロス集計なら、次のように整理します。

確認項目	設計例
判断	今月の受注見込みを担当者別に確認する
指標	受注予定金額
正本アプリ	案件アプリ
粒度	1レコード=1案件
行軸	受注予定月
列軸	営業担当
値	受注予定金額の合計
条件	確度A/B、失注除外
更新頻度	営業会議前に確認

このように、先に設計しておくと、クロス集計表の設定は自然に決まります。

逆に、先に「月を行、担当者を列、金額を合計」と置いてしまうと、どの金額なのか、どの状態の案件なのか、後から揺れます。

クロス集計で特に注意したいのは、軸に使うフィールドです。

軸に使うフィールド	避けたい状態	設計の方向
商品名	自由入力で表記ゆれする	商品マスタ、ルックアップ
部門	古い部門名と新部門名が混ざる	部門コード、履歴ルール
担当者	退職者、代理登録者が混ざる	担当者フィールドを明確化
ステータス	運用中に選択肢が増え続ける	状態定義を固定する
日付	予定日、実績日、請求日が混ざる	指標ごとに基準日を決める

軸が乱れると、クロス集計表の行や列が増え、読みづらくなります。

「株式会社ビットライト」と「(株)ビットライト」が別の列になる。

「営業部」と「営業」が別の行になる。

「完了」と「対応済み」が別の状態になる。

これでは、集計表を見ても判断できません。

クロス集計で使う軸は、選択肢、ユーザー選択、組織選択、マスタ参照などで揃えるのが基本です。

標準グラフで作れるクロス集計

kintone標準のクロス集計で足りるのは、次の条件を満たす場合です。

条件	標準で扱いやすい理由
正本データが1アプリにある	そのアプリ内で分類・集計できる
1レコードの粒度が合っている	件数や合計が意味を持つ
軸に使う値が揃っている	行・列が分裂しにくい
集計値が単純	レコード数、合計、平均などで足りる
最新値を見ればよい	保存せずに表示して確認できる

例としては、次のようなものです。

業務	行軸	列軸	値
問い合わせ管理	受付月	種別	件数
案件管理	予定月	ステータス	案件数
営業管理	担当者	確度	予定金額合計
作業実績	作業月	作業区分	作業時間合計
在庫確認	倉庫	商品カテゴリ	在庫数合計

この範囲であれば、標準グラフのクロス集計表で十分なことがあります。

ただし、標準グラフにも設計上の注意があります。

公式ヘルプでは、分類する項目に指定した値が空のレコードは集計対象にならないと説明されています。

また、集計対象になるのは、グラフを見るユーザーが閲覧権限を持つレコードやフィールドです。

つまり、ユーザーによってアクセス権が違う場合、同じグラフ名でも見える数字が変わることがあります。

これは不具合ではなく、権限設計の結果です。

月次会議で全社共通の数字として扱うなら、閲覧権限、集計条件、対象フィールドを明確にします。

標準クロス集計で足りるのは、1アプリ内のレコードを、単純な件数・合計・平均で確認できる場合です。複数アプリ横断や集計値どうしの計算が必要なら、別の構成を検討します。

利益率など二次計算が必要なケース

クロス集計でよく出る要望が、集計値を使った二次計算です。

たとえば、次のような数字です。

見たい数字	必要な計算
利益	売上合計 - 原価合計
利益率	利益 / 売上合計
受注率	受注件数 / 提案件数
対応完了率	完了件数 / 受付件数
平均単価	売上合計 / 件数

これらは、元レコードのフィールドをそのまま合計するだけでは出せません。

クロス集計のセルに入った集計値どうしを使って、さらに計算する必要があります。

gusukuサポートの記事でも、kintoneのクロス集計表はフィールド値をキーにした合計や件数は表示できる一方、集計値を使った計算結果は表示できないため、別アプリに集計値を作成する例が紹介されています。

gusukuサポート：クロス集計に計算式を足したような出力を作成する

このような場合、選択肢は主に3つです。

方法	向いているケース
元レコードに計算済みフィールドを持つ	1レコード内で完結する計算
集計結果アプリを作る	月別・部門別などの集計値を保存したい
外部BIやスプレッドシートへ渡す	複雑な分析、可視化、複数データ横断

たとえば、案件ごとの粗利は、案件レコード内で売上見込と原価見込から計算できます。

しかし、部門別・月別の利益率は、部門別・月別に売上合計と原価合計を出した後、さらに計算する必要があります。

この場合は、標準クロス集計だけで完結させようとしない方がよいです。

月別・部門別の集計結果を別アプリに保存し、そのアプリで利益や利益率を計算する。

または、外部BI側で計算指標を作る。

このように構成を分けます。

DataCollectや別集計アプリを使うケース

標準クロス集計で足りない場合、DataCollectや別集計アプリを検討します。

DataCollectの操作ガイドでは、ピボットテーブルで2つ以上のフィールドを掛け合わせたクロス集計を行い、行・列・値にフィールドを配置して組み合わせを確認できると説明されています。

DataCollect操作ガイド：ピボットテーブルとは

DataCollectや別集計アプリを検討するのは、次のような場合です。

状況	構成の考え方
行・列・値を試行錯誤したい	DataCollectのピボットで確認する
集計値を保存したい	集計結果アプリを作る
利益率など二次計算が必要	集計後の値を計算する場所を作る
月次会議時点の数字を残したい	集計日時つきで保存する
テーブル内明細を横断したい	明細アプリ化、または展開処理を作る

別集計アプリを作る場合は、集計結果の粒度を決めます。

たとえば、月別・部門別の売上を保存するなら、1レコードは「1か月×1部門」です。

フィールド	役割
集計月	行軸、または期間キー
部門	列軸、または分類キー
売上合計	集計値
原価合計	集計値
利益	計算値
利益率	計算値
集計日時	いつ時点の数字かを示す
対象条件	どの条件で集計したかを残す

この構成にすると、月次会議で使った数字を後から再現しやすくなります。

一方で、集計結果アプリを作ると、更新処理が必要になります。

どのタイミングで集計するか。

過去月を再集計するか。

元データが修正されたときにどう反映するか。

削除されたレコードをどう扱うか。

この運用ルールを決めずに集計結果だけ保存すると、今度は保存値と元データがずれます。

集計結果を保存するなら、「いつ作った数字か」「どの条件で作った数字か」「元データ修正時に再集計するか」をフィールドと運用ルールで残します。

複数アプリ横断と外部BIの判断

クロス集計の対象が複数アプリに広がると、標準グラフだけでは設計が苦しくなります。

たとえば、次のようなケースです。

見たい表	必要なデータ
顧客別の売上・問い合わせ件数	顧客アプリ、売上アプリ、問い合わせアプリ
案件別の予算・実績・請求	案件アプリ、作業実績アプリ、請求アプリ
商品別の売上・在庫	売上明細アプリ、在庫アプリ、商品マスタ
部門別の稼働・粗利	作業実績アプリ、案件アプリ、原価管理

複数アプリをまたぐ場合、まずキーを揃えます。

顧客コード。

案件番号。

商品コード。

部門コード。

担当者。

期間。

このキーが揃っていないと、外部BIに出しても名寄せで詰まります。

外部BIは、kintoneの代わりに数字の定義を考えてくれるものではありません。

正本データ、キー、更新タイミング、除外条件を決めたうえで、可視化や分析の場所として使います。

外部BIへ渡す前に、少なくとも次を決めます。

決めること	例
正本アプリ	売上は請求アプリ、案件数は案件アプリ
キー	顧客コード、案件番号、商品コード
期間	集計月、会計月、請求月
除外条件	テスト、キャンセル、失注、下書き
更新頻度	日次、週次、月次、会議前
権限	誰がどの粒度の数字を見られるか

ここが決まっていれば、kintone標準グラフ、DataCollect、スプレッドシート、外部BIのどれを使っても、数字の意味が揃います。

kintone予実管理の設計方法はこちら

更新頻度と保存ルールを決める

クロス集計は、いつ時点の数字かが重要です。

最新値を見ればよい表と、会議時点の数字を保存すべき表は分けます。

用途	更新頻度	保存の考え方
現場の未対応確認	リアルタイム	保存せず最新を見る
営業会議	週次	会議前時点を残すか決める
月次報告	月次	集計日時つきで保存する
経営管理	月次、四半期	確定値と速報値を分ける
外部提出	提出時	出力元と条件を残す

たとえば、問い合わせの未対応件数は最新値でよいことが多いです。

一方、月次売上や部門別利益率は、会議時点の数字を後から説明できる必要があります。

その場合は、集計結果アプリに保存する、定期レポートを使う、外部BI側でスナップショットを持つなどの構成を検討します。

保存する場合は、次のフィールドを用意します。

フィールド	理由
集計期間	何月、何週、どの期間の数字か
集計日時	いつ作った数字か
集計条件	対象ステータス、除外条件を残す
集計者/実行元	手動か自動かを分ける
元データ件数	集計対象の件数を確認する
備考	異常値や補正理由を残す

この情報がないと、後から数字を見たときに、なぜその値になったのか追えません。

クロス集計を業務で使うなら、表の見た目よりも、再現性の方が重要です。

よくある失敗

kintoneクロス集計でよくある失敗を整理します。

失敗	原因	対策
行や列が増えすぎる	軸の値が整理されていない	選択肢、マスタ、コードで揃える
数字の意味が説明できない	指標名が曖昧	売上、請求、入金などを分ける
利益率が出せない	集計値どうしの計算が必要	集計結果アプリや外部BIに分ける
人によって数字が違う	閲覧権限が違う	会議用の閲覧範囲を設計する
月次の数字を再現できない	最新値だけを見ている	集計日時つきで保存する
外部BIでも数字が合わない	キーや条件が揃っていない	正本、キー、除外条件を先に定義する

特に多いのは、表記ゆれと指標の曖昧さです。

クロス集計表は、軸が増えるほどそれらしく見えます。

しかし、軸が増えても、判断に使う数字が明確でなければ意味がありません。

最初は、見る人と判断内容を絞ります。

営業責任者が見る表。

経理が見る表。

現場責任者が見る表。

経営が見る表。

それぞれで、必要な軸と値は違います。

すべての人に同じクロス集計表を見せようとすると、表が大きくなりすぎます。

Bitlightに相談できること

Bitlightでは、kintoneのクロス集計を、単なるグラフ設定ではなく業務設計として整理できます。

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

• クロス集計で見るべき指標の整理
• 行軸・列軸・値・条件の設計
• 集計対象レコードと正本アプリの整理
• 標準グラフ、DataCollect、別集計アプリ、外部BIの使い分け
• 利益率、進捗率、受注率など二次計算の設計
• 集計結果アプリと更新ルールの設計
• 会議・月次報告で使える保存ルールの整理
• テーブル明細や関連レコードを含む集計構成の見直し

kintoneのクロス集計は、表を作るだけならすぐに始められます。

しかし、会議や現場判断で使える数字にするには、正本データ、粒度、軸、値、更新頻度を揃える必要があります。

標準機能で足りる表は標準機能で作る。

二次計算や履歴保存が必要なものは、別集計アプリや外部BIに分ける。

この境界を決めることで、kintone上の数字を説明できる状態にできます。