はじめまして、のぶじゃすと申します！
この記事は GYOMUハック/業務ハック Advent Calendar 2019 - Adventar の22日目の記事です。先日の記事が話題になったりなど、とても盛り上がっていてそのAdvent CalendarでBLOGを書けるのはとても嬉しいです！
皆様はじめまして @noblejasper と申します。私のかんたんな経歴としては
- webアプリケーションエンジニア（フロントエンド、サーバサイド）
- エンジニアの採用担当としてリクルーター
を経て、今年の7月ぐらいから採用業務の効率化や最適化のために採用向けのGYOMUハックをやらさせていただいております。
なにをやっているの？
シンプルに言うと、SalesforceでATS（Applicant Tracking System : 採用管理システム）のアプリ開発を行っています
今回このBLOGでは開発しているアプリケーションの詳細は説明しませんが、Salesforceに触れたのは2019年の7月からなのでまだ半年も経過していないペーペーのSalesforceエンジニアです。
- はじめまして、のぶじゃすと申します！
- おーい！みんな社内向けシステムの開発してる？
- 社内向けシステムを作りたいならSalesforceで作れ！
- さてここからが本題
おーい！みんな社内向けシステムの開発してる？
自社で自社の社内向けシステムを作る場面て思っている以上にたくさんあると思うんですよ。
例えば何かのデータを集めたり、集計したり、分析したりするために
- GSuiteのGoogleスプレッドシートの関数やGASを駆使して表計算する
- 簡単なプログラムを書いてCSVを整形してみたり
- メールを自動でタスク管理ツールに転送できる機能を作ってみたり
とか簡単なものから大変なものまでありますが、どれも社内向けシステムと言えるのではないでしょうか？
WebアプリケーションエンジニアがSalesforceエンジニアになるのってどうなの？
私は今Salesforceで大きめの社内向けシステムを開発しています。
まだまだ活用しきるところまではできていませんが、基本的な機能やデータ構造はできていて現場で使い始めるところまで開発できたので、 開発をして感じたwebアプリケーションエンジニアがSalesforceエンジニアになるメリットみたいなものをまとめていけたらいいなと思って書いています。
社内向けシステムを作りたいならSalesforceで作れ！
結論から言うと、社内向けシステムを作るのであれば絶対にSalesforceで開発するほうがいいです。 細かい理由は後述のメリットなどで書こうと思いますが、
- 早く作れる
- 早く直せる
- 余計に作らないといけないものがほぼ無い
他にもたくさんありそうですが、私が思う大きい理由はこんなところです。
さてここからが本題
前置きが長くなりましたが、ここからが本題です！
WebエンジニアがSalesforceエンジニアになるメリット
Webエンジニアと言っても最近ではポジションも細分化され、いろいろなスキルセットがある思っています。 私の独断と偏見でWebエンジニアのポジションごとにSalesforce開発でメリットになるであろう部分をまとめてみようと思います。
私が今まで経験してきた
- サーバサイドエンジニア
- UI・フロントエンドエンジニア
- SRE・インフラエンジニア
の軸で書いていきます！
このBLOG読まなくてもTrailheadやっておけば余裕で作れるようになるよ
Salesforceを知っている人なら皆さん既に触れているかと思いますが、 改めて考えるとTrailheadはやばいです。
簡単に言うと、Salesforceの使い方を例題を交えて覚えていけるチュートリアルなのですが、 カテゴリごとにまとまっていて、見やすいしわかりやすい。簡単。点数が増えていってレベル上げていける感じも楽しい。
自由にサンドボックス環境が作れたりするのもとてもありがたい。
これが無かったら今回アプリ開発するのは無理でした。
この後長文になりそうな気配なので、めんどくさい人はこのTrailheadを2つクリアしてください。 そしたらもう作れるようになると思いますｗ
サーバサイドエンジニア
実際にはサーバサイドエンジニアの経験が一番活きたのではないかと思っています。 後述するデータモデリングの話はサーバサイドエンジニアとしてやってきた事の1つでもあったりします。
高品質なScaffoldと、権限管理がはじめからある
まずはこれかなと。Saasですし当たり前といえば当たりまえなのですが、 なにか一つのテーブルに対してCRUDを手作業で作る必要は０です。０！
List, Show, Edit, Create はかなり高品質なものが提供されています。 個人的に一番感動したのはリストビューです。
ここまでのリストビューを標準で持っていたら、何もする必要ない。すごい。
更に、レポートと呼ばれる分析ツールと複数レポートをまとめて並べて分析できるダッシュボード機能もある。
メタ的な思考で考えないといけないことが多い
プログラムを数年開発していたことがあるエンジニアはきっとある程度メタ思考が身についていることと思います。 そのメタ思考はSalesforce開発においてはかなりコアな技術だと思います。
1度Salesforceの概念を飲み込めてしまえば、あとは「きっとここはこうなってるんだろうなー」ってイメージできるようになります。
大概の自動化はGUIで簡単につくれる
コード書く必要ないです。まじです。
「AのテーブルのBカラムがしきい値を超えたらCテーブルを新規作成する」とかぐらいであれば一瞬でできます。
プロセスビルダー、フロー、ワークフロールールという3種類の自動化ツールがあるのですが、これらはそれぞれできる範囲や動作速度が違ったりします。 興味を持っていただけたら詳しく調べてもらえると嬉しいですが、簡単に説明すると、
ワークフロールール < プロセスビルダー < フロー
の順番でできる事も増え、負荷が高くなります。メンテナンスコストももちろん増えます。
ワークフロールールはこの記事がわかりやすい www.synergy-marketing.co.jp
プロセスビルダー
フロー
UI・フロントエンドエンジニア
デザインシステムがかなり完成度高く提供されている
Lightning Design System というのですが、かなり幅広い範囲で作られており、 今回私が作る上で「あれのコンポーネント無いの？」みたいになったことはありませんでした。
コンポーネント思考のLightning Web Component
React や Vue.js のようなコンポーネント思考（呼び方合ってる？）なJSフレームワークがついています。
これを書く状態はそもそもすごい少ないです。サーバサイドエンジニアの時に書きましたが既に必要十分なものが標準で用意されており、 かなり大部分が標準のみで解決します。
しかし、独自に開発しないといけない場面も出てくる事があります。
そんな時にはフロントエンドのコードをJS, HTMLで記述しないといけない事が出てきます。Salesforce上でJSは結構幅広くいろんな事ができるので、生JS書けと言われたらしんどい場面もあります。 ES9 (ECMAScript 2018)で書けます。結構非同期処理書かないといけない場面も出がちなのでES使えるのは助かります。
このTrailheadをやればコンポーネント開発できるようになれそう
VSCodeで開発できる
なぞのWebインターフェイスでも開発できるぽいのですが、私はそっちではやったことないです。
Visual Studio Codeのほうが2億倍ぐらい使いやすいだろうし。私はこちらで開発していますが、とても快適です。
SRE・インフラエンジニア
そもそもインフラ的業務は皆無
Saasですし。
スケーリングみたいな概念がないので、現時点で私が知る限りはなさそうです。
あえて言うならデータモデリングとか、アーキテクチャ的な部分ではSRE的な方が担当している会社やチームもあるのではないかと思ったので、こちらの項目に書いてみました。
データモデリングはSalesforce開発のキモ
Salesforceで新しい機能やアプリケーションを作る事になると、 カスタムオブジェクトといわれる、RDBで言うところのテーブルを作る必要があります。 （営業担当者向けのはじめから作られている標準オブジェクトというものもあります。今回の私のように、オリジナルなものを作らないといけない場合にはカスタムオブジェクトは必須です。）
カスタムオブジェクトも結構高機能で、PrimaryKeyは自動で割り振られ、すべてのデータにはIDがあります。
カスタムオブジェクト内に項目（RDBで言うところのカラム）を追加していってテーブル構成を作るのですが、 カスタムオブジェクト同士の関係（リレーションですね）を設定する事ができます。
厳密にはできる事や使い方は違うのですが、Webアプリケーション開発の上での
- HasMany なリレーションは子オブジェクトからの参照関係という名前で表現されます。
- BelongsTo なリレーションは子オブジェクトからの主従関係という名前で表現されます。
- ManyToMany なリレーションは中間オブジェクトを作成し、中間オブジェクトからの参照関係で表現できます（もっといい方法あったら誰か教えてｗ）
文字が多くて見づらいけどオブジェクトリレーションのヘルプには細かく書いてある help.salesforce.com
とはいえモデリングも結構可逆性高い
例えばあるカラムを削除したり、型を変えたり、参照関係を削除したりしようとした時にも、 ある程度救済措置をとってくれて、カラム削除したあとにそのデータをどういう扱いにするかとかも削除時に選べたりします。
リレーションの親が削除された時に子も一緒に削除するかどうかとかもオブジェクト自体がメタ要素として持っていたりします。
あと1度削除してしまっても、ゴミ箱という概念があり、だいたいの場合戻せるらしいです（まだ実際の現場で経験したことはないですｗ）
いかがでしたでしょうか？
5ヶ月くらいSalesforce開発をしていて感じたメリットを書いてみましたが、最近毎日Salesforceに触れて開発をしているとふと思う事があります。
「これ、プログラムを書いて作るWebサービスなんてどんどん無くなっていくんだろうな」と。
現時点のSalesforce開発でもApexというJavaみたいな言語や、JSを書く事はまだあります。しばらくは必要あるんだろうなと思います。しかし既にAppExchangeというSalesforce上で他の開発したアプリケーションを使う機能とかがあり、多くの開発者がそこでアプリケーションを公開されています。このエコシステムが拡大していけばプログラムを書く場面なんてほぼ皆無で独自のツールやアプリケーションを開発できるようになっていくんだろうなと思っています。
こういった社内向けシステムの開発者、エンジニアとしてはどういう方向で進化していくのがいいんだろうかと考える事もあります。
きっとその答えはGYOMUハックエンジニアの諸先輩方がこのAdvent Calendarで書いてくれたりするんじゃないかなと思ったりしています。 是非他のBLOGも読んでみてください。きっとGYOMUハッカーの工夫や努力、苦悩などが見れたりするんじゃないかなーと思います。
※写真素材提供: フリー写真素材ぱくたそ
