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
Japan Dreamin’ 2020 登壇してきた！
遅くなりましたが、2020年1月25日（土）に開催された Japan Dreamin' 2020 に参加・登壇してきました。
今回の発表では、AppExchange プロダクトを継続して開発していく中で注意すべき点について話しました。こちらから資料を見ることができますので、よろしければご覧ください。
Japan Dreamin' 2020
Japan Dreamin’2020 での発表資料を参照できるものもあります。さまざまなテーマで発表されており、参考になる発表も数多くあると思いますので、ご自身の興味のあるテーマを探してみていただければと思います。
続きを読むSalesforce Evergreen に夢を見る
今年も技術系アドベントカレンダーの季節がやってまいりました。皆さま元気にお過ごしでしょうか？
先日 Dreamforce が開催され、まだ時差ぼけが治っていない方も多いかもしれませんが、クリスマスまで25日ですので、今日から毎日投稿されるアドベントカレンダーの記事を読んで楽しましょう！
この記事は Salesforce Platform Advent Calendar 2019 - Qiita 第1日目の投稿です。
はじめに
今年は Dreamforce では Developer 向けに大きな発表がありました。
そうです。
Salesforce Evergreen です。
Salesforce Evergreen とは？
Salesforce Developer Blog の記事によると Customer 360 Platform の新しい機能です。また、Salesforce Evergreen はフルマネージドな Kubernetes 上に構築されたサーバレス機能（Functions-as-a-Service）、一般的に利用される高性能なデータストア（マネージドデータストア）を提供します。
Salesforce Evergreen で何が変わるのか？
Salesforce プラットフォームでは苦手としていたことについて、解消されることが期待されます。その苦手なこととは下記のようなものです。
1. 重い処理を実行すること
2. 複雑なアーキテクチャを実装すること
3. 既存資産を活用すること
重い処理を実行する
Salesforce Evergreen では Function-as-a-Service によって機能を実装することができます。Saleasforce プラットフォームではマルチテナントを実現するためにサーバー処理能力を占有するような重い処理を実行することが苦手でした。
Salesforce Developer の多くを苦しめているガバナ制約などの制限となります。Salesforce プラットフォームでも重い処理は非同期的に実行することで回避できることもありますが、それでも重い処理は Heroku や Amazon EC2 などの外部サービスにオフロードしていました。
今回発表された Salesforce Evergreen では、上記のようにして回避していた課題を Function-as-a-Service として実装することでよりシームレスに開発できるようになります。
Low Code で Salesforce 製品の機能を自社にフィッティングするだけであれば、既存の Apex を利用して Salesforce プラットフォームに実装しても大きな問題はありません。
しかし、AppExchange に登録されているような業務システム製品では勤怠計算処理、会計集計処理など計算量が多い機能がありますが、Salesforce プラットフォームの制約のため機能の一部を妥協していることもあります。
Salesforce Evergreen を利用することでより複雑・高負荷な機能を実装できるようになり、より優れた機能を提供できるようになることが期待できます。
複雑なアーキテクチャを実装する
Salesforce プラットフォームはすべてのプログラムを一つのものとして管理してしまいます。Salesforce DX CLI を使ったり、第2世代管理パッケージを利用したりすることで分割して管理できるようになってきていますが、Microservices まで分解して管理することはできませんでした。
Salesforce Evergreen を利用することで機能を独立的に管理できるようになります。これによって開発するチームの責任分担もやりやすくなります。また、アーキテクチャも自由に設計できるようになるため、複雑な問題に対処するためにリッチなクラス構造を整えることができます。
加えて、Apex ではできなかったローカル開発が可能になり、ローカル環境で実行できる自動テストを実行できるようになります。Apex テストではテスト実行に時間がかかってしまっていた処理も継続的インテグレーション環境を構築し、並行実行することで時間短縮も可能になります。自動テスト環境は開発者にとっての基本的人権とも言えるところなので、この部分が大きく改善することは大きな意味があります。
既存資産を活用する
Salesforce プラットフォームでは開発言語が Apex に制限されるため、Javaなどで開発した既存資産は利用できませんでした。Salesforce プラットフォームに業務システムを寄せようとした場合、必要な業務システムは Salesforce プラットフォーム上にすべて再構築する必要がありました。
Salesforce Evergreen を利用すると JavaScript / Java のソースコードを実行できるため、既存資産にあるビジネスロジックを流用することができます。
それ以上に既存資産として有効活用できるものとして、インターネット上に多く公開されているライブラリやフレームワークです。Salesforce プラットフォームではライブラリを一元管理する仕組みがなく、個別に再実装したり、ソースコードをコピーして利用していました。
パッケージ管理ツールで利用しているパッケージをインポートして利用できるようになれば、余計なソースコードの管理が削減できることは開発生産性にも効果的です。
Apex は生き残るのか？
さて、皆さん気になっていることではないでしょうか？
Evergreen の登場によって、Apex がオワコンになる可能性が高まってきますが、将来的には必要なくなってしまうのでしょうか？
私の答えは「なくならない」です。
なぜか？
それは、Microservices が通常の開発ではオーバースペックだからです。ちょっとインテグレーションしたい場合にそこまでやってしまうと構築コストが跳ね上がってしまいます。"No Code" では実現しきれなかった処理で、"Low Code" で実現するスクリプト言語としてはなくならないと思います。
では、その構築コストに見合う開発を行なっている人たちは誰か？
SIer の一部もそれに見合う人たちもいると思いますが、一番活用するのは AppExchange にプロダクトを公開している ISV/OEM パートナーです。彼らは Salesforce プラットフォーム上に巨大な業務システムを構築しています。一枚岩のシステムは巨大になると管理コストが負担になってきたり、複数の開発チームで分担しにくくなってきます。
それらの問題を解決するための手段として、Microservices が発明され、大きなプロダクトを持つ企業を中心に広まってきています。そういった意味では、Salesforce Evergreen は ISV/OEM パートナーに向けた機能追加と言えるかもしれません。
しかし、ISV/OEM パートナーもすでに Apex で記述した大量の既存資産を抱えているため、Salesforce Evergreen に容易にはトランスフォームできません。このトランスフォームをうまく成し遂げた、または新たに参入して Salesforce Evergreen を使いこなした企業が大きく成長するのかもしれません。
おわりに
Dreamforce で Salesforce Evergreen が発表されたことを受けて、どういった影響がありそうか考えてみました。ISV/OEM パートナーとして開発しているものとしては新しい挑戦ができる楽しみ、と、やらなければ生き残れないのでは？という焦燥感を抱きました。
2020年2月には Developer Preview として実際に触れる環境が提供され始めます。まだまだこれから情報が増えていく段階ではあるので、楽しみにして待ちたいと思います。
最後に、アドベントカレンダーで Salesforce Evergreen について何かを書こうと思っていた矢先に、stomita (id:shinichitomita) さんによるガチ分析なブログが公開されました。非常に鋭く面白い内容ですので、ぜひそちらもどうぞ。
Enjoy Advent Calendar!
Salesforce Webinar 「Salesforce DX の始め方とパートナー様成功事例」にゲスト出演しました
こんにちは。
1ヶ月も経っていまさらな感じですが、2019年8月30日に開催されたセールスフォース・ドットコム社主催のウェビナーにゲスト出演しました。
今回のウェビナーでは、SalesforceDX の活用事例を2社、co-meeting木村さんと私から話しました。こちらから資料と動画を見ることができますので、よろしければご覧ください。
続きを読むJSTQB ALTM に合格したぞい
8月25日にJSTQB認定テスト技術者資格 Advanced Level ＜テストマネージャー＞を受験しました。
そして、10月に合格発表が…。
www.juse.or.jp
まったく合格できる気がしていなかったのですが、なんと合格できました！
よかったー。
昨日、合格証書も届き、ちゃんと合格したんだなぁ、と実感が湧きました。
「Full Advanced Level Professional：テスト技術者資格 Advanced Level 完全上級テスト技術者」の称号を得るためにはあとテクニカルテストアナリスト（ALTTA）が必要なのですが、日本語で出題されるJSTQBではまだ受験できません。
うーん、英語が身につくのが先か、日本で受験できるようになるのが先か…。
Enjoy Testing!
「難しい」という言葉
「難しい」というのは思考停止だ、という人が結構いる。
本当にそうなのだろうか？
メンタリティが違うような気がする。
研究者やエンジニアにとって難しい問題はむしろ好物だったりする。
難しい問題は解決していく対象である。
本質的な解法がないとしても近似解を求めようとする。
なんとか問題を解こうとして何年でも取り組んでいく。
そして、エンジニアは難しい問題を解くための技術を持っている。
代表的なものは、「分割統治法（Divide and Conquer Method）」がある。
そのままでは解決できない大きな問題を小さな問題に分割し、その全てを解決することで、最終的に最初の問題全体を解決する、という問題解決の手法である。
この手法は、大学時代に卒業研究するときに教授から学んだ。
「ロジック・ツリー」といったほうが馴染みがあるかもしれない。
難しいからといって、諦めるとか、思考停止するとかする必要なんてない。
難しいことを認識して、正しい問題を設定、および分割する。
その上でトライ・アンド・エラーしながら、ひとつずつ解決していく。
それだけだ。
ぼくらはエンジニアなのだから。
Salesforce パートナーオフィスアワーにゲスト出演
AWS Summit Tokyo の期間中のとある2018年5月31日(木)にひっそりと開催されたパートナーオフィスアワー(構築力）Webinarにゲスト出演させていただきました。
あらすじ
テーマは
- アプリケーションライフサイクル管理 と Salesforce DX
- Salesforce DX 事例
株式会社セールスフォース・ドットコムの川畑さんから頭出しとして米国で発表された資料をもとに概要を説明、株式会社フレクトの齋藤さんが実際に Salesforce DX を実戦投入したときの話を共有していく進行でした。
私は昨年の Salesforce World Tour Tokyo で発表させてもらった流れで合いの手を入れる係（発表ネタ、準備できなくてごめんなさい）。
