この記事の結論:ジムの売上・会員数の月次レポートを自動で作るなら、先にデータを集めるのではなく、店長がその数字を見て何を決めるのかから指標を絞ります。指標ごとに「どのシステムの、どの記録を、どう数えるか」を一行で書ける定義にし、POS・予約・決済・会員台帳のデータは、名前ではなく会員IDと日付でつなぎます。締め日の後に起きる決済のやり直しや返金は翌月の行で扱うと決め、取り込み・整える・計算・届けるの4段で組みます。毎月の数字は自動のチェックを通してから配り、レポートには個人の名前を載せません。
毎月の初めに各システムから数字を書き出し、表計算ソフトに貼って集計している運営者の方と、その作業を仕組みに置き換えたいエンジニアの方を想定した内容です。1店舗、または店舗ごとに独立して運営している場合を想定しています。複数の店舗で会員が相互に利用できる場合の数え方は、相互利用と店舗別集計の記事で扱っているので、そちらの定義と合わせて読んでください。
ジムの月次レポートは、指標を先に決めてからデータを集める
月次レポートの自動化で最初に決めるのは、使うツールではなく、店長がその数字を見て「何を決めるのか」です。取れるデータを全部並べたレポートは、作るのに手間がかかるわりに、見る人が毎月同じところしか見なくなります。
自動化する前の手作業のレポートを見直すと、次のような状態になっていることがよくあります。
| 手作業のレポートで起きること |
原因 |
自動化の前に決めること |
| 毎月の数字の数え方が、作る人によって違う |
定義が作る人の頭の中にある |
指標ごとの定義を文章で残す |
| 先月の数字が、今月見ると変わっている |
締めた後の修正が、過去の月に反映される |
締め日と、締めた後の修正の扱い |
| 数字はあるが、次に何をするかが決まらない |
判断と結びつかない指標が並んでいる |
指標ごとに「何を判断するか」 |
| 作るのに毎月何時間もかかる |
複数のシステムから書き出して貼り合わせている |
データの出どころと、つなぐ鍵 |
この表の右の列を先に埋めておくと、自動化の作業は「決めた定義どおりに計算する仕組みを作る」だけになります。
店長が見る指標は、判断につながるものに絞る
店長向けの月次レポートに入れる指標は、それぞれ「この数字が動いたら、何を見直すか」を一つ言えるものに絞ります。言えない指標は、レポートの本体ではなく、必要なときに開く詳細の画面に回します。
| 指標 |
定義の書き方の例 |
動いたときに見直すこと |
主な出どころ |
| 月末の在籍会員数 |
月の最終日に、休会中を除いて契約が有効な会員の数 |
入会と退会のどちらが動いたか |
会員台帳 |
| 新規入会数 |
その月に入会日がある会員の数 |
体験からの入会の流れ |
会員台帳 |
| 退会数 |
その月に退会日がある会員の数(申し出日ではなく契約の終了日) |
退会の理由、来館の間隔 |
会員台帳 |
| 休会中の会員数 |
月の最終日に休会の期間に入っている会員の数 |
休会から戻る案内 |
会員台帳 |
| 体験の予約数と実施数 |
その月に体験の予約日・来館日がある件数 |
予約の受け方、無断キャンセル |
予約 |
| 体験からの入会率 |
体験を実施した人のうち、決めた期間内に入会した人の割合 |
体験の内容、入会の手続き |
予約+会員台帳 |
| 会費の請求額 |
その月の利用分として請求した会費の合計(税込・税抜を決めて統一) |
プランの構成、値上げや割引 |
決済 |
| 物販・回数券の売上 |
その月にPOSで売り上げた額 |
品ぞろえ、店頭での案内 |
POS |
| 来館数 |
その月の入館の記録の件数(同じ人の同じ日の入館は1回) |
混む時間帯、スタッフの配置 |
入館の記録 |
「月末の在籍会員数」と「その月に来館した人の数」は、名前が似ていても別の数字です。どちらを「会員数」と呼ぶかを社内で一つに決めておかないと、店長と本部で同じ言葉が違う数字を指すことになります。
指標の数は、最初は10個以内に収めるのがおすすめです。数を増やすのは、毎月のレポートで「この数字がないと判断できなかった」場面が実際に出てからで間に合います。
元のデータは、POS・予約・決済・会員台帳に分かれている
ジムの数字の出どころは、多くの場合4つ以上のシステムに分かれていて、それぞれが知っていることと、データを書き出せるタイミングが違います。自動化の設計では、どの指標をどのシステムから取るかを決め、同じ数字を2か所から取らないようにします。
| システム |
知っていること |
つなぐ鍵になる項目 |
書き出しの方法の例 |
| 会員台帳(会員管理) |
入会日、退会日、休会の期間、プラン |
会員ID |
管理画面からのCSV、API |
| 予約 |
体験・レッスンの予約と来館の有無 |
会員ID(体験の人は仮のID)、予約日 |
管理画面からのCSV、API |
| 決済 |
会費の請求、支払いの成否、返金、手数料 |
決済サービス側の顧客ID、請求の期間 |
決済サービスのレポート、API |
| POS(店頭のレジ) |
物販・回数券などの売上 |
会員ID(会員価格の場合)、販売日 |
レジの管理画面からのCSV |
| 入館の記録 |
来館の日時 |
会員ID、入館の日時 |
入館システムからのCSV、API |
体験の人のように、まだ会員IDがない人の記録は、入会したときに会員IDとひも付ける項目を予約の側に持たせておきます。これがないと、体験からの入会率を自動で計算できず、毎月手で突き合わせることになります。
データをつなぐ鍵は会員IDと日付にし、名前で突き合わせない
複数のシステムのデータをつなぐときは、会員IDと日付を鍵にし、氏名や電話番号で突き合わせることはしません。氏名は表記の揺れ(全角と半角、旧字、結婚による変更)があり、手作業で貼り合わせていた頃のずれの多くがここから生まれます。
決済サービスの顧客IDのように、システムごとに別のIDを持っている場合は、会員台帳に「この会員の決済サービス側のID」を持たせ、対応表を一か所に置きます。
| 対応表に持たせる項目 |
例 |
| 会員ID |
会員台帳の番号 |
| 決済サービス側の顧客ID |
決済サービスが発行したID |
| 予約システム側のID |
予約システムのアカウントの番号 |
| 対応を登録した日 |
会員の登録時、または決済の登録時 |
日付は、どのシステムも同じ時間帯(日本時間)でそろえて扱います。決済サービスのレポートは協定世界時(UTC)で出るものがあり、そのまま集計すると、月の境目の深夜の取引が前の月や次の月に入ってしまいます。書き出すときに時間帯を指定できるなら、日本時間を指定しておきます。
締め日を決め、締めた後の決済のやり直しと返金は翌月の行で扱う
月次レポートを自動にするなら、「何日の何時のデータで、その月を締めるか」と、「締めた後に起きた変更をどう扱うか」を先に決めます。決めないまま自動で作ると、先月のレポートを開き直すたびに数字が変わり、店長が前の月と比べられなくなります。
ジムで締めた後に起きやすい変更と、扱い方の例は次のとおりです。
| 締めた後に起きること |
扱い方の例 |
| 月末に失敗した会費の決済が、翌月にやり直しで成功した |
請求は元の月、入金は成功した月として、別の行で数える |
| 前の月の会費を返金した |
返金した月の行に、マイナスの金額として入れる。元の月は書き換えない |
| 退会の手続きの入力が、月をまたいで遅れた |
契約の終了日で数える。遅れた分は翌月のレポートに「前月分の訂正」として出す |
| 物販の返品 |
返品を受けた月に、マイナスの売上として入れる |
ここで気をつけたいのが、決済サービスの入金額と売上の違いです。たとえばStripeのドキュメントでは、入金照合レポートが、銀行に入った入金の一つひとつに含まれる支払い・返金・手数料などの取引を照合するためのものとして説明されていて、入金は入金の到着予定日でまとめられます。つまり入金額は、手数料や返金を差し引き、入金の日程で区切られた金額です。月次レポートでは、「その月の利用分として請求した会費」と「その月に入金された額」を別の行にし、差の内訳は照合レポートで確かめるという分け方にしておくと、経理の数字とも食い違いを説明できます。
自動化は「取り込み→整える→計算→届ける」の4段で組む
月次レポートの自動化は、データの取り込み、形を整える、指標を計算する、店長に届ける、の4段に分けて組みます。1つの大きな処理にまとめると、どこかのシステムの書き出しの形が変わったときに、どこで壊れたのかが分からなくなります。
- 取り込む。 各システムからCSVやAPIでデータを取り、取り込んだ日時と元のファイルをそのまま保管する
- 整える。 日付を日本時間にそろえ、金額の税込・税抜を統一し、会員IDの対応表でつなぐ
- 計算する。 指標の定義の表どおりに、月ごとの数字を出す。締めた月の数字は保存して、上書きしない
- 届ける。 店長が普段使っている場所(メール、チャット、共有の表計算シート、管理画面)に、決めた日に届ける
置き場所は、店舗数とデータの量で選びます。
| 規模・状況 |
置き場所の例 |
向いている理由 |
| 1店舗、出どころが2〜3つ |
共有の表計算シートと、自動実行の機能 |
店長がそのまま開ける。始めるまでが早い |
| 出どころが4つ以上、過去の月の修正が多い |
小さなデータベースと、決まった時刻に動く処理 |
取り込んだ元のデータと、締めた数字を分けて持てる |
| 店舗が増える、分析もしたい |
クラウドのデータ分析基盤 |
データが増えても計算の時間が延びにくく、権限を細かく分けられる |
最初から大きな基盤を用意する必要はありません。1段目で取り込んだ元のデータをそのまま残しておけば、後から置き場所を移しても、過去の月を同じ定義で計算し直せます。
数字が合っているかを、配る前に自動で確かめる
自動で作ったレポートは、店長に届ける前に、決めたチェックを自動で通し、引っかかったら配らずに担当者へ通知が飛ぶようにします。手作業の頃は作る人が目で見て気づいていた異常を、自動化した後は仕組みが見つけるようにするためです。
| チェック |
内容 |
引っかかったときに疑うこと |
| 在籍数のつり合い |
前月末の在籍+入会−退会±休会の出入り=今月末の在籍 |
退会日や休会の入力漏れ |
| 取り込みの件数 |
各システムから取り込んだ件数が、前月と比べて極端に増減していない |
書き出しの失敗、形式の変更 |
| 対応表の漏れ |
決済の記録のうち、会員IDにつながらないものがない |
対応表への登録漏れ |
| 期間の外のデータ |
対象の月の外の日付が混じっていない |
時間帯のずれ |
| 請求と入金の差 |
差が、返金・手数料・やり直しの合計で説明できる |
決済サービス側の設定や、二重の請求 |
1つ目のつり合いのチェックは、会員数のずれを見つけるのにいちばん役に立ちます。この式が合わない月は、どこかの入力が抜けているので、レポートを配る前に直します。
レポートには個人の名前を載せず、人数と金額にまとめて配る
店長に毎月配る月次レポートは、人数や金額にまとめた形にし、会員一人ひとりの名前は載せません。個人の特定につながらない形に集計した統計情報は個人情報の外に置かれる、という整理が、個人情報保護委員会の示す通則編の中にあります。
| 載せるもの |
載せないもの |
名前が必要な作業の置き場所 |
| 入会数、退会数、在籍数、来館数 |
退会した人の氏名 |
見られる人を絞った会員管理の画面 |
| プランごとの人数、売上 |
支払いに失敗した人の氏名 |
決済の対応をする担当者の画面 |
| 時間帯ごとの来館数 |
来館の記録の明細 |
入館システムの管理画面 |
レポートをメールやチャットで送る場合、転送されることも考えて、会員の名前やカードの情報が入らない形に限っておくと安心です。決済サービスのレポートには、顧客の氏名やメールアドレスの列を加えて書き出せるものもあるので、取り込むときに必要な列だけを選び、名前の列は取り込まない設定にします。
最初の3か月は、手作業のレポートと並べて答え合わせをする
自動化した月次レポートは、最初の3か月ほどは手作業のレポートと並べて作り、数字が一致するのを見届けてから切り替えます。合わない数字が出たら、多くはどちらかの定義の違いなので、定義の表を直すきっかけになります。
| 月 |
やること |
| 1か月目 |
指標の定義の表を作り、自動のレポートと手作業のレポートを両方作る。差を一つずつ説明する |
| 2か月目 |
差の原因になった定義や入力の手順を直し、もう一度並べて作る |
| 3か月目 |
差がなくなったら、自動のレポートを正式なものとして配る。手作業は止める |
たとえば大阪と兵庫に1店舗ずつあり、それぞれの店長が自分の店の数字を見る、という形なら、店舗ごとに同じ定義のレポートを届け、本部では2店舗を並べた表を見る形にします。店舗間で会員が行き来するようになったら、冒頭で触れた相互利用の数え方に切り替えます。
株式会社bundlyzeではデータ分析基盤をAWSで組んできたほか、業種を問わず使える予約管理の仕組みも、企画を固めるところから稼働後の運用まで受け持ってきました。POSや予約、決済のデータを1か所に集めて月次の数字を自動で出す仕組みは、クラウドとデータ基盤の構築・運用の窓口でご相談をお受けしています。
参考資料
下の3つは、2026年10月3日に中身を読み直しています。