この記事では、 Salesforce の 開発時の カスタムオブジェクトとカスタム項目の API参照名 のネーミングルールについて紹介します。
Salesforce の 開発においては、ほとんどの場合に 「標準オブジェクトにカスタム項目を追加する」 か、 「カスタムオブジェクトを作成する」 ことで要件を満たすことが多いと思います。
これらは自由に設定できるため気軽に作成しがちですが、ルールを定めておかないと後で後悔することになります。
よくわかる API 参照名の重要性
私が目にした中で目を覆いたくなるような項目の例として、
Field1 , Field2, AAA といった API参照名があります。
Salesforce の 開発に携わっている人からすると、そのヤバさが伝わると思います。
そして何が問題かというと、これらは「成熟した Salesforce 組織」 における 「連携や画面上での重要な項目」 であったことです。
開発の初期段階や、カスタマイズが小さいうちは、まだ取り返しがつきます。
しかし、Apex もゴリゴリ書いていて、さまざまなシステムと連携して・・・という組織では、例えば AAA 項目の API参照名一つを変えるのも大事件です。
- SOQL の項目指定箇所がないか・・・？
- 連携項目に使われてないか・・・？
- リグレッションテストの影響範囲は・・・？
- そもそも
AAA項目であってる？（似たような項目のAAじゃないよね）
とか、これをシステムベンダーに見積もらせると相当な金額になることでしょう。 （そして、上記のような考慮事項が主張されていれば、おそらくその言い分は正しいのです。）
結果、 直さず 「このままいこう」 という結論になり、負債が永遠に残ってしまうのです。
個人的な推奨のルール
まず、その項目が関係する開発プロジェクトを表す英文字 3 ~ 4 文字を決めます。
例えば、「営業管理システム構築プロジェクト」なら、 Sales Management System Project から頭文字をとって SMSや SMSP にする、などです。
標準オブジェクトの場合
標準オブジェクト自体の API参照名は変更できないため、カスタム項目の追加だけだと思います。
そこで、カスタムオブジェクトの Prefix に、先ほどの英文字略称を追加するだけです。
例えば、 営業チーム 項目を追加する場合は SMSP_SalesTeamName などです。
カスタムオブジェクトの場合
カスタムオブジェクトは、以下の２種類のパターンに分けます。
(1.) そのプロジェクトでオブジェクトを作成した場合
オブジェクトの API 参照名に、先ほどの英文字略称を追加します。
例えば、 営業目標 オブジェクトを作成する場合は SMSP_SalesTarget などです。
そして、カスタム項目には Prefix を付与しません。 オブジェクトを見れば、どのタイミング・どのプロジェクトで作成されたものかがすぐにわかるので、その項目は同じ意味を持つと判断できるためです。
(2.) 別のプロジェクトで既存のオブジェクトに項目を追加した場合
この場合は、標準オブジェクトの場合と同じで、項目に Prefix を付与します。
例えば、営業目標 オブジェクト（SMSP_SalesTarget） に、文書管理システム連携プロジェクト（Document Integration Project（DIP）） で新たに 「関連文書ディレクトリ URL」 項目を追加したいとします。
SMSP_SalesTarget の項目は Prefix が付与されていないので、DIP_RelatedDocumentDirURL といった形で、混在させます。
こうすることで、項目の追加タイミングと関連プロジェクトが一目瞭然になるため、影響範囲の調査と項目の意味が非常に分かりやすく管理できるようになるのです。
他にもメリットがたくさん
この考え方は、他のさまざまな設定にも応用できます。
Lightning Recordページやページレイアウト、権限セットなど、API参照名を指定する場合はプロジェクトを表す略称を付与するべきです。
ルール付けしておくことで、リリース前のリソース確認もかなり容易になります。
- 他のプロジェクトのリソースが紛れ込んでいないかのチェックが一目でできる
- Prefix で Grep すればリソース漏れがないかの確認がしやすい
- ソートしやすい
などなど。
おわりに
Salesforce のネーミングルールはとても重要です。
ITにあまり詳しくなくても、画面で設定さえすればそれっぽいアプリケーションを作れてしまいますが、適当に設定すると酷い目に遭います。
負債を残さないようにしましょうね。
コメント