失敗しないための

エンタープライズ開発のきほん

自己紹介

川元 繁幸（Shigeyuki Kawamoto）＜略歴＞Webプログラマ⇒ サーバエンジニア⇒ ネットワークエンジニア⇒ セキュリティエンジニア⇒ 仮想化エンジニア⇒ Salesforceエンジニア⇒ R&D Researcher (in Silicon Valley)⇒ 海外子会社経営管理者 (Degree Obtained: MBA)⇒ テクニカルアーキテクト

Agenda・Salesforceによるエンタープライズ開発とは

1.システム更改-そもそものシステム更改の難しさ

2.パッケージ製品-パッケージ製品を利用するという前提の理解

3.Salesforceプラットフォーム-エンタープライズ開発の特徴-エンタープライズ開発の特徴から発生する問題①大量データボリュームへの対応策②データ連携処理の負荷への対応策③権限コントロールへの対応策④開発パフォーマンス向上の対応策⑤リソース管理の対応策⑥リソース保全の対応策

・まとめ

Salesforceによるエンタープライズ開発とは

１ システム更改

２ パッケージ製品

３ Salesforceプラットフォーム

Salesforceによるエンタープライズ開発としてよくあるパターンは、既存システムをシステム更改するプラットフォームとしてSalesforceを使うというパターン。

このパターンを構成する重要要素は以下の３つ。

1.システム更改そもそものシステム更改の難しさ

• アーキテクチャが違えば同じ機能の実装が難しくなることを念頭に置くべき。

• 「現行の要件定義書をもとに新規システム構築」するのではなく、本来はビジネスプロセス改善から始まるべき。

• そのため、システム老朽化やコスト削減ではなく明確な目的を持った戦略投資としてのシステム更改を目指すべき。[参考資料：システム再構築を成功に導くユーザガイド(IPA)]

https://www.ipa.go.jp/files/000057294.pdf

＜再構築手法の分類＞ ＜再構築でのパッケージ製品利用時のタスク類＞

2.パッケージ製品パッケージ製品を利用するという前提の理解

パッケージ製品を使う理由は「パッケージ製品の標準機能を使う」ためである。これにより開発期間とコストを削減することができる。SaaSの場合はさらにバージョンアップによるベネフィットを受けることが出来る。

しかし、既存システムと同様の機能全てがパッケージ製品に含まれていることはまずない。そのため、ビジネスプロセス改善から入り業務をなるべくパッケージ製品に合わせるアプローチを取るべき。

Configure Extend Enhance Replace

Configuration

Customization

ポイント＆クリック設定

（業務ロジックなし）

既存機能増強開発 新規機能拡張開発 既存機能置換開発

※カスタムの比率が高いのであればSalesforce

プラットフォームよりもHerokuプラットフォームの方が適している場合もある。

3.Salesforceプラットフォームエンタープライズ開発の特徴

# 開発影響要素 スタートアップ開発 エンタープライズ開発 エンタープライズ開発の特徴

① 既存システム 少ない 多い データ量が大量

② 連携システム 少ない 多い データ連携処理の負荷が高い

③ セキュリティ 合理的判断 重要 緻密なデータセキュリティが必要

④ 有識者 相対的に多い 相対的に少ない 労働集約型の開発になりがち

⑤ ステークホルダー 少ない 多い プロジェクトとベンダーが多い

⑥ システム規模 小さい 大きい 多量のシステムリソースが必要

「1.システム更改」と「2.パッケージ製品」において”あるべき論”を述べたが、実際の開発では「要件は現行踏襲」、「Salesforceの標準機能を利用したいが業務に合わないためカスタム開発」となる傾向があり、システム開発の難易度も比例して高くなる。しかし、Salesforceプラットフォームにおけるエンタープライズ開発の特徴を理解することで難易度を緩和し、システム開発の”失敗”を回避することが出来ると考えている。

※エンタープライズ開発の特徴を浮き彫りにするために、その対比としてスタートアップ開発を用いている。

3.Salesforceプラットフォームエンタープライズ開発の特徴から発生する問題

特徴から発生する問題

①大量データボリュームによる著しい性能劣化が発生する

②データ連携処理の負荷が高くてバッチウィンドウに収まらない

③データセキュリティとしての権限コントロールが複雑化

④思ったように開発が進まない。追加開発が発生してしまう

⑤同じような項目や設定がいくつも出来てしまう

⑥Salesforce上のリソースを使い切って何も出来なくなってしまう

エンタープライズ開発の特徴

①データ量が大量

②データ連携処理の負荷が高い

③緻密なデータセキュリティが必要

④労働集約型の開発になりがち

⑤プロジェクトとベンダーが多い

⑥多量のシステムリソースが必要

非機能面

機能面

3.Salesforceプラットフォーム①大量データボリュームへの対応策 (1/2)

しかし、少なくとも2018年の弊社の実績として、これらの対策を行っても1オブジェクトに7000万～8000万レコードを格納するとリストビュー、レポートといった機能の性能が著しく劣化したという事例もある。

オブジェクトへの対策

・カスタムインデックス・スキニーテーブル

レコードモデルへの対策

・取引先データスキューの回避・所有者スキューの回避・参照スキューの回避

大量データボリュームへの対応策として以下の方法がある。

3.Salesforceプラットフォーム①大量データボリュームへの対応策 (2/2)

Salesforce標準設定のみでは対応できないが、Salesforce標準設定以外で大量データボリュームに対応することができる。

# 利用技術 必要施策 検討事項

1 ビッグオブジェクト • カスタム開発 • 標準オブジェクトに関するSalesforce標準機能が利用できない

2 外部オブジェクト • カスタム開発 • 標準オブジェクトに関するSalesforce標準機能が利用できない

• 外部オブジェクトデータの取得中にコールアウト制限に達する可能性がある

3 マルチオルグ • Mulesoft導入• Platform Event

ライセンス追加

• オルグ間の双方向のデータ同期は要注意• 添付ファイルはAPIによる同期が必要• 他もろもろ現在進行系で研究中

3.Salesforceプラットフォーム②データ連携処理の負荷への対応策 (1/2)

データ連携処理の負荷が高くなる要因は以下の通り。

これらの処理制限はガバナ制限やプラットフォームの仕様によるものであり、現時点のSalesforceでは拡張や変更をすることが出来ない。

オブジェクト更新処理による要因

・オブジェクトのデータ処理スピード⇒Account、Userオブジェクトなどが遅い・データセキュリティ設定による性能劣化⇒ロールなども処理スピードに影響する・バッチによるデータ処理数制限⇒Bulk APIのガバナ制限最大１億件/24時間

バッチ処理の仕様による要因

・Bulk APIはSalesforceへCSVファイル転送後、

逐次バッチ処理されるため、インターネット回線の影響は最初のアップロード処理のみ・Salesforceのバッチ処理の実行タイミングは

確約されていないため、余裕を持ったバッチウィンドウにする必要あり

※大量データが格納されているオブジェクトに対する更新処理速度はさらに遅くなる※SOAP APIによる更新も可能だが処理速度は遅い

※Apexバッチがある場合はBulk APIと同じジョブ数を

消費するため、ガバナ制限により両方の機能が利用できなくなるリスクあり。

3.Salesforceプラットフォーム②データ連携処理の負荷への対応策 (2/2)

オブジェクトに関する設計の対応策

・バッチ処理時はトリガーが動作しないように設計する・ロール階層をなるべく少なくする

業務・運用設計による対応策

・翌営業日以降でのデータ反映を許容する・営業時間内でのオブジェクト更新を許容する

Salesforceプラットフォーム外による対応策

・外部オブジェクトの利用（例：Heroku Postgresはスケールアップ・アウトが可能）・マルチオルグによる分散（例：Mulesoftによる連携等）

データ連携処理の負荷が高くなる要因への対応策は以下の通り。

3.Salesforceプラットフォーム③権限コントロールへの対応策 (1/2)

プロファイル / 権限セット

組織の共有設定 共有ルール 共有オブジェクト

Salesforceベース共有設定

共有セット

コミュニティ共有設定 直接共有設定

オブジェクト・項目レベルセキュリティ

レコードレベルセキュリティ

＜所有者/キューベース＞• 公開(参照/更新)• 公開(参照のみ)• 非公開• 親レコードに連動• ロール※暗黙的な共有

＜所有者/条件(固定値)ベース＞• キュー• ロール• 公開グループ

＜プロファイル/オブジェクトベース＞• 取引先や取引先責任者に関連付けられているレコードにアクセス(コミュニティのみ利⽤可能)

＜オブジェクトベース＞• ユーザ• 公開グループ

ベースとしてプロファイル/権限セットによるオブジェクトや項目レベルセキュリティがあり、それを前提にレコードレベルでの各種設定を実施する。レコードレベルでのセキュリティ設定は、一旦範囲を狭めて徐々に広げていく考え方で設計する。

しかし、以下のような権限コントロールを求められた場合、複雑な権限設定となる可能性が高い。

兼務ユーザ 子レコードの状態から親レコードの権限制御 個別例外設定

3.Salesforceプラットフォーム③権限コントロールへの対応策 (2/2)大量データボリュームを扱う場合、権限コントロールはパフォーマンスに影響を与えるため、権

限コントロールの仕様と制約を理解し、極力シンプルな設定にすることが望ましい。# 制御方法 対応種別 レベル 適用対象 適用範囲 制約事項等

１ 組織の共有設定 設定

非公開 全レコード レコードの所有者と階層内でそのロールの上位にあるユーザのみ参照・編集 -

公開/参照のみ 全レコード • すべてのユーザは参照可能• 所有者と同階層の上位ロールユーザは編集可能 -

公開/参照・更新可能 全レコード すべてのユーザは参照・編集可能 -親レコードに連動 子レコード 親レコードのアクセス制御に依存 -

ロール 全レコード 上位ロールは常に下位ロールと同じレコードへのアクセス権 コミュニティにはロール数の制限がある

２ 共有ルール 設定所有者

• チャネルプログラム• ポータルロール(下位ロール)• ロール(内部下位、ポータル)• 公開グループ

• チャネルプログラム• ポータルロール(下位ロール)• ロール(内部下位、ポータル)• 公開グループ

-

条件 項目値の条件に該当 数式項目利⽤不可

３ 共有セット 設定 条件ログインユーザのAccount、Contact、Managerオブジェクトに含まれるAccount、Contactへのリレーション項目を指定

適⽤対象で指定した項目値とレコードに含まれるAccount、Contactのリレーション項目値が一致したレコードが参照・編集可能

• コミュニティのみ利⽤可能• 対象オブジェクトの共有設定を「公開/参照・更新可能」以外にする必要がある

• 対象オブジェクトに取引先または取引先責任者の参照項目を持つ必要がある

• 付与されたアクセス権はロール階層で上位のユーザには適⽤されない

４ 共有オブジェクト 開発 個別手動 共有対象

• チャネルプログラム• ポータルロール(下位ロール)• ロール(内部下位、ポータル)• 公開グループ• ユーザ

• Lightningでは手動共有が利⽤できない• Triggerを開発する必要がある

※プロファイルは最小限の設定を行い、権限セットで権限コントロールを行うことで複数のSalesforceアプリへの対応がやりやすくなる。

3.Salesforceプラットフォーム④開発パフォーマンス向上の対応策 (1/2)開発パフォーマンスが著しくない場合、以下の要因が考えられる。

Salesforceプラットフォームに対する理解の浸透不足

・Apex/Object/SOQLはJava/RDB/SQLに似ているが違うものと認識すること⇒Salesforceはオブジェクトが中核となるプラットフォームであり、正規化レベルを意識すること。・Salesforceの開発はガバナ制限との戦いであることを理解すること⇒構成はシンプルに、影響範囲は最小限に。特にトリガー周りの設計・開発には要注意。

開発環境の準備不足

・ネットワーク回線速度と開発PC性能⇒Salesforceはクラウドプラットフォームのためネットワーク回線速度が開発パフォーマンスに影響。

・セールスフォース・ドットコム社への問い合わせ方法の整備

⇒本番環境からのみ問い合わせ可能なため、問い合わせ方法の整備が必要。

不円滑なコミュニケーション

・チャットツールやファイル共有ツールの導入⇒QuipやSlackなどによりメールからの脱却。・アジャイル開発の導入

⇒「オンサイト顧客」と「タイムボックス」が重要。この２つが出来ない場合は超短期ウォーターフォール開発になるため要注意。

有識者のパフォーマンスを最大化し、チームメンバーへノウハウを効率よく伝搬させることが重要。

3.Salesforceプラットフォーム④開発パフォーマンス向上の対応策 (2/2)

Apex

データアクセス層ビジネスロジック層プレゼンテーション層

Visualforce(Page/Component)

LightningComponents(Aura/LWC)

Controllerクラス

Testクラス

Daoクラス(Controllerクラス⽤)

*Staticメソッド

Utilsクラス*Staticメソッド

オブジェクト（標準/カスタム）

Apexトリガー

個別クラス

TestDataFactoryクラス

共通クラスDaoクラス(共通⽤)*Staticメソッド

BizLogicクラス(Controllerクラス⽤)

*Staticメソッド

TgrHdlクラス*Staticメソッド

凡例

View

Controller

Model

クラス種別

参照

BatchクラスBatchSchedクラスApexスケジューラ

BizLogicクラス(TgrHdlクラス⽤)*Staticメソッド

Daoクラス(TgrHdlクラス⽤)*Staticメソッド

Daoクラス(Batchクラス⽤)*Staticメソッド

イベント起点

事前にプログラム開発関連コンポーネント相関図などの開発標準書を作成し、共通認識を作っておくこと。

オブジェクトやトリガーの構成によってはループ処理が発生するため注意すること。

標準オブジェクトに対するトリガーは多くなる傾向にあるため、特に注意すること。

3.Salesforceプラットフォーム⑤リソース管理の対応策 (1/2)リソース管理が上手く出来ていない場合、以下の要因と対応策が考えられる。

Salesforceプロジェクトの管理体制による要因

・同時並行で進行しているプロジェクト・複数のSalesforceアプリケーション開発・マルチベンダーの参入⇒随所でリソースが乱立し消費されている状態

Salesforceプラットフォームの開発体制の整備

・開発標準書の策定・Salesforce CoEによる情報集積とレビュー・CI/CDの適用⇒計画的にリソースを消費し管理できる状態にする

開発標準書は最低でも命名規約を策定し、リリース前にCoEにてレビューすることが望ましい。全てのリソースに3文字程度のPrefixコードを付与し、リソース管理することが最低限必要。

3.Salesforceプラットフォーム⑤リソース管理の対応策 (2/2)

Salesforceの全社最大活用を推進するSalesforce CoE（Center of Excellence）の設置が重要。

Cloud ApplicationsGovernance

Value Creation Office Service Operations

Cloud Applications ArchitectureApplication Architecture

Business Architecture

Appl

icat

ion

Hub Program

DeliveryContinuous

Improvement Team

Applications Maintenance &

Support

全社プラットフォームとしてのSalesforce活⽤戦略策定

スピーディーな機能展開

ビジネス効果創出のための継続的な変革推進

“小さく始めて大きく育てる”攻めの保守・運⽤

業務・IT一体となったプロセス/機能構築

クラウド利⽤におけるセキュリティ

/リスクガバナンス

3.Salesforceプラットフォーム⑥リソース保全の対応策リソース保全が上手く出来ていない場合、オンプレミス環境と同じ感覚で開発・運用を行ってい

ることが要因として考えられる。

Salesforceプラットフォームはエディションにより差はあるが、ハードリミットやガバナ制限があり、オンプレミスの開発と同じ感覚で開発を進めるとリソースを使い切ってしまう場合がある。オンプレミスの開発では5年毎のハード保守期限切れでシステム更改によりシステムのスクラッ

プ＆ビルドが出来るが、クラウド化により同じプラットフォームを使い続けることになる。そのため、定期的にリファクタリングを行い、リソース保全を行うことが重要になる。

オンプレミス環境

・ハード保守期限切れによるシステム更改・スケールアップによるリソース追加・１オンプレミス環境＝１アプリ

Salesforceプラットフォーム

・Salesforceプラットフォームを使い続ける・ハードリミットやガバナ制限がある・１Salesforceプラットフォーム＝複数アプリ

まとめ

①大量データボリュームへの対応策

・標準設定内：オブジェクト、レコードモデル

・標準設定外：ビッグオブジェクト、外部オブジェクト、マルチオルグ⇒1オブジェクトに数千万レコード以上を格納する場合はSalesforce標準設定外による対応を検討。

④開発パフォーマンス向上の対応策

・Salesforceプラットフォームに対する理解の浸透・開発環境の準備・円滑なコミュニケーション

⇒有識者のパフォーマンスを最大化し、チームメンバーへノウハウを効率よく伝搬させることが重要。

②データ連携処理の負荷への対応策

・オブジェクト関連設計：トリガー、ロールの最適化・業務・運用設計：データ更新タイミングの緩和・Salesforceプラットフォーム外での対応

⇒ガバナ制限やプラットフォームの仕様は拡張や変更が出来ない点に注意。

③権限コントロールへの対応策

・オブジェクト・項目レベルセキュリティ・レコードレベルセキュリティ

⇒標準設定出来ない権限コントロールの場合は複雑な権限設定となる可能性が高い。

⑤リソース管理の対応策

・開発標準書の策定・Salesforce CoEによる情報集積とレビュー・CI/CDの適用⇒計画的にリソースを消費し管理できる状態にする。

⑥リソース保全の対応策

・Salesforceプラットフォームを使い続ける・ハードリミットやガバナ制限がある・１Salesforceプラットフォーム＝複数アプリ

⇒定期的にリファクタリングを行い、リソース保全を行うことが重要になる。

非機能面

機能面

ご清聴ありがとうございました