組織のカスタマイズの確認
この単元を完了すると、次のことができるようになります。
- 現状評価のビジネス的価値と技術的価値を明らかにする。
- コードベースの何に注目すべきかを挙げる。
- プロセスおよび宣言型カスタマイズを調べる方法を挙げる。
詩人であり哲学者でもある George Santayana は、著書『Reason in Common Sense (常識の理由)』の中で、「Those who cannot remember the past are condemned to repeat it. (過去を思い出せない者は、それを繰り返す運命にある。)」と述べています。アプリケーションを作成するチームについても同じことが言えます。組織内で何が作成されたのか、なぜ作成されたのか、作成にはどのような標準が使用されたのかを確認する時間を取ることが、将来の成功につながります。
組織の現状を確認して採用への取り組みを開始すると、変更を行う前に問題を明確に特定できます。たとえば、実装の決定がそのときには理に適っていたが、今ではイノベーションの妨げとなっている技術的負債を特定します。また、適切な関係者との関わりを深め、プロセスが先に進みすぎる前にチームを調整する機会を見いだすこともできます。
変更を開始する前に仕事のやり方を確認することには、テクノロジチームとアプリケーション配信チームと同じメリットが多くあります。また、現在のシステムのどの問題や不満が、古いツールやテクノロジによって引き起こされているのか、どの問題が人に起因するのかを特定する機会でもあります。新しいテクノロジまたは機能を採用しようとする前に対処しなければなないのは、これらの人に起因する問題です。
では、組織の現状の調査を開始するには、どうしたらよいのでしょうか?
コードベースを調べるのは、骨の折れる作業に見えるかもしれません。組織にまだ慣れていなかったり、大量のコードが使用されている場合は、特にそうでしょう。しかし、組織のさまざまな部分が相互にどのように関連しているのかを理解することは、組織をより正確でわかりやすい単位で管理する方法を明らかにするうえで、欠くことのできない必要な作業です。
では、コードの何に注目すればよいでしょうか?
| コードの種別 |
注目すべき点 |
質問 |
| トリガ |
1.トリガパターン 2.トリガロジック |
組織ではオブジェクトごとに 1 つのトリガがあるのか? トリガ内に直接記述されたビジネスロジックまたはアプリケーションロジックがあるか? トリガは他のクラスにロジックまたは機能を「引き継ぐ」か (別名トリガハンドラ)? |
| Apex クラス |
1.命名規則 2.コメント 3.API バージョン |
Apex クラスでは、一般的なプレフィックスまたは名前空間を使用してコードの単位がグループ化されるのか? クラスには機能に基づいて類似した名前が付いているか? コードの目的と作成者がコメントに記録されているか? クラスには関数を明確にするコメントがあるか? クラスではどの API バージョンが使用されるのか? |
| Apex テスト |
1.テストパターン/単位 2.コードカバー率 3.テストデータ処理 |
テストは他のコードとどう関係するのか? 各クラスに独自のテストがあるのか? テストは機能グループごとにまとまっているか? コードベースにテストによってカバーされない部分があるか? テストは一般的なデータファクトリまたは静的リソースに依存するのか? テストの中に、'seeAllData=True’ アノテーションが使用されていたり、24 より前の API バージョンで実行されるものがあるか? |
| Lightning コンポーネントとイベント |
1.命名規則 2.コメント 3.Apex コントローラ 4.API バージョン |
コンポーネントでは、一般的なプレフィックスまたは名前空間を使用してグループが作成されるのか? コンポーネントには機能に関連する明確な名前が付いているか? アプリケーションイベントまたはコンポーネントイベントとなるように Lightning イベントが範囲設定されているか? コメントまたは Aura ドキュメントファイルにコンポーネントとイベントの目的と作成者が記録されているか? コンポーネントで Apex コントローラが使用されるか? コンポーネントとイベントではどの API バージョンが使用されるのか? |
| Visualforce |
1.命名規則 2.コメント 3.Apex コントローラ 4.API バージョン |
Visualforce ページでは、一般的なプレフィックスまたは名前空間を使用してグループが作成されるのか? ページには機能に関連する明確な名前が付いているか? ページで Apex コントローラが使用されるのか? ページではどの API バージョンが使用されるのか? ページがメールテンプレートに使用されているか？ |
これらは組織のコード内のパターンを特定するのに役立ちますが、これらの手法は、コードベースのすべての部分を理解するのには役に立たない場合があります。または、コードベースの構成に一貫性がないように見える場合、組織のコードがどのように接続されているのかを明らかにするために別の方法を試すことが必要な場合があります。
そのために役に立つのが、新しいDependency API です。新しい種類のクエリを実行することで、コードとメタデータがどのような構成になっているのかを特定できます。たとえば、特定のページの Lightning コンポーネント、または特定の Visualforce ページの Apex コントローラを調べ、その Apex コントローラまたは Lightning コンポーネントに何らかの形で接続するその他のメタデータをすべてたどることができます。また、これらのクエリを使用して、もう使用されていないメタデータを特定し、削除しても安全かどうか決めることができます。
では、組織で実行した宣言型のカスタマイズについてはどうでしょうか? コードではなく、クリックで作成したものを調べるにはどうしたらよいでしょうか?
1 つの方法は、Salesforce Optimizer を使用することです。このツールでは、Salesforce 実装の一部の機能を改善する方法が推奨されます。Optimizer レポートを確認した後、組織のプロセスと宣言型のカスタマイズをさらに詳しく調べることができます。
では、何に注目すればよいでしょうか?
| カスタマイズの種別 |
注目すべき点 |
質問 |
| プロセスビルダー |
1. オブジェクト関連パターン 2.有効/無効バージョン 3.プロセスロジック |
オブジェクトあたりいくつのプロセスが存在するのか? プロセスに明確な名前が付けられているか? プロセスあたりいくつの無効バージョンが存在するのか? 決定ノードに明確なロジックはあるのか? 一般的に使用されるアクションが呼び出し可能なプロセスにグループ化されているか? |
| ワークフロールール |
1.オブジェクト関連パターン 2.有効/無効ルール 3.アクションロジック |
オブジェクトにはいくつのワークフロールールがあるのか? 一部のオブジェクトの稼働率が他より高いか? ルールには説明を含む明確な名前が付けられているか? オブジェクトにいくつの有効ルールと無効ルールが存在するのか? ルールでどのようなアクションが実行されるのか? ルールでクロスオブジェクトの項目自動更新が実行されるのか? |
| フロー/ビジュアルワークフロー |
1.命名規則 2.オブジェクト関連パターン 3.有効/無効バージョン 4.フローロジック 5.フロー画面 |
フローでは、プレフィックスまたは類似名を使用してグループが作成されるのか? フローには機能に関連する明確な名前が付いているか? フローに明確な最新の説明があるか? フローはどのオブジェクトとやり取りをおこなうのか? 無効フローまたはフローバージョンと有効フローの間にはどのような関係があるのか? フローでは、サブフロー、呼び出し可能アクションまたはクイックアクションに一般的な機能が配置されるのか? フローに画面がある場合、それらは Lightning コンポーネントに基づいているか? 画面は特定のオブジェクトや項目に依存するのか? |
| オブジェクトおよび項目 |
1.命名規則 2.レコードタイプ 3.ページレイアウト 4.権限 5.アクション上書き |
標準オブジェクト動作を複製するカスタムオブジェクトが作成されたか? 複数のビジネスユニットで同じオブジェクトまたは項目が使用されているか? ビジネスロジックと入力規則はレコード種別ごとに区別されているか? オブジェクトと項目に明確な最新の説明があるか? |
プロセスと宣言型のカスタマイズが今まで適切に整理されていたとはっきり感じられることが必要です。組織が期待するほど整理されていないことがわかったとしても心配ありません。質を高め、より健全な組織を築くために役立つ標準を作成するためにチームが取り組める部分を明らかにする良い機会です。また、組織をクリーンアップするために最初に取り組むべきプロジェクトを見極めることもできます。
今後数か月で、これらの概念を実践するためのリソースや機会を追加する予定です。メタデータの分離を探索し、パッケージを作成し、ロック解除済みパッケージについて詳しく学習することができます。