Salesforce導入案件では、要件定義工程で非機能の検討を行う際に、必要となるストレージ容量の算出を行うことが多いと思います。

移行データのボリュームや将来的なデータの増加見込みを考慮して試算を行いますが、毎回エクセルとかで数式を作成して計算している方も多いと思います。

毎回エクセルファイルを作成してというのも面倒なので、簡単にストレージの計算が行えるようにWEBのシミュレーター機能を作成してみました。

サポーターさん

生成AIを使って数分で作成したものですが、意外としっかりしていてファイル出力やクリップボードへのコピーもできます。

今回は、このツールの機能や使い方を簡単に説明していきたいと思います。

ツールはこちらのページにて利用可能となっております。

Salesforceストレージ容量シミュレーターの仕様について

本シミュレーターでは、以下の機能を実装しています。

ツールの利用方法

基本操作

ストレージ容量試算画面を開くと以下の画面が表示されます。デフォルトでは、Accountなどのオブジェクト3つのレコードを初期表示しています。

上部は、試算のための入力フィールドが表示されます。

オブジェクトの追加と削除

オブジェクトを追加ボタン：クリックすると以下のように1行レコードが追加されます。

レコードの一番右の列にある削除ボタンをクリックすると明細レコードが削除されます。

容量計算

オブジェクト名を入力後、以下の項目を入力することで自動的に計算が行われます。

1. ユーザ数：オブジェクトを利用するユーザ数を入力します。
2. 月間レコード登録数/ユーザー：1ユーザ当たりの月間の登録レコード数を入力します。
3. 保存期間（年）：レコードの保存期間を年単位で入力します。
4. 成長率（%/年）：年間当たりのレコードの成長率（増加率）を入力します。

上記の項目はそれぞれ値を変更する度に都度計算が行われ、画面下部に計算結果が表示されます。

シミュレーション結果の表示

ストレージ使用量のサマリーとして以下の内容が自動計算されて表示されます。

①総レコード数：画面上部で入力した各オブジェクト毎のユーザ数ｘ月間レコード登録数ｘ12カ月ｘ保存期間ｘ成長率で計算したレコードの総数を表示

②総ストレージ使用量：①総レコード数ｘ2KBの結果をGB換算して表示

③月間増加量：月あたりのストレージの増加容量を表示

④年間増加量：年間あたりのストレージの増加容量を表示

CSVファイル出力

計算した結果をCSV形式やTSV形式で出力することができます。

CSV形式で出力した場合

CSV形式で出力したファイルをエクセルで開くと以下のように表示されます。

TSVファイルで出力した場合

TSV（タブ区切りファイル）の場合は、以下のように表示されます。

クリップボードへコピーする

クリップボードへコピーするを実行するとクリップボード内に以下の内容がコピーされます。

Salesforce ストレージ容量試算結果
=================================

出力日時: 2025/6/19 23:37:29

【サマリー】
総レコード数: 2,079,899
総ストレージ使用量: 3.967 GB
月間増加量: 0.0751 GB
年間増加量: 0.901 GB

【詳細結果】
Account:
– ユーザー数: 150
– 月間レコード登録数/ユーザー: 200
– 保存期間: 5年
– 成長率: 5%/年
– 累積レコード数: 1,989,227
– ストレージ使用量: 3.794 GB
– 月間増加量: 0.0696 GB
– 構成比: 95.6%

Contact:
– ユーザー数: 100
– 月間レコード登録数/ユーザー: 20
– 保存期間: 3年
– 成長率: 10%/年
– 累積レコード数: 79,440
– ストレージ使用量: 0.152 GB
– 月間増加量: 0.0046 GB
– 構成比: 3.8%

Opportunity:
– ユーザー数: 30
– 月間レコード登録数/ユーザー: 15
– 保存期間: 2年
– 成長率: 8%/年
– 累積レコード数: 11,232
– ストレージ使用量: 0.021 GB
– 月間増加量: 0.0009 GB
– 構成比: 0.5%

まとめ

いかがでしたでしょうか。使い方は非表示シンプルで分かりやすいと思います。

もし、利用にあたって仕様を変更したいなどご要望がございましたらお問い合わせフォームからご連絡ください。

ツールのURLを再度掲載しておきます。

Apexの処理設計書については、以下の記事よりダウンロードください。

参考

Apexトリガー処理設計書（Excelテンプレート）

Apexトリガーの処理設計書（基本設計書/詳細設計書）として利用できるエクセルの…

続きを読む

Apex Trigger一覧のサンプル

１．表紙（メッセージ定義書）

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

３．Apexトリガー一覧

【記載内容】

• 機能ID：システム機能一覧より割り当てた機能IDを記入します。
• トリガー名：トリガー名（論理名）を記入します。
• API参照名：トリガーの物理名を記入します。
• トリガー起動オブジェクト：トリガーを実行するオブジェクトを記入します。
• 処理No.：トリガーに複数の機能（処理）が分かれている場合に処理毎にNo.を割り当てます。
• 処理内容：処理の概要を記入します。
• 起動契機：トリガー内の各処理が実行される契機（before  insert / before update / before delete / after insert / after update / after delete / after undelete）を〇-で定義します。
• 備考：メモ欄としてご利用ください

Apexトリガー一覧の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

エクセルのダウンロードはこちら

圧縮ファイル（ZIP形式）でのダウンロードはこちら

以下は、スプレッドシートでの表示となります。

関連記事

他にも要件定義で必要となる以下のようなテンプレートなども用意しているのでぜひご利用ください。

バッチ処理設計書

バッチ処理設計書（Excelテンプレート）

バッチ処理設計書（基本設計書/詳細設計書）として利用できるエクセルの設計書テンプ…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

ジョブスケジュールのサンプル

バッチのジョブスケジュール表

主要項目

• サーバ：バッチを起動するサーバ環境
• 処理ID：バッチの処理ID
• バッチ処理名
• サイクル：日次、週次、月次などの処理サイクル
• タイミング：バッチ処理実行のタイミング
• 前提条件：バッチ実行の前提条件
• 開始時間：バッチ処理開始時間
• 終了時間：バッチ処理終了時間（予定時間）

テーラリングガイド

選択リスト値の定義

本テンプレートでは、バッチの処理サイクルを選択リスト値で設定し、名前の定義をしていますので、適宜変更してご利用ください。

バッチ処理一覧の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

エクセルのダウンロードはこちら

圧縮ファイル（ZIP形式）でのダウンロードはこちら

以下は、スプレッドシートでの表示となります。

関連記事

他にも要件定義で必要となる以下のようなテンプレートなども用意しているのでぜひご利用ください。

バッチ処理設計書

バッチ処理設計書（Excelテンプレート）

バッチ処理設計書（基本設計書/詳細設計書）として利用できるエクセルの設計書テンプ…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

運用保守のサービス内容を検討する際にご利用ください。

1.テーラリングガイド

１．表紙（メッセージ定義書）

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．サービスカタログ（テンプレート）

サービスカタログの内容を定義するためのシートとなります。

【項目説明】

• サービス名称：サービス名称を定義（総称）
• サービス項目（詳細）：サービス名称について具体的なサービス項目（内容）を定義
• サービス提供内容：具体的な作業内容を定義
• 重要度：業務停止に係るような作業内容であればそのリスクを定義
• 提供時間：サービスの提供時間を定義
• サービス提供方法：メールやウェブサイトによる受付や、コールセンターを配置しての電話対応などを定義
• サービスレベル：MTBF、MTTR、MTTF、MTTA: インシデント指標を定義（※１）
• ※1.MTBF (平均故障間隔)、MTTR (復旧、修復、対応、解決までの平均時間)、MTTF (平均故障時間)、MTTA (平均確認時間) 
• 実施手順：具体的な作業実施手順や実施手順を記載したマニュアルの名称を定義
• 前提条件/制約事項：サービス提供のための前提条件や対応の制約事項など
• サービス提供担当：報告先、対応者（担当者）、責任者などを定義

4．サービスカタログ（サンプル）

サービスカタログのサンプル例を別シートに記載しています。

５．選択リスト

サービスカタログのシートで利用する選択リスト項目を定義します。

2.サービスカタログ（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

サービスカタログのダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか設計・開発に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

ユーザ教育用のトレーニングマテリアル作成の際にご利用ください。

1.テーラリングガイド

１．表紙（メッセージ定義書）

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

「ヘッダー」にはファイル名を「フッター」にはCopyright を設定しているので、プロジェクトに合わせて変更してください。

３．目次

マニュアルの目次を定義しています。目次はWordの見出しで自動的に挿入されます。

【目次例】

1. はじめに
2. 本書の目的
   1. 利用者
   2. 記号
      1. 本書で使用する記号についての説明
   3. 用語の定義
      1. 本書で使用する記号についての説明
3. システム概要
   1. 全体概要
   2. システム要件
      1. システム要件とサポートされるブラウザ
         1. ブラウザ要件
         2. モバイルおよびデスクトップ
4. ログイン~ログアウト
   1. システムへのログイン手順
      1. 本システムへのログイン手順
5. お問い合わせ先
   1. 本システムに関するお問い合わせ先

4．はじめに

本書の目的と利用する記号や用語についての定義を記載します。

【記載内容】

• • 本書の目的
  • 記号
  • 用語の定義

５．システム概要

システムの全体概要や構成について最初に説明します。

• 全体概要：システムの全体概要
• 全体構成図：システムの全体構成図を添付

６．システム要件

本システムを利用するために必要なシステム要件とサポートされるブラウザについて記載します。

【記載例】

1.1.4 ブラウザ要件
以下のブラウザのうち、最新リリースから２つ前のバージョンに対応しており、最高のエクスペリエンスを提供します。

• Google Chrome
• Safari
• Mozilla Firefox
• Microsoft Edge

1.1.5 モバイルおよびデスクトップ OS

• Mac: macOS 10.14 (Mojave) またはそれ以降
• Windows: Windows 7 またはそれ以降
• iOS: iOS 13 またはそれ以降
• Android: Android 5.0 (Lollipop) またはそれ以降

※最新の情報はセールスフォース公式サイトで確認するようにしましょう。

７．ログイン～ログアウト

ここからは、実際のシステム操作手順を記載していきます。

ログイン手順

本番とSandboxの接続先URLが異なるのでそれぞれ記載しておきましょう。※マイドメインのURLを記載してもよいです。

• 本番環境の場合：https://login.salesforce.com/
• Sandbox環境の場合：https://test.salesforce.com/

８．よくある質問

エラー発生時の対応やよくある質問に対する回答（対応方法）などを記載しておくことで、お問い合わせを減らすことができるのでマニュアルには記載しておくことをお勧めします。

９．お問い合わせ先

システム操作手順について記載が終わったら、最後にお問い合わせ先を記載しておきましょう。

2.システム操作マニュアル（Word版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

システム操作マニュアル（ワード版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか設計・開発に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

データベース設計や機能設計で利用するコード体系、コード値を定義する際にご利用ください。

1.テーラリングガイド

１．表紙（メッセージ定義書）

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

基本設計工程としていますが、プロジェクトの工程に合わせて適宜変更してご利用ください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．コード体系一覧

コード設計では、まずシステムで利用するコードの体系を整理します。コードは細かく分類すると複数の種類がありますが、ここではシンプルに2種類で分類しています。

主にプログラム等で自動採番する可変のコード値と、選択リストなどで定義する固定のコード値に分類しています。

コード定義する項目名とコード体系（コードを構成する要素の組み合わせ）を定義して、桁数や構成内容の細かい定義を説明しています。

【記載内容】

• 項目名：コード体系として定義する項目名（論理名）を定義します。
• コード体系：コードを構成する要素の組み合わせを定義します。
• 設定方式：自動採番か固定値かを定義します。
• 桁数：コードの最大桁数を定義します。
• 説明：コードの採番方式や構成要素に関する説明を記入します。
• 設定例：実際に定義されるコード値の設定例を記入します。
• 補足：コードに関する補足事項を記入します。

4．コード値定義

続いてのシートでは、具体的なコード値を定義していきます。コード値と説明（プログラムの制御やコードの意味を定義します。

【記載内容】

• • 項目名：コード名（論理名）を記入します。
  • 物理名（API参照名）：コードを選択リストなどで定義する場合のAPI参照名を記入します。
  • 設定場所：コード値を定義する場所を記入します。選択リストや選択リスト値セット（グローバル選択リスト）、プログラム内に固定など
  • コード値：コード体系で定義されているコード値を記入します。※ひとつのコード体系について複数の値がある場合は行を分けて記入します。
  • 説明（処理制御）：コード値のそれぞれの意味や処理制御で利用する場合の制御内容などを記入します。

４．コード利用状況一覧

コード体系とコード値の定義が完了したら最後にコード利用状況一覧を作成します

こちらでは、コードを利用する各機能/プログラムとの紐づけをマトリクス表に整理します。これを作成することにより、コード値を変更した場合にどの機能/プログラムに影響するか簡単に確認することができるようになります。（影響範囲の調査用）

• 機能ID：システム機能IDを記入します。
• 機能種別：機能の種類（画面、帳票、バッチ、APIなど）
• 機能名：システム機能名を記入します。
• プログラムID：プログラムIDを記入します。
• プログラム名：具体的なプログラム名（API参照名）を記入します。
• コード名：縦軸にはコード名を定義して、対象のコードが利用される機能に対して●をつけていきます。

2.コード設計書/コード定義書の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

設計_基本設計_コード設計書/コード定義書（EXCEL版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか設計・開発に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

設計工程で機能や処理で利用するオブジェクトやフィールドとの関連を定義する場合にご利用ください。

はじめに

1.CRUD図とは

CRUD図は、データベースやシステムの開発過程において使用されるモデリングツールです。CRUDとは、「Create（作成）」「Read（読み取り）」「Update（更新）」「Delete（削除）」の頭文字を取ったもので、データの基本的な操作を表しています。

CRUD図は、データベースやシステム内でどのようなデータ操作が行われるかを可視化するために使用されます。以下にCRUD図の要素とその役割について説明します。

1. エンティティ（Entity）: エンティティは、データベース内の特定のデータを表すものです。例えば、ユーザーや商品などがエンティティとして表されます。（※Salesforceではオブジェクトに該当します）

2. 属性（Attributes）: 属性は、エンティティが持つ特性やデータの要素を表します。例えば、ユーザーエンティティの属性には「名前」「メールアドレス」「パスワード」などが含まれます。※Salesforceでは、フィールドに該当します

3. 関連（Relationships）: 関連は、エンティティ間の接続や依存関係を示します。例えば、ユーザーエンティティと注文エンティティの間には「1対多の関係」があり、1つのユーザーが複数の注文を持つことができます。

4. 操作（Operations）: 操作は、CRUDの基本操作（作成、読み取り、更新、削除）を表します。それぞれの操作は、エンティティに対して行われるアクションを示します。例えば、ユーザーエンティティに対する操作として「新しいユーザーの作成」「ユーザー情報の読み取り」「ユーザー情報の更新」「ユーザーの削除」があります。

CRUD図の作成目的

1. データ操作の可視化: CRUD図は、データベースやシステム内で行われるデータ操作を視覚的に表現することで、開発者やステークホルダーにとって理解しやすくします。これにより、システムの要件やデータフローを明確にすることができます。
2. 設計の基盤: CRUD図は、データベースやシステムの設計の基盤となります。エンティティ、属性、関連などの要素を明確に定義することで、データベースのテーブル構造やシステムの機能を設計する際の指針となります。開発者やデータベース管理者は、CRUD図を参照してデータベースやシステムの設計や実装を行うことができます。
3. コミュニケーションとドキュメント化: CRUD図は、開発者やステークホルダーとのコミュニケーションツールとしても役立ちます。図によってデータ操作のフローを明確に示すことで、開発者間や関係者間での理解の共有が容易になります。また、CRUD図はプロジェクトのドキュメントとして使用され、後から開発やメンテナンスを行うためのリファレンスとなります。

データの整合性とセキュリティ: CRUD図は、データベースやシステム内のデータの整合性とセキュリティを確保するためにも役立ちます。

適切な関連性や操作の定義によって、データの整合性を保つことができます。また、CRUD図はアクセス権や機能制限の設計にも活用され、データのセキュリティを確保するための基礎となります。

1.テーラリングガイド

１．表紙（メッセージ定義書）

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

基本設計工程としていますが、プロジェクトの工程に合わせて適宜変更してご利用ください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．CRUDマトリクス表（機能ｘオブジェクト（エンティティ）レベル）

CRUDマトリクス表は、大きく2種類の粒度の設計書が存在します。1つ目は下記のようなエンティティ（オブジェクト）に対してのCRUDを定義するものとなります。

こちらは、各機能（またはプログラム）で、どのオブジェクトをどのような目的「Create（作成）」「Read（読み取り）」「Update（更新）」「Delete（削除）」で利用するかを定義した設計書となります。この資料を作成しておくことで、データベースに変更が入る場合に、どの機能/プログラムに影響があるのか簡単に確認することができます。

【記載内容】

• 機能ID：システム機能のIDを記入します。
• 機能種別：システム機能の種別（画面、バッチ、帳票、APIなど）を選択します。
• 機能名：システム機能の名称を記入します。
• プログラムID：プログラムのIDを記入します。
• プログラム名：具体的なプログラム名（物理名）を記入します。※1つの機能で複数のプログラムがある場合には全て羅列します。
• 業務領域：概念データモデルで定義したエンティティの纏めりを定義　（不要な場合は削除してもよい）
• エンティティ（オブジェクト）：システム全体のオブジェクトを列で定義します。（オブジェクト名は論理名と物理名（API参照名）の両方を定義しておきます）

4．CRUDマトリクス表（機能ｘ項目（フィールド）レベル）

２つ目のCRUCマトリクス表は下記のような項目（フィールド）に対しての機能/プログラムのCRUDを定義したものとなります。

こちらの場合は、項目数が多い場合には列がかなり長くなってくるため、可読性の観点から1つのエンティティ（オブジェクト）に対して、1シート単位で作成したほうが良いかもしれません。

また、処理単位で記載するようなサンプルとなっていますが、メンテナンスも大変なため、機能またはプログラム単位で作成してもよいでしょう。

【記載内容】

• • 機能ID：システム機能のIDを記入します。
  • 機能種別：システム機能の種別（画面、バッチ、帳票、APIなど）を選択します。
  • 機能名：システム機能の名称を記入します。
  • プログラムID：プログラムのIDを記入します。
  • プログラム名：具体的なプログラム名（物理名）を記入します。※1つの機能で複数のプログラムがある場合には全て羅列します。
  • 処理ＩＤ：プログラム内の処理ごとに採番されたＩＤを定義します。
  • 処理名称：プログラム内の処理名称を記入します。
  • 業務領域：概念データモデルで定義したエンティティの纏めりを定義　（不要な場合は削除してもよい）
  • エンティティ（オブジェクト）：システム全体のオブジェクトを列で定義します。（オブジェクト名は論理名と物理名（API参照名）の両方を定義しておきます）
  • 項目（フィールド）：オブジェクト内の項目を論理名と物理名（API参照名）で定義します。

４．メッセージ定義

最初にメッセージIDの設定ルールを定義しましたが、その定義内容に基づきメッセージ定義を作成していきます。

メッセージを利用するシステム、機能領域、種別（Sevirity）によってメッセージIDを定義します。

発生元：メッセージを出力するシステム/機能を定義します。

出力先：メッセージを利用する機能や出力先の画面などを定義します。

Sevirity（重要度）：メッセージの重要度を定義します。

メッセージ：出力するメッセージ内容を定義します。パラメータによってメッセージ内容を置換する場合には、パラメータで置き換える部分を{n}で定義してください。

2.CRUD的陸図表の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

設計_基本設計_CRUDマトリクス表（EXCEL版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

帳票一覧が必要な方はこちらからダウンロードしてご利用ください。

参考

帳票一覧（Excelテンプレート）

帳票一覧の設計書テンプレートを用意いたしました。 帳票一覧のサンプル 帳票一覧 …

続きを読む

1.サンプル

1.帳票定義書のサンプル

帳票レイアウト

帳票項目定義

画像はクリックすると拡大表示されます。

2.テーラリングガイド

処理概要

帳票出力に関する処理概要など基本設計で利用します

[主要項目]

• 処理概要：帳票の処理概要を定義
• 帳票レイアウト：帳票イメージを添付
• 操作概要：帳票出力の操作概要を記述
• オブジェクト構成：帳票で利用するオブジェクトのCRUDを定義
• メッセージ一覧：メッセージを定義
• アクター：帳票を利用するプロファイルを定義

帳票レイアウト

帳票レイアウトの各項目やコンポーネントに対して番号を採番しておき、後続の画面項目とマッピングしておきます。

帳票項目定義

帳票レイアウトで採番した番号と一致するように番号と項目名を定義します

[主要項目]

• 表示ラベル：項目の論理名を定義
• 固定・可変：表示項目の値が固定値か可変値かを定義
• フォント種類：利用するフォントの種類を指定
• ポイント：利用するフォントのポイント（サイズ）を指定
• 表示位置：値を表示する位置を定義
• スタイル：フォントのスタイルを定義
• フォーマット：日付や数値の表示フォーマットを定義
• 取得元オブジェクト：値を取得する元のオブジェクトを定義
• 取得元項目：値を取得するオブジェクト項目を定義
• 編集：取得した値を加工する必要がある場合に編集内容を定義
• 補足：項目の補足

入出力処理設計

帳票の詳細設計（プログラムレベル）の処理を定義します。

SOQL定義

入出力処理設計で利用するSOQLを設計します。

帳票定義書のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

以下は、スプレッドシートでの表示となります。

関連記事

他にも要件定義で必要となる以下のようなテンプレートなども用意しているのでぜひご利用ください。

システム機能一覧

システム機能一覧（Excelテンプレート）

Salesforceの要件定義フェーズでシステム機能に関する要件の取り纏めに利用…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

設計工程でシステムやアプリケーションのメッセージを定義する場合にご利用ください。

メッセージ設定書と合わせてコード定義書のテンプレートもご利用ください。

Excel版

要件定義_要件定義書_別紙1「業務フロー図」（Excel版）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.テーラリングガイド

１．表紙（メッセージ定義書）

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

基本設計工程としていますが、プロジェクトの工程に合わせて適宜変更してご利用ください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．メッセージID設定ルール

はじめにメッセージIDの設定ルールについて記載しています。

メッセージIDの構成について本サンプルでは以下のように定義しています。

本プロジェクトで利用するシステムメッセージは、システムID＋機能領域ID＋Sevirity（重要度）＋3桁連番の組み合わせで定義する

メッセージの利用方法については以下のように定義しています。

メッセージIDをプログラムで利用する場合には、事前にカスタム表示ラベルにメッセージIDや定義内容を設置してから利用すること

プロジェクトの開発方針によっては、Apexで利用する場合には、Apexクラス内で固定メッセージを定義して利用する場合もあると思いますが、その場合には、定義しているApexクラスの内容も本設計書に追加するとよいでしょう。

４．メッセージ定義

最初にメッセージIDの設定ルールを定義しましたが、その定義内容に基づきメッセージ定義を作成していきます。

メッセージを利用するシステム、機能領域、種別（Sevirity）によってメッセージIDを定義します。

発生元：メッセージを出力するシステム/機能を定義します。

出力先：メッセージを利用する機能や出力先の画面などを定義します。

Sevirity（重要度）：メッセージの重要度を定義します。

メッセージ：出力するメッセージ内容を定義します。パラメータによってメッセージ内容を置換する場合には、パラメータで置き換える部分を{n}で定義してください。

７．メッセージ利用状況一覧

最後に、メッセージを利用するプログラムとの紐づけを行います。メッセージを変更したり削除した場合にどのプログラムに影響するか把握するためのものとなります。

2.メッセージ設計書（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

※ダウンロードのリンクをクリックすると自動的にファイルのダウンロードが開始されます。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

【重要】設計・開発時のレビュー関連（アンチパターン）

権限設計

①組織の共有設定、共有ルールを利用する前提で権限設定を行う場合、1オブジェクト当たり最大で300までの共有ルールしか設定できないことに注意が必要

サポートへ依頼することで、最大500まで拡張することは可能（エンティティごとの共有ルールの最大数の拡張）

公式のヘルプサイト：https://help.salesforce.com/s/articleView?id=000384485&type=1

ただし、共有ルールを大量に用いる場合は処理性能に影響が出る可能性が高いため性能要件も合わせて確認が必要

もし1オブジェクトあたり500以上のグループやユーザに対して共有ルールを設定する必要があるという場合でも拡張はできないため、個別に権限付与のSObjectのShareオブジェクトに対してレコードを生成するようなトリガーなどの処理を開発して対応が必要となります。

要件定義の段階で、必用な権限グループの総数は確認するようにしておきましょう。

データモデルの設計

①主従関係構築する際、1つの親レコードに対して、最大何件の子レコードが関連するか。

10万件を超過することが予想される、且つ、親レコードは削除処理の対象となることがある場合には、参照関係に変更できないか検討する。

※参照関係でも、カスケードオプションは付けないようにする必要がある！！

積み上げ集計などが必要な場合はトリガーやバッチ処理で代替することを検討したほうがよいです。

例えば、バッチ処理で、主従関係の子レコードを10万件以上削除したあとに、親レコードを削除しようとすると以下のようなエラーが発生します。

「Delete failed. First exception on row 0 with id a035h00000TE1BGXXX; first error: DELETE_OPERATION_TOO_LARGE, Cascade deleting too many records: occurring when cascading to」

カスケード削除（親と一緒に関連する子レコードなどを削除する）の場合に、削除対象のレコード数が多すぎて削除できない制約

Salesforceではカスケード削除は10万件までの上限でハードコーディングされているようで変更不可とのこと。

子レコード削除後は、ごみ箱に入って、完全に物理削除されるまで通常何日か必要です。その間は親レコードが削除できなくなるため、バッチ処理などで親子セットで削除すると親だけ最後に削除できず上記エラーが発生します。

ApexTrigger（トリガ）の設計・開発

Apexバッチの設計・開発

Startメソッドの中で、QueryLocatorの代わりにAggregateResultのIteratorなどを使っていないか。データが少量の場合は、成功するが大量の場合は、queryMore()が発生して以下のエラーが発生するので要注意！

「Aggregate query does not support queryMore(), use LIMIT to restrict the results to a single batch」

対方針：集計が必要な処理はSOQLの集計関数ではなく、For文などの繰り返し処理で計算させること。

フローの設計・開発

【画面処理フロー】

フローでは、要素の割り当てのガバナ制限があります。繰り返し処理で変数の割り当て処理が多い場合、以下のエラーが発生する可能性があります。

「お客様の組織はこの機能に対する最大限度を超えました。」

（対処方法）

上記エラーが出る場合は、要素の割り当て数を少なくするしかないため、大量データの加工などが必要な処理はフローではなく、トリガーまたは画面の開発を行う必要があります。

フローのテキストコンポーネントに入力された値を使って、すでに登録済みのデータと重複チェックをする場合、テキスト前後の半角/全角SP（スペース）やタブをTrimしない状態で重複チェックをすると、SOQLでの検索では、スペースなどが含まれた状態で検索されるため重複とならないが、レコードを登録する（INSERT･UPSERTなど）の際には、自動的にトリムされるため重複エラー（DML Exception）が発生します。

例えば取引先番号”ACC123″のレコードが取引先に存在する場合に、画面で入力された”　A123　”をSOQLで検索すると別の文字列のためレコードは検索されず重複なしと判断できます。

ただし、INSERT時には、Salesforceでは自動的に前後がトリムされるため”ACC123″としてレコードを登録しようとして重複エラーが発生します。

重複チェックをする項目については、上記が考慮された設計となっているかチェックする必要があります。

モバイルアプリケーションを利用する場合

・動的関連リスト（Summer22）を利用している場合、モバイルでは対応していないためタブが表示されなくなる（2022/7/7月時点の情報）

→（対策）標準の関連リストを利用もしくは、List Editorの利用　（こちらの記事を参考）

・Lightning web componentで開発した機能を呼び出すアクションを利用する場合、モバイルでは対応していない（2022/7/7月時点の情報）

→（対策）こちらについては、Aura Componentでアクションボタンを作成して、ラップすることで回避可能

上記のほかモバイルの考慮事項は、公式サイトで最新状況を確認してください。