組織のカスタマイズの確認
学習の目的
この単元を完了すると、次のことができるようになります。
- 現状評価のビジネス的価値と技術的価値を明らかにする。
- コードベースの何に注目すべきかを挙げる。
- プロセスおよび宣言型カスタマイズを調べる方法を挙げる。
詩人であり哲学者でもある 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.有効/無効バージョン 4.フローロジック 5.フロー画面 | フローでは、プレフィックスまたは類似名を使用してグループが作成されるのか? フローには機能に関連する明確な名前が付いているか? フローに明確な最新の説明があるか? フローはどのオブジェクトとやり取りをおこなうのか? 無効フローまたはフローバージョンと有効フローの間にはどのような関係があるのか? フローでは、サブフロー、呼び出し可能アクションまたはクイックアクションに一般的な機能が配置されるのか? フローに画面がある場合、それらは Lightning コンポーネントに基づいているか? 画面は特定のオブジェクトや項目に依存するのか? フローに変換する必要がある古い自動化はないか? |
オブジェクトおよび項目 | 1.命名規則 2.レコードタイプ 3.ページレイアウト 4.権限 5.アクション上書き | 標準オブジェクト動作を複製するカスタムオブジェクトが作成されたか? 複数のビジネスユニットで同じオブジェクトまたは項目が使用されているか? ビジネスロジックと入力規則はレコード種別ごとに区別されているか? オブジェクトと項目に明確な最新の説明があるか? |
プロセスと宣言型のカスタマイズが今まで適切に整理されていたとはっきり感じられることが必要です。組織が期待するほど整理されていないことがわかったとしても心配ありません。質を高め、より健全な組織を築くために役立つ標準を作成するためにチームが取り組める部分を明らかにする良い機会です。また、組織をクリーンアップするために最初に取り組むべきプロジェクトを見極めることもできます。
今後の予定
今後数か月で、これらの概念を実践するためのリソースや機会を追加する予定です。メタデータの分離を探索し、パッケージを作成し、ロック解除済みパッケージについて詳しく学習することができます。
リソース
- BA Times 記事: What About the Current State? (現状はどうなのか?)
- Atlassian 記事: Escaping the black hole of technical debt (技術的負債のブラックホールから逃れる)
- ブログ投稿: Paying Down Your Technical Debt (技術的負債の返済)
- Salesforce ヘルプ: Which Features Does Optimizer Evaluate? (Optimizer で評価される機能)