SaaSスタートアップ企業で経営管理を担当している方向けーSaaSメトリクスの財管一致管理
Asobicaでコーポレート（主に経理、予算回り）を担当している織田と申します。
元テニス部で、テニスでテニス肘になったことがないのに、キーボードを打鍵しすぎて最近テニス肘になりました。
ただ、Youtubeで検索すれば、いい感じのストレッチ動画に出会い、自力で改善できるのはいい時代だなと感じます。
本記事は、Asobica Advent Calendar 2日目の記事です。
昨日は、PdMの塚田さんが、「Asobicaにおけるプロダクトマネジメント」に関する考え方をまとめてくださっております。是非こちらも御覧ください。
さて、今回は、全SaaSスタートアップの経営管理担当者が悩んでいるであろう、「会計数値とSaaSメトリクスの連動性（いわゆる財管一致問題）」について、Asobicaで取り組んでいる内容をご紹介できればと思っております。
こんな方向けの記事です。
・スタートアップで、経理を担当しており、その傍らSaaSメトリクスの実績集計もやっているような方
・スタートアップで、SaaSメトリクスの集計等を担当しており、経理と連携して財管一致をさせなければいけない方
内容が完全に実務的なものなので、上記の方以外は、あまり参考にならない/何を言っているのかよくわからない内容であることを予めお詫びします。
A_そもそも財管一致とは
財管一致とは、財務会計と管理会計を一致させることを意味しており、「管理対象としているある項目について、財務会計上の数値（特にPL）と、管理会計で使用している数値が一致している状態」を指します。
「管理会計で使用している数値」とは、今回は、SaaSメトリクスを指します。
財管一致には、下記のメリットとデメリットがあると考えます。
メリット：経営管理が明瞭になる。同じ内容を指すのに、数値が2種類あると混乱しやすい。
デメリット：一般的に、手間が増える。事業構造が複雑化すると、すべてのデータの細分までの把握が難しくなり、ズレの要因の解明にコストがかかる。
B_Asobicaは財管一致させています
Asobicaでは、「財管一致」させることを選択しています。
理由としては、下記が挙げられます。
数値管理のストレスが減る
事業計画上のPLと各部のKGIが財管一致で連動できていないと、現場では目標達成に盛り上がる中、PL上の売上が実際に目標達成するかどうかは蓋をあけないとわからないという事象が生まれる可能性があります。（ひやひやします）
財管一致でKPI/KGIを管理するというルールが全社で認識統一されており、予算策定～実績把握の全プロセスでそれを徹底できれば、獲得予算を達成したが、KGI（PL上のMRR売上）は未達ということは基本発生しなくなります。
弊社コーポレート部長が会計士であり、財務会計と管理会計を一致させるメリットへの理解が深く、財管一致させる方針をとっているためです。
たまたま担当者が、データ間の整合をとることに得意意識があり、好きな人間であったためです（筆者）。
事業計画策定及び予実管理上のメリットを感じること
SaaSメトリクスの内容が、そのままPLの売上数値として使えるので、計画策定は財管一致させる前提に立った方が、楽になると思います。
上記とセットの話ですが、財管一致を意識しないと予実管理の際に、NewMRRは現場目線では目標達成しているのに、投資家に見せるPLベースに置き換えると売上未達という微妙なズレが発生しうるので、予実管理の難易度が高まります。
なお、以降の記載の前提として、Asobicaのことをもう少し補足しますと、
Asobicaは基本的には、BtoBのSaaSを提供している会社です。プロダクトは複数出しております。（※）
Asobicaのコーポレート部は現在10名の正社員がおりまして、経理2名（私含む）で運用しております。私が一部、経営管理業務を担っており、ここで触れているような財管一致させたメトリクス管理や、予実管理を行っております。
なので、私自身経理の知見があるうえで、経営管理業務を構築し、運用しているという前提がございます。
※弊社のサービスサイトはこちらです。
C_具体的に、どのようなやり方で財管一致させているか
今回は、SaaS企業が必ず追うであろう、「SaaSメトリクス」に関する数値の財管一致に絞ってお話します。
以下のC_01～C_02_02までは、単にスプシの運用についての説明をしており、C_03～C_04にて、財管一致のコツについて触れています。
C_01_まずはCRMでどこまでやるかを決める
弊社は、Salesforceを使っております。私の感覚ですが、Salesforceは「営業プロセスの管理」をするためのツールであり、販売管理システム（※）として、作りこむのにはかなりのハードルがあるものだと考えております。
（※）私なりの定義ですが、販売管理システムとは、
「受注情報（※1）と請求情報（※2）を管理するシステム」です。
一般的には、お客様とのお金のやりとりに直結する基幹システムとなるので、登録情報の一切のミスが許されない類のものと考えます。
※1 契約した商品の明細、オプション情報、契約期間、契約書リンクといった内容を網羅した情報群
※2 いつ、どこに、どういう明細表記の請求書を送るかの内容を網羅した情報群
弊社は、Salesforce上も財管一致させる努力をしています。
ただ、財務会計上発生する特殊な値引き額の期間按分等を、Salesforceですべて表現しようと思うと、運用の複雑化をもたらすので最小限にとどめております。
すみ分けを決めれば、Salesforceで各部が自部門の数値をどこまでトラックするかがおおむね決まるので、足りない部分を後述のスプレッドシートで補いに行きます。
C_02_01_スプシでの管理_なぜスプシか？
excelやスプシ（スプレッドシート）大好きマンであるのと、引継ぎが一番しやすいツールという観点で、「スプシでのSaaSメトリクスの管理」を行っております。（弊社がGWSメインのIT環境であるため、Excelではなくスプシを選択しています。）
95%のスタートアップがスプシで管理しているのでは、と想像しています。
スプシで管理を行うメリットは下記と考えます。
追加コストがかからない
入力が簡単
フォーマットを後で変えやすい
CRM等をベースにすると、大きな運用変更はフロントへの負担がかかり、クイックな変更が難しい
引継ぎコスト
私の引継ぎ先は今のところ経理メンバーとなる可能性が高いので、汎用性の高いツールを使う
やはり、追加コストがかからず、ある程度のレベルまでの数値管理が十分可能なツールとして、スプシの魅力は高いです。
ただ一方で、自由度が高いがゆえに、属人性が高まるデメリットは常にはらんでおります。そこはなるべく平易な関数を使う、フォーマットの統一感には拘るという配慮はしています。
なお、以降触れるSaaSメトリクスとは、下記の指標等です。
NewMRRやExpansionMRR等、月末MRRを構成する数値の内訳
CMRRベースの数値も管理
チャーンレート
更新率
継続年数
NRR
ARPA
平均受注単価
バンドル率
上記をプロダクト毎の切り口、業界毎の切り口でも出せるように管理しています。
月毎のリード獲得数や商談獲得数は、マーケティング部やセールス部で別途管理しております。いわゆる顧客のヘルススコアは、CS部やデータ事業部という部署で管理しています。
中長期では、それらのデータも連動させて、Asobica全体の数値がぎゅっと見れるものを、各部協力のもとで作成できればと考えております。
C_02_02_スプシでの管理_手作業データベースの構築
ここまで概念的なお話でしたが、ここから具体のお話をしていきます。
個人的には、「後からでも、別の切り口での分析を行いやすい」「フォーマットを後から変えやすい」構成にすることが大事だと思っております。
スタートアップでは、見たい切り口が頻繁に変わります。その都度、手作業で大幅に改造することは計り知れない大変さがあり、加工過程でミスが発生しうるので、不安が残る運用になります。
この点を踏まえて、具体的にどういう構成にしているかでいいますと、
まず、心臓となる「データベースシート」を用意し、そこに1取引単位で、すべての契約情報を行格納する
主な入力内容は下記です。
取引先名、契約開始日、契約終了日、契約によって増減するMRR金額、プロダクト名、SaaSメトリクス上のラベル（※）
※その増減が、NewMRRなのか、ChurnMRRなのか等を、1行1行ラベルを付す。
入力する金額は、仕訳で実際に計上する月毎の売上金額である必要があります。財管一致のため。そのため、契約書に記載の数値と一致しないケースもありえます。
アウトプットシートを用意する。弊社は、下記の粒度でシートを用意しています。
プロダクト毎のシート
プロダクト毎のNewMRRやチャーンレートがわかります。
ターゲットセグメント毎の情報
例えば、A業界のNewMRRや平均受注単価等がわかります。
あまりシート数を増やし過ぎたくないので、業界ごとにシートは作らず、１シートで運用しています。
取引先毎の各月MRRがわかるシート
各月のMRR増減要因が、企業名・プロダクト名で具体的に把握できるシート
財管一致ルールで弊社は運用しているため、売上の数値責任を負っている各部は、自部門で把握している数値と、財管一致後の数値がずれていないかを気にします。その際に、例えばｘｘ月のNewMRRの内訳が取引先単位でわかるものがあると、検証がしやすくなります。
用意したアウトプットシートに対して、データベースシートの数値を基本SumifsとQuery関数のみで数値を拾うように組んでいます。手打ちは、データベースシート以外排除しています。
コツとなるのは、下記３点です。
ポイント１：データベースシートは、予備の入力列を多めに確保しておく
QUERY関数に頼っている部分もあるので、後から列挿入で、列番号（アルファベット）がずれることは避けたいです。
弊社は、今のところ、10列空白列を残しています。（普段はたたむ）
入力細分化で行が増える分には問題はほぼ起きないですが、列を増やすのは影響が大きいので、最初から余白があるとよいです。
ポイント２：取引先マスタ、案件マスタを用意する。
構成では触れませんでしたが、一定のマスタシートを用意するのがおすすめです。
例えば取引先マスタシートは、1番から始まり、これまで契約したことがない取引先が増えるたびに、新規付番していきます。
ニーズとして、プロダクト毎、あるいは合算での「累計契約社数」「現在の契約社数」をぱっと出したい要望をもらうことがあり、その際にこのマスタで管理していると、ぱっと数値を拾いやすくなります。大した工数かからないので、やっておいたほうがいいです。
案件マスタは、「A社との契約で、B部門とC部門に契約がある」場合に、この二つ契約がある状態を、取引先数と別の粒度で管理するためのものです。ここは、企業の商材特性に応じて、要不要が発生すると思います。
SaaS企業の場合は、一般的には、下記の3粒度でのSaaSメトリクス管理はやる前提にしたほうが、後で集計要望をもらった際に楽だと考えます。
１）取引先単位
例えばもともとA社との間にBという契約があり、その後カスタマーセールス/BDRの成果で別部門とCという契約を結べた場合に、このCという取引は、A社に対する「Expansion」として管理するような粒度です。
２）プロダクト単位
A社にB商材を販売しており、その後C商材を追加契約いただいた際は、このC商材は、C商材という粒度においては、「NewMRR」として管理するイメージです。
３）案件単位
１）の例について、案件単位で見る場合は、新しい案件が増えたので、案件マスタを発番して、「NewMRR」として管理します。
ポイント３：運用面ですが、絶対に数値を取りこぼさないルールを作る
前提として、データベースシートへの入力は、「契約が確定したもの」のみを入れています。見込みの情報は排除しています。
別途、週次でMRRのフォーキャストを追う業務もしております。見込み情報はそちらで管理しています。
取りこぼさないとは、「コーポレートが感知していない、NewMRRやChurnが発生しない」状態を指します。
一言で言うと、「販売管理ルールの制定、徹底」をすることです。
具体的に、下記の徹底を行っています。
MRRを増加あるいは一部減額させる取引には、必ず契約書を必要とする。
契約書を締結する権限は、法務グループのみ有する。送付するためには、必ずバクラク申請（ワークフローシステム）を必要とする。
ワークフロー上、データベースシートの入力ステップがあり、そのワークフローをトリガーに、入力を行っています。
解約を行う際も、専用のバクラク申請フォーマットがあります。解約自体は、口頭合意等で内部統制上OKとする運用をしております。そこでも、入力ステップが確保されており、確実にチャーンの事実をデータベースシートに転記できます。
細かい話が多いですが、情報の信頼性の確保（ミスが少ない、反映までのタイムラグが短い）のためには、大事な要素です。
C_03_財管一致させるための論点
ようやく、財管一致の工夫の話です。
まず、論点となる事項は下記です。
タイムリーに収益認識基準に沿った、売上金額を算出できる体制をつくる
他部署のKGI/KPIの管理もうまく回る座組をつくる
財管一致していることを、チェックする体制をつくる
1点目（タイムリーに収益認識基準に沿った、売上金額を算出できる体制をつくる）に関しては、「契約が締結された後に、即座に財管一致したNewMRR等の数値の算出ができるか」ともいえます。即時反映が大事なので、契約締結後に論点にぶち当たり、収益認識基準に則った財務会計上の売上を検討する流れだと、即時反映が難しい/後から数値を修正しなければいけないリスクがあります。
なので、下記ふたつが重要になると考えます。
収益認識基準を高度に理解し、後から監査法人に誤りの指摘を受けないような処理方法を決定する必要がある。
都度監査法人に相談するのは、工数がかかるので、正しい回答を自分たちで出せることが大切です。
新規事業等の情報を、上流でキャッチできるように、事業サイクルにしっかりコーポレートが入り込む体制が必要である。
上流の段階で、商材の特性を理解し、収益認識上の履行義務が何なのかをしっかり把握することが必要です。
2点目（他部署のKGI/KPIの管理もうまく回る座組をつくる）について、各部は自部門の、より詳細な数値は管理しています。そして、Saleforceでそれがすべて見えることを望むケースが多いと思います。
そのため、財管一致を目指すことにより、どうしてもSalesforceと差分が出てしまうところは、うまい共存方法を構築する必要があります。
弊社の場合は、結果的に各部もスプシを多く活用している運用になっているため、手で補正しやすく、大きな問題は出ませんでしたが、Salesforce上メインで各部が数値管理をしている場合は、そことスプシは一定差分がでることを理解したうえで運用する必要があると思います。
3点目（財管一致していることを、チェックする体制をつくる）については、主に下記二つの内部統制を引くことで、数値の正確性を担保できると考え、運用しています。
スプシ上で表示されている各月のMRRと、PL上に計上されている各月のMRR売上が一致しているかどうかのチェックシート
また、念のためSalesforce上で認識されているMRRと、PLの数値との比較も行います。当然差分は出ますが、そこが説明できる差分かを検証します。（この資料は、監査法人にも提出しています）
C_04_SaaS企業が気にする収益認識の論点
最後に、財管一致を気にする際に、よくぶち当たる論点を列挙します。答えを自分で考えて作らなければいけないものもあり、ここは是非社外との横のつながりを強化して、ベストプラクティスを吸収していきたいなと今後考えております。
値引きの処理
例えば初月のみ無料とした場合に、それを契約期間にわたって按分する必要がある等
契約当初から、途中の月での金額増額/減額が確定している場合に、その増減が履行義務の変化を伴う増減なのかの判断
契約書上、プロダクト毎の金額内訳が明確に表示されていない場合の、プロダクト毎の売上金額
売り方によってはこのような論点が出うる
MRRには影響しないですが、初期費用をどのように按分計上していくかの論点（商材によって、初期費用の履行義務の性質が変わり、処理の仕方が変わることは全然ありえます）
D_まとめ
ここまで書いた内容を、正直弊社もすべて精度高くできているかというと、まだまだなところはあります。特に、収益認識の整理については、もう少し処理のパターンの型化をしておく必要がありますし、販売管理のルールの明文化もまだしきれていません。
財管一致させることは、予実管理をやりやすくするメリットがありますし、スプシでメトリクスを管理する必要がある場合は、一旦はこのnoteで記載したようなルールでやることで、割と精度高く、効率的に管理できると思っております。（とはいえ、エンジニアやデータアナリストの力を借りればもっと楽に更新できる余地はあると思います）
長文になりましたが、以上となります。最後までお読みくださった方、ありがとうございました。
明日は、コーポレート部長のすとうなおきさんが、「スタートアップにおけるSO設計の考え方」を投稿してくださります。
最後になりますが、Asobicaでは仲間をいろんなポジションで募集しております。ご興味ある方は是非下記をご覧ください。ビジネスサイドからエンジニアまで、幅広く募集させていただいております。