DevとAdminのあいだ

（本記事はSalesforce Platform Advent Calendar 2019 - Qiita19日目の記事です）

※あんまり技術ネタっぽいことではないので、（実に久々に）こちらに記事を投稿することにしました。

Salesforce界隈では、"DevとAdmin"というテーマは常に存在してきました。
このテーマは...時代とともに進化し続けていくのだろうと思いますが、実に久々にツラツラと考えてみました。
そんなわけで、"実に久々にこのテーマについてツラツラと考えてたこと"を備忘録的に書き残してみたいと思います。（結論的なものはないです特に。）

"Low Code" と "Pro Code"

そういえば、ここ最近ではSalesforce界隈でも、"Low Code"といったキーワードを目にすることが多くなったと思います。
※ここでいう"Low Code"とは、いわゆる標準機能（プロセスビルダーやフローなど）のことを指し、"Pro Code"とは、Apex, Visualforce Page, Lightning Componentといったいわゆる開発言語を指すものとして扱います。

Salesforceでは以前よりLow Codeに相当する機能を提供してきました。ワークフロールールに始まり、ビジュアル化が進んだプロセスビルダーやフローといった機能ですね。そして昨今では"Low Code"というキーワードで、コードを書くことなく様々な機能を開発できるプラットフォーム（LCP = Low Code Platform）が注目を集めています。
例えば、Salesforceや、OutSystems, ServiceNowなどが挙げられると思いますが、これらのLCPを耳にしたという方も多いのではないでしょうか。
実際のところ、Low Codeによる開発は、敷居の低さ、高い生産性、低コストを実現可能にする点では非常に優れていると思います。

Salesforceの文脈でいうと、"Low CodeはAdmin系" , "Pro CodeはDev系"...という印象があるかと思います。Admin系/Dev系が主に使うのは確かにその通りかもしれませんが、実際のところは実現したい要求によって使い分けが非常に重要になってきます。
具体的にどういう感じか考えてみたいと思います。

Low Codeが推奨される範囲

Low Codeで構築すべき範囲としては以下のようなものが挙げられると思います。（思いつくあたりでいくつかテキトーに）

• レポート・ダッシュボード
  • もはや言うことないでしょう。これをApexで作って♪と言われても
• メールアラート, Chatter投稿
  • Apexで実装するには割と面倒なことが多いので、できればプロセスビルダーでやりたい...。ただ、Chatter投稿に関してはメンション先や添付ファイルをつけたいなどの細かい要望がある場合にはApexトリガなどで頑張る感じになるかもしれません。
• カスタム通知
  • プロセスビルダーでぜひお願いしたい。
• 承認プロセス
  • もはや自作したら負け♪
• レコードへのアクセス制御（項目レベル、レコードレベル）
  • もはや自作したら負k...ただし、Apex共有は仕方ない...かも。

上に挙げたものはごく一部ではありますが、どれもこれもApexで実装したくないものばかりだと思います。
「ビジネスプロセスの自動化」を中心に、「ID」「セキュリティ」あたりでよく目にするものは、積極的に活用したい範囲と言えるでしょう。
他には「外部オブジェクト」なんかも便利ではあるんですが、費用面で色々と折り合わないことも多かったりしますね。。（遠い目

Pro Codeが推奨される範囲

（これまた一部ですが）

• 複雑なロジックを要する機能
  • 複数オブジェクトへの更新
  • 複雑なバリデーション
  • 大量データ処理
• 帳票類
  • （妙に複雑な帳票とかは無くして欲しいが）
• 複雑な画面
  • （妙に複雑なg...）
• 外部システムとの連携
  • （アウトバウンドメッセージでは対応できない場合など）

Pro Codeが必要になるのは、特殊な条件下での機能だったり、複数のオブジェクトにまたがる処理をするような機能や、特定業務に特化した画面...だったりと、色々ありますが、「Low Codeじゃ太刀打ちできない」という基準は1つ考えられるかな、と思います。
Low Codeじゃ実現できないような要求があれば、Low Codeよりも自由度の高いPro Code（Apexプログラミング）が必要になりますし、場合によってはApexでも対応できないとなると、さらに自由度の高いモノを引っ張り出してくる必要もでてきます。

Low Codeは、Pro Codeから抽象度をさらに1段上にあげて、まるでブロックを組み合わせるように組んでいけるもの...と捉えていますが、同時に制約も1段上がります。したがって、自由度の高いものを要求する場合にはやはりPro Codeの出番になるのかな、と。
残念ながら、Apexよりさらに自由度の高いものをSalesforce上で実装することはできないので、自由度の高いものが必要な場合には、自由度の高い別のプラットフォームとの組み合わせが必要になりますね。（そして、Evergreenへの期待が高まる...！）

選択を間違えない

そんなこんなで、Salesforceでの開発においては、Low Code / Pro Code が適している範囲がそれぞれあって、使いどころを適切に選択していくことが非常に重要になってきます。（誤った選択が積み重なっていくと、哀しくカオスなシステムがまた1つ産み出されることでしょう...）
Admin系にしてもDev系にしても、そういった選球眼をしっかりと持ち、常に磨きをかけていくことが大事でしょう。

性能効率性だとか保守性だとか

ここまでのところで、何がしかのシステムを構築していく上で、「Pro Codeだけでガンバる」というわけではないということが見えてきたと思います。
"エンジン音だけ聞いてブルドーザーだと認識できるようにわかって" きたかと思います。

さて、ここで違った観点で1つ考えてみたいと思います。

何かシステムを構築しようとする際に、コード（Pro Code）を闇雲に量産していった先に何が待っているかは言うに及ばず、だと思います。
"そう、コーラを飲んだらゲップが出るっていうくらい確実" にイバラ道が待ってることでしょう。

一方でLow Codeでも闇雲に追加していった先には、きっと同じ道が待ち受けていることだと思います。（きっと）
例えば、

• ワークフロールールが何故か動かない
• 1つ条件を変えたくとも、様々な箇所で同じように変更する必要があるワークフロールール
• 一括データ更新しようにもタイムアウトが発生するので数件毎にしか処理できない

などなど。

Pro Codeでいえば、プログラムの保守性を高めるために、どういった実装がより好ましいか等、ベストプラクティスやバッドノウハウが色々と考案されてきました。

では、Low Codeの方ではどうでしょうか？
メンテ不能やパフォーマンスが"貧弱！貧弱ゥ！"にならないよう、例えばプロセスビルダーやワークフロールールをどう組むべきか？（その他、バージョン管理とかどうするのか）等といった手法が考案されているかと思います。が、、、残念ながら、勉強不足でして詳しいことは分かりません。誰か教えてください。
（あるいはお近くのゴールデンな方にお尋ねするのが良いかも...！）

もしかしたら、そこでのバッドノウハウは、Pro Codeと組み合わせることで簡単に解決できることなのかもしれません。
そして、こういったあたりがDevとAdminが協働することで高い効果を生むポイントの1つなのかもしれません。

※1 ちなみに現在のところ、とあるSalesforce環境ではワークフロールールが上限近くまで作られていて、トリガ作るのも躊躇するしデータ更新するにも数件ずつしかできない...みたいな状況があって（多少改善できたけれども...）、どうしたもんかなぁと悩んでるところです。。

※2 ワークフロールールとかフローとかは、メタデータを抜き出してバージョン管理システムで管理する...なんてこともできるかもしれませんが、そのツールを使うのはDev系がメインでAdmin系にはキビシイと思うあたりで、みんなどうしてるのかな？と。。
flosumといったAppExchangeを使うのが良いのかもしれませんね。
www.flosum.com

DevとAdmin、そしてCTA

"プラス方向にメンタルをグングン上げるとテンションが光属性になりAdmin系になる"
"逆にマイナス方向に下げるとメンタルのテンションが闇属性になりDev系になる"
"このプラスとマイナスのテンションをスパークさせた能力こそが...年収1000マン超えを約束された職種CTAなんだ"

...などということは全く知らんですが、Dev系とAdmin系の両方を兼ね備えた人材というのは、それはいわゆる「CTA」と呼ばれるスーパーな人材なのかもしれませんね。
ここ最近のコミュニティ界隈でもCTAに対する注目度がさらに増して（キャラクターが追加されたりと）きています。
CTAを目指す上で習得した知識や経験は、必ずしもSalesforce内だけでしか通用しないということはないと思いますし、CTA取得を目標にするのはスキル向上（＋給料も向上？）という観点で非常に良いことでしょう。

ただ、なんとなくSalesforceを主軸において構成を考えることに重きを置かれているような印象もある（ベンダー主体の資格なんだから当然か）ので、様々な状況下で考案するアーキテクチャの中においては、Salesforceだって1要素でしかない...と捉えつつ、公平な立場を取り続けていきたいと思います。（知らんけど）

別にCTAを目指すことを推奨したいわけでもないし、タメになるようなことがない話となってしまいましたが、引き続き「DevとAdminのあいだ」について考えてまいりたいと思います。（たぶん）