要約

  • Atlassianの公式例では、25人のConfluence Cloudに入れたアプリを、同じサイトにJira利用者100人がいるTeamwork Collectionへ移すと、100人の価格が適用される。
  • Collectionは内包する製品の利用者を重複なく数える。一方、Marketplaceアプリには独自のライセンスがあり、統合に伴って課金対象が広がりうる。
  • Enterpriseのインスタンス別契約、複数インスタンス契約、Forgeの利用許可者別課金は、それぞれ異なる範囲を扱う。購入できる方式と実際の見積もりを合わせて判断する必要がある。

25人のために買った道具が、引っ越し先で100人分の価格表を渡される。AtlassianのMarketplaceアプリ課金説明には、そういう公式例が載っている。

出発点は、利用者25人のConfluence Cloudと、そこにインストールしたアプリだ。このサブスクリプションを、同じサイトにJira利用者100人がいるTeamwork Collectionへ移す。するとアプリには100人の価格が適用される。変わったのは、アプリが属する購入の枠である。

課金対象の人数は4倍になる。金額を計算するには、そのアプリの料金表、段階別価格、割引が必要だ。公式例だけで移行後の総額は決まらないが、購買担当者が確認すべき順番は決まる。製品をまとめた後、今まで使っていたアプリは誰を数え始めるのか。

一つにまとめた請求書の中で、計算は分かれる

Collectionの課金説明は、内包するアプリのどれか一つ以上にアクセスできる人を課金対象とし、複数のアプリにアクセスする同じ人を一度だけ数える。Teamwork Collectionに含まれるJira、Confluence、Loomなどは、請求書上で一つのCollection契約として表示される。

複数の製品を行き来する社員が多い会社には、説明しやすい仕組みだ。一人の社員が製品の数だけ増殖するわけではない。購入の説明をまとめ、請求項目を減らすことには意味がある。

Marketplaceアプリは、それぞれのライセンスを持って一緒に移動する。Atlassianは、課金がアプリのライセンスとインストール先製品との結び付きに依存し、Collectionへの移行で価格が変わりうると説明している。

つまり、内包製品の利用者の重複を取り除く計算と、専門的なアプリの課金対象を広げる計算は、同時に成立する。前者はセット商品の中で同じ人を数え直す。後者は、別の供給者がどの集団に対してアプリの利用資格を売るかを決める。

セット商品の見積もりだけを比較すると、最初の計算はよく見える。既存アプリの見積もりを並べて初めて、二つ目が見える。請求書の行が短くなった分だけ、確認する関係まで減ったと思うと、買い物の一部が表から落ちる。

小さな部署にとっては、とりわけ説明が難しい。必要としていた仕事は変わらず、道具も同じでも、その商業的な範囲だけが大きくなる。利用部門が増えたという報告より先に、請求対象が増える設計だ。

道具を開いていない人も、ライセンスの内側にいる

Forgeの課金モデル説明は、標準方式ではホストとなるインスタンスの全利用者に対して課金すると明記する。Marketplaceアプリを実際に何人が使っているかとは別の数え方である。

公式の説明用計算では、Jiraの利用者は500人、そのうちアプリを使う人は50人だ。例示単価が一人当たり月2ドルなら、500人分の月1000ドルになる。人数と単価は、課金の仕組みを示すための教材として提示されている。

専門的な道具を売る側と、それを欲しい少人数のチームの間には、ここで距離ができる。チームは自分たちの文書、報告、作業手順を改善したい。購入する資格の範囲は、より大きな共有環境についてくる。機能が役に立つという説明に加え、その大きさの契約を買う理由も必要になる。

会社が共有環境を大きくすることにも、もちろん目的がある。共同作業をしやすくし、設定をまとめ、分散した管理を減らしたい。ホスト全体に従って売られるアプリにとっては、その共有環境が販売対象の範囲になる。運用上の統合と、専門ツールの購入費は、同じ方向に動くとは限らない。

Jiraアプリについては、人数の単純合計でもない。同じサイトにJira利用者100人とJira Service Managementのエージェント80人がいる公式例では、大きい方の100人が採用される。180人を足し上げる方式ではない。100人のJira契約を無効にした場合は、次の請求サイクルから残る80人の価格になる。

購買担当者が追うべきなのは、そのアプリの人数を決めているホスト製品だ。アプリの利用ログを読むだけでは、どの集団のライセンスを買っているかまでは分からない。

インストール先にも値札が付く

Enterpriseの請求説明には、Acmeという架空の組織を使った別の例がある。Jiraの8000人を、5000人と3000人の二つのインスタンスに分けている。5000人側に入れたMarketplaceアプリは、そのインスタンス単位の方式では5000人の枠で請求される。

会社全体の規模が、そのまま個々のアプリの購入規模になるわけではない。どこに入れるかは、どの範囲のライセンスを買うかという選択でもある。特定の仕事をする道具と、全社で使う道具では、適した置き場所が異なりうる。

ただし、環境を細かく分ければ管理の仕事も付いてくる。設定を保ち、利用者にアクセス方法を案内し、別の環境にいる部署との連携を整える。アプリの見積もりが下がったという数字だけでは、この仕事を含む費用比較は終わらない。

AtlassianはCloud EnterpriseのJiraとConfluenceについて、複数インスタンスをまとめるアプリ課金も説明している。組織単位の一つのMarketplace契約で複数のインスタンスを扱い、そこをまたぐ同じ利用者を一度だけ数える。人数は契約開始時に選んだ利用者枠に基づく。契約後、機能を使うためには各インスタンスへのインストールが必要だ。

これは、同じ人が複数の環境に現れる重複を扱う。一つの大きな環境の中で、必要な少人数だけにアプリ利用を認めて課金する方式とは、対象となる境界が違う。何を重複と呼んでいるのかを決めてから、料金方式を比べるべきだ。

同ページは、すべてのアプリが複数インスタンス価格を提供するという説明を未来形で書いている。個別購入では、そのアプリに今用意されている選択肢を確認する必要がある。文書に載る方式と、手元の見積もりで選べる方式を一致させる作業が残る。

少人数に絞る方式でも、供給者は価格を選ぶ

Forgeの利用者別課金の導入ガイドは、管理者がアプリへのアクセスを許可した人だけを課金対象にする設計を説明する。数えるのは利用資格を与えた人であり、クリック数や実際に使った日数とは別の基準だ。

今回確認した開発者文書は、この機能をEAPとし、非本番環境での開発、配備、試験を説明している。Marketplaceでの公開、価格設定、改訂、承認は今後の更新に含まれると書く。同時に公開済みアプリや本番移行の条件も載っているため、現在の購入では対象アプリに実際に有効な課金方式を確かめる必要がある。

設計の中でも、供給者の選択は残る。パートナーが採用を決め、価格を調整でき、既存顧客もアプリの方式変更に伴って移行する。対象はForgeで、Connectアプリは先にForgeへ移る必要がある。買い手が許可名簿を短くしただけでは、その名簿に合わせた商品が生まれるわけではない。

少人数で買える方式は、専門ツールが大きな組織に入る入口を広げる可能性がある。一方で、供給者は狭くなった販売対象に合わせて単価を見直せる。課金人数と総支出の関係は、最後まで見積もりに残る。

個別の移行額や節約額を確定するには、適用ライセンス、選んだ人数枠、供給者の見積もりが必要だ。公式の25人から100人への例は、それをいつ確認すべきかを教える。移行が終わり、道具が新しい仕事の組み合わせに組み込まれる前である。

製品をまとめる買い物は、連れていくアプリまで新しい範囲で見積もって完成する。小さな道具が大きな建物へ移るなら、機能の置き場所だけでなく、家賃を数える範囲も見ておきたい。