PPT &#8211; AI開発実践ラボ

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

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. 成果物/納品物

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

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

参考

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

3. スケジュール

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

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

参考

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

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

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

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

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

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

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

参考

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

4. 体制と役割

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

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

参考

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

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

一般公開資料

プロジェクト計画書（PPT版）のダウンロードはこちら

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

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

関係者用資料

プロジェクト作業工程と成果物の定義（PPT版）のダウンロードは別途関係者用ページからご確認ください

サポーターさん

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

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

セールスフォース標準化推進ラボ — Sun, 27 Nov 2022 07:40:39 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したプロジェクト計画書の体制図・役割と担当範囲のマトリクス表などのパワーポイント（PPT）版のテンプレートをご提供しております。

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

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

サポーターさん

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

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

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

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

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

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

４．担当者の役割定義

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

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

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

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

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

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

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

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

一般公開資料

プロジェクト計画_プロジェクト体制図・役割表(ワイド版16：9)（PPT版）のダウンロードはこちら

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

サポーターさん

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

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

セールスフォース標準化推進ラボ — Wed, 23 Nov 2022 09:15:27 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したプロジェクト計画_プロジェクト作業工程と成果物の定義のパワーポイント（PPT）版のテンプレートをご提供しております。

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

サポーターさん

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

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．利用規約

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

３．改訂履歴

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

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

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

４．目次

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般公開資料

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

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

関係者用資料

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

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

サポーターさん

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

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

要件定義_ユーザ説明資料_メール-to-ケース（Mail-To-Case）機能概要説明」ダウンロード

セールスフォース標準化推進ラボ — Sun, 09 Oct 2022 06:44:53 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供するユーザ説明資料「メール-to-ケース（Mail-To-Case）の資料の説明とダウンロード方法を説明いたします。

サポーターさん

メール-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版資料）

要件定義_ユーザ説明資料_機能概要説明資料「メール-to-ケース」_(BIZ UDPゴシック)_2021008_v1.0
（PDF版）のダウンロードはこちら

関係者のみ（PPT版資料）

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

参考

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

サポーターさん

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

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

要件定義_要件定義書_別紙2「ビジネスルール定義書」（PPT版）サンプル

セールスフォース標準化推進ラボ — Sun, 02 Oct 2022 09:14:31 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要件定義書_別紙2「ビジネスルール定義書」_(ワイド版16：9)のパワーポイント（PPT）版のテンプレートをご提供しております。

サポーターさん

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

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

Excel版

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

PPT版

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

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

参考

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

３．本書の構成

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

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

４．目次

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

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

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

６．ビジネスルール一覧

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

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

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

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

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

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

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

８．添付ファイル（Appendix）

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

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

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

一般公開資料

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

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

サポーターさん

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

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

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

セールスフォース標準化推進ラボ — Sat, 24 Sep 2022 10:57:47 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要件定義_要件定義書_別紙1「業務フロー図」のパワーポイント（PPT）版のテンプレートをご提供しております。

サポーターさん

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

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

参考

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

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

参考

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

３．本書の構成

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

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

４．目次

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

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

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

６．基本用語

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

７．凡例

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

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

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

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

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

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

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

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

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

１０．現行業務フロー

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

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

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

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

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

その他（サンプル）

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

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

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

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

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

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

一般公開資料

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

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

サポーターさん

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

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

要件定義書（別紙5）「テスト要件定義書」（PPT版テンプレート）サンプル

セールスフォース標準化推進ラボ — Sun, 18 Sep 2022 09:12:56 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要件定義書の別紙5「テスト要件定義書」（PPT版）のテンプレートの利用手順とダウンロード方法をご説明いたします。

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

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

参考

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

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

資料ダウンロード

要件定義_要件定義書_別紙4「テスト要件定義書」_(ワイド版16：9)（PPT版）のダウンロードはこちら

2.まとめ

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

参考

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

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

サポーターさん

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

プロジェクトマスタスケジュール（PPTテンプレート）

セールスフォース標準化推進ラボ — Wed, 29 Dec 2021 00:10:38 +0000

プロジェクト計画書やテスト計画書など各種計画書で必要となるマスタスケジュールのテンプレートサンプルをご用意いたしました。

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

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

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

ワイド版（１６：９）

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

（ダークモード）

凡例

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

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

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

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

一般公開資料

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

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

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

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

サポーターさん

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

ワイド版（16:9）

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

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

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

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

サポーターさん

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

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

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

セールスフォース標準化推進ラボ — Sat, 27 Nov 2021 08:41:43 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したテスト方針書（PPT版）のテンプレートをご提供しております。

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

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

参考

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

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

参考

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

1.テーラリングガイド

１．テスト方針書の構成

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

２．基本事項

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

３．テスト範囲

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

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

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

4.テスト方針

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

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

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

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

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

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

5.管理方針

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

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

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

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

参考

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

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

品質管理

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

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

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

2.まとめ

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

参考

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

サポーターさん

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

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

一般公開資料

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

テスト方針書（PPT版）のダウンロードはこちら

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

テスト方針書（PPT版）のダウンロードはこちら

サポーターさん

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