席数課金(per-seat)が、実は成長に静かに課される税だと気づいていましたか？ 人を採用するたびに請求書は少しずつ膨らみ、その結果、多くのチームは、本来自分たちを一つにまとめるはずのシステムへのアクセスを絞らざるを得なくなります。リソース課金(resource-based)はその税を取り除きます——ただし、その代わりに予算の立て方も変わってきます。本稿では、席数モデルの隠れコストを解剖し、「リソース」が実際に何を測るのか、誰が最も得をするのか、そして二つのモデルを比べる前に立てておくべき問いを明らかにします。
席数課金の隠れコストは請求書には載らない
ログインの一つひとつに値段が付くと、逆説的なことが起きます。企業が、誰をシステムに入れるかを制限することで管理し始めるのです。現場の第一線——工員、倉庫担当、季節の協力スタッフ——は「一席の価値がない」として門の外に置かれます。そして彼らが置き去りにされるや、隙間を埋めるために隠れた表計算が再来します——シフトを追うExcelファイル、トラブルを報告するチャットグループ。統合のために買った「唯一のプラットフォーム」が、再び分断していきます——技術が足りないからではなく、料金モデルがそれを促すからです。それが最も高くつくコストであり、決して請求書には現れません。
例:「席」が誰にデータを見せるかを決めるとき
オフィス社員約四十人、店舗社員六百人の小売チェーンを思い浮かべてください。席数モデルでは、全社員に権限を与えるのは莫大な費用なので、実際にはオフィス組だけがアカウントを持ちます。その帰結:各店舗の売上は、社員が毎晩メッセージで送り、経理が手入力します。最も価値のある販売データが、席を持たない人々の層で堰き止められ、常に一日遅れます。ユーザーを増やしても費用が発生しなければ、まさにその店舗社員が売場でシステムへ直接記録でき、データレイヤーは発生源で初めて本当に完全になります。
「リソース課金」で、あなたは何に対価を払うのか
リソース課金は、プラットフォームが実際に消費するもの——主にストレージと計算能力——に応じて課金し、アクセスする人数には課金しません。ユーザーを一人増やすことはほとんど費用がかかりません。一人ログインが増えても、容量や処理量が大きく増えるわけではないからです。費用を増やすのは、本物の作業量です——取引の件数、保存するデータ量、そして分析やAIのような重いタスク。ゆえに物差しは、コストにすぎない人員数ではなく、収益を生む当のもの——事業活動の規模——に沿います。
誰が最も得をし、誰は慎重に検討すべきか
人員は多いが一人ひとりがシステムに軽く触れるだけの事業——製造、小売チェーン、フィールドサービス——は、違いを最もはっきり実感します。何千人のユーザーがいても席のコストが発生しません。逆に、裏面についても正直でありましょう。データ量や計算量が大きく変動するなら、リソース課金は席数課金より予測しにくくなります。ユーザーは少ないが非常に重い分析を回す小さなチームは、人員は多いが取引が軽いチームほど節約できないこともあります。これは「常に安い」モデルではなく——「人ではなく仕事に応じて払う」モデルであり、結論を出す前に自分の仕事の形を知る必要があります。
二つのモデルを正しく比べる四つの問い
- 組織の中で本当にデータに触れる必要があるのは何人か、現場も含めて——自ら制限した結果として今払っている「席」の数ではなく?
- あなたの作業量(取引、ストレージ、計算)は安定しているか、それとも季節で大きく変動するか? 安定していればリソースは予算化しやすい。
- 自社のデータの上でAIや重い分析を回す予定はあるか? あるなら、そのタスクがどう課金されるかをはっきり尋ねましょう。
- 初月の請求書だけを比べるのではなく、実際の人員成長計画に沿って、両モデルの三年間総コストを計算しましょう。
この四つに正直に答えると、どのモデルが自社に合うかが、どんな料金比較表よりもはっきり見えてくることが多いです。
実際に何が変わるのか
「席」が物差しでなくなると、利用の広がりが調達プロセスに阻まれなくなります。ある活動に触れる全員が、その中でデータを記録し読めるようになるため、データはアカウントを持つ少数によって入力し直されるのではなく、発生源で即座にデジタル化されます。まさにこれが、単一のデータレイヤー——そしてその後、完全なデータから学ぶ専用のAI——を実現可能にします。要するに、ソフトウェアの課金の仕方は、誰があなたのデータに足跡を残せるかを決めるのであり、それは請求書の一行よりもはるかに遠くまで響くのです。
「ユーザーの追加に費用がかからなくなると、全社がようやく1つのシステムに収まります。」