リソースとコストの最適化

リソースの最適化とコストの最適化が連携して、コストあたりの価値を最大化します。Salesforce は、マルチテナントインフラストラクチャを管理し、すべてのテナントに対してプラットフォームを公平に保つガバナ制限を適用し、ライセンスと消費クレジットを使用してアクセスの価格を設定します。最適化するのは、得られる価値です。つまり、各費用とプラットフォーム容量の各単位で得られるビジネス上の成果です。リソースの最適化はメカニズムであり、すでに支払った金額を効率的に利用します。コストの最適化は結果として実現され、コストを意図的に競争優位性を促進するものに向けることができます。この柱は、同じ目標の 2 つのビューであるため、それらを 1 つの決定として扱います。

このコストあたりの価値ビューにより、アーキテクチャに関するあらゆる意思決定が形成されます。総所有コストを把握することで、能力と投資のトレードオフを改善できます。ビジネス要件に合わせてソリューションのサイズを適切に設定できるため、価値の提供を加速する機能を過度にプロビジョニングしたり、投資不足にしたりする必要はありません。ライセンス、消費クレジット、API コール、Sandbox 環境はすべて同じ等式への入力です。重要なのは、各元帳が返す値であり、どの元帳に基づいているかではありません。問題は「これはコストかリソースか」ではなく「この入力に適切な見返りがあるか」です。

この柱を無視すると、予測可能な結果になります。会社は未使用のライセンスを蓄積し、他の機能は資金源のない状態のまま、予算を消費します。非効率的なアーキテクチャでは、API の容量、ストレージ、開発作業が無駄になり、設計の改善によって回避できない問題が発生します。予測可能な方法で特定の化合物の経時的なリソースの非効率性:

データ量が増加すると、パフォーマンスが低下します。
非選択クエリでテーブル全体をスキャンすると、クエリタイムアウトは数十万件のレコードで発生します。
ソリューションで不要な項目が取得されると、ヒープ制限例外が表示されます。
CPU タイムアウトは、複雑な計算が同期して実行されるときに発生します。
回避策は、チームが新しい制限のたびに適用することで増えていきます。

これらの各失敗は、信頼性の問題であると同時にコストの問題でもあります。無駄な計算は支払った容量を消費するためです。最も重要なのは、予算とエンジニアリング業務量が戦略的なイニシアチブではなく無駄に消費されるため、チームがイノベーションに投資する機会を逃していることです。

コスト効率に優れたソリューションは、次の点で価値を最大化します。

すでに購入済みのプラットフォーム機能の使用
適切な規模のライセンスと使用量を実際の使用量に合わせる
アプローチにコミットする前に完了するコストのモデル化
ビジネス結果に対する支出の継続的な監視

これらの慣行は複合的です。コスト意識とリソース効率を設計に組み込んだチームは、最適化を支出が膨らんだ後のクリーンアップ作業として処理するチームよりも、1 ドルあたりの能力が高くなっています。

リソースとコストの最適化は、他のアーキテクチャの柱に直接接続します。Operational Excellenceは、手作業を削減する自動化により、継続的なコストを削減します。信頼性とTrustは、ビジネス継続性保証とコンプライアンスの価値を通じてプレミアム投資を正当化します。これらの柱を組み合わせることで、アーキテクチャで最大限の利益が得られるため、企業は自信を持って投資できます。

次の原則を使用して、プラットフォームのリソースとコストを最適化するためのアーキテクチャ上の意思決定を導きます。

**総所有コストを最適化します。**総所有コスト (TCO) は、サブスクリプション料金だけでなく、消費クレジット、実装コスト、運用コスト、インテグレーションコスト、変更管理作業にまで及びます。TCO 分析を使用して意思決定を評価し、ソリューションのライフサイクル全体にわたって投資の全体像を明らかにします。先行投資を増やすと、運用コストが大幅に削減され、TCO 分析でそのトレードオフが明らかになる場合があります。短期的なコスト最小化ではなく、長期的な価値のために最適化します。
**支出をビジネスバリューと一致させます。**すべての Salesforce 投資を測定可能なビジネス成果に結び付けます。ライセンス支出により、採用と ToDo の完了によって測定されるユーザーの生産性が可能になります。Data 360 への投資は、取引開始と顧客の生涯価値で測定される意思決定を促進します。Sandbox のコストは、リリースの頻度と品質で測定される開発速度に資金を提供します。支出が価値と一致する場合、成功を促進するものに自信を持って投資し、その見返りを得られなくなった支出を特定します。
**プラットフォームの制限内で設計します。**ガバナ制限では、ソリューションでトランザクションごとに処理できる内容を定義します。最初から設計上の制約として扱い、回避の障害とはなりません。ピーク負荷と最大データ量の制限内で快適に動作するトランザクションを設計し、将来の機能、他のインストール済みパッケージ、予期しないデータパターンに対するマージンを構築します。構想からの制限内で設計されたソリューションは、予測可能なパフォーマンスを持ち、後で緊急リファクタリングを回避します。
**すでに支払ったリソースを最適化します。**容量を追加する前に、すでにプロビジョニングされているプラットフォーム資産のスループット、効率、価値を最大化します。効率的なクエリ、レコードの一括処理 (一括処理)、キャッシュ、統制のとれたデータライフサイクルにより、ソリューションで必要とされるコンピューティング、ストレージ、API の消費を削減します。このリソースの効率性が、持続可能なコストの最適化を促進するメカニズムです。プロビジョニングされたリソースから無駄を排除することで、パフォーマンスと長期的な TCO の両方が向上します。
**実際の使用に適したサイズのライセンスと消費。**各ユーザーを作業で必要なライセンス種別と照合し、自動化とエージェントを設計して、測定サービスを効率的に呼び出します。過剰なライセンスと監視されていない消費クレジットは、最も一般的でコストのかかる廃棄物です。ロール、ログイン活動、機能の使用状況を定期的に監査することで、商談の権利化が明確になり、クレジットバーンを明確に把握できるため、消費ベースのコストを予測できます。
**財務ガバナンスとコスト認識の文化を確立します。**積極的な監視と説明責任の共有により、Salesforce の支出を戦略的投資として管理します。財務ガバナンスでは、リリース後にコストを検出するのではなく、コストメリット分析を設計上の意思決定に使用します。コスト認識は、コストと機能要件を加重するビジネス関係者、アーキテクト、開発者の間で共有される責任であるため、集中管理されたボトルネックのないすべてのレベルでスマートな投資判断が行われます。
**継続的な最適化を実践します。**最適化は、1 回限りの課題ではなく、継続的な課題です。技術およびビジネスの関係者がアクセスできるダッシュボードを使用して、支出とリソースの消費を監視します。消費支出がしきい値に達したときにアラートがトリガーされるように設定し、消費の暴走を見逃さないようにします。定期的なレビューでは、徐々に蓄積される無駄を明らかにし、以前の最適化投資で期待どおりのリターンが得られたことを検証し、ビジネスの優先度とデータ量の変化に応じて新しい機会を明らかにします。

Salesforce の操作を理解することで、制御する内容に対して最適化作業を集中できます。このプラットフォームは、従来の IT 環境で専任チームを必要とするインフラストラクチャレベルのリソース管理を処理します。

マルチテナントリソース割り当て: Salesforce は、共有インフラストラクチャのすべてのお客様で CPU、メモリ、およびデータベース接続を公平に共有し、テナントの消費を監視し、1 つのテナントが他のテナントのパフォーマンスを低下させないように制限を適用します。
**ガバナ制限アーキテクチャ:**プラットフォームで適用される境界(同期トランザクションあたり100 SOQLクエリ、CPU時間10秒、ヒープサイズ6 MB)により、すべてのテナントがリソースの枯渇から保護されます。Salesforce は、これらの制限をマルチテナントインフラストラクチャの容量に合わせて調整します。これらの制限はアーキテクチャの境界であり、恣意的な制限ではありません。
クエリオプティマイザーおよび実行エンジン: Salesforce クエリオプティマイザーは、実行計画の生成、データ配信に関する統計の維持、最適なクエリパスの選択を行います。標準項目のプラットフォーム管理インデックスにより、一般的なクエリパターンが高速化され、オプティマイザーはデータ量の変更に自動的に適応します。
インフラストラクチャの拡張: Salesforce は、ハードウェア容量のプロビジョニング、データベースクラスタの管理、負荷の分散を行い、使用量の増加に応じてインフラストラクチャを拡張します。サーバーのプロビジョニング、データベースレプリケーションの管理、ロードバランサーの設定を行うことはありません。
プラットフォームパフォーマンス最適化: Salesforceは、コアプラットフォームコード、クエリ実行、API応答時間、UIフレームワークのパフォーマンスを継続的に最適化し、定期的なリリースを通じてインフラストラクチャの改善を、お客様のアクションなしで提供します。

Salesforce はプラットフォームの商業面も管理するため、ライセンスと消費はコンピューティングとストレージと同じ柱に属することになります。このプラットフォームでは、容量を購入するエディション、ライセンスの種類、アドオン、消費クレジットモデルを定義し、それらのクレジットを引き出す使用量を測定します。これらの価格はサーバーのプロビジョニング時以外は設定しませんが、各ユーザーが保持するライセンス、自動化でどの程度効率的に測定サービスを呼び出すか、有効な Sandbox の数など、それぞれの使用量を決定します。

これらのプラットフォーム操作は、基盤となります。Salesforce はインフラストラクチャと価格設定モデルの両方を管理しているため、最適化の取り組みは、プロビジョニングされたリソースをどの程度効率的に使用するか、およびプロビジョニングされたリソースをどの程度意図的に使用するかなど、その上で行うアーキテクチャ上の意思決定に全面的に反映されます。

Shared Responsibility Model は、Salesforce 内で作成するすべてのリソース効率をユーザーが所有できることを意味します。プラットフォームリソース管理は作業をサポートしますが、最適化の必要性を置き換えるものではありません。効率的なソリューションでは、すでに支払ったコンピューティング、ストレージ、APIの容量からより多くのビジネスバリューを回収できます。これは、1回限りの予算削減ではなく、コストの最適化を持続可能にするメカニズムです。一方、無駄な計算では、インフラストラクチャリソースが消費され、ビジネス上の価値とコスト複合がもたらされません。データ量が増加するとパフォーマンスは予測どおりに低下し、設計可能な制限にチームがパッチを適用すると回避策も増えます。

最適化の責務は、パフォーマンス、コード整理、パッケージ化、データの 4 つの相互接続領域にまたがっています。それぞれは、技術的な意思決定を行う前のコストあたりの値です。このセクションでは、その決定方法とその理由について説明します。このセクションで参照される正確な実装レシピ、コードレベルテンプレート、設定ナビゲーション、および特定のチューニングしきい値は、リソースとコストの最適化パターンライブラリにあります。

パフォーマンスの最適化は、ガバナ制限の考慮方法の変更から始まります。それらは回避の障害ではありませんこれは、初期設計から採用することで、予測可能なパフォーマンス特性を備えたソリューションが生成されるアーキテクチャ上の制約です。すべてのトランザクションは固定された境界内で実行され、これらの境界はプラットフォーム上のすべてのテナントで公正なリソース共有を適用するために存在します。許可されている 100 件の SOQL クエリのうち 95 件を消費する Apex トランザクションでは、今後の機能、他のチームによって追加されたトリガー、または予期しないデータパターンに対してマージンが残りません。トランザクションを制限の半分未満に抑えているアーキテクトは、制限がなくなったときに緊急リファクタリングなしで拡張できるソリューションを構築できます。ピーク負荷時および最大データ量の制限内で適切に設計し、機能や別のパッケージの自動化を追加してもトランザクションがエッジを越さないようにします。一般的でコストのかかる失敗として、Developer Sandboxでは10件のレコードに対してソリューションは完璧に機能しますが、本番ではガバナ制限に達します。Developer Sandbox は設定のみをコピーし、データは含まれません。Full Copy Sandbox で現実的なボリュームに対してテストを行うと、拡張性の問題が顧客よりも先に表面化します。

クエリの選択性は、ソリューションが数百万件のレコードに拡張されるか、数十万件にタイムアウトするかを示す唯一の最大の指標です。選択的クエリではインデックスを使用してレコードを効率的に検索しますが、非選択的クエリではテーブル全体がスキャンされ、データベースリソースが過度に消費され、最終的にはタイムアウトになります。プラットフォームでは、定義された項目セットで標準インデックスが管理され、オブジェクトが最初の 100 万件のレコードを超えると厳格化する選択性のしきい値が適用されます。選択性を考慮した設計とは、大規模オブジェクトのテーブルスキャンを表示するクエリは本番インシデントで発生するのを待っているため、インデックス付けされた項目を主条件として絞り込み、大規模オブジェクトに対してリリースする前にクエリプランツールを使用して検証することを意味します。選択性とは、購入する必要のない容量です。効率的なクエリはミリ秒で返され、他のすべてのテナントと独自の組織の他のすべてのトランザクションでデータベースリソースを使用できる状態になります。

一括処理は、大規模に機能する Apex と制限に達する Apex を区別する基本的なスケーラビリティパターンです。アンチパターン (ループ内に配置されたクエリまたは DML ステートメント) は、小さなレコードセットでは正しく機能しますが、一括操作が実行されるときのガバナ制限に違反します。対応策は、ループ外の単一ステートメントで必要なすべてのデータを照会し、反復中にすばやく検索できるように結果を ID でキー指定されたマップに整理し、一括処理 DML でコレクション全体を処理することです。制限に近づくことなく標準 200 レコードトリガーバッチを処理するようにすべての自動化を設計し、本番での読み込みに関係なく同じコードを拡張できます。

非同期処理は、ユーザートランザクションの同期制限内で完了できない作業や完了すべきでない作業に対して存在します。この作業を非同期コンテキストに移行すると、使用できるガバナ制限がおよそ 2 倍になり、長時間実行される操作によってユーザーがブロックされることがなくなります。この余裕は本物ですが、無料ではありません。制限に近づいていると感じるたびに非同期に達するのは間違いです。非同期はアーキテクチャ上のトレードオフを意図的に考えており、最終的な一貫性をもたらすため、作業の結果を要求元のトランザクションに表示されず、即座の確認に依存しないユーザーエクスペリエンスの決定を迫られます。エラーはトリガーしたユーザーではなくジョブログに表示されるため、明示的なエラー処理と監視が必要です。また、1 つの業務が複数のトランザクションにまたがる場合、システムの精神モデルが複雑になる可能性があります。コストあたりの価値の決定は、作業で本当に必要な業務量と複雑さを比較検討し、作業が快適に収まるときに作業を同期させることです。

非同期が適切なコールの場合、メカニズムの選択は制限のサイズではなく作業の形状に従います。Batch Apexはボリューム用です。数百万件のレコードをチャンクに分割して処理し、それぞれに独自のガバナ制限を設定します。そのため、データ移行、データアーカイブ、一括強化が属しています。キュー可能は順序どおりです。同期制限を超えているがバッチスケールを必要としない複数ステップのワークフローを処理し、順序どおりに実行する必要があるステップに対して、1つのジョブを別のジョブからチェーンできます。プラットフォームイベントは分離を目的とします。つまり、プロデューサーはコンシューマーを認識せず、待機することもせずにイベントを生成します。このパターンは、システム間通知や、同じトランザクションに属しない作業を分離するために使用します。ただし、少なくとも 1 回の配信には十分な登録者が必要であることを考慮します。future メソッドは、プリミティブ入力 (通常は同期トリガーからのコールアウト) を使用する単純な非同期作業の狭いケースに対応します。複雑なオブジェクトをチェーニングまたは受け入れることができないからこそ、万能な非同期作業のツールではないのです。非同期メカニズムを作業の形状に合わせます。それ以外の場合、ゲインを上回る一貫性と監視コストのためにガバナ制限の問題をトレードします。

キャッシュにより、反復作業が保持する業務量に変換されます。プラットフォームキャッシュでは、トランザクションの境界を越えてシリアル化可能なデータが保存されるため、キャッシュヒットによって、値を生成したクエリや再計算の再実行が回避され、SOQL と CPU の消費量が直接削減されます。キャッシュの作成または破棄の決定は、キャッシュに含める内容と期間によって決まります。カスタムメタデータ、設定、選択リスト値など、変更よりも頻繁に参照されるデータをキャッシュし、1 つのデフォルトではなくデータの不安定さに合わせて存続可能時間を設定します。毎月変更される参照データは安全に何時間もキャッシュできますが、1 日の間に移行する設定では、キャッシュで重要な古くなった値が提供されないように短い期間が必要です。キャッシュが攻撃的すぎると、正確性のリスクに対してパフォーマンスが低下します。また、ヒット率が低いキャッシュでは、容量が返されずにストレージが消費されます。そのため、ヒット率は想定する設定ではなく、監視する指標です。パーティションの選択はセキュリティ上の決定事項です。ユーザー間で共有されるデータには組織パーティションを使用し、分離しておく必要のあるユーザー範囲のデータにはセッションパーティションを使用し、すべてのユーザーが参照できる組織パーティションに個人識別情報を配置しないでください。Lightning Data Serviceでは、同じ考え方がクライアントにも拡張されています。つまり、キャッシュされたレコードをページのすべてのコンポーネントで共有し、冗長なサーバの往復を排除します。すべてのキャッシュヒットはコンピューティングと API の容量であり、返される値が正しい限り、コストをかける必要はありません。

データスキューは、不均衡なレコード配信によって生じるパフォーマンスのホットスポットです。1 つの親レコードに 10,000 件を超える子が蓄積されると、クエリのパフォーマンスが低下し、同時処理中に行ロックの競合が発生します。しきい値は設計信号であり、ハードリミットではありません。複数の親に負荷を分散し、親が境界に近づいてきたときにアラートを表示するスケジュール済みジョブで大規模オブジェクトを監視し、同時バッチが同じ行で競合しないように一括負荷を親 ID で並び替えます。インテグレーションユーザーが数十万件のレコードを所有する所有権のスキューでは、同じロックの競合が発生し、同じ負荷分散が必要になります。

Salesforce には、ソリューションの進化に合わせてパフォーマンス特性を健全に保つためのツールが用意されています。Scale Center では、実行時間の長い操作、行ロックの競合、制限に近づいているトランザクションをトランザクションレベルで表示し、関連する特定のトリガーとオブジェクトに名前を付けます。ApexGuru は AI 分析を本番ランタイムテレメトリに適用して、規模に達する前にアンチパターンを明らかにします。Salesforce Code Analyzer は CI/CD パイプラインで静的分析を実行するため、クエリがループ内に出現するか、その他のパフォーマンスの不具合が検出されるとビルドが失敗します。Event Monitoring は経時的な消費トレンドを明らかにし、Signature Success Plan 機能の Proactive Monitoring は組織のパフォーマンスと拡張性のリスクを継続的に評価します。

コード整理は、メンテナンス性で表されるコスト決定です。通常、メンテナンスは、成熟したソリューションの開発業務量の大部分を消費します。そのため、選択した構造によって、手直しではなく、将来の業務量を変更するかどうかが決まります。3 つのパターンでその値の大部分が伝達されます。トリガーハンドラーパターンでは、トリガーロジックがハンドラークラスで一元化され、トリガーファイル自体が最小限の委任ポイントに削減されます。これにより、トリガーコンテキストに関係なくロジックをテストでき、再帰制御が 1 つのホームに提供されます。サービスレイヤーパターンは、トリガー、REST エンドポイント、フロー呼び出し可能、または一括処理ジョブからコール可能な操作を公開するクラスでビジネスロジックをカプセル化するため、ビジネスルールがすべてのエントリポイントで複製されて同期からずれることなく、1 つの実装内で機能します。セレクターパターンでは、各オブジェクトの SOQL が専用クラスに一元化されます。これにより、クエリチューニングが一点変更され、すべてのクエリに明示的な名前付きインテントが付与されます。

混合 DML エラーは、明示的に設計する価値のある別個の組織上の危険です。これは、ユーザーや権限セットなどの設定オブジェクトと、取引先やカスタムオブジェクトなどの非設定オブジェクトの両方で DML を 1 つのトランザクションで実行した場合に発生します。これは、ユーザーのアクセス権に影響する設定変更を個別のトランザクションでコミットする必要があるためです。この障害は、インテグレーションジョブ、テスト設定、ユーザープロビジョニングの自動化で大規模に現れます。アーキテクチャ上の対応策は、非同期処理またはプラットフォームイベントを使用してトランザクションの境界を越えて設定 DML と非設定 DML を分離すること、1 つのビジネスステップで 2 つの操作を組み合わせることを回避するデータモデルを設計すること、テストで設定 DML を分離することです。

パッケージの選択は、長期的な開発コストと、会社全体で達成できる再利用を決定します。第二世代管理パッケージは、名前空間保護を備えたソース駆動のモジュール型開発を提供し、AgentExchange を介して配布される独立系ソフトウェアベンダー (ISV) 製品に適しています。ロック解除済みパッケージを使用すると、名前空間のオーバーヘッドなしで内部チームに同じモジュール性と連動関係管理が提供されます。これは、マーケットプレイスの掲載はなく、独立したリリースを必要とするエンタープライズアプリケーションに適しています。第一世代管理パッケージは既存の製品で引き続き使用されますが、新しいモジュール開発のメンテナンスを可能にするソース駆動型ワークフローはありません。

モジュール性は、作成するコンポーネントにも及びます。明確なプロパティ・インタフェースを使用して、1つの責任に基づいてLightning Webコンポーネントを設計し、継承よりも構成を優先し、小さなフォーカスされたコンポーネントから複雑なUIを構成することができます。また、親とのコミュニケーションには、親に直接アクセスするのではなく、カスタム・イベントを使用します。再利用可能な Apex を呼び出し可能なアクションとして公開し、管理者が開発者が作成した機能から Flow Builder で自動化を構成できるようにします。これにより、重複が減り、宣言型とプログラム型の世界が橋渡しされます。適切に設計されたモジュール性により、必要なすべての場所で再実装して個別に管理するのではなく、機能を一度構築すれば再利用できます。

未管理のデータの増加は、パフォーマンスを徐々に低下させる最も一般的な原因であり、ストレージコストと Sandbox の更新時間を並行して増加させます。データ効率は 2 つの決定によって決まります。1 つ目はデータモデルの設計です。主従関係では、カスケード削除、積み上げ集計、およびデータ共有が提供されますが、より緊密な結合が必要になります。ルックアップにより、カスタム積み上げ集計ロジックのコストを柔軟に調整できます。また、絞り込む項目の慎重なインデックス戦略により、オブジェクトの増大に合わせてクエリが選択されます。2 つ目はデータライフサイクルです。オブジェクトがアーカイブ戦略なしで数百万件に膨れ上がると、クエリタイムアウト、非選択クエリ、リストビューがタイムアウトするため、オブジェクトが無期限にレコードを蓄積するのを防ぐのではなく、作成からアーカイブまでのライフサイクル全体を定義します。

アーカイブメカニズムは、コンプライアンスを解決した後にのみ選択します。メカニズムを選択する前に、データレジデンシー、消去権、または保持の要件によってオプションが制約されるかどうかを確認します。Big Object は挿入後に変更できません。これにより、アーカイブされた個人データのレコードのみの削除が、監査履歴に影響する可能性がある削除と再作成の操作になります。Big Object は、標準の制限とは別に大量の履歴データセットをストレージに保存するため、日常業務で不要になった完了したトランザクションや監査ログに適しています。外部ストレージは、組織の量を削減しながら、Salesforce Connect を介してデータを照会可能にします。柔軟なクエリパターンやエンタープライズデータウェアハウスとの統合に適しています。ストレージの消費量をオブジェクトレベルで監視して、問題になる前に増加を可視化し、従来の添付ファイルではなく Salesforce Files を使用し、ストレージを浪費する包括的な最大値を適用するのではなく、コンプライアンスに必要な項目ごとに項目監査履歴の保持を設定します。

コストの最適化では、ビジネス価値とソリューションのコストのバランスを取ります。コストの最適化は、そもそも正確なコストを確立することにかかっています。そのためには、すべてのコストコンポーネントを考慮します。ライセンスコストなどの 1 つのコンポーネントを参照すると、ソリューションの実際のコストが正しく理解されないためです。わずかなライセンス料では、実装コスト、運用コスト、インテグレーションコスト、変更コストが隠蔽され、コストの低下を招く可能性があります。目に見える数値のみに関する決定では、画像の一部のみが使用されます。総所有コストは、全体像を把握するモデルです。これには、Salesforce ソリューションの存続期間全体に関連するすべてのコストが含まれ、ソリューションに明確に関連付けられている直接コストと、現実的だが見過ごされやすい間接コストに分けられます。両方のコストをモデル化すると、初期費用だけでなく長期的な価値も考慮した、十分な情報に基づいたアーキテクチャの決定になります。

システムの実装、運用、メンテナンスには、次のような直接的なコストが発生します。

ライセンスおよび消費コストは、エディション、ユーザー種別、機能セットによって異なる継続的なサブスクリプション料金と、消費ベースのクレジットです。エディションの選択は、ユーザーごとの違いが大きいため、基本的なコストの決定に使用されます。消費コストを早期にモデル化することは困難であるため、設計に関する意思決定が行われるときにこれらの推定値を再確認します。
実装コストには、ソリューションの設計、開発、テスト、データ移行、トレーニングが含まれます。ほとんどの場合は 1 回限りですが、複雑さに応じて継続的なメンテナンス義務が発生します。企業は、開発に重点を置き、テストやトレーニングの価値を低く評価するため、実装作業を計画的に過小評価しています。
運用コストには、管理、ユーザーサポート、監視、インシデント対応、運用ツールが含まれます。ソリューションは複雑になるにつれて大きくなり、多くの場合、外部請求書ではなく内部作業として現れるため、計画では見えなくなります。
メンテナンスコストには、機能強化、技術的負債の修正、リリース適応、および設定変更が含まれます。通常、メンテナンスは、成熟したソリューションの開発能力の 60 ～ 80% を消費します。これは、進行中のコストカテゴリの中で最大のコストです。
インテグレーションコストには、インテグレーションプラットフォームライセンス、API消費、同期開発、継続的なメンテナンスが含まれます。システム数が増加するにつれて 2 地点間インテグレーションのメンテナンス化合物が増えるため、エコシステムが複雑になるにつれて拡張します。
変更コストには、ビジネスプロセスの再設計、変更管理、採用、関係者の調整が含まれます。これらは、ビジネスユニットや地域全体にリーチすることで増加し、ビジネスチームの取り組みとして現れるため、省略されることがよくあります。

間接コストは、初期計画ではすぐには現れませんが、ソリューションのライフサイクル全体で大幅に蓄積され、成熟した実装では直接コストを上回ることがよくあります。間接支出を無視して直接コストのみを最適化する会社は、総投資の大部分を見逃します。いくつかのカテゴリは明示的に注意する必要があります。

組織コストは、Salesforce の成功を促進する投資ですが、Salesforce の請求書には表示されません。これには、管理者、開発者、アーキテクトの内部チーム給与、バージョン管理や CI/CD ツールなどの開発インフラストラクチャ、トレーニングおよび認定のメンテナンスとスキル開発、イノベーションではなくメンテナンスに割り当てられる開発業務量の機会コストが含まれます。最後の項目は支出済みとしてまったく表示されないため、検出が困難です。出荷されなかったイノベーションとして現れます。

技術的負債利息は、アーキテクチャのショートカットの複利コストです。稼働開始の期限を順守するためにショートカットを実行すると、メンテナンスの負担が発生し、後で解決するために元の作業の数倍が必要になる可能性があります。また、負債の修復に費やすすべてのスプリントは、新しいビジネス価値を提供しない短期作業です。アーキテクチャの改善を十分に先延ばしにしたチームは、最終的に業務量のほとんどを新しい業務量ではなくメンテナンスに費やすことになります。

ガバナンスオーバーヘッドは、承認プロセス、調整ミーティング、手動レビューに時間を消費します。ガバナンスはリスクの軽減と一貫性によって真の価値をもたらしますが、過剰なガバナンスは意思決定の遅れや重複作業によって隠れたコストを生み出します。そのため、変更のたびに一元的な承認のボトルネックを要求するのではなく、安全な自律性を促進するシステムを設計することを目的としています。

未使用の機能は、機能が実装されても完全に採用されることはありません。部分的にリリースされたソリューションでは、比例した価値を提供せずに継続的なメンテナンスを消費します。また、ライセンス使用率と機能採用の監視により、さらに投資するか、容量をリダイレクトするために廃止する能力が明らかになります。

全体像のみが適切な投資判断をサポートするため、包括的なコスト表示には、直接品目と間接品目の両方を割り当てる必要があります。

アプローチに取り組む前に、ベースラインと最適化されたアーキテクチャの代替案の TCO モデルを作成します。文書化した前提条件を使用して 3 ～ 5 年間のコストを予測するモデルを使用すると、オプションを体系的に比較できます。最も重要な仮定に基づいて感度分析を実行し、コスト推定の差異と境界を決定します。状況の変化に応じて決定を再確認するように計画します。後の再評価では、新しい議論ではなく証拠に基づく比較になるため、前提条件を書き留める規律は価値の一部です。

初期コストのみではなく、包括的な TCO の比較を使用して、カスタム開発に対して市販のソリューションを評価します。構築と購入の意思決定は、継続的なサブスクリプション料金または継続的なメンテナンス義務のいずれかによって長期投資を形成し、2 つのパスの投資プロファイルは根本的に異なります。

AgentExchange (旧 AppExchange) は、Salesforce ISV コミュニティが提供する主要な既成ソリューションのソースです。投資プロファイルでは、迅速性とメンテナンスの共有が優先されます。導入は、同等のカスタムビルドで数か月ではなく数週間で測定されます。ベンダーは、プラットフォームリリースの互換性などの機能を顧客の手間をかけずに維持します。既存の顧客ベースによって機能が実証されているため、実装リスクが軽減されます。専門分野の機能では、ベンダー分野の専門知識と、1 つの企業が単独で調達する資金を上回る研究投資からメリットが得られます。サポートの対応可能状況は ISV によって異なりますが、通常は問題のエスカレーションパスが定義され、モデルごとに継続的なサブスクリプションコストがかかります。

カスタム開発では、適合と制御が優先されます。汎用ソリューションパターンを損なうことなく、固有の組織要件に正確に適合し、機能とロードマップの優先度を完全に制御できます。また、基本プラットフォームライセンスを超える継続的なサブスクリプションはなく、同じ既成のソリューションを使用する競合他社が使用できない機能によって競争優位性を生み出すことができます。トレードオフは、メンテナンスと各 Salesforce リリースとの互換性を維持する責任を会社が負うことです。

長期的な TCO の比較によって、これらのプロファイルが決定事項になります。既成のソリューションでは、複利の年間サブスクリプション料金が適用されますが、ベンダーが提供するメンテナンス、機能強化、互換性の更新が含まれます。カスタムソリューションには 1 回限りの開発投資が必要ですが、継続的なメンテナンスコストとリリース互換性に関する全責任が発生します。両方のプロジェクトの合計が 3 ～ 5 年の場合、比較に初期費用ではなく投資全体が反映されるため、通常は初日に割安に見えたオプションが優先されます。

ローコスト以外にも、4 つの要素によって構築と購入の意思決定が左右されます。

戦略的な差別化によって、機能が構築する価値のある競争優位性であるか、購入する価値がある商品であるかが決まります。
実質的なカスタム機能には数か月かかるため、商談の獲得や競争圧力に対応するためにすぐに機能が必要な場合、Time to Value (価値実現までの時間) は購入に有利です。
組織の能力は、ソリューションを長期にわたって維持および進化させる能力を持つ有能な内部チームが存在する場所でのみ構築し、その能力がない場合に購入することを重視します。
独自の形式や広範なカスタマイズによってディープロックインを作成するソリューションは、要件が変更された場合にリスクとなるため、イグジットコストでは柔軟性を維持するオプションが優先されます。

その場しのぎの判断ではなく、一貫した評価に基づいて決定を体系化します。

ライセンスと消費は、コンピューティングやストレージと同様にコストあたりの価値の方程式への入力であり、最も一般的な廃棄物の発生源の1つです。最適化とは、無味乾燥な削減ではありません。これは、すべてのユーザーを作業に適したライセンスに一致させ、すべての従量制サービスを効率的に呼び出すことです。

ライセンスの最適化では、すべてのユーザーを正しいライセンス種別に一致させます。その中核となるのは、社内の各ユーザーを、業務に必要なライセンスと照合することです。制限された機能 (参照のみのアクセスや単純なワークフローの承認) のみを必要とするユーザーにフルプラットフォームライセンスを割り当てるなどのオーバーライセンスは、企業が犯す最も一般的でコストのかかるミスの 1 つであり、誰かが確認するまで意識されません。ユーザーロール、ログイン活動、機能の使用状況を定期的に監査することで、ユーザーベース全体で割り当てを権利化することで、大幅な節約が可能になります。更新時だけでなく、頻繁に実行します。ロールが変わったり、社内の役職が変わったりすると、ミスマッチは静かに増えていきます。

Agentforce、Data 360、その他のAI搭載機能を採用し、シート単位ではなく使用量単位で価格設定しているため、消費クレジットの最適化はますます重要になっています。チームがプロセスを非効率的に設計したり、使用パターンを監視しなかったりすると、クレジットプールが驚くほど早く枯渇する可能性があります。固定ライセンス数とは異なり、プロビジョニングの決定をせずに消費が急増する可能性があります。クレジットバーンレートを明確に把握し、レビューをトリガーする消費しきい値を設定し、自動化とエージェントが効率的に測定サービスを呼び出すように設計します。トランザクションをガバナ制限内に収める同じ効率化作業により、従量制サービスがクレジット予算内に収まるようにします。これは、消費の観点で表された同じコストあたりの価値です。

環境および Sandbox 戦略は、コストに直接影響するリソース決定であり、Salesforce デリバリモデルの成熟には適切に構造化された環境戦略が必要です。開発環境、テスト環境、ステージング環境、本番環境ではそれぞれ目的が異なります。また、Sandbox 種別を適切に組み合わせることで、本番に移行する前に変更を安全に構築および検証できます。課題は、慎重なガバナンスがなければ、特に大規模プログラムや実行時間が長いプログラムでは有効な Sandbox の数が急増し、コストの増加を招くことです。対応策は、Sandbox プロビジョニングを他のリソースと同じ意図で処理することです。使用頻度がなくなった Sandbox をアイドルのままにするのではなく、更新またはプロビジョニング解除し、利便性よりも実際のデータ忠実度のニーズに基づいて Sandbox 種別を選択できるようにし、資産が作業に合わせてサイズを維持するように、所有権、更新ケイデンス、廃止に関する明確なポリシーを設定します。

マルチ組織アーキテクチャでは、コストが増加します。単一組織アーキテクチャでは、管理、設定、維持する作業量が単純に少なくなるため、ライセンスの統合、プラットフォームインフラストラクチャの共有、管理オーバーヘッドの削減というメリットが得られます。すべてのビジネスユニットが 1 つの組織内で運用されている場合、インテグレーションは組織間ではなく内部であり、データ共有はネイティブであり、Sandbox、サポート、ガバナンスツールの合計フットプリントは比例して小さくなります。複数組織アーキテクチャは、地域、規制コンプライアンス、または組織の分離に必要になる場合がありますが、一部のコストカテゴリでは乗数効果が生じます。各追加組織は、独自のライセンス要件、独自の Sandbox 資産、独自のインテグレーションオーバーヘッド、独自の管理作業を伴い、組織間リリース、ID 統合、およびデータ同期を管理するためのより高度なツールを必要とします。元に戻すのが難しく、コストのかかるアーキテクチャ上の意思決定を行う前に、追加組織ごとの真の TCO を把握します。

API とインテグレーションのコストは、Salesforce エコシステムで最も過小評価されているコスト要因の 1 つです。Salesforce を外部システムに接続すると、一見簡単そうに見えますが、複雑なインテグレーション要件により、ミドルウェアライセンス、開発作業、継続的なメンテナンス、すべてのデータ交換から生じる API 消費にかかるコストがすぐに蓄積されます。多くの統合システム、大量のデータ、ほぼリアルタイムの同期要件がある企業は、特にリスクにさらされます。ここで重要なのは、アーキテクチャのアプローチです。小さな API コールを頻繁に行う雑多できめ細かいインテグレーションは、ラウンドトリップを最小限に抑えて適切に設計された一括またはイベント駆動型パターンよりも高価で脆弱であり、接続アプリケーションが増殖するにつれ、違いの複合化が生じます。インテグレーション設計標準を管理し、可能な場合はインテグレーションプラットフォームを統合し、既存のインテグレーションが引き続き元の設計どおりに効率的に動作するかどうかを定期的に確認します。

持続可能なアーキテクチャには、初期設計の最適化以上のものが必要です。継続的な監視と体系的な説明責任が求められます。コスト監視とガバナンスは、最適化を 1 回限りの課題から継続的な運用方法に変えるフレームワークです。一貫した追跡と明確な所有権により、予期しないコスト超過のリスクが軽減され、支出されるすべての費用がビジネス価値と一致します。

技術チームとビジネス関係者の両方がアクセスできるダッシュボードを使用して支出パターンを可視化し、投資に関する会話を請求書ではなくデータに基づいて行います。コストの可視化は、投資の優先度と最適化の機会に関するデータ主導の会話を開始し、3 つの異なるビューが使用できる場合に最適です。ライセンス利用状況ダッシュボードでは、無効なユーザー、ライセンスが過剰なユーザー、ライセンス種別の不一致が明らかになります。これらは、頭数が固定された中で隠れている最適化の機会です。業務量ダッシュボードには、ストレージ、API、処理の消費量と増加トレンドが表示されるため、チームは制限後ではなく停止が発生する前に最適化できます。投資ダッシュボードには、ビジネスユニット別の支出、所有チーム別の環境コスト、稼働率に対するアドオンコスト、現在の成長に基づく推定支出が表示され、予算に関する会話が割り当てに関する会話に変わります。

これらのダッシュボードは、Digital Walletやメタデータを照会するカスタムレポートなど、さまざまなツールから取得できます。このツールは、意思決定が行われる場所でデータを表示する規律よりも重要です。ダッシュボードをビジネスの関係者やリーダーと共有して、事後的な予算の議論ではなく、十分な情報に基づいた投資ディスカッションの透明性を確保します。利用パターンを確認する財務チームは、支出を最適化できます。合計請求書のみが表示されているチームは、その請求書のみをカットできます。

制限を超える前に最適化のフラグを設定するプロアクティブなアラートを含め、会社全体で支出意識を実装します。

ライセンス予算は、業務量に近づいているときにアラートで部門ごとに割り当て目標を設定するため、未制御のプロビジョニングは更新時にのみ検出されます。
ストレージ予算は、次の更新サイクルの前にトレンドが制限を超えた場合にアラートで増加率を監視します。これらのアラートは事前に警告するため、期限切れになる前にアーカイブを実装できます。
API予算は、使用率のしきい値(70%や85%など)でアラートを表示して制限に対する消費を追跡するため、制限によって障害が発生した場合の緊急対応ではなく、最適化を積極的に行います。
Sandbox の予算は、割り当て制限と承認プロセスによって環境の急増を制御します。

予算管理により、必要な投資をブロックすることなくコスト意識を高めることができます。アラートしきい値により、反応型のスクランブルではなく、入念な最適化を可能にする早期の警告が提供されます。

コスト割り当てにより、ビジネスユニット全体で説明責任と情報に基づいた意思決定が可能になり、会社は説明責任の程度が異なる 2 つのモデルのいずれかを使用してコスト割り当てを実装します。実際の金融請求を適用せずにビジネスユニット別にコストを表示します。これにより、透明性が向上し、内部請求の競合のないコスト認識ディスカッションと最適化の優先順位付けが促進されます。これは、財務説明責任よりもコラボレーションコスト管理を好む会社に適しています。チャージバックでは、実際のコストをビジネスユニットに割り当て、消費に関する意思決定の直接的な財務説明責任を作成します。コストは部門の予算に直接影響するため、最適化の動作は強化されますが、誰が何に対して支払うかに関する紛争を回避するための正確な割り当て方法が必要です。いずれの場合も、割り当てルールは同じロジックに従います。ユーザー部門別のライセンスコスト、開発チームを所有することによる環境コスト、インテグレーションを使用するビジネスプロセス別のインテグレーションコスト、作業に資金を提供するイニシアチブ別の開発コストです。これらのルールがない場合、すべてのコストは中央の IT 予算に計上され、ビジネス関係者はプラットフォームを無料として扱います。これはまさに、コスト意識のない要求が発生する条件です。

クラウド FinOps プラクティスを Salesforce Platform の経済性に適応させて、定期的なクリーンアップではなく継続的な最適化機能を作成します。5 つの練習は重みを運びます。

財務、アーキテクチャ、ビジネスの関係者間の部門横断的なコラボレーションにより、コストに関する意思決定がビジネス価値と支出を加重するようになります。財務に関する専門知識をアーキテクチャに関するディスカッションに、技術的な理解を予算計画に取り込みます。
継続的な最適化ケイデンスにより、定期的なレビューサイクル (支出の急増を把握する毎月の異常レビュー、ライセンスの割り当てと容量の使用状況を検証する四半期ごとの使用状況監査、戦略的な優先度に基づいて支出を調整する毎年の包括的な TCO 評価) でコストドリフトを回避できます。
データに基づく投資の意思決定では、前提条件や過去の習慣ではなく、使用状況データと TCO モデルが使用されます。これらの決定により、「私たちは常にこの方法で行ってきた」が、現在の支出が最適な価値をもたらすかどうかの分析に置き換えられます。
コスト監視を自動化すると、稼働率の追跡、最適化の機会の特定、レポートの生成などの手作業が軽減されるため、組織の複雑さに合わせて業務が拡張でき、人員を直線的に増やす必要がありません。
コスト認識教育は、コスト設計を理解しているアーキテクトとプラットフォームの経済性を理解している開発者がより効率的な自動化を記述するため、アーキテクチャの決定が総所有コストにどのように影響するかをチームが理解するのに役立ちます。

コスト認識をアーキテクチャレビュープロセスに統合し、投資の影響が、導入後に発見されるのではなく、機能的および技術的な考慮事項と共に表示されるようにします。主要な設計の選択肢を文書化するアーキテクチャ決定レコードにコスト影響評価を含めます。定義済みの投資しきい値を超えるソリューションの TCO 予測が必要です。設計時にライセンスの影響を評価し、アプローチに取り組む前にプレミアムライセンスまたはアドオンが必要かどうかを判断します。API の使用やミドルウェアライセンスに影響するパターンを採用する前に、インテグレーションコストを評価します。機能要件と非機能要件の両方にコストの観点が含まれるアーキテクチャ審査委員会は、より適切な投資判断を生み出します。コストをアーキテクチャ上の意思決定の唯一の要因ではなく 1 つの入力として捉えることで、企業は重要な項目に適切に投資し、不要な項目に無駄を費やすことを回避します。

クラウドコンピューティングの持続可能性は、リソースを効率的に使用することでデジタルインフラストラクチャの環境への影響を最小限に抑えることに重点を置いており、コストあたりの価値と自然に一致します。つまり、リソース消費量を減らすのと同じ効率性によってコストも削減されます。Salesforce とアーキテクトは、Sustainability の結果について責任を共有します。Salesforce は、電力使用量の有効性の最適化、冷却効率、ハードウェアライフサイクル管理、マルチテナントリソースのプーリング、プラットフォームレベルの効率の向上など、データセンターインフラストラクチャを管理します。このマルチテナント環境内のソリューションのリソース消費パターンに影響します。

個々のソリューションとデータセンターの排出量の関係は間接的であり、正確に把握することが重要です。1 つのテナントの最適化では、データセンターの排出量を直接削減することはできません。すべてのテナントで効率が向上したことで、Salesforce のインフラストラクチャの稼働率が向上し、業務量の拡張が延期されます。そのため、SOQL クエリ、CPU 時間、ヒープ消費量、ストレージなどのリソース効率総計値は、持続可能性のプロキシインジケーターとして機能します。計算の無駄を省くことで、パフォーマンスとコストが向上し、プラットフォーム全体の効率向上につながります。この柱の設計原則 (一括処理、選択的なクエリ、キャッシュ、非同期処理、統制のとれたデータライフサイクルなど) により、リソースの消費が少ないソリューションが実現します。サステナビリティは、アーキテクチャに組み込まれた個別のイニシアチブではありません。これは、財務コストだけでなく環境への影響も測定した場合のリソース効率です。

複数のアーキテクチャプラクティスが持続可能性の価値の大部分を占め、それぞれがパフォーマンスやコストも向上するため、同じ柱に属することになります。

無効な自動化では、インフラストラクチャリソースが消費され、ビジネス上の価値がもたらされません。無関係なレコードを処理するトリガー、不必要に実行されるワークフロー、作業が存在しない場合に実行されるスケジュール済みジョブでは、計算、ストレージ、エネルギーのすべてが無駄になります。この救済策は、未使用とみなされるものに関する明示的な条件 (過去 90 日間に実行がない、一貫してゼロレコードを処理する一括処理ジョブ、新しい実装に置き換えられたが無効化されていない自動化) を含む四半期ごとの自動化監査です。ビジネス要件が再浮上した場合にロールバックできるように、各無効化を文書化します。過去 1 年間ほとんど実行されなかった、過去の実装から残された数十のプロセスビルダーを擁する会社は、関連するレコードを保存するたびに、そのすべてを評価するために支払います。

リソースを大量に消費する業務をピーク時間外にスケジュールすると、負荷が時間枠全体に分散されます。マルチテナント環境では、この規則により営業時間中のプラットフォームの応答性が向上し、テナント全体で集計することで、Salesforce はインフラストラクチャをより高い平均稼働率で運用できます。使用量の少ない時間帯にバッチのアーカイブ、強化、クリーンアップをスケジュールし、深夜に 20 個を起動して処理の急増を引き起こすのではなく、ジョブをずらすようにします。また、スケジュール済みポーリングよりもイベント駆動型パターンを推奨して、存在しない作業のチェックにサイクルが費やされないようにします。

同じ値を繰り返し計算すると、CPU サイクルとインフラストラクチャ容量が無駄になります。1 回計算して結果をキャッシュし、トランザクションとユーザー全体で再利用します。プラットフォームキャッシュでは、繰り返し照会される参照データが提供されます。キャッシュされた積み上げ集計値では、ほぼリアルタイムの精度で十分な場合はリアルタイムの集計クエリが回避されます。数式項目は、値を保存してその管理を自動化するのではなく、レコードアクセス時に動的に再計算されます。Lightning Data Serviceでは、クライアント側の冗長なサーバ要求が排除されます。回避された各計算は、プラットフォームに返される業務量です。

データストレージは、インフラストラクチャリソースを消費し、データストレージが大きくなるとクエリパフォーマンスが低下します。有効な操作で不要になったデータをアーカイブまたは削除する保持ポリシーにより、有効なテーブルを小さくしてクエリを高速に維持できます。スケジュール済みジョブで古いレコードを Big Object または外部ストレージにアーカイブし、ストレージを消費し続けるソフト削除ではなく、コンプライアンスに準拠した場合はハード削除し、コンプライアンスの要件を大幅に上回る履歴を保存する最大件数を適用するのではなく、項目ごとに項目監査履歴の保持を設定します。スケジュール済み処理と同様に、個々のアーカイブの決定によってデータセンターのエネルギー使用量が直接削減されるわけではありませんが、すべてのテナントのデータライフサイクル規律を統合することで、プラットフォームの効率が向上し、ストレージインフラストラクチャの拡張が延期されます。

外部インテグレーションでは、Salesforce と接続先のシステムの両方でリソースが消費されます。変更データキャプチャとその他のイベント駆動型パターンでは、変更の確認と変更なしの確認を繰り返すポーリングコールが排除されるため、API の消費量が減り、ガバナ制限の利点が得られ、無駄な計算が排除されます。複合 API パターンでは、複数の操作を 1 つのコールに集約します。Bulk API v2 では、何千もの個々の REST コールよりもはるかに効率的に大量の処理が行われ、指数関数的なバックオフを使用した再試行ロジックにより、困難な外部システムへの対応が回避されます。5 分ごとにポーリングを行い、ほとんどの場合何も実行しないインテグレーションは純粋に無駄ですが、変更イベントによって実行される同じインテグレーションでは実際の変更のみが処理されます。

エージェントアーキテクチャでは、大規模な言語モデルの推測によって計算リソースを消費し、同じ効率の考え方が適用されます。プロンプトの長さを最小限に抑え、無制限に成長する完全な逐語的なトランスクリプトを運ぶのではなく会話履歴を要約し、最も能力の高いモデルにデフォルトするのではなく、タスクに十分な最小のモデルを使用し、参照データと確定的応答をキャッシュします。5 件のみ評価された場合に 50 件のベクトル検索結果を取得すると、付加価値のない推測および取得リソースが費やされるため、実際の使用量に一致するように取得制限を設定します。

この柱の他の部分と同様に、ソリューションの進化、データ量の増加、ユーザー母集団の拡大に伴ってリソースの消費パターンも変化するため、持続可能性には 1 回限りのものではなく継続的な監視が必要です。監視は、アクションをトリガーするときにのみ重要です。各評価指標 (トランザクションあたりの目標を超える SOQL クエリ数、毎月のパーセントを超えるストレージの増加率、目標を下回るキャッシュヒット率) のアクション可能なしきい値を定義し、最初に追求する最適化を文書化します。効率性の向上が集計に最も大きな影響を与える、大量のトランザクションや頻繁に実行される自動化に労力を集中します。プロセスビルダーは 2025 年 12 月 31 日にサポートが終了しました。残りのプロセスビルダーをフローに移行します。単に無効化しないでください。

このチェックリストを使用して、ソリューションがコストあたりの最大値を返すかどうかを評価します。この 2 つは 1 つの決定であるため、この柱のリソース効率とコスト規律が 1 つのレビューにまとめられます。

価値とコストのモデリング

Salesforce の重要な投資をすべて測定可能なビジネス成果に結び付けます。
アプローチに取り組む前に、直接、間接、1 回限り、継続的なカテゴリで総所有コストをモデル化します。
ベースラインの TCO と最適化されたアーキテクチャの代替案の 3 ～ 5 年間の TCO を比較します。
その場しのぎの判断に頼らず、戦略的な差別化、タイムトゥバリュー、イグジットコストを加重する一貫したBuild-vs-Buy評価を適用します。

リソース効率

ピーク負荷と最大データ量のガバナ制限内で快適に動作するトランザクションを設計します。
インデックス付き項目に対してクエリを選択し、クエリプランツールを使用して検証してから、大きなオブジェクトに対してリリースします。
すべてのデータ操作を一括処理し、同期制限が必要な場所では意図的に非同期処理を選択します。
参照データをプラットフォームキャッシュと Lightning データサービスを介してキャッシュし、クエリや再計算が繰り返されないようにします。
負荷を分散して大量のオブジェクトを監視することで、データの歪みを回避します。
トリガー、サービス、セレクターロジックを一元化して、ビジネスロジックをテストしやすく、変更コストを低く抑えます。
作成からアーカイブまでのデータライフサイクル全体を定義し、オブジェクトレベルでストレージ消費量を監視します。

ライセンスと消費

各ユーザーを作業で必要なライセンス種別と照合し、ロール、ログイン活動、機能の使用状況を定期的に監査します。
消費クレジットの燃焼率に対する可視性を確立し、自動化とエージェントを設計して、測定されたサービスを効率的に呼び出します。
明確な所有権、更新ケイデンス、廃止ポリシーを使用して Sandbox プロビジョニングを管理します。
組織を追加する前にマルチ組織のコスト乗数を完全に理解し、雑談パターンよりも一括またはイベント駆動型インテグレーションを推奨します。

監視とガバナンス

技術チームとビジネス関係者の両方がアクセスできるコストおよび業務量ダッシュボードを提供します。
ライセンス、ストレージ、API 消費、Sandbox の予算アラートを設定して、事後対応型ではなくプロアクティブに最適化できるようにします。
コスト割り当てによってビジネスユニット全体の説明責任が作成されるようにするため、ショーバックまたはチャージバックを設定します。
FinOps ケイデンス (毎月の異常レビュー、四半期ごとの使用状況監査、および毎年の包括的な TCO 評価) を採用する。
コスト影響評価をアーキテクチャレビューとアーキテクチャ決定レコードに統合します。

継続的な最適化と持続可能性

最適化を継続的に行い、以前の最適化投資で期待どおりの結果が得られたことを確認します。
定期的な監査により、未使用の自動化と重複する計算を排除します。
経時的なリソース消費を追跡し、指標が超過したときに最適化をトリガーするアクション可能なしきい値を定義します。

適切に構築されたフレームワークに関するフィードバックを共有する。