サポーターさん

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

参考

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

続きを読む

サポーターさん

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

にほんブログ村

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

サポーターさん

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

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

一般公開資料

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

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

関係者用資料

サポーターさん

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

にほんブログ村

体制図については、クラウドサービスを使って作成することも増えてきていますが、プロジェクト計画書など関係者で共有する資料の場合、加工ができないと困る場合もあると思います。

今回はパワーポイントの図を使って体制図や役割表を作成しているので、容易に加工してご利用いただくことが可能となっています。

サポーターさん

プロジェクト計画で各作業工程と成果物を定義する際にご利用ください。

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

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

２．改訂履歴

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

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

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

３．プロジェクト体制図（サンプル１）

体制図のサンプルは上記の4種類となります。

作成時の注意事項としては、指揮命令系統を明確に定義することと、全体のチーム構成などがわかるようにしましょう。

またお客様や関係者も含めた構成とする場合は、それぞれのコミュニケーションルートを明確にすることと、役職など階層は合わせるように注意しましょう。

４．担当者の役割定義

各担当者の役割や責任範囲、作業内容などを定義します。

誰がどのような役割で参画し、何に対して責任を持つのか。またどのような作業を担当する予定か明確にわかるように定義しましょう。

５．工程ごとの役割と担当範囲

こちらの資料は補足となります。

各工程ごとに誰がどのような役割となり、具体的にどの作業に対して責任をもって作業を行うのか明確にします。

この粒度で作業担当を明確にしてからプロジェクトを開始するようにしましょう。

体制図・役割表（PPT版）のダウンロード

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

一般公開資料

※クリック後は、ダウンロードが開始されるまでお待ちください。

サポーターさん

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

にほんブログ村

こういった工程や作業内容、成果物を明確に定義してお客様と合意していないプロジェクトも散見されますが、ステークホルダ（プロジェクト関係者全員）と認識合わせをしておことは非常に重要なため、普段実施していないという方は、取り入れてみてください。

サポーターさん

プロジェクト計画で各作業工程と成果物を定義する際にご利用ください。

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

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

２．利用規約

こちらは、削除してご利用ください。本書に関する規約と補足事項を記載しています。

３．改訂履歴

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

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

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

４．目次

目次についても本体に組み込んでご利用いただく場合は、こちらのスライドは削除していただいて構いません。

・各作業工程と成果物の定義

・各作業工程と開始・終了条件

５．プロジェクト各作業工程の定義

１．プロジェクト作業工程の定義（工程名称、作業内容、成果物）

最初のスライドでは、要件定義から設計工程について、工程の名称と作業内容、成果物を定義しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

６．各作業工程の開始・終了条件（Criteria）

各作業工程を定義したあとは、作業工程の開始条件・終了条件・承認者などについて整理します。

何をもってその工程を完了とするのか明確な基準を定義しておきます。また承認者や時期なども定義しておくとよいでしょう。

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

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

一般公開資料

※ダウンロードされるまで少し時間がかかる場合があります

関係者用資料

※ダウンロードされるまで少し時間がかかる場合があります

サポーターさん

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

にほんブログ村

サポーターさん

メール-to-ケースの設定方法については以下の記事を参考にしてください。

参考

メール-to-ケース（オンデマンドサービス）で受信メールからケースを自動生成

今回の記事では、サービスクラウド（Service Cloud）でよく利用されるメ…

続きを読む

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

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

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

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

※今回は、要件定義書

例）本書は、Salesforceの標準機能である「メールtoケース（オンデマンドサービス方式）]の機能に関しての概要説明を行うことを目的として作成しています。

４．目次

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

• 機能概要「メール-to-ケース（オンデマンドサービス方式）
• 概要説明
• 前提条件
• 処理プロセス（メール送信からSFDCケースの自動起票まで）
• 組織の制限
• 注意事項

５．機能概要「メール-to-ケース（オンデマンドサービス方式） 」

メール-to-ケースに関する機能概要の説明文や機能を利用するための前提条件を記載しています。

６．機能概要「メール-to-ケース（オンデマンドサービス方式）

こちらのスライドでは、メール-to-ケースの処理プロセスを簡単に表現しています。

実際のSalesforce内部の処理はもう少し複雑だと思いますが、お客様に説明が必要な部分だけ抜粋して書いています。

詳細な説明が必要な場合は、別途補足資料を作成するか口頭で説明してください。

７．補足①）受信メールからメールおよびファイルレコード生成処理

次に補足資料として、受信メールからメールや添付ファイルが生成されるまでの処理のイメージを記載しています。

メールオブジェクトと添付ファイルの関係性や保存される主要な項目について説明しています。

８．補足②）メールからケースレコードを生成（取引先責任者と関連付け）

補足②として、先ほどの続きで、メールから今度はケースの作成や取引先責任者との紐づけルールなどについて説明しています。

特に取引先責任者との紐づけに関しては。どういう場合に紐づいて、どういう場合に紐づかないのか明確に説明しておく必要があります。

9.補足③）メール転送時のヘッダ情報（一部）

補足③では、メールtoケースでお客様とメールをやり取りする際にメールのヘッダ情報から送信元の特定やケースの紐づけなどを行うための情報を取得しているため、メールヘッダに登録される一般的な内容を説明しています。

10.補足④）メールヘッダサンプル

補足④では、実際にメールtoケースでやり取りしたメールに含まれているヘッダのサンプルを掲載しています。

11.補足⑤）メールのスレッド化

補足⑤はメールのスレッド化に関するルール（Salesforce公式サイトの内容を説明）

12.組織の制限

メール-to-ケースの機能について、組織の制限を記載しています。

特に大規模システムで多くのお客様からお問い合わせを受け付けるコールセンター業務のような場合には、これらの制限が非常に重要となります。非機能要件の中で要件を満たしているのかしっかり議論してください。

13.注意事項

最後に公式サイトに記載されている注意事項について説明しています。

こちらも重要な事項となるため、どのようなメールのやり取りがされるのか、制限の緩和が必要なのかなど、しっかりと議論する必要があります。

2.ユーザ説明資料「機能概要説明書（メール-to-ケース）のダウンロード

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

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

関係者のみ（PPT版資料）

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

参考

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

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

続きを読む

サポーターさん

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

にほんブログ村

サポーターさん

業務要件定義で業務フローを作成する際に合わせてご利用ください。

業務フロー図のエクセル版は以下の記事からダウンロードしてご利用いただけます。

Excel版

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

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

続きを読む

PPT版

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

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

続きを読む

要件定義書（本体）は以下の記事からダウンロードしてご利用いただけます。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

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

続きを読む

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

３．本書の構成

要件定義書の構成に合わせて修正してください。

※今回は、要件定義書の別紙として定義しているため、上記の構成資料を用意していますが、単独で利用する場合には不要です。

４．目次

必要なビジネスルール（業務ルール）の数に合わせて、目次を定義してください。

５．はじめに（目的・概要）

はじめに本書の作成に関する目的や概要を記載します。※省略しても構いません。

６．ビジネスルール一覧

ビジネスルール定義書の中で、定義するルールを一覧化します。

業務領域、ビジネスルールID、ビジネスルール名、説明など、プロジェクトに合わせて必要な項目の定義を変更してください。

また、業務フロー図と合わせて用いる場合には、業務フロー内で利用している一意の番号を定義しておくとよいでしょう。

７．ビジネスルール（業務ルール）定義

ビジネスルール一覧で定義したビジネスルール（業務ルール）それぞれについて、一つずつ詳細なルール内容を定義します。

上記の例では、物販・飲食・宿泊・輸送などのサービスを対象とした割引制度の例を記載しています。

割引であれば、割引名用や対象とするサービスは何か、適用条件は何か、割引率の計算式は何かといった具合に業務上のルールを明確に定義します。

８．添付ファイル（Appendix）

業務ルールの説明資料の添付ファイルとして利用するものがあれば、添付ファイルの一覧に定義します。

2.要件定義_要件定義書_別紙2「ビジネスルール定義書」（PPT版）のダウンロード

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

一般公開資料

※ダウンロードされるまで少し時間がかかる場合があります

サポーターさん

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

にほんブログ村

サポーターさん

業務フロー図のエクセル版は以前から提供していましたが、PPT版を提供してほしいというご要望が多いため追加で作成しました

業務フロー図のエクセル版は以下の記事からダウンロードしてご利用いただけます。

参考

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

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

続きを読む

要件定義書（本体）は以下の記事からダウンロードしてご利用いただけます。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

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

続きを読む

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

３．本書の構成

要件定義書の構成に合わせて修正してください。

※今回は、要件定義書の別紙として定義しているため、上記の構成資料を用意していますが、単独で利用する場合には不要です。

４．目次

業務フローの構成に合わせて、目次を定義してください。

５．はじめに（目的・概要）

はじめに本書（業務フロー図）の作成に関する目的や概要を記載します。※省略しても構いません。

６．基本用語

資料の文中で利用されている特殊な業務用語やシステム用語について、説明が必要なものはこちらに定義しておきましょう。

７．凡例

業務フロー図として利用する図形についての説明を凡例として記載します。本書では、以下の図をサンプルとして定義しています。

開始、終了、作業、システム操作、プログラム、条件分岐、コメント、帳票、データ、データベース（DB）、遷移、領域定義、プロセスフロー、データフロー

８．業務階層（レイヤー）の定義

最初に業務領域や業務階層を定義します。

上記のように、一般的には業務プロセスは大きく3段階（大分類、中分類、小分類）にレイヤーを分けて、大分類の大きな流れから中小へとブレークダウンして整理するとわかりやすいと思います。

※図で可視化するのが難しい場合は、表形式でまとめても構いません。

９．現行業務一覧（As-Is）

業務フローは、一般的に現行の業務フローと新業務フローの2種類を作成します。まずは現行の業務（As-Is）を整理し、それをベースに新業務フローを検討する流れとなります。

現行業務一覧では、プロジェクトで対象とする業務範囲について、現行業務の担当者からヒアリングしたり、現場視察して作成していきます。

１０．現行業務フロー

現行業務一覧に沿って、それぞれ詳細な業務の流れと作業内容を確認して、業務フロー図を作成していきます。

本書のサンプルでは以下のように各項目を定義しています。※プロジェクトに合わせて適宜変更してご利用ください。

一番左の縦軸はアクター（人やシステムなど作業を行う側）を定義

上の矢印は、作業の時系列を表現します。

一番右側には、作業と紐づけて作業内容をテキストで表現しています。

その他（サンプル）

そのほか、新業務フローについても、同様に業務一覧、業務フローを作成していきます。

テンプレートをダウンロードしてご利用いただくと、現行業務フローと新業務フローのサンプルがそれぞれ含まれておりますのでご利用ください。

サンプルとして業務フロー図を記載していますが、業務フロー図の書き方や粒度はプロジェクトの方針に沿って変更してください。

だれが、なにを、いつ、なんのために行うのか（時系列とアクター）をしっかり意識して抜け漏れがないように作成していきましょう。

2.要件定義_要件定義書_別紙1「業務フロー図」（PPT版）のダウンロード

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

一般公開資料

※ダウンロードされるまで少し時間がかかる場合があります

サポーターさん

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

にほんブログ村

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

要件定義書本編については以下の記事からダウンロード可能です。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

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

続きを読む

1.テーラリングガイド

テンプレートをダウンロード後、テーラリングガイドを参考にご自身のプロジェクトに合わせてカスタマイズしてご利用ください。

1.本書の構成

上記の通り、今回のサンプルでは、要件定義書の別紙5の位置づけで作成しておりますので、上記の構成となりますが、要件定義書の構成に合わせてテスト要件を非機能の中に入れて纏める場合もあると思います。

プロジェクトに合わせて、要件定義書の構成を検討してください。

2.目次

続いて、目次としてテスト方針書の章立て（構成）を定義していいます。

こちらについても、プロジェクトの中で章立てを検討し、目次を変更してください。

サンプルは、比較的中規模程度のプロジェクトで必要最低限の項目を定義していますが、大規模プロジェクトの場合には、より詳細な内容を定義しておくことをお勧めします。

特にスコープ、品質管理、体制・役割については、テスト工程の見積に大きく影響するため曖昧に終わらず、しっかり明確になるまで検討しておく方がよいです。

3.テストの目的・概要

テスト実施の目的と実施期間などテスト全体の概要を記載しておきましょう。

4.テスト範囲（スコープの定義）

自社が担当するテスト範囲を明確にするため、まずは、システム全体構成図の中からスコープを定義するとわかりやすいでしょう。また、スコープ外はどこか明確な場合は、同じようにスコープ外を明記しておくほうがよいでしょう。

システム領域や機能単位でスコープが明確な場合は、具体的に定義しておくほうがよいです。（非機能についても同様）

続いて、テストの前提条件や制約事項について定義します。

5.テストの位置づけ

上記は、Salesforceで構築したシステムの機能要件に対するテストの位置づけを表現したものとなります。

Salesforceのサービス基盤（プラットフォーム）部分と、設定・開発したアプリケーション部分に分けてテスト対象を定義しています。機能要件では、アプリケーション部分のみテスト対象とすることを明記し、各テスト工程でどのようなテストを実施するか説明しています。

今回対象の欄については、プロジェクトに合わせて、どの機能をどのようにテストを行うのか定義します。

内部結合テストについては、処理結合テスト、機能結合テスト、業務結合テストに分けて定義していますが、プロジェクトによって実施範囲ややり方が異なることが多いので、規模や方針に合わせて変更してください。

非機能

非機能についても同様にプロジェクトでのテストの位置づけを定義します。

主に性能テスト、セキュリティテスト、基盤テストについてのテスト観点を定義します。

例では、性能については、基本的にアプリケーション（オンライン、バッチ処理）について記載しています。

※Salesforceのプラットフォーム（基盤）に対しての性能試験（主に負荷試験）を実施する場合は、事前にサポートへ連絡して、作業内容や実施日時についての調整が必要となるので注意が必要です。

6.テスト計画書作成方針

テスト計画書の作成に関する方針を定義します。

テスト計画書として定義する項目（目次）や記載内容（粒度）について定義しておきましょう。

・スケジュール、テスト評価基準の定義、テストの開始・終了条件、テスト実施体制と役割、テスト方法（ツール）、テストデータ、テスト環境、テスト観点、エビデンス作成に関する方針、レビュー実施に関する方針など。

7.テスト環境方針

テスト環境の方針について、各テスト工程（単体テスト、結合テスト、総合テスト、受入テスト、移行リハ）毎にどの環境を利用するか定義します。

どのシステムがどのタイミングでどの環境を利用するのかわかるようにしておきましょう。

同じ環境を他のシステムや他のベンダー担当者が利用する場合もあると思いますが、その場合は占有期間や利用方針を定義しておき、テストに影響がでないように調整しておきましょう。

8.テスト設計方針

テスト設計に関して定義します。

通常は各テスト工程に適したテスト観点表を作成して、内部レビューを実施した上で、テスト設計を行う流れになると思います。

9.テスト担当社方針

テスト担当として、テスト設計を行う担当者とテストの実施を行う担当者についてそれぞれ定義します。

記載例）

テスト設計者については、システムの業務要件、各種テスト技法を把握している者など、設計に必要な知識を要しているものを担当社とする

10.テスト実施概要

テスト実施概要の章では、各テスト工程でのテスト概要を記載します。

11.テストデータ作成方針

テストデータの作成方針では、各テスト工程で、それぞれ作成するテストデータの内容が異なるため、どのようなテストデータを作成するのかわかるように記述しておきます。

例：外部結合テストや統合テスト（システムテスト）については、システムの上流側で生成されるデータを利用する

12.テスト実施体制と役割

テスト工程での関係各社の役割を定義します。

特に他社と共同で行うテスト工程では、テストシナリオやケースの作成やテストデータの作成について、誰がどの範囲を担当するのかを明確にしておきましょう。

お客様については、UAT以外は主に設計や実施結果の報告についてのレビューを実施していただくことが多いと思います。

また、UAT（ユーザ受入テスト）について、シナリオの作成やデータの準備はベンダー側で実施すると考えているお客様がいる場合もあるため、誰が実施するのか協議の上確定し、本書に決定内容を記述しておきましょう。

13.テスト品質管理方針

テスト品質は、非常に重要な内容となります。具体的に定量的に品質評価するための評価方法や、メトリクス、定量指標の決定などに関する基本方針を定義します。

システムの品質管理は、しっかりやるとかなりの工数がかかる作業となり、また品質管理のスキルも必要となります。

テスト品質の管理として、どこまで実施するのか、どの部分は実施しないのか明確にしておきましょう。

14.成果物の定義

最後にテスト工程で作成する成果物を定義しておきます。エビデンスの作成が必要な場合は、具体的にどのようなエビデンスを作成するのか明確に定義しておきましょう。

例：画面のスクリーンショット、システムログの取得など

15.補足資料（Appendix）

テスト要件に関する補足資料がある場合は、追加するか別紙として定義しておきましょう。

2.テスト方針書（PPT版）テンプレートのダウンロード

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

資料ダウンロード

2.まとめ

テスト方針書についてはこちらの記事を参照ください。

参考

テスト方針書（PPT版テンプレート）サンプル

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

続きを読む

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

サポーターさん

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

にほんブログ村

パワーポイントテンプレートは、本サイトをご利用のユーザ様の自社テンプレートやお客様のテンプレート、コーポレートカラーの違い、サイズ（通常、ワイド版）などに近いものをご提供できるように今後もどんどん増やしていきたいと思います。

業務フロー図/業務プロセスのサンプル

マスタスケジュール（パワーポイント）のテンプレート

ワイド版（１６：９）

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

（ダークモード）

凡例

【凡例】に記載の打ち合わせやレビューのアイコンは、PPTのツールバー標準（Microsoft社）のアイコンを利用してます。

必要に応じて、変更してご利用ください。

マスタスケジュール（PPT版）のダウンロード

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

一般公開資料

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

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

サポーターさん

スライドはダウンロードしてからご利用ください

ワイド版（16:9）

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

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

サポーターさん

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

にほんブログ村

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

※テスト方針書と合わせてテスト計画書が必要な方は以下の記事よりダウンロードいただけます。

参考

テスト計画書（結合テスト）（PPTテンプレート）サンプル

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

続きを読む

テスト方針書の詳細な説明や利用方法については、以下の記事を参考にしてください。

参考

テスト方針書の作成（前編）はじめに~テスト環境方針

今回の記事では、全体テスト方針書の作成方法について説明したいと思います。 テスト…

続きを読む

1.テーラリングガイド

１．テスト方針書の構成

サンプルでは、テスト方針書とその他添付資料を分けて定義していますが、方針書のPPTにすべて記述しても構いません。

２．基本事項

基本事項に関しては、テストの構成などを定義していますが、事前にお客様を含め関係者で認識合わせをしておくべき事項について、纏めるとよいでしょう。

３．テスト範囲

3章のテスト範囲については、テスト対象とするシステム・機能領域を明確にします。システム構成図を使ってわかりやすく説明するとよいでしょう。

また、複数ベンダーで開発を行う場合には、各社の責任範囲を明確にするためにも、どの領域をどのベンダーが対応するのかわかるように図示してください。

以下、詳細な機能や非機能に関しては、具体的な機能名や処理名を記載するようにしましょう。

4.テスト方針

4章のテスト方針は、テスト方針書のメインページとなります。方針として定義するべき内容に抜けもれがないようにしましょう。

サンプルの例では、テスト環境方針、担当者方針、設計方針、実行方針などについて記述をしています。

またテストで利用するツールがある場合には、ツールの概要や利用シーンなどを方針として纏めるとよいでしょう。

テスト実施方針のところでは、特に非機能について、どこまで実施するか方針の段階で明確にしておきましょう。

また実施方法や指標値についても合わせて検討してください。

テストの作業内容や成果物の作成などについては、お客様含め各社でどのような役割分担で進めるのかを明確にします。

5.管理方針

管理方針では、進捗や品質管理などに関しての方針を記述します。

テストの進捗管理方法もプロジェクトによって異なると思いますが、以下の例では、総テストケースに対しての消化ケース数で進捗率を算出しています。

進捗管理表を用いて、サマリーやグラフを使って可視化するとわかりやすいのでお勧めです。

進捗管理表は、こちらからダウンロードしてご利用いただけます。

参考

テスト進捗管理表（Excelテンプレート）サンプル

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

続きを読む

品質管理

品質管理については、品質要素と品質水準を明確に定義しておきましょう。

以下の例では、品質要素として、テスト密度とバグ密度を用いています。それぞれ過去のプロジェクトなどを参考にして、指標値を設定しましょう。

バグ（故障管理）についても、管理表を用いて管理をするのか、ツールやサービスを用いて管理するか、検出したバグに対して、改修状況を確認するだけではなく、バグの傾向分析を行って、関連する機能については横展開での対応など、次のアクションにつなげるためのプロセスも検討しましょう。

2.まとめ

テーラリングでは、一部のページに対しての簡単な説明のみとなりますが、より詳細な説明やテスト方針書の利用方法を知りたい方は、以下の記事を参考にしてください。

参考

テスト方針書の作成（前編）はじめに~テスト環境方針

今回の記事では、全体テスト方針書の作成方法について説明したいと思います。 テスト…

続きを読む

サポーターさん

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

3.テスト方針書（ＰＰＴ版）テンプレートのダウンロード

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

一般公開資料

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

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

サポーターさん

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

にほんブログ村