Salesforceにおける継続的ノーコード開発のベストプラクティス
はじめに
先日のMiryさんとの収録でSalesforceでのノーコード開発で実践すべきプラクティスを伺うことができました。
Salesforceを活用しきる点において非常に先行する取り組みをされており、さまざまなノウハウがあることがわかりました。Podcastという音声メディアではググラビリティ（検索性）に劣るので、私なりにエッセンスをまとめたいと思います。
ベストプラクティス
ビジネスが成長する中でSalesforceを利用したノーコード開発を継続するためのベストプラクティスを下記の3点にまとめました。
- ノーコーディングルール
- ドキュメンテーション
- リファクタリング
以下では、それぞれのプラクティスについて掘り下げていきます。
ノーコーディングルール
ノーコードにおいても設計指針を策定することが重要です。
決めていくことはさまざまありますが、例えばトリガー系処理の優先順などです。
具体的にはトリガー系処理を下記のような優先順に取り決めます。
- 数式
- ワークフロールール
- プロセスビルダー
- フロー
- Apexトリガー
このような優先順にしている理由として、「できるだけSalesforce Adminが理解・対応できるようにして開発エンジニアではなくても対応する」という考えがあります。これによって、プログラミングできないようなビジネス寄りの人が設定変更できるようになり、業務と開発の両方を理解した人が作業することで適切な要件の落とし込みが素早くできるようになります。
なぜ、このようなルールが必要なのかというと、開発エンジニアは慣れているプロコードの方が楽なのでルール化しておかないとSalesforce Adminが理解・変更できる領域が狭まってしまいます。そのため、この方針を背景とともにメンバーが理解し、設定を考える上での具体的なルールに落とし込むことが重要になります。
ドキュメンテーション
Salesforceの設定は簡単に変更できるため、ついその場の対応で設定を変更していきがちです。そういった場当たり的な対応を続けていると、下記のような負の連鎖が起きてしまいます。
まず、現在Salesforce組織にどういった設定がされているか分からなくなります。記憶力がいい人がすべてを把握して対応していれば、まだ管理できた状態を保てます。しかし、歴史が長くなり忘れてしまったり、別の人が対応することになったりすると問題が表出してきます。
このような状態では、現在の設定がどういった経緯で設定されたか分からないため、安易に変更できなくなり、下記のような問題が発生してきます。
まず、既存の設定を変更するために経緯を確認し、影響範囲を調査する作業が必要となるため、設定変更に時間がかかってしまうことです。Salesforceでは設定画面を操作して設定していくため、関連する設定を探しにくいところがあります。
次に、そのような調査や検討が飛ばされてしまうことです。調査する時間が取れないため、時間のあるときに見直そうと現在の設定に影響しないように追加で設定ししてしまうことです。しかし、こういった負債は日々の作業に追われて返済されることなく溜まっていくことになります。
最後の問題は、継ぎ接ぎだらけの設定になることで複雑化してしまうことです。複雑化してしまった設定のメンテナンス性は低下し、処理も遅くなってしまいます。
このようにして、設定は日々肥大化し、複雑化していきます。では、このような状態にならないようにするためにはどのようにすればよいのでしょうか？
設定が肥大化・複雑化していく問題に対する万能な解決策「銀の弾丸」はありません。地道なエンジニアリングで負債を溜めないようにしていくしかありません。
その中でもドキュメントを残すプラクティスが重要です。ドキュメントに過去の経緯や影響範囲などがまとまっていることで上記のような問題が起こりにくくなります。ドキュメントベースで他の人とレビューしたり、共有したりできるようになります。
このようにドキュメンテーションしていくことで、肥大化・複雑化しがちな既存の設定を見直し最適な状態に保つ礎を築くことができます。
リファクタリング
ドキュメンテーションのプラクティスでも触れましたが、ノーコード開発を継続するためにはメンテナンス性を高い状態に保つことが重要です。
ドキュメンテーションによって日頃から肥大化・複雑化する設定を増やさないことも重要ですが、日々忙しくしているとどうしても負債が蓄積されていってしまいます。また、ビジネスの変化によって不要となる設定や項目があったり、新しい機能がリリースされることでより良い設定ができるようになったりします。
そのため、定期的に時間を確保して、既存の設定や項目を見直す作業「リファクタリング」を実施することが重要です。
リファクタリングでは下記のようなことを実施します。
1. 不要になった設定や項目がないか確認する
2. 肥大化・複雑化している設定を簡潔に直せないか考える
3. 新しい機能で利用できるものがないか考える
Salesforceの設定はビジネスに合わせてスピード優先で走りながら直していく側面もあります。ビジネスの変化が落ち着いたところで設定を最適化した方がよい局面もあるので、リファクタリングをプロセスに取り込んでいくことでメンテナンス性とスピードのバランスを取ることが重要です。
今後の課題
Salesforceにおける継続的ノーコード開発において課題と考えていることが2点あります。
テスト
Miryさんも話していましたが、ノーコードで開発した物はマニュアルテストを頑張って実施していくしかありません。開発物が増大すると影響範囲も広くなり、既存の設定に影響ないことを確認するためのマニュアルテストの負担が増えていきます。
テスト自動化ツールを利用して、マニュアルテストの一部を自動テストに置き換えていく、などの取り組みも必要になると考えます。
構成管理
Salesforceの設定の構成管理をどのように実施していくか、はまだ解決できていない課題だと考えています。SalesforceDXによってメタデータの取り扱いやソースコード管理ができるようになってきていますが、まだ開発エンジニア向けの機能であり、Salesforce Adminが扱うには難しいのが現状です。
SalesforceDXの機能拡充が進み解決していくとは思いますが、それまでは工夫して対応していく必要があると考えます。
まとめ
この記事では、継続的にノーコード開発を実践するためのベストプラクティスとして、ノーコーディングルール、ドキュメンテーション、リファクタリングを紹介しました。
一貫する考え方としては、エンジニアリング手法を導入しながら Salesforce Admin をエンパワーメントすることです。今後ますます Salesforce Platform が強力になることで業務要件を簡単に開発できるようになっていき、Salesforce Admin によるノーコード開発はより広く実践されていくことになります。しかし、ノーコード開発は開発モデルがまだ成熟しておらず、このようなベストプラクティスが蓄積されていくことが重要だと感じました。
この記事は、 note.com に投稿した記事の転載になります。
note.com
