モダンなSalesforce開発において、Lightning Web Component（LWC）は欠かせない技術要素となっています。しかし、多くの開発チームが「どのようなコーディング規約を設ければよいのか」「チーム全体で一貫したコードスタイルを維持するにはどうすればよいのか」といった課題を抱えています。

本記事では、SalesforceのApexコーディング規約の考え方を参考にしながら、LWC開発における実践的なコーディング規約の策定と活用方法について詳しく解説します。品質の高いLWCアプリケーションを開発するために、ぜひ本ガイドを参考にして、あなたのプロジェクトに最適なコーディング規約を構築してください。

本記事では、このテンプレートの特徴と効果的な活用方法について詳しく解説します。

なぜコーディング規約が重要なのか

1. フロントエンド開発の複雑性への対応

LWC開発では、JavaScript、HTML、CSS、そしてSalesforceのメタデータが複雑に絡み合います。統一されたコーディング規約がないと、以下のような問題が発生します：

• コンポーネント間でのスタイリングの不整合
• JavaScript のパフォーマンスの劣化
• コンポーネントの再利用性の低下
• デバッグの困難さ

2. Salesforceプラットフォーム特有の制約

LWC開発では、一般的なWebフロントエンド開発とは異なる独特の制約があります：

• Locker Service によるセキュリティ制約
• Lightning Data Service の効率的な活用
• イベント伝播とコンポーネント間通信
• レスポンシブデザインとLightning Design System（SLDS）の準拠

3. 長期保守性の確保

LWCコンポーネントは、Salesforceの組織内で長期間にわたって使用されます。初期開発から数年後の機能拡張や修正を考慮した、保守しやすいコード構造を保つことが重要です。

1.テーラリングガイド

１．目次サンプル

目次
1 はじめに 
　1.1 本書の目的 7
　1.1.1 利用者 7
1.2 記号 7
　1.2.1 本書で使用する記号についての説明 7
1.3 用語の定義 7
　1.3.1 本書で使用する記号についての説明 7
2 基本方針 8
　2.1 可読性の優先 8
　2.2 保守性の確保 8
　2.3 Lightning固有の考慮事項 8
3 命名規則 8
　3.1 コンポーネント名 8
　3.2 メソッド名 9
　3.3 定数名 10
4 ファイル構造とフォーマット 11
　4.1 ファイル構成 11
　4.2 インデント 11
　4.3 行の長さ 12
5 Javascript設計 13
　5.1 クラス構造の順序 13
　5.2 プロパティ設計 15
6 HTMLテンプレート設計 17
　6.1 テンプレート構造 17
　6.2 イベントハンドリング 18
7 CSSスタイル設計 21
　7.1 SLDS準拠 21
　7.2 CSSカスタムプロパティ 22
8 データアクセスとAPIコール 22
　8.1 Lightning Data Service (LDS) 22
　8.2 Apexメソッド呼び出し 24
9 イベント設計 25
　9.1 カスタムイベント 25
　9.2 プラットフォームイベント 27
10 テスト設計 28
　10.1 Jestテスト 28
　10.2 テストデータファクトリ 31
11 セキュリティとベストプラクティス 33
　11.1 セキュリティ考慮事項 33
　11.2 パフォーマンス最適化 34
12 国際化対応 36
　12.1 カスタムラベル使用 36
　12.2 日付・通貨・数値フォーマット 38
13 エラーハンドリング 40
　13.1 統一的なエラーハンドリング 40
　13.2 バリデーションエラー 43
14 デバッグとトラブルシューティング 45
　14.1 ログ出力 45
　14.2 パフォーマンス監視 46
15 コンポーネント設計パターン 48
　15.1 コンポーネント間通信 48
　15.2 コンポーネント間通信 50
16 メタデータ設計 53
　16.1 コンポーネントメタデータ 53
17 運用保守 55
　17.1 コードレビューチェックリスト 55

２.基本方針（可読性・保守性の重視）

テンプレートでは、「可読性の優先」「保守性の確保」「Salesforce固有の考慮事項」の3つを基本方針として掲げています。これらの方針は、長期的な開発・運用を見据えた重要な指針となります。

可読性の優先

• コードは書く時間よりも読む時間の方が長いことを念頭に置く
• 自己説明的なコードを心がける
• 適切なコメントで意図を明確にする

保守性の確保

• 単一責任原則に従ったコンポーネント設計
• 疎結合と高凝集を実現する構造
• 将来の変更に対応しやすい設計

パフォーマンスの重視

• 不要な再レンダリングを避ける
• 効率的なデータフェッチ
• 適切なライフサイクルフックの活用

３.命名規則の統一

3.1 コンポーネント名
規則:
• kebab-case（小文字、単語間はハイフン）
• 意味のある名前を使用
• 業務領域を表現する接頭辞を付ける

3.2 メソッド名
規則:
• camelCase（最初は小文字、以降の単語は大文字開始）
• 意味のある名前を使用
• Boolean型はis、has、canで開始

3.3 定数名
規則:
• UPPER_SNAKE_CASE（全て大文字、単語間はアンダースコア）
• 意味を明確に表現

4.ファイル構造とフォーマット

4.1 ファイル構成

my-component/

├── my-component.js         // Javascript ロジック

├── my-component.html       // HTML テンプレート

├── my-component.css        // CSS スタイル

├── my-component.js-meta.xml // メタデータ

└── __tests__/

    └── my-component.test.js // テストファイル

4.2 インデント

規則:

• 2スペースインデント（タブ文字は使用しない）
• 一貫したインデントレベルを維持

4.3 行の長さ

規則:

• 1行120文字以内を推奨
• 長い行は適切な位置で改行

5.Javascript設計

クラス構造体の順序、ﾌﾟﾛﾊﾟﾃｨ設計の規則と例を記述しています。

6.HTMLテンプレート設計

テンプレート構造、イベントハンドリングについての規約と例文について解説しています。

7.CSSスタイル設計

CSSスタイル設計のSLDS準拠について、CSSカスタムプロパティの利用方法について解説しています。

8 データアクセスとAPIコール

Lightning Data ServiceやApexメソッドの呼び出しに関する規則について解説しています。

8.1 Lightning Data Service (LDS)
規則:
• 単一レコード操作にはLDSを優先的に使用
• @wireでリアクティブなデータバインディング
• エラーハンドリングを適切に実装

8.2 Apexメソッド呼び出し
規則:
• @wireで自動データバインディング
• imperative callで手動データ取得
• 適切なエラーハンドリング

9.イベント設計

カスタムイベント、プラットフォームイベントについて解説

10.テスト設計

Jestテスト、テストデータファクトリについて解説

11.セキュリティとベストプラクティス

11.1 セキュリティ考慮事項
規則:
• ユーザー入力は常にサニタイズ
• lightning-formatted-textでXSS対策
• CRUD/FLS権限を考慮

その他

テンプレートを参照ください。

テンプレートの効果的な活用方法

1. プロジェクト開始時の規約策定

新しいSalesforceプロジェクトを開始する際、このテンプレートをベースとして、プロジェクト固有の要件に合わせてカスタマイズすることで、短時間で実用的なコーディング規約を策定できます。

活用手順：

1. テンプレートをダウンロードし、開発チーム全体で内容を確認
2. プロジェクトの特性に応じて、必要な項目を追加・修正
3. チーム内での合意形成とドキュメント化

2. 既存プロジェクトの品質改善

既に進行中のプロジェクトでも、段階的にコーディング規約を導入することで品質向上を図ることができます。

段階的導入のアプローチ：

• 第1段階: 新規開発コードから規約適用開始
• 第2段階: 既存コードの修正時に規約に合わせてリファクタリング
• 第3段階: 重要なモジュールから順次全面的な規約適用

3. コードレビューの効率化

テンプレートに含まれるチェックリストを活用することで、コードレビューの観点が明確になり、見落としを防ぐことができます。

4. 新人教育・オンボーディング

新しくチームに参加する開発者に対して、このテンプレートを教育資料として使用することで、Salesforce開発のベストプラクティスを効率的に伝えることができます。

実装時の注意点とコツ

段階的な導入を心がける

すべての規約を一度に導入しようとすると、開発チームに大きな負担をかけてしまいます。重要度の高い項目から順次導入し、チーム全体が慣れてから次の項目に進むことが重要です。

ツールを活用した自動化

可能な限り、IDE（Salesforce CLI、VS Code）の設定やCI/CDパイプラインを活用して、規約チェックを自動化しましょう。手動でのチェックに頼りすぎると、継続が困難になります。

定期的な見直しと改善

プロジェクトの進行に伴い、新たな課題や改善点が見つかることがあります。定期的に規約を見直し、チームの成長とプロジェクトの変化に応じてアップデートしていくことが大切です。

テンプレートに含まれる実践的なコード例

このテンプレートの大きな特徴の一つは、豊富な実装例が含まれていることです。抽象的な説明だけでなく、具体的なコード例を通じて「良い例」と「悪い例」を明示しているため、開発者が実際のコーディング時に迷うことなく適用できます。

SLDSの活用例

(css)
/*  良い例 - SLDS準拠 */
.account-container {
  padding: var(--lwc-spacing-medium);
}

.header {
  margin-bottom: var(--lwc-spacing-large);
}

.content {
  display: flex;
  flex-direction: column;
  gap: var(--lwc-spacing-medium);
}

.empty-state {
  text-align: center;
  padding: var(--lwc-spacing-x-large);
  color: var(--lwc-color-text-weak);
}

.error-message {
  color: var(--lwc-color-text-error);
  padding: var(--lwc-spacing-small);
  border: 1px solid var(--lwc-color-border-error);
  border-radius: var(--lwc-border-radius-medium);
  background-color: var(--lwc-color-background-error);
}

/* レスポンシブ対応 */
@media (max-width: 768px) {
  .content {
    padding: var(--lwc-spacing-small);
  }
}

継続的な品質向上のために

コーディング規約の導入は、ゴールではなくスタートラインです。継続的に品質を向上させるために、以下の取り組みを推奨します：

定期的なコードレビュー会の実施

チーム全体でコードレビューを行う時間を定期的に設け、規約の適用状況や新たな課題について議論します。

メトリクス測定と改善

テストカバレッジ、複雑度、規約違反数などのメトリクスを測定し、定量的な改善を図ります。

知識共有とベストプラクティスの蓄積

チーム内で発見されたベストプラクティスを規約に反映し、組織の知見として蓄積していきます。

まとめ

今回公開したSalesforce Apexコーディング規約テンプレートは、実際の開発現場での経験を基に作成された実践的なドキュメントです。このテンプレートを活用することで、開発チームは以下のメリットを得ることができます：

• 開発効率の向上: 統一されたコーディングスタイルにより、コードレビューや保守作業が効率化
• 品質の向上: Salesforce特有の制約を考慮したベストプラクティスにより、バグの削減と性能向上を実現
• チーム力の強化: 共通の規約により、チーム内でのコミュニケーションと協力が促進
• スケーラビリティの確保: 将来の機能拡張や保守作業に対応しやすいコード構造の実現

Salesforce開発の品質向上を目指すすべてのチームに、このテンプレートを積極的に活用していただき、より良いシステム開発を実現していただければと思います。

資料のダウンロード

テンプレートのダウンロードは、Creative Content Lab Tokyoの公式サイトから無料で行えます。ぜひ、あなたのプロジェクトでもご活用ください。

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

一般公開資料

開発コーディング規約のダウンロード

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

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

最後に

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

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

にほんブログ村

Salesforce開発において、品質の高いコードを書くことは、システムの保守性、拡張性、そして開発チームの生産性に直結する重要な要素です。

しかし、多くの開発現場では「どのようなコーディング規約を設ければよいのか」「チーム全体で一貫したコードスタイルを維持するにはどうすればよいのか」といった課題を抱えています。

そこで今回、Creative Content Lab Tokyoでは、実際の開発現場で使用できるSalesforce Apexコーディング規約テンプレートを無料公開いたします。

本記事では、このテンプレートの特徴と効果的な活用方法について詳しく解説します。

是非、本テンプレートを利用して各プロジェクトの実態にあった実践的なApexコーディング規約を作成してみてください。

なぜApexコーディング規約が重要なのか

1. チーム開発における統一性の確保

複数の開発者が参加するプロジェクトでは、各々が異なるコーディングスタイルでコードを書いてしまうことがよくあります。

これにより、コードレビューが困難になり、バグの発見が遅れたり、新しいメンバーがコードを理解するのに時間がかかったりします。

統一されたコーディング規約があることで：

• コードの可読性が向上し、誰が書いたコードでも理解しやすくなる
• コードレビューの効率が上がり、品質向上に集中できる
• 新規参画メンバーのオンボーディングが迅速になる

2. Salesforce特有の制約への対応

SalesforceのApex開発では、一般的なプログラミング言語にはない独特の制約があります：

• ガバナ制限（SOQL、DML、CPUタイムなど）
• セキュリティモデル（共有設定、FLS）
• マルチテナント環境特有の考慮事項

これらの制約を理解せずに開発を進めると、本番環境で予期しないエラーが発生する可能性があります。

3. 保守性の確保

Salesforceシステムは長期間にわたって運用されることが多く、初期開発から数年後に機能追加や修正が必要になることが一般的です。この際、コーディング規約に従って書かれたコードは、修正や拡張が容易になります。

1.テーラリングガイド

目次サンプル

1.基本方針（可読性・保守性の重視）

テンプレートでは、「可読性の優先」「保守性の確保」「Salesforce固有の考慮事項」の3つを基本方針として掲げています。これらの方針は、長期的な開発・運用を見据えた重要な指針となります。

2.命名規則の統一

クラス名、メソッド名、変数名、定数名それぞれに対して明確なルールを設定しています。例えば：

クラス名: PascalCaseで名詞または名詞句を使用

• AccountService
• accService

メソッド名: camelCaseで動詞または動詞句で開始

• updateAccountStatus()
• update()

3.コード構造とフォーマット

一貫したインデント（4スペース）、適切な行の長さ（120文字以内）、効果的な空行の使用など、チーム全体で統一すべき基本的なフォーマットルールを定義しています。

4.クラス設計のベストプラクティス

クラス内の要素の配置順序（定数→静的変数→インスタンス変数→コンストラクタ→パブリックメソッド→プライベートメソッド）や、適切なアクセス修飾子の使用方法を明示しています。

5.SOQL/DML操作の最適化

Salesforce開発で最も重要な要素の一つであるデータベース操作について、パフォーマンスとガバナ制限を考慮したベストプラクティスを提供しています：

• バルク処理の実装方法
• 効率的なSOQLクエリの書き方
• Database クラスを使用した部分成功制御

6.包括的なテスト戦略

85%以上のテストカバレッジ達成を目標とし、ポジティブ・ネガティブ両方のテストケースを含む、実践的なテストクラス作成方法を解説しています。

テンプレートの効果的な活用方法

1. プロジェクト開始時の規約策定

新しいSalesforceプロジェクトを開始する際、このテンプレートをベースとして、プロジェクト固有の要件に合わせてカスタマイズすることで、短時間で実用的なコーディング規約を策定できます。

活用手順：

1. テンプレートをダウンロードし、開発チーム全体で内容を確認
2. プロジェクトの特性に応じて、必要な項目を追加・修正
3. チーム内での合意形成とドキュメント化
4. 開発環境への組み込み（IDE設定、CI/CDパイプライン）

2. 既存プロジェクトの品質改善

既に進行中のプロジェクトでも、段階的にコーディング規約を導入することで品質向上を図ることができます。

段階的導入のアプローチ：

• 第1段階: 新規開発コードから規約適用開始
• 第2段階: 既存コードの修正時に規約に合わせてリファクタリング
• 第3段階: 重要なモジュールから順次全面的な規約適用

3. コードレビューの効率化

テンプレートに含まれるチェックリストを活用することで、コードレビューの観点が明確になり、見落としを防ぐことができます。

チェックリストの活用例：

• 基本事項（命名規則、アクセス修飾子、フォーマット）
• 設計・構造（単一責任原則、メソッドサイズ、例外処理）
• Salesforce固有（ガバナ制限、バルク処理、セキュリティ）
• パフォーマンス（SOQLクエリ最適化、DML最適化）

4. 新人教育・オンボーディング

新しくチームに参加する開発者に対して、このテンプレートを教育資料として使用することで、Salesforce開発のベストプラクティスを効率的に伝えることができます。

実装時の注意点とコツ

段階的な導入を心がける

すべての規約を一度に導入しようとすると、開発チームに大きな負担をかけてしまいます。重要度の高い項目から順次導入し、チーム全体が慣れてから次の項目に進むことが重要です。

ツールを活用した自動化

可能な限り、IDE（Salesforce CLI、VS Code）の設定やCI/CDパイプラインを活用して、規約チェックを自動化しましょう。手動でのチェックに頼りすぎると、継続が困難になります。

定期的な見直しと改善

プロジェクトの進行に伴い、新たな課題や改善点が見つかることがあります。定期的に規約を見直し、チームの成長とプロジェクトの変化に応じてアップデートしていくことが大切です。

テンプレートに含まれる実践的なコード例

このテンプレートの大きな特徴の一つは、豊富な実装例が含まれていることです。抽象的な説明だけでなく、具体的なコード例を通じて「良い例」と「悪い例」を明示しているため、開発者が実際のコーディング時に迷うことなく適用できます。

バルク処理の実装例

//  良い例 - バルク処理対応
public void updateAccountTypes(List<Account> accounts, String newType) {
    List<Account> accountsToUpdate = new List<Account>();
    
    for (Account acc : accounts) {
        if (acc.Type != newType) {
            acc.Type = newType;
            accountsToUpdate.add(acc);
        }
    }
    
    if (!accountsToUpdate.isEmpty()) {
        try {
            Database.update(accountsToUpdate, false);
        } catch (DmlException e) {
            handleDmlException(e);
        }
    }
}

セキュリティを考慮した実装例

//  良い例 - 権限チェック
public void updateAccounts(List<Account> accounts) {
    if (!Schema.SObjectType.Account.isUpdateable()) {
        throw new SecurityException('Insufficient privileges to update Account');
    }
    
    update accounts;
}

継続的な品質向上のために

コーディング規約の導入は、ゴールではなくスタートラインです。継続的に品質を向上させるために、以下の取り組みを推奨します：

定期的なコードレビュー会の実施

チーム全体でコードレビューを行う時間を定期的に設け、規約の適用状況や新たな課題について議論します。

メトリクス測定と改善

テストカバレッジ、複雑度、規約違反数などのメトリクスを測定し、定量的な改善を図ります。

知識共有とベストプラクティスの蓄積

チーム内で発見されたベストプラクティスを規約に反映し、組織の知見として蓄積していきます。

まとめ

今回公開したSalesforce Apexコーディング規約テンプレートは、実際の開発現場での経験を基に作成された実践的なドキュメントです。このテンプレートを活用することで、開発チームは以下のメリットを得ることができます：

• 開発効率の向上: 統一されたコーディングスタイルにより、コードレビューや保守作業が効率化
• 品質の向上: Salesforce特有の制約を考慮したベストプラクティスにより、バグの削減と性能向上を実現
• チーム力の強化: 共通の規約により、チーム内でのコミュニケーションと協力が促進
• スケーラビリティの確保: 将来の機能拡張や保守作業に対応しやすいコード構造の実現

Salesforce開発の品質向上を目指すすべてのチームに、このテンプレートを積極的に活用していただき、より良いシステム開発を実現していただければと思います。

資料のダウンロード

テンプレートのダウンロードは、Creative Content Lab Tokyoの公式サイトから無料で行えます。ぜひ、あなたのプロジェクトでもご活用ください。

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

一般公開資料

開発コーディング規約のダウンロード

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

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

最後に

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

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

にほんブログ村

サポーターさん

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

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]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

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

にほんブログ村

サポーターさん

機能の紹介記事は以下を参考にしてください。

参考

Salesforceワークベンチ(workbench)の機能一覧と使い方の説明（SOQL実行・Metadataのバックアップ/デプロイなど）

本記事では、Salesforce workbenchについての概要や機能について…

続きを読む

1.ユーザ説明資料サンプル

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

３．はじめに（本書の目的）

資料の目的を記載します。

４．目次

機能概要説明資料の目次を以下の内容で記載しています。

• Workbench概要
• Workbenchとは
• 機能一覧
• Workbenchの使い方
• Workbenchへの接続方法
• 機能紹介
• メタデータ照会機能
• クエリ実行機能
• データ操作（DML）機能
• マイグレーション機能
• その他ユーティリティ

５．Workbench（ワークベンチ）概要

はじめにWorkbenchについての概要を記載しています。ワークベンチとはどういったものか、できることは何かなど概要レベルで説明します。

続いて、Workbenchの機能一覧を記載（最新の機能一覧は公式サイトからご確認ください）

６．Workbenchの使い方（ワークベンチへのログイン）

ブラウザでWorkbenchへログインして利用するための手順を記載しています。

Workbench接続先サイト（https://workbench.developerforce.com/login.php）

※サイトのURLの最新情報は公式サイトからご確認ください。

Salesforceのユーザアカウントを使ってログインを行います。

ユーザ名とパスワードを設定して、ログイン

Workbenchのトップ画面で、利用する機能を選択するか、もしくはタブに表示されている各種メニューから利用する機能を選択します。

７．メタデータ情報照会（標準/カスタムオブジェクト）

指定したオブジェクトに関するメタデータ情報を参照することができます。

Metadata Types & Components：メタデータタイプの確認やコンポーネントについての詳細情報を確認することができます。

セッション情報（Session Infromation）：

接続しているSalesforceインスタンスのセッション情報（サービスのエンドポイントなど）を確認することができます。

８．クエリ実行機能（SOQLクエリ）

SOQL：SOQLのクエリを直接実行することができます。表示形式やソート順の指定が可能またフィルタ条件や取得レコードの上限の指定も可能です。

そのほか、削除済み、アーカイブレコードを含めるかなどの指定もできます。

Async SOQL Query：非同期のSOQL(Insert/Upsert）の実行ができます。

最初の画面で指定したSOQLで取得したレコードを使って、INSERTまたはUPSERTを実行することができます。

SOSL（Salesforce Object Search Language) の実行が可能です。SOQLは、Salesforceのレコード内のテキスト検索を実行することができます。

Streaming Push Topics：Salesforceのレコードを監視し、本機能で登録したSOQLクエリに該当した場合に、あらかじめ購読（Subscribe登録）されたクライアントに対して、プッシュ通知を実現するものとなります。

9.データ操作（DML）機能

Insert：指定オブジェクトに対して1つまたは複数のレコードを登録することができます。

【説明】INSERTでは、各項目に直接値を設定して、実行します。実行結果では、作成されたレコードIDと処理結果を確認することができます。

Update：指定オブジェクトに対して1つまたは複数のレコードを更新することができます。

【説明】UPDATEでは、各項目に直接値を設定して、実行します。実行結果では、更新されたレコードIDと処理結果を確認することができます。

Upsert：指定オブジェクトに対して1つまたは複数のレコードを更新または新規登録することができます。

外部IDなどのキー項目を比較し、すでにSalesforce上に登録されているキーと一致する場合にはレコードを更新し、一致しない場合は新規レコードとして登録されます。

【説明】UPSERTでは、各項目に直接値を設定して、実行します。

実行結果の確認画面では、処理結果とステータスを確認することができます。INSERT/UPDATEはレコード単位で確認可能

Delete：指定オブジェクトに対して1つまたは複数のレコードを削除することができます。

【説明】DELETEでは、削除対象のIDを指定して削除処理を実行します。実行結果の確認画面では、処理結果とステータスを確認することができます。

Undelete：指定オブジェクトに対して1つまたは複数の削除されたレコードを復元することができます。

【説明】指定オブジェクトに対して1つまたは複数の削除されたレコードを復元することができます。

Purge：指定オブジェクトに対して1つまたは複数の削除されたレコードをゴミ箱から削除することができます。

【説明】実行結果の確認画面では、処理結果とステータスを確認することができます。

10.マイグレーション

Retrieve：マニフェストファイルで指定したメタデータを取得することができます。Package.xmlファイルは事前に作成しておく必用があります。

マニフェストファイル（Package.xml）のサンプル。以下のサイトからフルバージョンをダウンロードすることができます。

全メタデータ取得用のマニフェストファイル（Package.xml）のサンプルダウンロード

https://creativecontentlabtokyo.com/retrieve-salesforce-full-metadata-package-xml-file-download/

説明：Retrieveを実行すると、メタデータAPIを利用してメタデータの取得処理が行われます。

実行結果の画面では、処理結果と合わせて取得したメタデータの圧縮ファイル（Zip）がダウンロード可能となります。※このZipファイルを使って、Deployを行うことができます。

Deploy（デプロイ）：指定したメタデータのZIPファイルを使ってSalesforce組織にメタデータをデプロイします。

【説明】Deployには、以下のように様々なオプションが用意されています。

・チェック（検証）だけを実行

・警告を無視

・エラーの場合にロールバック

・Apexテストの実行、テストレベルの指定など

実行するとメタデータAPIで処理が行われます。処理結果には、処理した件数や結果が表示されます。

【説明】Deploy実施結果では、ZIPファイルに含まれるメタデータごとの処理結果の詳細情報を確認することができます。

11.その他ユーティリティ機能

Rest Explorer：WorkbenchからSalesforce組織に対して直接REST APIを実行することができます。

利用可能なメソッドは、GET、POST、PUT、PATCH、DELETE、HEADとなります。

Apex Execute：WorkbenchからSalesforceに対して直接Apexコードを実行することができます。

例では、Account（取引先）のレコードを3件取得してリストに格納する処理を実行してます。実行結果では、デバッグログを確認することができます。

Password Management：WorkbenchからSalesforceのユーザに対してパスワードの設定やリセットを行うことができます。

Bulk API Job Status：DataloaderやWorkbenchなどから実行されたBulk APIのジョブステータスを確認することができます。

一括データ読み込みジョブのIDを指定して実行します。実行結果の確認画面では、ステータスや処理件数、失敗件数などを確認することができます。

Metadata API Process Status：メタデータAPIの処理プロセスのステータス（実行状況）を確認することができます。確認したいIDを指定して実行します。

2.ユーザ説明資料「機能概要説明書（Salesforce Workbench（ワークベンチ））のダウンロード

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

一般公開資料（PDF版資料）

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

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

関係者のみ（PPT版資料）

関係者の方は、以下のページからログインして資料をダウンロードしてください

参考

保護中: 【関係者】ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

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

続きを読む

サポーターさん

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

にほんブログ村

サポーターさん

Workbenchでメタデータをdownloadする場合やVisualStudioCodeなどでご活用ください。

Salesforce Workbenchを使ってメタデータを取得（バックアップ）したりデプロイ（リストア）する方法は、以下の記事で説明しているので、合わせてご利用ください。

参考

Salesforceワークベンチ(workbench)の機能一覧と使い方の説明（SOQL実行・Metadataのバックアップ/デプロイなど）

本記事では、Salesforce workbenchについての概要や機能について…

続きを読む

Package.xmlファイル

公式で提供されている標準（デフォルト）のpackage.xml マニフェストファイル

本サイトで提供している全メタデータファイル取得用のPackage.xmlファイル

マニフェストのサンプルや記述方法は、Salesforce公式サイトのHELPをご確認ください。

全メタデータ定義版Package.xmlファイルのダウンロード

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

一般公開資料

※XMLファイルの場合ダウンロード時に警告でストップする場合があるため、Zipファイルに圧縮していますので、解凍してからご利用ください。

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

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

サポーターさん

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

にほんブログ村

サイト立ち上げ時に作成したテンプレートはかなり古くなっているので、内容のアップデートも含めて新しく作成しなおしたものとなります。

サポーターさん

Salesforce以外にも使える汎用的なプロジェクト計画書です。是非ご自身のプロジェクトでご活用ください。

表紙・改訂履歴・はじめに・目次

（表紙）

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

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

情報種別：社外秘など

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

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

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

※（プロジェクト計画（工程定義）（本書）は基本的にプロジェクト計画書などに組み込んで利用していただく想定で作成したものとなるため、表紙は本体の方で設定していただいて構いません。

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

（改訂履歴）

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

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

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

（はじめに（本書の目的））

プロジェクト計画書を作成する目的について記述します。（以下、記述例）

（目次）

プロジェクト計画書の目次に関しては、プロジェクトの規模や特性によって必要な項目を追加・変更してご利用ください。

目次（記載例）

2.プロジェクト概要

1-1.プロジェクトの背景と目的

プロジェクトの背景とゴールを記載

1-2.システム全体像と開発範囲

1-3.RFP要求事項に対する対応方針

1-4.プロジェクト評価基準（達成目標）

2.プロジェクト工程の定義と作業内容

プロジェクトによって作業工程が異なるため、工程の名称や作業内容、契約方式や成果物を整理してまとめておきましょう。

プロジェクト工程と成果物の定義に関しての最新資料は以下からダウンロードできます。

参考

プロジェクト計画_プロジェクト作業工程と成果物の定義（PPT版）サンプル

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

続きを読む

2-1. 各作業工程の定義（工程名称・作業内容・成果物）（1/3）

要件定義から設計工程について、工程の名称と作業内容、成果物を定義しています。

工程の呼び方に関しては、会社やプロジェクトごとに呼称が異なると思いますが、名称について補足説明をいれておくとよいでしょう。例：RD（requirements definition）など

以下は、各工程の作業内容の説明（サンプル）となります。契約内容に基づき適切な工程と作業内容を定義してください。

要求分析（SA）：現場担当者へのインタビューを実施し、現行業務プロセスの整理。本来あるべき姿と現状のギャップ（課題・問題点）を抽出したうえで、新業務プロセスの検討を行う。また、新業務プロセスに合わせて構築するITシステムの範囲や要求仕様を明確にし、関係者で合意する

システム要件定義（RD）：業務要件定義で抽出した要求仕様に基づき、システムに求められる機能要件/非機能要件を明らかにし、要件定義書として文書化する

外部設計（BD）：データモデルの検討、画面遷移、画面一覧、帳票一覧、入出力設計、外部システム連携方式、バッチ処理方式などについてのシステム設計を行う

内部設計（DD）：以下についてのプログラムレベルの設計書を作成

・システム機能詳細設計、非機能（アカウント、権限設計、セキュリティ）、データベース詳細設計、外部IF詳細設計

ソフトウェア開発（PG）：データベースの構築、（オブジェクト、項目設定）、アカウント作成、権限設定、プログラム開発

2-1. 各作業工程の定義（工程名称・作業内容・成果物）（2/3）

ソフトウェアテスト（UT）：

前工程で開発したプログラムを構成する最小単位（ユニット）の機能が正しく動作することを検証するためのテスト

※Apexクラスに関しては、全ロジックを網羅するテストクラスを作成し自動テストを実行する。（カバレッジ目標NN％以上）

内部結合テスト（IT-a）：本システム内で開発したプログラムや機能を結合してテストを実施することで、要求仕様を満たしているか検討する工程

外部結合テスト（IT-b）：本システムと外部システム間を結合して行うテスト、外部設計（基本設計）で設計したシステム間のデータ受け渡しが正しいことを検証

システムテスト（ST）：本番相当の運用環境を用いてシステム全体のテストを実施する。要件定義工程で定義した機能要件/非機能要件を満たしていることを確認するためのテストを実施する。※性能・負荷試験も実施・移行リハは別途定義

2-1. 各作業工程の定義（工程名称・作業内容・成果物）（3/3）

受入テスト（UAT）：構築したシステムが合意した要求仕様を満たしていることを検証していただく

教育：本番での業務運用開始に向けて、本システムの利用者、システムの操作方法などをハンズオン形式で教育する。運用管理者に対しては、管理者向けの内容を実施する。

移行リハ：業務、システム、データの移行に関して、移行計画書に基づき移行リハーサルの実施

本番移行：本番移行作業計画を作成し、作業承認の上、本番移行作業を実施する

運用保守：サービスカタログに基づき、運用保守の作業を実施する。本番運用開始後3カ月間は、現地サポートを行う

2-2. 工程の開始・終了条件（要件定義～テスト）

工程の開始条件、終了条件を定義します。

2-3. 成果物/納品物

プロジェクトの各工程で作成する成果物の名称、形式、納品の有無を記載します。

成果物一覧のサンプルは以下よりダウンロードできます。

参考

要件定義_要件定義書_別紙7「成果物納品物一覧」（Excel版）サンプル

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

続きを読む

3. スケジュール

スケジュールの章では、プロジェクト全体のマスタスケジュールやマイルストーンの定義を行います。週単位のスケジュールやクリティカルパスの定義、工程ごとの詳細スケジュールなども用意できるようであれば追加してください。

最新のマスタスケジュールテンプレートは以下からダウンロードできます。

参考

マスタスケジュールの作成方法の解説とPPTサンプルテンプレートのダウンロード

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

続きを読む

3-1. マスタスケジュール（年単位）

3-2. マスタスケジュール（週単位）

3-3. マスタスケジュール（週単位）（クリティカルパス設定）

3-4. 工程別詳細スケジュール

工程別詳細スケジュールは、WBS（work breakdown structure）を別途エクセルで作成してそちらを参照するようにしてください。

WBSのテンプレートは以下の記事からダウンロードできます。

参考

WBS（work-breakdown-structure）（Excelテンプレート）サンプル

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

続きを読む

4. 体制と役割

体制と役割の章では、体制図（自社とお客様組織、関連ベンダーなど）を定義します。

体制図では、階層やチーム分けを意識して行い、また関係各社とのコミュニケーションルート（窓口）の定義もしっかりと行いましょう。最新の体制図のサンプルテンプレートは以下の記事からダウンロードできます。

参考

プロジェクト計画_体制図・役割と担当範囲（PPT版）サンプル

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

続きを読む

4-1. プロジェクト体制図

サンプル２

4-2. 担当と役割

自社の担当者の名前、役割のほか、責任範囲と作業内容を明確に定義します。※プロジェクトに合わせて作業内容の定義を修正してください。

4-3. 役割と担当範囲：要件定義工程

4-4. 担当役割に求められる資格・経験・スキル

担当者に求められる資格や経験などRFPで求められている場合もありますので、その場合には要件を満たしていることの証明として記載しておきましょう。

（例）プロジェクトマネージャの（ＸＸ）は、PMPの資格を保有しており、同程度の規模の案件を10年ほどPMとして従事していた経験あり

4-5. 担当者の教育・訓練計画

担当者のスキルなどが要件を満たさない場合などに、教育・訓練を行う場合にその計画を記載します。

サポーターさん

資料のサンプルは準備中です。

4-6. 各工程ごとの体制（詳細）

各工程ごとに作業体制（メンバーの増員や入れ替えなど）がある場合がほとんどだと思いますが、工程ごとに体制が決まっている場合には、それぞれの行程の体制を明示しておきましょう。

5. 品質管理

5章では、品質管理について定義します。品質については、どこまで何を実施するかプロジェクト計画の中で明確にしておく必要があります。品質を高めるには当然それに見合った工数が必要となるため見積金額にかなり影響がでる内容となります。

5-1. 品質管理単位

5-2. 品質要素と品質水準

5-3. 品質管理体制

5-4. レビュー計画

5-5. テスト計画

5-6. (補足) 品質とコスト(PAF法)に関して

6. コミュニケーション管理

6-1. コミュニケーション管理概要

6-2. 会議体

6-3. 議事録の運用ルール

6-4. 問題・課題発生時の報告ルート

6-5. 進捗管理・報告について

6-6. 変更管理について

7. 設備・作業環境計画

7-1. 作業場所と設備

8. セキュリティ管理

セキュリティ管理の章では、個人情報などの取扱に関する方針や管理方法などを記述します。

8-1. 情報の取扱に関して

8-2. 知的財産の扱いについて

9. 標準化計画

9-1. 作業方針書・規約に関して

9-2. 文書管理ルール

10. 補足資料（Appendix）

10-1. 添付資料（Appendix）

プロジェクト作業工程と成果物の定義（PPT版）のダウンロード

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

一般公開資料

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

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

関係者用資料

サポーターさん

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

にほんブログ村

サポーターさん

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

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

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版）のダウンロード

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

一般公開資料

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

サポーターさん

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

にほんブログ村