使用量の計測と料金設定：技術部門対財務部門

はじめに

使用量ベースやハイブリッド型の価格設定が固定されたままになることはめったにありません。価格設定のロジックがハードコーディングされていると、料金階層やクレジット枠にわずかな調整を加えるだけでも、エンジニアリングチケットが発生してしまいます。これは財務部門にとっては処理が遅く、開発者にとっては苛立たしいものです。では、使用量の計測と、それに基づいて構築される価格設定は、誰が担当すべきなのでしょうか？ ここで整理してみましょう。

価格変更が頻繁に行われるようになった理由

価格設定は、一度決めてしまえばそれで終わりというものではなくなりました。コンサルティング会社hyとOMR Reviewsによる「SaaS & AI Pricing Report」は、Growth Unhingedのデータを引用し、米国のソフトウェア企業の4社中3社が過去1年間に価格設定を変更したと報告しています。これは非常に大きな動きです。

価格設定モデルも変化しています。hyが180社のソフトウェア企業を対象に行った調査によると、37％がすでに利用量ベースのモデルを採用しており、59％がユーザー単位の課金とAPI利用量など、複数の価格設定指標を組み合わせています。クレジットの追加、実験の実施、パッケージ構成の微調整などが行われる中、変更は例外ではなく、むしろ当たり前になりつつあります。

価格設定のロジックがなぜエンジニアリング部門の管轄になるのか

これはたいてい偶然に起こる。初期段階では、開発者が指標をハードコーディングする――API呼び出し回数をカウントし、単価を適用し、合計額を請求書に反映させる。それが機能するため、誰も疑問を抱かない。

その後、価格設定が進化します。新しい料金階層、無料枠、あるいは異なる超過料金率の導入により、誰かがチケットを登録し、スプリントの枠を待ち、リリースが請求処理に支障をきたさないことを願うことになります。リードタイムは長引き、すべてのリリースには何らかのリスクが伴います。財務部門は、自分たちがコントロールできない待ち行列に並ばざるを得なくなります。

ハイブリッドモデルでは、この状況はさらに悪化します。価格構成要素が多ければ多いほど、コード内のどこに変化が潜んでいるか特定しにくくなるからです。

エンジニア主導の価格設定がもたらすコスト

スプレッドシートで証明できなくても、そのコストは現実のものだ。

• 導入の遅れ：価格設定のアイデアは、プロダクト開発業務の後ろに追いやられ、数週間も放置されることがあります。
• エラー：コードの奥深くに埋もれたロジックは財務部門が読み解くのが難しいため、請求書に誤りが表れがちです。
• 財務部門の盲点：数値の算出方法が財務部門に把握できない場合、紛争の解決に時間がかかります。
• 機会費用：エンジニアは製品開発ではなく、課金コードのメンテナンスに時間を費やしている。

私の見解はこうだ。価格変更にコードのデプロイが必要な場合、価格設定のスピードは市場のスピードではなく、リリースカレンダーのスピードに左右されることになる。

財務部門が担当すべきこと、エンジニアリング部門が担当すべきこと

責任の所在は「どちらか一方」というものではありません。意思決定の種類に応じて分担すべきです。

エンジニアリング部門は、イベントの計測、データパイプライン、およびソースにおける利用データの正確性を担当する。

財務とプロダクトは、指標の定義、価格設定、パッケージング、およびクレジットを管轄する。

簡単な判断基準があります。変更内容が「何を計測するか」に関するものであれば、それはエンジニアリングの管轄です。計測された利用状況が「どのように収益に結びつくか」に関するものであれば、それは財務とプロダクトの管轄です。例えば、プランに含まれるAPI呼び出し数を1,000回から1,500回に変更する決定は、価格設定に関する判断です。一方、すべての呼び出しが正確に1回だけログに記録されるようにすることは、エンジニアリングの判断です。

価格変更に関するガバナンス

ガードレールのないまま管理権限を委譲すれば、混乱を招くことになります。以下は、特定のツールに依存しない一般的なベストプラクティスです：

• 承認：変更を本番環境に反映する前に、財務部門とプロダクト部門の担当者による署名入りの承認を必須とする。
• テスト：本番稼働前に、実際の利用データを用いて影響をプレビューする。
• バージョン管理：各価格設定構成にバージョン番号を付与し、バージョンの比較やロールバックが可能にする。
• 発効日：変更が適用される時期と、サイクル途中で既に記録された利用状況の取り扱い方法を定義する。
• 監査証跡：誰が、何を、いつ変更したかを記録する。

これを価格設定におけるコードレビューと捉えてください。誰も他者のチェックなしにコードをリリースすることはありません。価格設定にも同様の配慮が必要です。

財務主導の価格設定に必要な前提条件

財務部門は、信頼できないものを管理することはできません。まず、以下の3つの基盤が不可欠です。

正確な利用データ。イベントの重複や欠落は、それに基づいて設定した価格の信頼性を損ないます。

合意された指標の定義。プロダクト部門と財務部門で「アクティブユーザー」の定義が異なれば、請求書がその論争に決着をつけてくれることになりますが、その結末は決して好ましいものではありません。

信頼できる情報源。利用データは通常、データウェアハウス、APIの背後、またはファイル内に格納されています。各指標について1つの「システム・オブ・レコード」を選び、それを一貫して使用してください。

価格設定の責任移管前に確認すべき事項

CFO、プロダクト責任者、エンジニアリング責任者を一堂に集め、以下の点について検討してください：

1. 昨年、どのような価格変更を行い、それぞれの適用までにどれくらいの時間がかかったか？
2. 課金対象となるすべての指標について、合意された定義が1つずつ存在していますか？
3. 財務部門は、利用実績がどのように請求明細行になったかを追跡できますか？
4. 変更の承認者は誰か、また本番運用前にどのようにテストを行うか？
5. 利用データはどこに保存されており、その正確性について誰が責任を負っていますか？

これらの質問のうち2つか3つに答えられない場合、そこが出発点となります。

計測システムを再構築せずに価格設定を変更する

ここでツールが役立ちます。Zenskarの「Usage Metering」ページによると、チームは請求対象の指標を平易な言葉で定義し、集計ロジックをAIに生成させたり、複雑なロジックにはカスタムSQLを記述したりできます。利用状況データは、Postgres、Athena、MySQLなどのソースから取得し、API経由で送信するか、CSVとしてアップロードできます。同じ指標を、製品、契約、明細項目をまたいで再利用することが可能です。

所有権の観点で重要なのは、使用量ベースの課金ソフトウェアが、使用量とは独立して、料金階層、超過料金、および課金周期の変更を可能にするべきだということです。また、データパイプラインを中断することなく、課金ロジックをサイクル途中で変更することも可能です。単一の指標で契約をまたいだ異なる価格モデルを駆動できるため、価格設定が進化しても計測は安定して維持されます。

結論

最も健全なモデルは「共有」型です。エンジニアリング部門は利用データを正確に保ち、その流れを確保します。財務部門とプロダクト部門は、明確なガバナンスの下で、そのデータの価値を管理します。現在、あなたのエンジニアリングのタスクキューには、どのような価格変更が控えていますか？

主なポイント：

• 価格設定がハードコーディングされていると、各料金階層やクレジットの微調整のたびにエンジニアリングチケットが発生してしまいます。
• 決定の種類ごとに責任の所在を分担します。エンジニアリング部門は利用データの収集と正確性を担当し、財務部門とプロダクト部門は指標の定義、価格設定、パッケージ構成、およびクレジットを管理します。
• まず、承認、テスト、バージョン管理、発効日、監査証跡といった安全策を整備する。
• 財務主導の価格設定には、正確な利用データ、合意された指標の定義、および指標ごとに1つの記録システムが必要です。
• 引き渡し前の5つの質問を活用して、出発点を見つけましょう。
• 計測システムの再構築を必要とせずに価格設定を変更できるツールを選択してください。