> For the complete documentation index, see [llms.txt](https://support.bridge-funeral.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.bridge-funeral.com/kai-fa-kuo-zhang/30-clicks-before-code.md).

# ノーコード / ローコード開発｜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 。標準項目の編集は不可。

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

### 入力規則

データの整合性チェック。詳しくは [入力規則とエラーメッセージ](/salesforce-ji-chu/12-validation-rules.md) を参照。

### 数式項目 (Formula Field)

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

例:

* `税抜小計 × 税率 = 税額`
* `生年月日 → 年齢`
* `葬儀日 - 死亡日 = 経過日数`

```
TODAY() - DeathDate__c
```

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

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

例:

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

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

## ③ フロー (Flow) ★主役

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

### 3 種類のフロー

| 種類             | 起動タイミング        |
| -------------- | -------------- |
| **画面フロー**      | ユーザーがボタンを押したとき |
| **レコードトリガフロー** | レコードが保存されたとき   |
| **自動起動フロー**    | 別の処理から呼ばれて動く   |

詳しくは Backlog 設計資料: 05. 自動フロー (パッケージ提供元の社内資料) を参照。

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

| フロー名                         | 用途                |
| ---------------------------- | ----------------- |
| `CreateBillingDocument`      | 見積→請求伝票を作成        |
| `CreateDeceased`             | 施行情報からおくやみ情報を自動生成 |
| `UpdateBillingSummaryToatal` | 請求金額の自動集計         |

[一般ユーザー向け 14-auto-processing.md](/nori/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 一覧

Backlog 設計資料: 04. 自動処理 (Apex) (パッケージ提供元の社内資料) を参照。

主要クラス:

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

### Apex の注意

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

## ⑤ Lightning Web Component (LWC) ★UI 部品

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

### いつ LWC を使うべきか

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

### ブリッジ葬儀の LWC 一覧

詳しくは Backlog 設計資料: 06. Lightning Web Components (パッケージ提供元の社内資料) を参照。

主要 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](/kai-fa-kuo-zhang/31-trailhead.md) を参照。

## 次に進む

* [Trailhead (無料学習)](/kai-fa-kuo-zhang/31-trailhead.md)
* [システム拡張・外部連携](/kai-fa-kuo-zhang/40-integrations.md)
* 一般: [裏で自動で動く処理を知る](/nori/14-auto-processing.md)

***

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://support.bridge-funeral.com/kai-fa-kuo-zhang/30-clicks-before-code.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.