KPIダッシュボード

勤怠データ・顧客データをもとに KPI を可視化する機能。出典は BT社資料「KPIダッシュボード機能お見積」と「【別紙】KPIダッシュボード機能基本設計」。

開発要件

#	指標	絞り込み・切替
①	全体｜月別契約・粗利数値（契約数・キャンセル数・売上・粗利）	チャネル別／支社別／営業課別／営業マン別。全体/自社/加盟店切替
②	全体｜月別完工・粗利数値（完工数・売上・粗利）	チャネル別／営業課別／営業マン別。全体/自社/加盟店切替
③	自社（訪問販売）｜月別・週別・日別の稼働時間〜粗利数値	支社別／営業課別／営業マン別。勤怠データを活用
④	自社（催事）｜月別開催数〜粗利数値	—
⑤	自社（催事）｜店舗別開催数〜粗利数値	—

集計ロジック（基本設計より）

基本設計書では、指標ごとにベーステーブル・集計軸・売上/粗利の定義・フィルタが定義されています。要点は以下。

契約・粗利（①）：ベース contracts。集計軸は contract_date（契約日）。契約数＝レコード数、売上＝total_amount（ご提案金額）の合計、粗利＝提案金額−仕切り金額（税込）の差。キャンセル数＝契約ステータスがクーリングオフ。担当はユーザーテーブルとリレーションしてフィルタ。
完工・粗利（②）：customers ＋ customer_progress（完工日 construction_completion_date）＋ contracts。完工状況は customers.construction_status が「完工」。
稼働〜粗利（③）：operation_reports（日報）＋ telemarketing_appointments。channel=0（自社）かつ訪問販売に限定。稼働時間は work_hours または end_time − start_time の合計。日報と契約は担当者・日付で対応づけ。
催事（④⑤）：開催数は es_reports（催事日報）を店舗名でグルーピングして件数集計。売上・粗利は contracts ＋ telemarketing_appointments（アポ）を「自社（telemarketing_appointments.user_type=0）かつ催事チャネル（telemarketing_appointments.channel＝催事チャネルID）」に絞って集計するため、起点テーブルは es_reports 単独ではなく telemarketing_appointments も含む。店舗別（⑤）のグループ化キーは telemarketing_appointments.event_location（event_stores.id → event_stores.name、カインズ系）または同 event_location_others（ヤマダデンキ系、店舗名を直接保持）。es_reports.event_location も店舗名を保持しうる文字列カラムだが、これは開催数側のグルーピングに使うカラムで、売上・粗利側の店舗キーとは別系統。

技術条件

グラフは Chart.js / Recharts 等の既存ライブラリ使用 が条件。
KPI基本設計確定後の仕様変更は保守稼働を伴う。

費用

項目	内容
開発費用	105万円
工期	1か月
納品物	システム、ソースコード一式

実装状況

未実装（実コードで確認）。トップのホーム画面（HomeController → frontend.dashboard）は実装されていますが、その中身は 「本日／明日以降のタスク」表示 で、本機能が求める売上・粗利・完工・稼働の集計やグラフはありません。HomeController はビューを返すのみで集計処理を持たず、KPI集計用のコントローラ・テーブルも存在しません。

一方で、集計の 元データ（contracts・operation_reports・es_reports・telemarketing_appointments・customer_progress）はDBに揃っており、基本設計書の集計ロジックはそのまま再利用可能な資産 です。作り変えでは、この設計を起点にダッシュボードを新規実装する位置づけになります。