ブリッジ葬儀サイトへ戻る

開発・拡張

ノーコード / ローコード開発｜Clicks before Code の考え方

「業務改善のためにシステムを変えたい」 — Salesforce ではその実現手段として コードを書かない (ノーコード) から コードで作り込む (プロコード) まで、複数のレイヤーがあります。Salesforce 公式の指針 「Clicks before Code」 の考え方と、各手段の使い分けを整理します。

「Clicks before Code」とは

Salesforce 公式の開発哲学:

コードを書く前に、まず画面操作 (Clicks) で実現できないか考えよう

理由:

  1. メンテナンス性: コードは書いた人しか直せない。Clicks はビジネス担当でも触れる
  2. アップグレード追従: 設定ベースは Salesforce のアップデートに自動追従
  3. 検証コストが低い: コード変更には Apex テストが必要だが、設定は基本テスト不要
  4. 障害リスクが低い: 致命的バグの可能性が低い

5 つの実現手段 (易→難)

手段

種類

できること

設定

ノーコード

項目追加・レコードタイプ・ページレイアウト

入力規則・数式項目

ノーコード

値検証・自動計算

フロー (Flow)

ローコード

業務フローの自動化・画面付き処理

Apex

プロコード

複雑なビジネスロジック・トリガ

Lightning Web Component (LWC)

プロコード

カスタム UI 部品

① 設定 (基本のノーコード)

Setup → オブジェクトマネージャ 以下で実現できる範囲。

カスタマイズ

例

カスタム項目の追加

お客様に「来店経路」を追加

値リスト追加

宗派 Picklist に新しい宗派を追加 / Picklist 全般の選択肢追加

ページレイアウト変更

伝票画面の項目並び順

レコードタイプ追加

取引先タイプ「寺社」を追加

タブ表示制御

プロファイル別のタブ表示

ホームページのレイアウト

App Builder で配置変更

ブリッジ葬儀標準オブジェクトへの 項目追加 は OK 。標準項目の編集は不可。

② 入力規則・数式項目 (簡易ロジック)

入力規則

データの整合性チェック。詳しくは 入力規則とエラーメッセージ を参照。

数式項目 (Formula Field)

他の項目の値から 計算結果を自動表示 する項目。データは保存されず、毎回計算。

例:

  • 税抜小計 × 税率 = 税額
  • 生年月日 → 年齢
  • 葬儀日 - 死亡日 = 経過日数
TODAY() - DeathDate__c

ロールアップ集計 (Roll-Up Summary)

子レコードの集計値を親に表示 (主従関係限定)。

例:

  • 伝票の 税込合計 = 伝票明細の金額合計

ロールアップ集計は 再計算がリアルタイム 。常に最新値が見える。

③ フロー (Flow) ★主役

Salesforce の 業務自動化 ツール。コード不要で複雑な処理が組めます。

3 種類のフロー

種類

起動タイミング

画面フロー

ユーザーがボタンを押したとき

レコードトリガフロー

レコードが保存されたとき

自動起動フロー

別の処理から呼ばれて動く

ブリッジ葬儀のフロー一覧 (例)

フロー名

用途

CreateBillingDocument

見積→請求伝票を作成

CreateDeceased

施行情報からおくやみ情報を自動生成

UpdateBillingSummaryToatal

請求金額の自動集計

一般ユーザー向け 14-auto-processing.md でフロー全体を解説。

フローの作成

Setup → プロセス自動化 → フロー → 新規フロー

ビジュアルエディタで:

  1. 起動条件・トリガを設定
  2. 要素 (Action / Decision / Loop) を配置
  3. データを取得・更新・作成
  4. 保存・有効化

フローの利点

  • ビジュアルで分かりやすい
  • 修正・拡張が容易
  • 業務寄りの担当者でも編集可能
  • Apex に比べてアップグレード耐性が高い

フローの限界

  • ループ内の大量処理はパフォーマンス低下
  • 複雑すぎる条件分岐は管理しづらい
  • 「画面付きの自動処理」は便利だが UI 制約あり

④ Apex (プロコード)

Salesforce 上で動くサーバーサイドプログラミング言語 (Java に似た構文)。

いつ Apex を使うべきか

  • 複雑なビジネスロジック: フローで実現すると条件分岐が爆発する
  • 大量データ処理: バッチ処理 (10 万件以上の集計など)
  • 外部 API 呼び出し: REST / SOAP 連携
  • 複雑な計算: 税額・割引の高精度処理 (ブリッジ葬儀の SlipAmountCalculationService 等)
  • トリガ: レコード保存時の複雑な制御

Apex の構造

種類

用途

Apex Class

ロジックの実装

Apex Trigger

レコード保存時の自動実行

Test Class

必須のテストコード (本番組織で 75% 以上のカバレッジ要件)

Batch Apex

大量データの分割処理

Queueable Apex

非同期処理

ブリッジ葬儀の Apex 一覧

主要クラス:

  • SlipAmountCalculationService (税額計算)
  • SlipDetailController (伝票明細管理)
  • SlipPdfController (PDF データ取得)
  • BridgePostInstallHandler (インストール時の初期化)

Apex の注意

  • テストコード必須 (75% 以上のカバレッジで本番デプロイ可)
  • ガバナ制限 (1 トランザクション 100 SOQL クエリまで等)
  • 開発者の確保・教育が必要

⑤ Lightning Web Component (LWC) ★UI 部品

Salesforce 推奨の モダンな UI フレームワーク 。Web Components 標準ベース。

いつ LWC を使うべきか

  • 標準画面で実現できない カスタム UI が必要
  • 複雑なインタラクション (Excel ライクなエディタ等)
  • ユーザー体験を最適化したい

ブリッジ葬儀の LWC 一覧

主要 LWC:

  • slipDetailEditor (伝票エディタ)
  • productSearchModal (商品検索モーダル)
  • slipPdfPrint (伝票 PDF 出力)
  • ceremonyPdfPrint (施行情報 PDF 出力)
  • ceremonyScheduleEditor (葬儀日程エディタ)
  • cardView (ホーム画面カードビュー)
  • issuerSelector / issuerManagerModal (発行元管理)

LWC vs Aura vs Visualforce

技術

状態

採用方針

LWC

Salesforce 推奨の現行

新規開発はすべて LWC

Aura Components

メンテナンスモード

レガシー扱い

Visualforce

メンテナンスモード

レガシー扱い

ブリッジ葬儀は LWC のみ で実装。Aura / Visualforce は不使用。

Visualforce (補足)

Salesforce 旧時代の UI 技術。HTML 内に Apex タグを埋め込む方式。

  • メンテナンスモード: Salesforce による新機能投入なし
  • 既存組織で残っている 場合は引き続き動く
  • 新規開発では LWC を推奨

使い分けマトリクス

やりたいこと

推奨手段

項目追加

設定

値の自動計算

数式項目

入力時の値検証

入力規則

子→親の集計

ロールアップ集計

ボタンで処理実行

画面フロー

保存時の自動連動

レコードトリガフロー

複雑な計算・大量データ

Apex

外部 API 連携

Apex (REST callout)

標準にないカスタム UI

LWC

業務改善のアプローチ

新しい業務要件を受けたら、上から順に検討:

1. 設定だけで対応可能か? → Yes なら設定
2. 数式項目・入力規則で済むか? → Yes ならそれら
3. フローで自動化できるか? → Yes ならフロー
4. やっぱり Apex が必要 → Apex
5. UI のカスタマイズが必要 → LWC + Apex

こんなときは

開発者がいない組織での進め方

  • 設定・数式項目・フローまでで戦う
  • それを超える要件は外部開発者に依頼 or 諦め

フローと Apex どちらを選ぶか迷う

判断軸

フロー

Apex

担当者が業務寄り

◯

✗

大量データ

✗

◯

外部 API

✗

◯

複雑な条件分岐

△

◯

維持コスト

低

高

目安: 「フロー要素 30 個以下で表現できれば フロー、それを超えたら Apex」

パッケージのフロー / Apex を変えたい

→ 直接編集できません。追加カスタマイズで上書き する方針も推奨できない (アップグレード時に衝突)。組織独自の処理として並列で追加するのが基本。

Trailhead で学ぶ

Clicks before Code の各手段を体系的に学べる無料学習サイト → Trailhead を参照。

次に進む

📅 最終更新日: 2026-06-16