先日は写真の振り返りだけでしたけれども、今回は私が交流会でお話しした内容をまとめておきます。

わたしが参加したのは 14:25からの交流タイムです。
テーブルが並んでいて、そこにいる名物代表に質問をしながら交流を図るという時間だったようです。

なお、私のいた卓は私が代表として、Team Spirit の社長に見守られながら「Salesforce について何でもこたえる」というお題で交流させていただきました。「給料については答えないからね!!!」とだけ念押ししてはじめたのも良い想い出。誰も聞いてくれなかったので、良い人たちが集まってくれて良かったと思うのです。

質問の順番とかは覚えてなかったり、抜けがあるかもしれませんけれども。よっしーさんがメモってくれていたので、これを元に。あと順番もあえてバラバラにしています。言葉も言い換えていたりするので、元の質問と全然違っていたり、質問をまとめていたり回答も異なっている場合もあります。が、本質と伝えたいことでまとめました。

しょっさんの仕事

ご質問
しょっさんはどんな仕事をしているんですか

しょっさんの回答サマリ
プリセールスの立場で、お客さまのビジネス課題を解決するためのアーキテクチャをデザインすることが仕事です。
Salesforce だけで実現できることは多くありません。さまざまなシステム、クラウドサービスなどを考慮して、お客さまが実現したいことを企業全体でどのように実現できるか、実現可能なシステムの構成を考えています。

追加でご質問
抽象度の高いコンポーネントを組み合わせてアーキテクチャを構成する部分がスコープですか

しょっさんの回答サマリ
提案時に提供するシステム構成は、一般的に抽象度の高いコンポーネントで表現することがほとんどです。「CRM」や「ERP」といったものです。
これだけでは実現可能性が分かりませんから、実際には具体的なシステムの構成を想定して、それらの組み合わせの実績や実現性を考慮してアーキテクチャを構成します。抽象と具象を何度も行き来することで、抽象度の高いアーキテクチャでも実現性を担保できるように設計することが重要です。

データの配置についても同様の考え方になります。
アーキテクチャとしては「顧客情報」「契約情報」といった単位でまとめて表現することになりますが、それらは実際には正規化されて実装されます。
Salesforce で実現する場合には、取引先や取引先責任者といった具体的なオブジェクトとその構造を理解した上で、実装可能なデータの配置や大量データの取扱などを考慮してデータの置き場所を決定します。

要件定義の考慮点

ご質問
要件定義で考慮すべき点はなんですか

しょっさんの回答サマリ
Salesforce で要件定義を行う場合には、標準機能と開発を 8対2 になるようにコントロールすることが重要です。利用者の要求をそのまま定義するのではなく、Salesforce などサービスが提供する標準機能で実現できるような要件へとシフトしていって、開発する余地を削減することが重要です。

あまりにも開発に寄せすぎてしまうことで、Salesforce の良さが失われると共に保守にも工数を多く割くことになります。
ですから要件定義を行うビジネスアーキテクト、アナリストとしても Salesforce の標準機能を抑えて要件定義局面を迎えられなければなりません。

要件定義に関しては、過去にめっちゃヒットしたコンテンツがあるのでこちらもどうぞ。

開発者の立ち位置

ご質問
アドミンと開発者で考えたとき、Salesforce において開発者の立ち位置がよく分からない。

しょっさんの回答サマリ
アプリケーションを開発していくプロセスや複雑な処理の実現など、開発者でなければ分からないことはまだ多いでしょう。
アドミンの方にも開発してもらうことになったとしても、開発のガバナンスを統制したり、テストやリリースのアプローチは開発者が示してあげるべきです。

フローで開発すると言うことになっても、すべてをフローで実装するとなると規模が大きくなると画面では手一杯になり、より複雑になることもあります。特定の汎用的な部品を Apex で開発しておいて、フローから呼び出すような構成を取ることで部品の再利用性を高めたり、視認性を高めたりすることもできます。

開発者はアドミンを支援できるように DevOps Center を利用したり、GitHub との連携をおこなってバージョンコントロールをしたり、開発者だからこそ提供できるプレゼンスもあると考えています。

あれも話してたよねってことがあれば教えてください 🙇🏻