Metering †
要約 †
メータリングとは、何かのリソース（あるいはアプリケーションが扱うその他のなにか）の制約や消費にもとづいたビジネスモデル。
制約モデルは、特定のリソースにだけアクセスできるように制限するもの。
消費モデルは、リソースの利用量を制限する（リソースをすべて使い切ると、ソフトウェアが使えなくなる）もの。
これらを組み合わせた、以下のようなビジネスモデルがある。
同時アクセスリソース（Concurrent Resource Management） †
システムに同時アクセスするリソースの数を計測する。この場合の「リソース」は、ユーザーやセッションなどであることが多い。
「同時10ユーザーまで使用可能」などのパターン。
このモデルにおける「リソース」を定義するには、tarchitecture的な考えかたが必要。
このビジネスモデルは、「エンタープライズ」業界以外ではほとんど使われていない。
特定リソース（Identified Resource Management） †
リソースに対して制約をかけて、（ユーザー名などで）適切に認証されている場合にだけシステムへのアクセスを許可する。
このビジネスモデルを、先の同時アクセス型と組み合わせることも多い。
「35人までのユーザーが、最大で同時10人までシステムにアクセスできる」
「用意されている5つのプラグインのうち、3つまでを利用できる」
など。
ユーザーをいくつかのグループに分類して、グループごとに、使える機能やアプリケーションを定義するという方法もある。
この手法を使う場合の管理の手間は、企業のIT部門にとっては悩みの種だ。LDAPなどの既存の基盤があるのなら、それを活用すればいい。
リソース消費（Consumptive Resource Management） †
一定の量のリソースを用意して、アプリケーションの起動時や実行中に、そのリソースを消費する。
そして、使ったリソースについて課金する。
たとえば時間をリソースとした場合なら、「一定の時間（100時間、あるいは30日など）だけ利用可能」などのライセンスになる。
これを一般化した「抽象化したリソースを定義して、それを計測する」というビジネスモデルも考えられる。
動画公開用アプリを扱っているとしよう。売りとなる機能はふたつ。
バックグラウンドノイズの自動除去と、背景の露出の自動補正だ。
このとき、ノイズ除去機能を使うたびに1単位、露出補正機能を使うたびに3単位というように定めて、合計で20単位まで扱えるようなライセンスを設定する。
このモデルを、サブスクリプションベースのサービスモデルの基盤にすることもできる。
たとえば、月額料金を定めて、その間に一定量のリソースを使えるようにする。
もしリソースを使い切ったら、追加料金を支払うか、いったんアプリケーションの利用をやめる。
使い切れなかったりソースは、次の期間に持ち越せるようにする。
リソース消費モデルの要件として、大切ではあるが見過ごされがちなものがある。報告と補充だ。
- 報告
- ある操作にどれだけの「コスト」がかかるのか、どれくらいの頻度でその操作が発生するのか、割り当てをオーバーしたときの追加料金はどれくらいかなどを、事前にユーザーが知ることができなければいけない。
- 補充
- リソースを使い切った場合の追加注文を、簡単にできるようにしておかなければいけない。
担当者のつぶやき †
みんなの突っ込み †
