ライセンスの最適化 - パターン

適切に設計されたリソースとコストの最適化 → ライセンスと消費

パターン

参照すべき場所外観
プラットフォーム | 組織✅ ライセンス種別は実際のユーザー要件と使用パターンに一致 (役職ではない)
プラットフォーム | 組織✅ カスタムオブジェクトのみにアクセスするユーザーには、Salesforce フルライセンスではなく Platform ライセンスが付与されます。
プラットフォーム | 組織✅ 外部ユーザー (顧客、パートナー、コミュニティメンバー) は、内部ライセンスではなく Experience Cloud ライセンスを使用します。
プラットフォーム | 組織✅ データアクセス権のない認証のみが必要なユーザーは Identity ライセンスを受け取ります
プラットフォーム | 組織✅ 四半期ごとのライセンス監査で、カスタムオブジェクトのみにアクセスするユーザーをプラットフォームライセンスの候補として特定
プラットフォーム | 組織✅ 自動四半期レポートでは、90 日間ログインゼロのユーザー、カスタムオブジェクトのみにアクセスするユーザー、内部ライセンスの外部ユーザーを特定し、体系的な適正サイズ設定を実現します。
プラットフォーム | 組織✅ ライセンスの割り当ては、何年も変更されることなく、ロールの変更に基づいて確認および調整されます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 組織⚠️ Salesforce フルライセンスは、実際のシステム使用パターンではなく役職に基づいてすべての従業員に割り当てられます。
プラットフォーム | 組織⚠️ カスタムオブジェクトのみにアクセスするユーザーには、プラットフォームライセンスではなく Sales Cloud または Service Cloud フルライセンスが付与されます。
プラットフォーム | 組織⚠️ 外部ユーザーは Experience Cloud ライセンスではなく内部ライセンス容量を消費します。
プラットフォーム | 組織⚠️ 初期リリース時に設定されたライセンス割り当ては、ロールが変更されても 3 年間変更されません。
プラットフォーム | 組織⚠️ ライセンス監査は実施されず、40% のライセンスが未使用または十分に活用されていない
プラットフォーム | 組織⚠️ ログイン数が 1 か月未満のユーザーは、ライセンスの再利用の対象として識別されません。

パターン

参照すべき場所外観
プラットフォーム | セキュリティ✅ Shield コンポーネント (プラットフォームの暗号化、イベント監視、項目監査履歴) は、特定のコンプライアンスニーズに対応しているかどうかに基づいて個別に評価されます。
Data 360 | アーキテクチャ✅ Data 360 への投資は、システム間の ID 解決、リアルタイムの顧客データアクセス、セグメントの有効化の要件によって正当化されます。
AI | ビジネス✅ AI 投資では、不特定の値を想定するのではなく、定義済みの測定期間内に実証された ROI が必要です。
プラットフォーム | Industry Cloud✅ Industry Cloud (金融サービス、医療、製造、Net Zero) は、カスタム開発コストと市場投入までの時間の要件に対して評価されます。
プラットフォーム | Industry Cloud✅ Industry Cloud 評価では、標準ワークフローの実装時間が 40 ～ 60% 短縮されますが、カスタマイズを考慮することで時間が節約されます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | セキュリティ⚠️ すべての Shield コンポーネントは、特定のコンポーネントが実際のコンプライアンスやセキュリティのニーズに対応しているかどうかを評価せずに購入されます。
Data 360 | アーキテクチャ⚠️ Data 360 は、よりシンプルなインテグレーションアプローチが要件を満たしているかどうかを評価せずに購入される
AI | ビジネス⚠️ AI 投資に測定可能なビジネス価値評価指標や ROI の実証がない
AI | ビジネス⚠️ AI 投資は、特定の測定期間や成功基準を定義しないで価値を提供することを前提としています。
プラットフォーム | Industry Cloud⚠️ Industry Cloud は、カスタム開発コストと比較したり、市場投入までの時間を短縮したりすることなく購入されます。

パターン

参照すべき場所外観
プラットフォーム | プロビジョニング✅ 新しいユーザープロビジョニングワークフローでは、カスタムアプリケーションのみにアクセスするユーザーにプラットフォームライセンスが自動的に割り当てられます。
プラットフォーム | プロビジョニング✅ 新規ユーザープロビジョニングワークフローは、メールドメインに基づく Experience Cloud ライセンスの割り当てのために外部ユーザーをキューに入れます。
プラットフォーム | プロビジョニング✅ 割り当てポリシーでは、ユーザーロールとプラットフォームの使用要件に基づいてライセンス種別の明確な条件を定義します。
プラットフォーム | プロビジョニング✅ 承認ワークフローでは、プレミアムライセンスの種類にビジネスの正当性が必要
プラットフォーム | プロビジョニング✅ 誤った割り当てを遡って修正するのではなく、プロビジョニング時に適切なライセンス割り当てが適用される
プラットフォーム | 組織✅ 再利用プロセスでは、無効なユーザー (60 ～ 90 日) を自動的に特定し、未使用のライセンスを再割り当てするために再利用します。
プラットフォーム | 組織✅ ログインベースのレポートでは、組織ポリシーに基づいて 60 ～ 90 日間無効なユーザーを特定します。
プラットフォーム | 組織✅ 四半期ごとの再利用により、従業員の職務変更や退職に伴うライセンスの無駄の累積を防止
プラットフォーム | KPI✅ 利用状況監視ダッシュボードでは、ログイン頻度、機能の使用パターン、ライセンス種別の妥当性を追跡します。
プラットフォーム | ビジネス✅ 利用状況データはビジネスリーダーと共有されるため、更新計画時にデータ主導のライセンス投資を判断できます。
「Reports & Dashboards (レポートおよびダッシュボード)」 →「License Utilization Dashboard (ライセンス使用状況ダッシュボード)」
[設定] → [ユーザー] → [有効ユーザー]		✅ パターン:ライセンス利用状況ダッシュボードには、有効なライセンスと無効なライセンス、ログイン頻度の分布、ライセンス種別ごとの機能の使用状況、ライセンス種別の分布が表示されます。
✅ 利用状況ダッシュボードでは、無効なユーザー、ライセンスが過剰なユーザー、確認が必要なライセンス種別の不一致を明らかにします。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | プロビジョニング⚠️ ライセンス割り当てポリシーが存在しない。各要求はアドホックに処理される
プラットフォーム | プロビジョニング⚠️ 承認ワークフローでは、プレミアムライセンスの種類にビジネスの正当性は必要ありません。
プラットフォーム | 組織⚠️ 無効なユーザーの識別が自動化ではなく手動であり、頻度が低い
プラットフォーム | 組織⚠️ ライセンスの再利用は、四半期ごとではなく 1 年ごとの更新時にのみ行われます。
プラットフォーム | 組織⚠️ ライセンスの無駄は、従業員が役割を変更したり、ライセンスを再利用せずに退職したりすると、何年も蓄積されます。
プラットフォーム | KPI⚠️ 使用状況監視ダッシュボードが存在しない。使用パターンが不明
プラットフォーム | ビジネス⚠️ ビジネスリーダーが更新計画時にライセンス利用状況データを可視化できない

パターン

参照すべき場所外観
プラットフォーム | 契約✅ ユーザー数コミットメントは、楽観的な売上予測ではなくビジネスプランでサポートされる
プラットフォーム | 契約✅ ランプスケジュールは、未使用容量の前払いではなく、実際のユーザーオンボーディングタイムラインと投資を照合します。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 契約⚠️ ユーザー数に過度にコミットすると、未使用のライセンスによってすぐに無駄が発生し、価値を提供できずに予算が消費されます。
プラットフォーム | 契約⚠️ 成長予測が正しくないことが判明した場合、柔軟性のニーズを評価しずに複数年契約を締結
プラットフォーム | 契約⚠️ 調整のタイミングがビジネス計画サイクルと一致せず、調整が実際の人員変更よりも遅れる
プラットフォーム | 契約⚠️ ボリューム割引を達成すると雇用計画が遅れるため、組織は 200 個の未使用ライセンスを 18 か月間保持している

パターン

参照すべき場所外観
プラットフォーム | アーキテクチャ✅ インテグレーション アーキテクチャ計画では、API消費を予測し、Enterprise EditionとUnlimited EditionのどちらでTCOが向上するかを評価
プラットフォーム | アーキテクチャ✅ 含まれる機能 (API 制限、ストレージ、Sandbox 割り当て、プレミアサポート) に対するユーザーごとのプレミアムのエディションコスト比較モデル
プラットフォーム | アーキテクチャ✅ Edition 決定モデルでは、将来の再評価を可能にする文書化した前提条件を使用して、両方の価格モデルに対する使用量を予測しました。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | アーキテクチャ⚠️ アーキテクチャ要件を分析しなくても、予算の制約に基づいてデフォルトで最上位または最下位の階層が選択されます。
プラットフォーム | アーキテクチャ⚠️ Enterprise Editionを選択すると、インテグレーション要件やAPIの超過コストを予想することなく、ユーザーあたりのコストを最小限に抑えることができます。
プラットフォーム | アーキテクチャ⚠️ リリース後にインテグレーション要件が制限を超え、API の超過とアーキテクチャのやり直しによってコストが 2 倍になる
プラットフォーム | アーキテクチャ⚠️ Edition の決定は、価格設定モデルと文書化の前提条件の両方に対して実際の使用量をモデル化せずに行われます。
プラットフォーム | 組織⚠️ エディションの選択は、アーキテクチャ上の制約をモデル化することなく、ユーザーごとの年間サブスクリプションコストのみに基づきます。

パターン

参照すべき場所外観
プラットフォーム | アーキテクチャ✅ 単一組織最適化アプローチ (共有ルール、権限セット、レコードタイプ) は、複数組織アーキテクチャを採用する前に評価されます。
プラットフォーム | アーキテクチャ✅ 複数組織のTCOモデルでは、管理、リリース管理、監視、インシデント対応、コンプライアンスなど、運用コストは2~3倍に増加
プラットフォーム | アーキテクチャ✅ 複数組織アーキテクチャは、規制要件 (GDPR データレジデンシー、財務分離) によってコストの増加が相殺される場合にのみ採用されます。
プラットフォーム | アーキテクチャ✅ 権限境界を持つ単一組織では満たすことができない、真の分離要件をマルチ組織の正当性で文書化
プラットフォーム | 契約✅ マルチ組織ライセンスのコストは、組織ごとに別々のライセンスプールをモデル化するため、ボリューム価格がなくなり、重複する管理ライセンスが必要になります。
プラットフォーム | アーキテクチャ✅ 複数組織の運用コストは、複数の実装にまたがる並列メンテナンスをモデル化し、開発と運用の労力を増加

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | アーキテクチャ⚠️ マルチ組織アーキテクチャを採用しているのは、モデリングなしでビジネスユニットが「独立」を望んでおり、コストが 2 ～ 3 倍に増加するためです。
プラットフォーム | アーキテクチャ⚠️ 共有ルールを使用する単一組織が実際の要件をわずかなコストで満たすかどうかを評価せずに複数組織の採用が行われる
プラットフォーム | アーキテクチャ⚠️ 複数組織の TCO モデルには、運用コストの乗算は含まれません (システム管理者、リリース管理、監視、コンプライアンスの場合は 2 ～ 3 倍)。
プラットフォーム | アーキテクチャ⚠️ マルチ組織アーキテクチャには、永続的なコスト増殖と複利なコスト増殖を超える価値を示すビジネス上の正当性が文書化されていない
プラットフォーム | 契約⚠️ マルチ組織ライセンスコスト分析では、ボリューム価格設定のメリットを失う個別のライセンスプールは考慮されません。
プラットフォーム | アーキテクチャ⚠️ 複数組織の運用負荷はモデル化されていません。導入後に組織間の並列メンテナンスが検出されます。

パターン

参照すべき場所外観
プラットフォーム | インテグレーション✅ マルチ組織の TCO には、MuleSoft ライセンス (年間 2 万～ 20 万ドル以上)、インテグレーション開発、継続的なメンテナンス、API 業務量計画が含まれます。
プラットフォーム | インテグレーション✅ MuleSoft の投資、開発工数、継続的な運用コストが明示的に示されている組織間インテグレーションコストがモデル化されている
プラットフォーム | アーキテクチャ✅ API 消費の乗算がモデル化されている: 複数の組織で同時に 5 ～ 10 個の API コールを使用する組織間トランザクション
プラットフォーム | インテグレーション✅ 組織間で同期された参照データを維持するためのデータ整合性オーバーヘッドには、開発作業、監視、競合の解決が含まれます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | インテグレーション⚠️ マルチ組織アーキテクチャは、年間 24 万ドルのインテグレーションコストをモデル化することなく、ライセンスコストの比較に基づいて承認されます。
プラットフォーム | インテグレーション⚠️ 組織間インテグレーションのコストは明示的にモデル化されていません。単一組織では、これらのコストは完全に排除されます。
プラットフォーム | アーキテクチャ⚠️ 組織間コールからの API 消費の乗算は業務量計画では考慮されません。
プラットフォーム | インテグレーション⚠️ 同期された参照データのデータ整合性のオーバーヘッドは、複数組織の TCO モデルに含まれません。

パターン

参照すべき場所外観
「設定」→「Sandbox」 → 「環境戦略」
DevOps → Sandbox 割り当て計画		✅ パターン: チームは、モックデータを使用した機能開発に Developer Pro Sandbox を使用し、インテグレーションテスト用に対象取引先を使用した部分的なコピーを行います。
✅ 完全なデータ量がアーキテクチャ上必要な場合の本番稼働前のUATおよびパフォーマンス検証専用のフル コピーを予約
「設定」 →「Sandbox」 →「バランスの取れた戦略」
「財務」 → 「環境予算」		✅ パターン:15人の開発チームが、15個のDeveloper Pro Sandbox(毎月750ドル)、並列作業ストリーム用の3個のPartial Copy(毎月900ドル)、UAT用の1個のFull Copy(毎月3,000ドル)を使用してバランスの取れた戦略を実装
✅理論上の最大並列化のために過剰なプロビジョニングを行うのではなく、実際の開発パターンに一致する月額 4,650 ドル
「設定」 → 「Sandbox テンプレート」 → 「データの選択」
[設定] → [部分的なコピーの設定]		✅ パターン: Partial Copy Sandboxテンプレートには過去12か月間の商談とケースが含まれ、アーカイブデータは除外されます。
✅ フルコピーではなく、5 GB の容量内で代表的なテストデータを提供し、戦略的なデータ選択により低コストの Sandbox タイプを実現
「プロセス」→「Sandbox ライフサイクル」
「設定」→「一時的な環境追跡」		✅ パターン: 一時的な Sandbox 管理で、削除日が文書化されている特定のプロジェクト用に作成された環境を追跡する
✅ 更新の正当性を要求する有効期限ポリシーを実装して、初期範囲を超える一時的な環境を維持し、永続的な状況のドリフトを防止
「設定」 →「Sandbox 更新スケジュール」
[カレンダー] → [更新の最適化]		✅ パターン: 更新ケイデンスの最適化により、Sandboxの更新を任意のスケジュールではなく実際のデータ更新の要件に合わせる
✅ テストパターンで月次更新が不要な場合は四半期ごとのフルコピー更新で十分であり、追加の Sandbox の容量を解放できます。

アンチパターン

参照すべき場所どんな悪い感じか
オーバープロビジョニング → 投資の無駄遣い⚠️ アンチパターン: 組織は Full Copy Sandbox を 5 つ購入し、すべての開発チームに専用の環境を提供します。
⚠️ 部分的なコピーがほとんどのテスト要件を満たす場合、乗算のコストは5~10倍になります。完全な本番環境への忠実性を必要とするシナリオでは、完全コピーを予約してください。
戦略なし → 保険料のデフォルト⚠️ アンチパターン: 15人チームで「環境が多いほど良い」という理由で、30個のDeveloper Proと5個のFull Copy Sandbox(毎月18,000ドル)を含むプレミアム戦略を購入
⚠️ 環境の可用性によって制約される開発速度を示す分析はなく、バランスの取れた戦略では毎月 4,650 ドルで同じ速度を実現します。
絞り込まれていないテンプレート → 強制アップグレード⚠️ アンチパターン: Partial Copyテンプレートには、フィルタリングなしのすべてのオブジェクトが含まれており、テストに関連しない履歴データで5 GBの容量を消費します。
⚠️ 戦略的なデータ選択により、Sandbox あたりのコストを 5 ～ 10 分の 1 に抑えて Partial Copy を使用できる場合、Full Copy の購入を強制する
Sandbox の無秩序な増加 → 永続的な一時⚠️ 対策パターン: プロジェクトの Sandbox が正当な理由なく永続的なステータスに移行するため、Sandbox が一時的に急増する
⚠️ 一時的な環境に消費予算を無期限に蓄積できる有効期限ポリシーや更新要件がない