インテンショナル

更新スケジュールについては、こちらを参照してください。

はじめに

インテントソリューションは、ビジネス価値を即座に経時的に提供します。インテントアーキテクチャは戦略的に計画され、効果的に管理でき、人間にとって読みやすく、理解しやすいものです。

機能と修正には優先順位が付けられ、ビジネス関係者とテクノロジー関係者の両方に透過的な方法で提供されます。エンジニアリングの選択肢により、デリバリチームやメンテナンスチームが簡単に作業できる実装が作成されます。追加機能や複雑さはありません。インテントアーキテクチャは、明確で一貫した実装パターンに従うため、ビジネスに合わせて所有、維持、進化しやすくなります。ビルダーは新機能の設計を解釈して実装でき、メンテナンスチームは実装された内容をドキュメントで理解できます。

戦略、メンテナンス性、可読性の 3 つの主要な領域に焦点を当てることで、より意図的なシステムを作成できます。

戦略

アーキテクチャの戦略とは、システムが綿密に計画され、提供されることを意味します。つまり、配送チームとメンテナンスチームは現在および将来に行う作業を明確に把握し、全員が作業の「理由」について意思統一を図ります。つまり、緊急の要求に効果的かつ効率的に優先順位を付けることができ、関係者は要求の影響とトレードオフを明確に理解できます。

優先順位付け、ロードマップ、ガバナンスに重点を置くことで、アーキテクチャに明確な戦略を組み込むことができます。

優先順位付け

優先順位付けとは、提供する作業の順序と範囲を計画することです。優先度付けには、成果物がビジネスに及ぼす真の影響を把握し、他の作業要求や製品またはプログラムの全体的なロードマップに対してそれらの影響を評価します。

特定の作業項目の影響を評価する 1 つの方法は、実際のコストやビジネス上のメリットを確認することです。自動化のKPIを特定したら、ビジネス インパクト計算ワークシートを使用して実装の全体的なコストまたはメリットを評価できます。これらの計算は、どの自動化をどのような順序で作成するかについて関係者の意見をまとめるのに役立ちます。また、延期または回避する自動化を特定するのにも役立ちます。自動化の場合、効果的な作業の特定についての詳細は、「プロセス設計」を参照してください。

また、配信の優先順位付けフレームワークを確立すると、ユーザーとメンテナンスチームがユーザーの期待を管理し、ロードマップに沿って進めることができます。

優先度付けに使用できる考慮事項を次に示します。

• 成果物のビジネスへの影響 (コスト/利益)
• 成果物に必要な新規作業量
• 成果物を維持するために必要な作業量

以下のパターンとアンチパターンのリストは、Salesforce 作業における適切な (および不適切な) 優先順位付けを示しています。これらを使用して実装計画を検証したり、構築する前に優先度をより適切に特定する必要がある場所を特定したりできます。

優先度付けに役立つ Salesforce のツールについての詳細は、「Tools Relevant to Intentional (インテントに関連するツール)」を参照してください。

ロードマップ

ロードマップとは、優先順位が付けられ、検証済みで、明確に定義された、実行すべき作業のビューです。効果的なロードマップにより、今後の作業のビジネスへの影響とテクノロジーへの影響を明確に把握できます。ビジネス関係者と技術関係者とのエンゲージメントは、ロードマップの重要な部分です。ロードマップを使用すると、作業を開始する前にアプローチと結果に関するフィードバックや賛同を得ることができます。最終的に、ロードマップは、今後の作業の「理由」についてすべての関係者と一致させます。

チームがバックログを使用している場合、ロードマップはバックログの項目の要約やリストではないと理解することが重要です。リレーションはその逆です。項目は、ロードマップの成果物に明確かつ確実に関連付けることができる場合にのみバックログに入ります。関係者のエンゲージメントに基づいて作成された高品質のロードマップにより、デリバリチームとメンテナンスチームは、何に焦点を絞るべきか、どのように要請に優先度を付けるべきかを明確に把握できるため、競合する要請を整理して関係者の期待を管理しやすくなります。

ロードマップが不十分または存在しない場合、次のようになります。

• 新機能のリリース時期が明確でない
• 関係者間で優先度が競合する
• 提供されるソリューションと組織全体のビジョンの乖離
• 進行中の作業を理解しにくい
• チーム全体の作業負荷の不均衡
• 作業項目間のリレーションと連動関係が認識されていない
• 不適切な連動関係による実装の停止

多くの場合、意思決定を行うためには、各自の役割に合った情報が必要です。効果的なロードマップを作成するには、利用者と必要な情報の種類を明確に理解する必要があります。ロードマップは、ビジネス利用者と技術利用者をサポートする 2 つのスタイルに分類されます。各スタイルには、異なる種別の情報をサポートする 2 つのレベルの粒度が含まれます。

ビジネスロードマップは、関係者が組織の変更を計画し、成長機会を活用し、企業目標を常に把握するのに役立ちます。ビジネスロードマップは、IT 支出を全体的なビジネスビジョンに合わせる方法も提供します。

• ビジネス機能ロードマップを作成して、有効化される機能をエグゼクティブ関係者に表示します。このタイプのロードマップには、機能自体と、業務効率の向上や新しい製品ラインの立ち上げなど、ビジネス目標に合わせた機能の概要が含まれます。
• リソース計画、予算編成、変更管理でビジネス関係者をサポートする必要がある場合、ビジネス機能ロードマップを作成して特定の機能にドリルダウンし、そのサポート機能を示します。

テクノロジーロードマップは、予算とリソース割り当ての計画で技術関係者を支援します。また、実装チームは、プロジェクトの全体像のどこにプロジェクトが適合するかを理解し、チーム間の連動関係を特定できます。

• 実装する特定のシステムとシステムレベルの連動関係を示すテクノロジーシステムロードマップを作成します。この種類のロードマップでは、概要レベルのシステム情報と、システムとビジネス機能間の連携が示されます。
• リソース計画とイネーブルメントの要件に役立つ、リリースされるシステムの特定のコンポーネントにドリルダウンするテクノロジーコンポーネントロードマップを作成します。この種類のロードマップには、コンポーネントレベルの情報と実装要件 (宣言型開発やプロコードなど) が示されます。

ロードマップに現実的なスケジュールが含まれていることを確認します。よくある間違いは、システムの実装に要する時間のみを含め、関連活動の完了に要する時間は考慮しないことです。これにより、実装チームメンバーの過剰な割り当てや、予想以上の遅延が発生する可能性があります。ロードマップを作成するときは、次の作業にかかる時間を考慮してください。

• すべての新機能と更新された機能のドキュメント
• 新機能をサポートするために必要な既存の機能のメンテナンス
• インテグレーションをサポートするために必要な関連システムの更新
• 稼働開始直後にプロジェクトチームからサポートが向上
• テスト、トレーニング、変更管理

適切に連携したビジネスロードマップとテクノロジーロードマップでは、機能のリリース時期とその背後にあるテクノロジーに関する総合的なビューが伝達されます。次のパターンとアンチパターンのリストは、Salesforce 組織にとって適切な (および不適切な) ロードマップを示しています。これらを使用して、ロードマップ戦略を検証または改善できます。

ロードマップに役立つ Salesforce ツールについての詳細は、「Tools Relevant to Intentional (インテントに関連するツール)」を参照してください。

ガバナンス

ガバナンスは、関係者との優先順位付け、意思決定、変更管理を処理するために使用される構造です。ガバナンスにより、意思決定とコミュニケーションの方法が明確になります。フィードバックや要請を意思決定プロセスに取り込み、すべての関係者がメンテナンスや開発作業の状況を把握するための一貫した方法を提供します。ガバナンスにより、リリース管理プロセスが明確で一貫性のあるものになり、すべてのチームメンバーが各自の役割と責任を理解できるようになります。

適切なガバナンスがない場合、チームは次のようなさまざまな問題を経験します。

• 重複する機能の要求がアドホックに届いた
• 実装チームは、ビジネス上の価値、トレードオフ、組織全体の目標を適切に考慮せずに、より影響力のある関係者からの「より容易な」取り組みや要求を優先する
• 一貫した承認およびレビュープロセスの欠如
• リリースケイデンスと品質の一貫性がない
• 開発作業における高い不具合率、上書き、競合、重複作業

システムに効果的なガバナンスがないことを示す最も明確な兆候は、リリースが遅く、煩雑であることかもしれません。ガバナンスシステムの規模は有効性の基準ではないことを認識しておくことが重要です。実際、(多くの大企業で採用されているような) ガバナンスのための精巧なシステムによって、リリースの速度と頻度が抑制される可能性があります。

優れたガバナンスとは、悪いカスタマイズが開発の初期段階を通り越しやすくし、良いカスタマイズを予測可能かつ一貫して本番に取り込むことです。

多くの場合、ガバナンスの取り組みは反応的です。技術的な債務超過などの問題がビジネスで問題になり始めたときに開始または二重化されます。多くの場合、企業は、開発者ツールチェーンとソース制御システム内で効果的な設計標準を作成し、その標準を適用する自動化を構築する代わりに、開発作業とリリースを「封鎖」します。

Salesforce ガバナンスシステムのフレームワークを構築するときは、次の要素を含めて、次の主要な質問に答えてください。

• **作業要求。**ユーザーが機能や特長を尋ねる方法は?バグの報告方法は?
• **優先順位付けと作業計画。**誰が重要な作業要求を決定しますか?作業の範囲設定、優先度設定、受け入れまたはサインオフは?
• **環境とリリース計画。**開発、テスト、リリースの環境パイプラインは?誰が何をプロビジョニング、更新、アクセス権を付与しますか?リリースと検証は誰が行いますか?変更のリリース方法とタイミングは?Salesforce リリースサイクル中のリリースまたは環境をどのように処理しますか?(詳細は、「アプリケーションライフサイクル管理」を参照してください)。
• **サービス所有権と本番サポート。**Who supports what? (誰が何をサポートするか)「ホットフィックス」本番の問題を処理するのは誰ですか?これらの項目は、どのようにテストおよびリリースされますか?組織の全体的なセキュリティ基準の責任者は誰ですか?

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不十分な) ガバナンスを示しています。これらを使用して、ガバナンス戦略を検証または改善できます。

ガバナンスに使用できる Salesforce ツールについての詳細は、「Tools Relevant to Intentional (インテントに関連するツール)」を参照してください。

戦略パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、戦略のパターンをさらに確認できます。

メンテナンス性

メンテナンス性とは、予測可能な定期的なシステムへの新機能の追加や技術的な負債のシステム外への移動によって、システムを健全な状態に保つことができることを意味します。メンテナンス可能なシステムにより、チームは予測可能なスピードと品質でビジネスに価値を提供できます。システムの保守性は、可読性、疎結合性、テスト戦略の綿密さなど、いくつかの要素によって決まります。

最も重要なことは、システムの保守性は、その設計の単純さに左右されます。このセクションでは、より簡単なソリューション設計を作成し、メンテナンス性を高める方法について説明します。

カスタム機能よりも標準機能を使用することと、技術的な負債を処理することの 2 つの主要な点に焦点を絞ることで、メンテナンスしやすいソリューションを構築できます。

標準機能とカスタム機能

Salesforce には、Sales Cloud、Service Cloud、および多くの Salesforce 業種ソリューションを含むさまざまな事前作成済みソリューションと、独自のカスタムソリューションを作成する柔軟性があります。Salesforce 独自のクラウドソリューションを強化する基本サービスは、Salesforce Customer 360 Platform 上に構築されたすべてのカスタムソリューションでも使用できます。Salesforce の事前作成済みサービスとソリューションをできるだけ多くのソリューションの信頼できる基盤として使用します。

事前作成済みプラットフォームサービスには、2 つの異なる利点があります。まず、アプリケーションはリリースのたびに最新の Salesforce のイノベーションから自然にメリットを得られます。2 つ目は、開発チームが基本的なアーキテクチャの面倒な作業ではなく、Salesforce ソリューションによって提供されるビジネス機能の拡張と深化に集中できることです。

標準機能を使用するタイミングとカスタム機能を作成するタイミングを適切に選択することは、アーキテクチャの観点から困難ではありません。キーは次のとおりです。

• **プラットフォームのカスタマイズとは、コピーではなく、変更と拡張を意味します。**アーキテクチャを設計または評価するときには、次の点について質問する必要があります。これはすでに Salesforce プラットフォームのどこかに存在しますか?回答が「Yes, but...[ビジネスの関係者が求める変更をここに挿入してください...]」の場合、プラットフォームで事前作成済み機能を使用します。実行するアーキテクチャ作業では、ビジネスの期待を満たすために事前作成済み Salesforce 機能を設定する最も便利な方法を特定します。
• カスタマイズなし。時間の経過と共に、すべての変更は結果をもたらします。カスタムソリューションを実装する必要がある場合は、可能な限りローコードテクノロジーを使用し、実装で構成可能なユニットを作成することで、システムに蓄積される避けられない技術的負債を軽減できます。
• build-buy スペクトルを考慮します。Salesforce AppExchangeは、Salesforce を拡張するアプリケーションとソリューションのマーケットプレイスです。AppExchange アプリケーションでは、カスタムソリューションの構築と管理に伴うオーバーヘッドなしで機能を提供できます。AppExchange ソリューションを評価するときは、次の点を考慮してください。
  • ソリューションの特徴とギャップを特定します。理想的なのは、すべてのビジネス要件を満たすアプリケーションを見つけることです。実際には、完璧な適合が見つからない場合があります。ソリューションを評価するときに、潜在的なソリューションの機能をビジネス要件の優先リストに対応付けます。これにより、最も重要な要件に最も適したソリューションを見つけることができます。
  • Sandbox と無料トライアルを使用します。無料トライアル期間を使用して Sandbox 環境でアプリケーションを評価し、最適なアプリケーションを特定します。アプリケーションで既存の設定と競合する設定変更が必要かどうかを判断します。
  • 短期コストと長期コストを考慮します。サブスクリプションベースのアプリケーションの定期的なコストに対して、長期的なアプリケーションメンテナンスの節約を評価します。ビジネス関係者が決して使用しない多くの機能に対して定期的なコストを支払う必要があるシナリオを回避します。
• **Salesforce の事前作成済みデータモデルを使用します。**Salesforce では、営業、サービス、さまざまな業種向けに事前作成済みデータモデルを提供しています。Salesforce が提供するデータモデルを使用することで、システムの機能が 1 回のみ定義され (冗長性とサイロ化を排除)、システム全体にわたる一元化された情報源が確立され、分析によるアプリケーションデータの理解が容易になり、Salesforce の事前作成済み人工知能サービスが使いやすくなり、メンテナンスコストが削減され (サポートする必要があるカスタマイズが減るため)、技術的負債が軽減されます。

単純なことです次のパターンとアンチパターンからわかるように、アンチパターンは、カスタムソリューションで標準機能を複製するか、より複雑なテクノロジーを使用してカスタマイズを行うかに集約されます。

実際には、カスタム機能のアンチパターンがビジネス関係者から最善または唯一の実現可能な方法とみなされる場合があります。このような場合は、このパスを選択する際のトレードオフを関係者に説明し、決定、その根拠、実装を徹底的に文書化することが重要です。これは、コアバリューを早期に提供し、経時的に対応することで、関係者が最善の方法を理解するのに役立つ領域でもあります。

メンテナンス性の向上に役立つ Salesforce ツールについての詳細は、「Tools Relevant to Intentional (インテントに関連するツール)」を参照してください。

技術的負債

技術的負債は、どのシステムにも当然含まれます。昨日のサウンドデザインは、テクノロジーやビジネスニーズが変化するとアンチパターンになる可能性があります。Salesforce Platform 機能のギャップを埋めるために構築されたものが、Salesforce の新しいリリースや製品の発売で突然冗長になることがあります。すでに実装したテクノロジーよりも、よりパフォーマンスの高いテクノロジーや柔軟なテクノロジーの方が優先される可能性があります。技術的負債はさまざまな方法で作成できます。

Salesforce Customer 360 Platform を使用してアプリケーションを構築する主なメリットは、下位互換性が組み込まれていることです。つまり、新しいプラットフォームの革新により、今後ソリューションで使用するパターンが変わる可能性がありますが、以前の Salesforce テクノロジーに基づいて構築したソリューションの日常業務は引き続き機能します。時間が経つにつれて、古いテクノロジーに基づくソリューションでは、アプリケーションに新機能を追加するリスクやボトルネックが発生し始め、ソリューション全体の健全性が低下します。

Salesforce ソリューションで健全でわかりやすい設計を維持するためには、技術的負債に対処するための定期的な作業を計画して実行することが不可欠です。技術的負債の計画、監査、修正を怠ることは、適切に設計されていないシステムを作成する確実な方法です。

技術的な負債を最小限に抑える 1 つの方法は、ショートカットを避け、カスタム機能よりも標準機能を選択することで、できるだけ導入しないようにすることです。ハードコード値などのショートカットは、時間を節約したいと思うかもしれませんが、長期的には返済する必要のある負債を生み出します。

アーキテクチャの観点から技術的負債に対処する鍵は次のとおりです。

• アクションとアクションのないビジネスに対する実際のコストまたは利益の特定
• 適切なロードマッピング
• 構成可能なソリューションの構築

難しいのは、関係者がアクションを実行するタイミングを合わせることです。一部の関係者は、継続的なメンテナンスを「昨日の過ち」に対処したり、予算でサポートする必要がある機能を取り除いたりしていると感じるかもしれません。

アクションとアクションなしの実際のビジネスへの影響を、明確に定義された成果物とタイムラインと共に示すことで、関係者は技術的負債に対処する価値と相対的な優先度を理解することができます。技術的な負債をビジネスへの影響に結び付ける作業を一貫して行うことは、関係者が作業内容をより深く理解することに役立つだけではありません。また、ユーザーが真にメリットを得られる方法で技術的負債を特定して対処するのに役立ちます。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不十分な) 技術的債務管理を示しています。

技術的負債に役立つ Salesforce ツールについての詳細は、「Tools Relevant to Intentional (インテントに関連するツール)」を参照してください。

メンテナンス性パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、メンテナンス性を向上するパターンを見つけます。

読みやすさ

可読性の概念の中核は、ユーザーが物事の仕組みを容易に理解できるように一貫性を確保することです。読みやすいシステムを構築することで、配送チームとメンテナンスチームが連携し、システムに不慣れなユーザーでもピースがどのように組み合わされるかをすばやく理解できます。つまり、チームは、制度的または歴史的な Knowledge を持つ個人に依存しなくても、ベンダーや新しいチーム メンバーを効果的にオンボーディングできます。つまり、システムの構成とコードは人間にとって読みやすく、理解しやすいため、チームの熟練した個人は選択肢の質とトレードオフに集中できます。読みやすさにより、ガバナンスと品質保証のプロセスがスピードアップし、チームが冗長なカスタマイズを作成する可能性があるタイミングをより適切に特定できます。また、再利用可能でテスト可能な方法で動作するシステムの可能性を高めることもできます。

効果的な設計基準とドキュメントを使用して、読みやすさを高めることができます。

設計標準

設計標準では、開発の初期段階でも、すべてのカスタマイズの一貫性を保つための指針が提供されます。設計標準はガードレールのように機能し、システムで作業するすべてのデリバリチームとメンテナンスチームが、カスタマイズのアプローチと実装方法を常に一致させます。設計標準を定義すると、デリバリチームとメンテナンスチームの生産性が向上し、コードとアーキテクチャのレビューが容易になり、より適切なドキュメント作成の基礎となります。

設計標準がない場合、チームはサイロで作業する可能性が高くなります。設計標準で提供される一貫性がなければ、企業は次の課題に苦労することになります。

• ベンダーと開発チームがソリューション全体でアドホックなパターンとアプローチを使用しているため、アンチパターンが導入され、再利用性が低下する可能性がある(「懸念の分離」を参照)。
• 本番の問題を解決する時間が増え、新しいチームメンバーのオンボーディングに必要なチームをサポートし、チームがさまざまなパターンやアプローチを理解できるようになりました。
• チーム間のコラボレーションの不十分さ、チーム間の作業の重複、競合を解決する時間の無駄、インテグレーションテスト中に発見されたバグ。
• ストレスと離職率の増加。

設計標準の主な利点は、関係者が設計標準を作成するために行う必要がある会話と決定に起因します。具体的には、このプロセスにより、ビジネスとテクノロジーをリードする企業が、ビジネスにとって最適な設計がどのようになっているかを調整できるようになります。

設計標準に次のものを含めます。

• Salesforce メタデータの命名規則。システムのすべてのカスタマイズの命名方法に関する一連の規則を定義します。優れた命名規則は、オブジェクト、項目、コード、フロー、その他のシステム要素の名前に一貫性を持たせるだけではありません。優れた命名規則は、開発チームが構築の目的と機能に関する情報を伝える名前を使用するのにも役立ちます。その結果、他の関係者は名前を確認するだけで特定のカスタマイズをより適切に理解できます。
• 承認済みデザインパターンとその使用事例。パターン & アンチパターンエクスプローラーのライブラリと、各パターンを使用するタイミング (および使用しないタイミング) に関する重要な情報を設定します。ライブラリには、必要な Apex トリガー パターン、またはシステムで必要な構成可能性に基づくフロー オーケストレーション パターンが含まれている場合があります。
• 開発環境とツールガイダンス。開発チームが作業に使用するツールを明確にリストします。これには、コードを記述するすべてのユーザー向けに承認されたツールチェーンや言語、またはローコード開発向けに承認された (または承認されていない) 宣言型機能が含まれます。標準には、カスタマイズとドキュメント化のためのソース制御システムのリスト、および必要なチェックイン/チェックアウト手順が含まれている場合があります。また、さまざまな種類の開発作業に使用する環境のリストが含まれている場合もあります。

これらの標準の定義に加えて、標準を維持および保存する方法と場所を決定する必要があります。社内のチームが設計標準を見つけられない場合 (または、その存在に気づいていない場合)、有効ではありません。設計標準がドキュメントと同じシステム内に存在していることが理想的です (詳細は次のセクションを参照してください)。

次のパターンとアンチパターンのリストは、Salesforce 組織にとって適切な (および不適切な) 設計標準を示しています。これらを使用して、設計標準を検証または改善できます。

設計標準の定義に役立つ Salesforce ツールについての詳細は、「Tools Relevant to Intentional (インテントに関連するツール)」を参照してください。

ドキュメント

ドキュメントには、システムの内容、方法、理由が記載されています。有意義で一貫性のあるドキュメントがないと、チームはシステムをそのまま理解しようとして多くの時間を浪費します (機能とカスタマイズを誤解する可能性もあります)。

優れたドキュメントは作成に時間がかかります。ほとんどのチームは、大規模なプロジェクトでは文書化が重要であることに同意していますが、設定の更新や自動化の微調整など、迅速な変更を行う場合はスキップしたくなります。システムに行った変更を文書化しないことは、常にアンチパターンです。ドキュメントをスキップすると、先行作業の時間を節約できますが、適切にドキュメント化されていない組織のトラブルシューティングに要する時間は、その時間の節約を相殺する以上のものになります。予定している更新に必要な作業のレベルに関係なく、すべての見積にドキュメントを作成するための十分な時間を常に含めます。

明確なドキュメントがない場合、次のようなさまざまな問題が発生する可能性があります。

• 既存の実装のやり直しに費やす開発サイクル
• 以前の決定を再確認したり、困惑したりする反復的なディスカッション
• 新規チームメンバーまたはベンダーのオンボーディングの長期化
• 制度的または歴史的な Knowledge を持つ個人への過剰依存
• 同じ機能または類似する機能をビジネス全体でサポートする冗長アーキテクチャ
• ソリューションの目的と価値を主要な関係者に伝えることが難しい

Salesforce ソリューションの場合、次のドキュメントを保持します。

• ソリューションの概要。図を使用すると、自分と関係者がさまざまな詳細レベルでソリューションを視覚化できます。Salesforce ダイアグラムフレームワークを使用すると、ソリューションのビジネス能力や技術的な実装の詳細を示すダイアグラムを作成できます。
• 決定レコード。検討されたオプション、トレードオフ、最終決定、および推論の記録を、すべてのチームメンバーが将来の参照のためにアクセスできる一元的な場所に保管します。
• コード。コード形式自体はドキュメントの主要な部分であり、設計標準に合わせることができます (準拠させる必要があります)。また、鍵情報のログを作成し、コードを変更するたびに更新します。すべてのクラス、トリガー、およびコンポーネントについて、次のドキュメントを作成します。
  • コードの作成者
  • コードが記述されたとき
  • コードで実行される内容
  • 主要な連動関係
  • すべての変更
• 宣言型カスタマイズ。組織でメタデータに対して実行できるあらゆる種類のカスタマイズについて、Salesforce ではメタデータの目的とインテントに関する有益な情報をチームに提供するための組み込み属性を提供しています。設計標準の一部として、チームがこれらの組み込み機能をどのように使用するか、宣言型カスタマイズをどのように命名するかを含めます。また、コードに使用する情報と同じ鍵情報のログも保持します。

現在および将来のすべてのチームメンバーが同じ方法でドキュメントを解釈できるように、一連のドキュメント標準を作成します (設計標準が役立ちます)。また、ユーザーがドキュメントを検索して関連するセクションや用語を見つける方法を考慮することも重要です。システムが老朽化し、複雑さが増すにつれて、ドキュメントも増加します。ドキュメントの情報の有用性は、ユーザーが関連項目を検索および見つける頻度、速度、および容易さに直接関連します。

以下のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) ドキュメントを示しています。これらを使用して、ドキュメント戦略を検証または改善できます。

ドキュメント用の Salesforce ツールについての詳細は、「Tools Relevant to Intentional (インテントに関連するツール)」を参照してください。

読みやすさパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、より多くのパターンを見やすくします。

インテンショナルに関連するツール

Resources Relevant to Intentional (インテントに関連するリソース)

ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくためのアンケートにご協力ください。また、今後の展望についてもお聞かせください。