はじめに

はじめまして、そしてこんにちは。株式会社SHIFT ソリューション開発部Salesforceグループのホンマです。

Salesforce導入支援案件の中で、各機能の「命名」について、悩んだことがある方は多いのではないでしょうか。

私はその一人であり、過去、携わってきたプロジェクト（以下、PJ）においても、項目やフローなどの名前を定義したとき、或いは変更を加えたいときに「あの時、ああしておけばよかった」と思うことが多々あります。

この記事では未来の自分のための備忘録的側面を持ちつつ、Salesforce開発（ローコード・コーディング問わず）に関わる皆さんの気づきになりそうなことをまとめています。

これを読んだ方にとって良い標になれば幸いです。

命名規則の作成

Salesforce開発問わず、PJを始めるときに命名規則の有無について確認すると思います。

命名規則はプログラムの可読性向上や開発資産の管理の効率化を目的とした指標です。

SalesforceにおいてはApexやLWCの開発資産だけでなく、項目やフローなどのローコード資産に対してもこの規則を適応します。

命名規則を始めに定義しておかないと、開発者は「私の考える最強の名前」を思い思いに付けてしまい、結果、統一感が無く、場合によっては管理が難しい状況に陥ってしまいます。

Salesforceの表示ラベル名は画面上に表示されるため、ユーザから名前の指示があることが多いですが、API名に関してはウラで使われますので、ユーザが指示or気にすることはないでしょう。

じゃあ、API名は好き勝手作って良いのかと言えば、そうではないことは自明です。

どう命名するかですが、次のようなことを気を付けておきましょう。

• ローマ字的な命名はしない
  ローマ字読みの場合、短い単語であれば読めますが、文字が長くなるほど可読性が高くなるとは思えないですし、SalesforceのAPI名には40文字までの制約があるため、文字数に合わせて略称を使いたい場合に、略しにくいデメリットがあります。
  
  またローマ字の場合、例えば「しゃ」はsyaかshaか、表記はどっちにすべきかなどの決めが必要になるため、規則定義時に余計な気を回す必要があると考えています。なるべく避けるべきパターンではないでしょうか。

• ○○ケースの定義
  所謂、アッパーキャメルケースやスネークケースなどのことです。可読性を上げるための手法の一つとして、この点についても事前に決めておく必要があります。組織の中で統一感があればどの記法でも問題ないと思いますが、これを決めるとき、項目のAPI名はアッパーキャメルケース、Apexのメソッドはスネークケース、と細かく定義してしまうと、レビューや管理が煩雑になるので注意が必要です。

• メソッド名の付け方
  例えば、Apexで「条件を満たす文字列の場合、末尾にセミコロンを追加する」処理を目的とするメソッドがあるとします。その場合、考えられるメソッド名は　1,StringAddSemicolon　2,AddSemicolon　3,SemicolonMethod　などでしょうか。
  
  さすがに3,SemicolonMethodは名前を見ただけではセミコロンをどうしたいのか分からないので論外ですが、1や2はそれっぽいなと思ってしまいますし、どちらにせよ、間違っていない印象です。
  
  ただ、同じ組織の中でどちらの名づけもOKとしてしまうと、プログラム全体の統一感がなくなります。個人的には、メソッド名の1単語目を動詞にすることで何がしたい処理か、分かりやすくなると考えています。例の場合、追加＝addを先頭に持っていくことで可読性は上がります。この考え方はメソッド名だけではなく、フロー名の付けるときにも同じ考え方ができます。

• プレフィックス（接頭辞）を付ける
  プレフィックスを付けるかどうかは賛否両論あると思います。Salesforce開発の場合においては、「特定の機能で使用・作成したことが分かるようになる」ことがメリットとなる可能性が大いにあります。
  
  例えば、営業部がセールス、カスタマーサクセス部がサービスを使うといったように、複数の部署が1つのSalesforceを利用することはよくある話です。そうすると「取引先オブジェクトに退会済というカスタム項目が2つある場合、営業部orCS部どちらで使っているのか」をプレフィックスを設けることで識別が可能になります。
  
  当然、同じ項目名の場合、共通化できないか検討は必要ですが、2つ作らなければならない、かつプレフィックスを付けられるタイミングであれば有効であると考えています。
  
  また、AppExchangeを導入している場合、標準オブジェクト内にAppExchange用のカスタム項目が追加される場合があります。これらの項目と識別化を図るためにプレフィックスを付けるのも有効と言えるでしょう。
  
  ただし、仮に先にセールスで作った退会済項目にプレフィックスを付けてしまうと、後からサービスでも同じ項目を使いたいときに、何となく使いにくい状況になってしまいます。どのような文字をプレフィックスにするかの検討の際に気を付けてください。

表示ラベル・API名を変更したいとき

基本的にSalesforce内で開発した機能の表示ラベルやAPI名の変更は可能です。

ただし、項目の場合注意が必要です。

変更する項目がApexクラスやApexトリガーで使用されていると「Apex クラスまたは Apex トリガーで参照されているカスタム項目の名前は変更できません」というメッセージが表示されます。

この場合、対象個所を一度コメントアウトをしてから、その後項目のAPI名を修正する、といった手順を踏む必要があります。

フローだけに使用されている項目の場合、API名を変更してもメッセージは出ないのですが少し問題があります。画面フローの場合、画面要素の中でデータテーブルに変更項目を使用していると、変更後のAPI名で正常に項目の取得が出来なくなります。

この画像は、カスタム項目：Active（選択リスト）のAPI名をActiveListからActiveListsに変更後、画面フローのデバッグ機能を使用した状態を示しています。

画面フローのデータテーブルの列の設定で、変更した項目のAPI名を修正・保存することで、この問題は解消されます。

エラーとして画面に表示されないため、一見気づきにくいです。このようなことが発生するため、API名変更をする時は、影響確認が必須となります。

API名の変更ができない機能

先述の通り、よく使われる項目やフローは名前の変更が可能ですが、よく使われる機能の中でAPI名変更できないのがカスタム表示ラベルです。

この時は、諦めて新しくカスタム表示ラベルを作りましょう。

余談：そもそも、なぜ名称の変更をしなければならないのか

私が考える主な理由は以下2つです。

①命名規則に沿わない名前を間違えてつけてしまったので、修正をするために変更したい

②（導入開発時に）仕様変更などによって合わない名前がついているので、変更したい

※スペルミスなどで修正したいこともあると思いますが、これは①のルールに違反していることが多いため、割愛

①の場合、開発者自身かレビュアーが気づいて修正することになるでしょう。大量の項目や機能を作っていればスペルミスなどをすることもありますので、間違いに気づいたときに修正すれば良いのです。

難しいのが②です。所謂ウォーターフォールで上から順にPJが進む場合、設計書を作成するはずですから、そのときに名前も決めて、設計書レビューの時に適切な名前になっているか確認できていれば、あとは製造時に開発者がミスをしなければ、名前の変更は必要ありません。

しかし、モックや動作検証のために実装した機能（特にフロー）を要件定義や設計の段階で開発し、これを開発物として流用する場合、適当な名前がそのまま使われてしまったり、当初想定していた機能範囲外のことを実装したりして、結果として出来上がったものと名前が合っていないことはあり得ない話ではないはずです。（モックの段階で適切な名前を考えておけば修正は発生しないでしょ、というご指摘はごもっとも）

Salesforceのようなパッケージの場合、ユーザの求める動きが実現できるか確認する作業は必ず発生します。なので、このような経験のあるSalesforceエンジニアは私だけではないと信じています。

おわりに ～まとめと感想～

名前を付ける行為は別に論理的思考が必要ではありませんが、開発者の経験やセンスが光ってしまう部分だと思います。

事前に最低限のルールを決めておかないと、奇をてらった名前やローマ字つづりの可読性が低い名前をつけられてしまう可能性があるので、命名規則はPJの始めに必ず決めましょう。また、お客様によっては独自の命名規則を定義していることもありますので、まずは確認を忘れなく。

過去関わったPJでは、数か月前に自分で命名したAPI名に対して、なんでこんな分かりにくい名前を付けてしまったんだろうと後悔したことがあります。Salesforceの場合、項目やフローの説明が定義可能ですが、名前を見ただけで「こう！」だと分かる方が運用や追加開発をする人たちにとって親切になります。 とりあえず、で名づけるのではなく、きちんと意味のあるものになるように名づける努力は引き続きしていきます。

✅あわせて読みたいおすすめマガジン

✅お問合せはお気軽に

✅SHIFTについて

✅SHIFTのサービスについて

✅SHIFTの導入事例

✅お役立ち資料はこちら

🌟SHIFTの採用情報はこちら

PHOTO：UnsplashのDima Solomin