費用と上限

誰が何を使えるかが決まると、次に気になるのが費用です。使える機能が広いほど、上限をどこに置くかの判断が重くなります。このレッスンでは、支出上限の仕組みと、初期値の決め方を扱います。

支出上限は3層で決まる

支出上限は、組織全体の上限・グループ単位の上限・個人単位の上書きの3層で構成されています。グループ単位の上限には、グループ全体で1つの予算を共有する「プールされた予算」と、メンバー1人あたりの上限の両方を設定できます。

メンバーが複数のグループに属し、それぞれ違う上限が設定されている場合はどうなるでしょうか。この場合は「Multi-group spend limit」という、組織全体で1つだけ決める設定が使われます。この設定を「高いほうの上限」にしておけば、大きなグループに控えめな基準値を置きつつ、特定のチームだけ余裕を持たせる形になります。「低いほうの上限」にしておけば、大きなグループに広い上限を設定しつつ、サブグループで予算を絞り込む形になります。

上限に達するとどうなるか

上限に達したメンバーは、使えなくなって終わりではありません。アプリ内の通知から「Request more usage」を選ぶと、管理者へ増額のリクエストが送られます。Owner・Primary Owner、またはBillingの権限を持つカスタムロールのメンバーが、管理コンソールでリクエストを確認し、承認か却下かを選べます。却下した場合、そのメンバーの申請ボタンは30日間非表示になりますが、管理者側からはいつでも直接上限を引き上げられます。

この仕組みがあるおかげで、上限は「一度決めたら終わり」ではなく、実際の使われ方を見ながら調整していくものだと分かります。

初期値は控えめから始める

上限をどこに置くか、最初は見当がつきにくいものです。公式のガイドは、ロールアウト前に大まかな階層を作ることを勧めています。高頻度だが単純な作業が多い役割、チャットで日常業務をこなす一般的な役割、複雑な作業を伴うエンジニアや研究の役割、というように分けると、上限を役割ごとに一貫させやすくなります。

そして、初期値そのものについては「控えめに始めるほうがよい」という方針が示されています。低すぎた上限をあとで引き上げるのは簡単ですが、使いすぎてしまった状態から予算の話し合いをするのは気まずいものです。最初から寛大な上限を設定するより、控えめな値から始めて、実際の使われ方を見ながら引き上げていくほうが、結果として運用しやすくなります。

例で見る、上限の運用

一般企業であれば、営業・マーケティング部門は高頻度だが単純な作業が多いので控えめな個人上限にしつつグループでプールされた予算を持たせ、開発部門は複雑な作業が多いので個人上限を高めに設定する、といった組み立てが考えられます。

病院であれば、外来の事務作業を支援する部署は控えめな上限で十分なことが多く、研究部門で長い文献をまとめて扱う場合は個人単位で上限を引き上げる、という判断がありえます。いずれの場合も、最初の数か月は「Request more usage」の発生状況を見ながら、基準値そのものを見直す運用を組み込んでおくとよいでしょう。

やってみよう

演習1：自分の組織を3階層に分ける

自分の組織のメンバーを、高頻度だが単純な作業が多い役割・チャットで日常業務をこなす役割・複雑な作業をする役割の3つに大まかに分けてみてください。境界があいまいな人がいれば、どちらに寄せるか理由とともに考えます。

演習2：Multi-group spend limitをどちらにするか考える

複数グループに属すメンバーがいる場合、「高いほうの上限」と「低いほうの上限」のどちらが自分の組織に合いそうか考えてみてください。大きなグループに控えめな基準を置きたいか、広い基準を置いてサブグループで絞りたいかで、選ぶべき方向が変わります。

今日のまとめ

3行で振り返ります。

• 支出上限は組織全体・グループ・個人の3層で決まり、個人単位の上書きは常にグループの上限より優先される
• 上限に達したメンバーは「Request more usage」で増額を申請でき、Billing権限を持つ管理者が承認・却下できる
• 上限の初期値は役割ごとの階層を作り、控えめに始めて実際の使われ方を見ながら引き上げていくのが安全

次のレッスンでは、ここまで決めてきたアクセス・ガバナンス・支出が実際にどう動いているかを、何を記録し、どれだけ残すかという可視性の決定で確かめます。