データ分析

NuAppには、システム内に蓄積されたデータを可視化・分析するための機能として、「カスタム集計」「ダッシュボード」「集計（SQLによる設定）」という、特性の異なる3つのアプローチが用意されています。

これらは単に画面上の見せ方が違うだけでなく、「仕組み」「誰が運用するか」「データ処理の限界値」が根本から異なります。開発者がユーザーの要件に合わせて最適な機能を正しく選定し、過不足のないデータ分析基盤を設計するための判断基準を解説します。

3つのデータ分析機能の位置づけ（比較一覧）

ユーザーからの「データを集計して見たい」というざっくりとした要望に対し、開発者は以下の3つの特性を頭に入れた上で、どのアプローチが最適かをハンドリングする必要があります。

機能名	作成・運用の主体	裏側の仕組み / 特徴	主なユースケース
① カスタム集計	エンドユーザー（現場のリーダー等）	アプリのUI上で、ユーザーがインタラクティブ（動的）に集計軸やフィルターを切り替えてクロス集計できる。	「今月の売上を、急遽『担当者別』だけでなく『エリア別』でもクロス分析したくなった」
② ダッシュボード	開発者 / 管理者	①のカスタム集計で保存したグラフや表の条件を複数並べ、アプリのトップ画面等にタイル状に配置する。	「毎朝、経営陣やマネージャーが、全社の主要KPI（売上・案件数・進捗）を一目で俯瞰したい」
③ 集計	開発者（SE）	裏側の Google BigQuery に対して発行するSQLを記述して設定。複数モデルを跨ぐ複雑な結合や、特殊な関数等の利用が可能。	「数年分の実績データと予算モデルを結合した予実管理」「複雑な社内ロジックに基づく配賦計算」

開発者が迷う「選定の境界線」：カスタム集計 vs SQL集計

設計時にSEが最も頭を悩ませるのが、「カスタム集計（ダッシュボード）」で実装すべきか、それとも「集計（SQL）」で実装すべきかという境界線です。判断基準は以下の2点です。

基準A：データの構造と結合の複雑さ

カスタム集計が向いているケース： 集計対象が「1つのモデル（例：商談モデルのみ）」の範囲で完結する場合です。UI上のクリック操作だけで綺麗なグラフやクロス集計表が作れます。
SQL集計が必要なケース： 「Aモデル（予算）とBモデル（実績）を期間と部門でマッピングしたい」など、複数のトランザクションモデル同士を対等に結合（JOIN）する必要がある場合は、カスタム集計では対応できません。BigQueryのパワーを活かしたSQL集計の一択となります。

基準B：運用の柔軟性と「誰が育てるか」

カスタム集計（ダッシュボード）の思想： 「別の切り口でもデータを見たい」という要望が現場から上がった際、その都度開発者がシステムを改修（SQLを書き換え）していてはアジャイルな経営判断の足を引っ張ってしまいます。あえて「カスタム集計」をエンドユーザーに開放しておくことで、現場が自分たちで分析軸（ディメンション）を増やし、システムリリース後も自律的にダッシュボードを成長させていく運用が可能になります（開発者側の運用保守コストも劇的に下がります）。

設計のベストプラクティス

1. ダッシュボードのパーツは「まずカスタム集計で作る」

ダッシュボードは独立した機能ではなく、「カスタム集計で保存したビューを再利用して画面に並べるもの」です。そのため、ダッシュボードを設計する際は、まず対象のモデルで現場が必要とするカスタム集計（グラフや表）の「型」を個別に作成して保存しておく、という手順になります。

2. 集計は「BigQueryへのデータ同期タイミング」を考慮する

NuAppのデータ分析機能は、裏側でGoogle BigQueryにレプリケーション（同期）されたデータに対してクエリを投げます。データはほぼリアルタイムですが、タイムラグが生じることや、バックエンドのプロセス処理が終わらないと最新情報が反映されないこともあります。そのため、「1秒前に登録した伝票が、集計の画面に即座に反映されないと業務が回らない」といった超リアルタイム性が求められる画面には不向きです。特性を理解した上でユースケースを検討して下さい。

3. 分析に必要な「データ項目」を最初のモデリングで仕込む

どれほど強力な集計機能があっても、元データ（モデル）にその項目が存在しなければ集計は不可能です。基本設計（モデリング）の段階で、ユーザーに「最終的にどんなダッシュボード（レポート）が見たいですか？」と問いかけ、そこから逆算して「売上日（日付型）」「商品カテゴリ（選択肢型）」などの分析の軸となる属性をモデルにあらかじめ仕込んでおくことが、データ分析アプリを成功させる最大のコツです。