要件定義 &#8211; AI開発実践ラボ

1.はじめに

申し送り事項一覧に関しては、前の工程で決まり切らなかった仕様や課題などについて、後工程で検討するために記録して残しておくものとなります。

要件定義工程では、要求事項を取り纏めますが、詳細な設計などについては、設計工程以降で検討する内容となりますので、申し送り対象として記録しておきます。

そのほかには、本来要件定義で決めるべきものが、決めきれなかったりした場合にも後続フェーズで引き続き検討が必要な場合がありますので、この場合にも申し送りとして記録しておきます。

1.申し送り事項一覧（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

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

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

情報種別：社外秘など

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

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

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更（例では、「移行要件定義書」として設定）

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

2.改訂履歴

3.本書の構成

プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

もしくは、要件定義以外でも申し送り事項として利用する場合もあると思いますので、その場合本書の構成は不要であれば削除してご利用ください。

4.申し送り事項一覧

申し送り事項について、一覧形式で以下の内容を記録していきます。

No.：シーケンスで番号を登録しておきます。
カテゴリ：申し送りの種別（課題、仕様検討、タスクなど）を定義します。複数のカテゴリが必要であれば列を追加して大中小などで管理してください。
件名：申し送りの内容がすぐにわかるようにタイトルをつけておきます。
申し送り内容：申し送りの内容を記入しますが、後工程で担当者が変わる場合には内容がわかるように丁寧に記載しておく必要があります。
申し送りの経緯（理由）：申し送りとなった経緯や理由があれば記載しておきます。
起票者：申し送りを記入した担当者の名前を記入
起票日：申し送りを記入した日付を入力
承認者：申し送りの内容について承認した方の名前を記入します。（基本的にはお客様のプロジェクト責任者を記入）
承認日：申し送りの内容が承認された日付を入力
備考：備考があれば記入

以上となりますが、上記以外に必要な添付ファイルがあれば、別紙や補足資料としてページを追加しておきましょう。

2.テンプレートのダウンロード

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

一般公開資料（PPT版）

要件定義_要件定義書_別紙9「申し送り事項一覧」（Excel版）のダウンロード

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

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

まとめ

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

参考

サポーターさん

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

Salesforce導入プロジェクト要件定義書_別紙4「非機能要件定義書」テンプレート

Salesforce導入プロジェクト要件定義書_別紙6「移行要件定義書」テンプレート

セールスフォース標準化推進ラボ — Sun, 05 Mar 2023 08:34:09 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供する要件定義書_別紙6「移行要件定義書」の資料の説明とダウンロード方法を説明いたします。

非機能要件定義書が必要な方は、こちらの記事からダウンロードいただけます。

参考

データおよびストレージリソースの監視（https://help.salesforce.com/s/articleView?id=sf.admin_monitorresources.htm&type=5）

1.はじめに

要件定義工程で実施する移行要件定義は、後続の工程で作成する詳細な移行計画を立てるために必要な要件を確認することが目的となります。また、移行作業に必要な要員や作業工数を見積するためにも必要なものとなります。

本サイトで提供している移行計画書のテンプレートでは、まず必要となる最低限の移行要件を確認するための書式となっております。業務やシステムの範囲が膨大で、他システムも多く、複雑なシステムの場合には、追加で検討しておくべき内容もありますので、その場合にはテンプレートに必要な事項を追加して要件定義を実施してください。

1.非機能要件定義書（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

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

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

情報種別：社外秘など

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

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

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更（例では、「移行要件定義書」として設定）

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

2.改訂履歴

3.本書の構成

プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

別紙とせず、非機能要件定義書の移行要件の中に入れても大丈夫です。

4.目次

目次は、移行要件定義書の章立てに合わせて適宜修正してください。

本サンプルでは以下の目次構成としてます。

章	タイトル	説明
1．	はじめに
1-1.	概要	移行の目的と概要
1-2.	前提条件・制約事項	前提条件と制約事項
2．	移行要件
2-1.	移行の位置づけ	本プロジェクトに関する移行の位置づけを定義
2-2.	移行時期	移行時期（スケジュール、マイルストーン）を定義
2-3.	展開方式	移行の展開方式について定義
2-4.	移行範囲（スコープ）	移行の作業範囲について定義
2-5.	移行計画書作成方針	移行計画書の作成方針
2-6.	環境用方針	移行環境の利用方針
2-7.	移行に伴う影響範囲の特定と対策	移行に伴う影響範囲と対策を定義
2-8.	移行設計方針	移行ツールの設計方針について定義
2-9.	移行データ作成方針	各移行工程で作成する移行データの作成方針
2-10.	移行リハーサル方針（計画、実施、評価）	移行リハーサルの実施方針を定義
2-11.	教育実施方針	システム操作トレーニングなどの教育について定義
2-12.	移行実施体制と役割	移行実施体制と役割を定義
2-13.	移行工程の成果物	各移行工程の成果物を定義
3.	補足資料
3-1.

5.はじめに（概要、目的）

最初に、本書の位置づけや目的について概要として纏めています。

参考

1.本書の位置づけ

本書は、Salesforce導入プロジェクトにおいて、旧システムから新システム（Salesforce）への業務、システム,、及びデータの移行に関する

要件を取り纏めたものとなります。

2.背景と目的

※移行の背景と目的について説明（移行によって得られるメリットや期待される成果について）します。

6.前提条件・制約事項

続いては、移行にあたっての前提条件や制約事項を記載します。

参考

（１）移行要件の作業範囲（検討範囲）　※当初お見積り（提案書）の内容に基づき記載

①新システムの利用にあたっての教育

担当者向け：オンラインでＮ回実施、システム管理者向け：対面でＮ回実施

②移行リハーサルの実施

移行リハーサルに関しては、2回までの実施とする。

③移行対象データ

移行対象のデータは、以下Ｎ個のデータ（CSVファイルベースでN個）までとする。

④移行プログラムの作成について

本プロジェクトでは、移行対象プログラムは作成せず、Salesforce標準のデータ移行ツール（Dataloader）を利用する前提とする。

（２）移行作業における役割分担

①移行計画書については、弊社主体で作成し、貴社及び関係各社にて内容のレビューを実施していただく。

②既存システムからのデータ抽出及びクレンジング（不要なデータの削除や補正作業など）は貴社にて実施していただく。

③…

上記のように、基本的には当初提案した内容（お見積りの前提）に基づいて、前提条件を記載し、移行作業にあたっての制約事項（環境や端末の制限など）があれば追加します。

7.移行の位置づけ

移行要件の最初は、本書で扱う移行の定義について記載しています。

本サンプルでは、移行を以下のように定義しています。

参考

1.業務移行：新システムを用いた新業務フローへの業務運営に切り替えること。業務運営の切り替えにあたっては関係各所への教育（システムの操作含む）を実施し、新業務の切替後、滞りなく業務運営が行えるようにすること。

2.システム移行：新システムを利用可能な状態（必要なプログラムを本番環境へ移行し、運用開始のための設定変更を実施）にして、旧システムを停止後、新システムの運用に切り替えること。

3.データ移行：既存システムや外部システムから抽出した各種データを新システムに取り込み可能な様式に変換し、データ移行用プログラムを使って、データの取り込みを実施すること。

[/st-cmemo]

8.移行時期（全体スケジュール）

移行時期（全体スケジュール）については、基本的に当初のマスタスケジュールをベースに作成します。

特に移行に関するスケジュールは作業内容（工程、担当者、作業内容、実施時期など）を分かりやすく記載するとよいでしょう。

9.移行時期（マイルストーン）

全体スケジュールの線表の中で定義したマイルストーンについて、具体的な時期や内容を纏めます。

本書では、以下の内容を参考例としています。

参考

1.移行計画書作成時期： XXXX年XX月XX日

2.計画書レビュー時期、回数： XXXX年XX月XX日

3.移行プログラム（設計・開発・テスト）※必要な場合：

4.移行データの作成（貴社主体作業）：

5.移行リハーサル実施計画：

6.移行リハーサル実施と検証：

7.移行作業手順書作成（更新）時期：

8.移行リハーサル結果取り纏め（報告）

9.稼働判定会議（切替の承認）

10.移行本番作業実施

11.移行後の確認作業と報告

[/st-cmemo]

10.展開方式

展開方式に関しては、一般的な移行方式を提示したうえで、プロジェクトで求められる要件に基づき適切な展開方式を検討する必要があります。

それぞれメリット、デメリットがありますが、お客様の業務への影響やコストなど制約事項を勘案して検討する必要があります。

記入例

参考

本プロジェクトでは、業務の特性上、全国一斉での切り替えが難しいため、各ブロック（拠点）毎に段階的に移行の方針とする。

具体的な段階移行に関するスケジュールや段取りは移行計画書の中で詳細化する。

【一般的な移行方式の種類】

1.一括移行方式：現行システムから新システムに全機能（業務）を一気に切り替える方式。

メリット：作業が1回で終わるためコスト（工数）が少なくて済む、スケジュール調整がしやすい、移行後のリカバリーが比較的容易

デメリット：一括移行のため、失敗した際に業務に対する影響範囲が大きい。

適合する条件：長時間のシステム停止が可能なこと。

2.段階移行方式：業務単位や拠点単位などに分けて、順次移行作業を実施すること。

メリット：一括移行が難しい煩雑なシステムやデータ量が大量な場合、業務範囲が広い場合などに部分的に移行ができるため調整がしやすい。

部分的に移行していくため、失敗時のリスクが一括移行よりも低い

デメリット：一括移行よりもコストが多く、作業時間や手間が増える。

3.平行運用方式：現行システムを利用しながら新システムを平行して利用する方式。

メリット：最大のメリットは新システムに問題が発生した際も現行システムを利用しての運用が可能なため、移行失敗のリスクが最小限となる。

デメリット：現行システムと新システムの両方で操作が必要なため、2重入力となり、業務負荷が高い。新旧システムの入出力の比較を行うため

移行にかかるコストや手間は一番高くなる。

[/st-cmemo]

11.移行範囲

移行範囲では、業務、システム、データの領域ごとに、それぞれの移行範囲を定義しています。

まずは、大枠での移行範囲を定義し、詳細な移行対象については、それぞれ領域ごとに細かく定義しています。

最初に業務移行についての対象を定義します。業務分類（大分類、中分類、小分類）に分けて、移行対象とする業務は何かを明確にします。

続いて、システム移行についての対象を定義します。

Salesforceのシステム移行については、上記のように、ある程度メタデータの種類や内容が決まっています。メタデータ全体の中からプロジェクトで利用した（移行対象）を定義します。

最後にデータ移行についての対象を定義します。

データ移行では、移行対象のデータ（件数）と合わせて、移行方式や形式、文字コード、キー項などの属性も合わせて定義しておきましょう。

また、想定データ件数については、後続のデータ容量算出の際に必要となるため、移行対象データの件数以外にも、年間の増分なども確認しておきましょう。

12.データ移行にあたっての容量試算

Salesforceのデータ容量の算出方式を提示し、今回の移行対象のデータ容量と将来の増分でデータストレージの容量の算出を行います。必要があればファイルストレージについても算出します。

（データ量の試算方法）

Salesforceでは、1レコードの項目数にかかわらず、1レコード＝2KBとしてストレージ容量の計算が行われます。

各組織にはデフォルトで10GBのストレージ(※1)が用意されており、ユーザライセンスを追加購入する毎にストレージ容量が加算される仕組みとなっています。

1ユーザライセンス当たりの追加容量はライセンスの種類によって異なります。

また、ファイルストレージも同様に組織ごとに最小で10GB(※1)が割り当てられ、ユーザライセンスを追加する毎に容量が加算される仕組みとなります。

※1.割り当てられる最小ストレージの容量は、組織ライセンスによって異なります。

ストレージ容量の最小割り当てとライセンスによる追加の詳細に関しては、以下公式のHELPサイトにてご確認ください。

13.移行計画書作成方針

移行計画書の作成方針では、後続の工程で作成する移行計画書に記載するべき事項を定義しておきます。

上記のように記載内容を定義することで、計画書作成に必要な作業工数の見積が可能となります。

14.環境利用方針

移行作業（UATや教育、移行リハーサルなど）について、環境の利用方針を定義します。詳細は移行計画の中で確定していくことになると思いますが、外部連携など必要な場合には連携先システムの環境情報についても事前に確認しておくとよいでしょう。

また上記の図の他に、具体的な環境情報（システム、環境名、利用用途、利用者、利用次期）について表などにまとめるとよいでしょう。

15.移行に伴う影響範囲の特定と対策

移行作業でのシステム停止や新業務への切り替えに伴い発生する業務影響などを調査し、事前に対策を検討する必要があります。

16.移行設計方針（移行ツール）

移行ツールを利用する場合の設計方針を記載します。

以下の例では、システム移行では、Salesforceの変更セットを利用したリリースを実施することと、データ移行に関しては移行専用ツールは作成せず、Dataloaderを使った手動の移行を行う方針とし、データのマッピングなどを設計段階で実施することとしています。

17.移行データ作成方針

移行データ作成方針では、基本的にシステムの上流側でデータを作成するという方針としています。

また図の例では、移行対象データの作成の流れを記載し、誰がどの作業を実施するのかを明確に定義しています。※より詳細な作業内容は移行計画書で定義します。

18.移行リハーサル実施方針

移行リハーサルの実施に関して、目的、実施内容、検証方法などを定義します。

リハーサルの実施回数なども見積工数に影響するため明確にしておくとよいでしょう。例えば、基本的に移行リハーサルは2回実施し、1回目で検出した課題や問題をクリアして2回目を実施し、予定通りの結果となった場合に終了とする。結果によっては、再度3回目移行のリハーサルを実施する。など

19.教育・トレーニング

教育の方針について、システムが変更になることの概要の説明や業務内容の変更点については、お客様から一般ユーザの方へ説明いただくとよいでしょう。

その後、システムの全体概要を説明し、実際のシステムをハンズオンで操作しながら習得していただくというやり方が一般的です。

教育の実施内容については、回数や対象者数を確認　※1名と10名では必要な時間や講師の数が異なるので必ず確認しましょう。

また実施については、オンラインなのか、出張で現地まで行って対面でやるのかについても明確にしておきましょう。

続いて、トレーニングで利用する操作マニュアルについての章立ても確認しておきます。※作成するページ数によって作業工数の見積が変わるため。

上記のように管理者向けと一般ユーザ向けの2つを作成することが多いですが、ユーザ向けについては、複数の種類を作成する場合もあるため必要な種類を確認しておきましょう。

20.体制と役割

移行に関連する作業について、工程と作業内容ごとに各社の役割を明確にしておきましょう。

21.成果物定義

最後に移行に関する成果物を定義します。作成する成果物とその内容を記載します。

以上となりますが、上記以外に必要な添付ファイルがあれば、別紙や補足資料としてページを追加しておきましょう。

2.テンプレートのダウンロード

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

一般公開資料（PPT版）

要件定義_要件定義書_別紙6「移行要件定義書」（PPT版）のダウンロード

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

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

まとめ

参考

サポーターさん

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

要件定義_ユーザ説明資料_Salesforceセキュリティとデータアクセス（権限）」ダウンロード

セールスフォース標準化推進ラボ — Sat, 18 Feb 2023 11:22:00 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供するユーザ説明資料「Salesforceのセキュリティとデータアクセス（権限コントロール）の説明と資料のダウンロード方法を説明いたします。

サポーターさん

ロールやプロファイルを使った機能やデータアクセス制御などについて説明します

Salesforceの導入が初めてのお客様などへの説明用資料としてご活用いただければ幸いです。

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

１．表紙

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

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

情報種別：社外秘など

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

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

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

（例ではセキュリティとデータアクセスとなっています）

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

２．改訂履歴

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

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

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

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

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

（記入例）本書は、Salesforceのセキュリティとデータアクセス（権限制御）の機能に関する概要の説明を行うことを目的として作成しています。※機能に関しては、2023年1月1日時点で提供されている内容となるため、それ以降に変更が発生した場合には、適宜Updateの内容に合わせて本書の当該事項について修正させていただきます。

４．目次

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

（目次の例）

セキュリティとデータアクセス概要
Salesforceのセキュリティとデータアクセス
セキュリティとデータアクセス（全体像）
外部からSalesforceへのアクセス制御
組織レベルのセキュリティ（IPアドレス制限）
組織レベルのセキュリティ（ログイン時間の制御）
組織レベルのセキュリティ（API制御）（接続アプリケーション）
組織レベルのセキュリティ（デバイス端末管理）
Salesforce組織内部のセキュリティ/アクセス制御
Salesforceの操作や機能に対する権限コントロール
プロファイル(操作や機能アクセス制御）
権限セット（操作や機能アクセス制御)
権限セットグループ
組織の共有設定
ロール階層を用いたアクセス権の制御
共有ルールを用いたアクセス制御
レコードの個別共有

５．Salesforceのセキュリティとデータアクセス

はじめにセキュリティとデータアクセスの内容について纏めています。

【外部からのアクセス制御】
　・組織レベルのアクセス制御：外部のシステム/端末などからSalesforce組織へのアクセス制御
【Salesforce組織内部のセキュリティやデータアクセス制御】
　・オブジェクトレベル：Salesforceのオブジェクト（RDBのテーブルと同義）に対するユーザのアクセス制御
　・項目レベル：Salesforceのオブジェクト内の項目（フィールド）に対するユーザのアクセス制御
　・レコード単位：Salesforceのオブジェクトや項目ではなく、作成されたレコードに対するアクセス制御

６．Salesforceのセキュリティとデータアクセス（マトリクス表）

Salesforceのデータアクセスに関するセキュリティコントロールについてのサマリーを上記のようにまとめています。

外部からのアクセス制御とSalesforce組織内部のアクセス制御の大きく2つの分類に分けています。さらに、それぞれの分類の中で、セキュリティレベル、制御単位、セキュリティ機能、機能説明について記載しています。

それぞれの内容について詳細は、次の章移行で具体的に説明をします。

７．組織レベルのセキュリティ（IPアドレス制限）

IPアドレスの範囲（ホワイトリスト）を設定することで、アクセス元のIPアドレスを制限することが可能となります。

組織単位でIPアドレスを制限する場合は、アクセスしているIPアドレスを含めるように設定しないと、誰もアクセスできなくなってしまうため注意が必要

８．組織レベルのセキュリティ（ログイン時間の制御）

プロファイル（ユーザレベルで設定する権限機能）によりログイン時間を制限することができます。

ログイン可能な曜日と時間帯（開始から終了）の指定が可能

上記の図では、日曜日は終日ログイン不可とし、月曜日は午前9時から午後6時までログイン可能としている。

それ以外の曜日は、24時間いつでもログイン可能な設定となる。

9.組織レベルのセキュリティ（APIアクセス制御）（接続アプリケーション）

API や標準プロトコル (SAML、OAuth、OpenID Connect等)を使用して、外部アプリケーションを Salesforce

に統合（セキュアに接続）できるようにする仕組み

図の例では、 CircleCIからOAuthを利用してSalesforceに接続するための設定例となります。

接続アプリケーション画面からコンシューマキーキーの情報なども確認することが可能で、この情報を使ってCircleCIから接続するための設定を行う。

10.組織レベルのセキュリティ（デバイス端末管理）

デバイス端末の管理として、モバイル端末でSalesforceネイティブアプリケーションを利用している場合、デバイス端末ごとにSalesforceへのログインアクセス制限を設けることができます。

※本機能を利用する場合は、権限セットを使ってユーザに必要な権限を付与する必要があります。

詳細は、以下、Salesforce公式Helpサイト「モバイルデバイス追跡」を参照（https://help.salesforce.com/s/articleView?id=sf.security_device_management.htm&type=5）

モバイル端末からのアクセスは、ユーザデバイス（Userdevice）オブジェクトに記録されます。

以下のような情報がログとして残ります。

ユーザ名、名前、状態、デバイス種類、プラットフォームまたはOS種別
デバイス固有ID、プラットフォームまたはOSバージョン、最終アクセス日時、作成日

11.Salesforceの操作や機能に対する権限コントロール

Salesforceで利用可能な機能や操作を制限する場合やデータのアクセスを制御したい場合

ロール/プロファイル（権限セット）/公開グループといった権限コントロールの機能を組み合わせて利用することで実現

制御種別：「操作や機能アクセス制御」と「レコードに対するアクセス制御」の2対の軸で分類しています。

機能名：具体的な権限コントロール機能（プロファイル、権限セット、組織の共有設定、ロール、共有ルールなど）

説明：それぞれの権限コントロール機能に関する説明など

12.プロファイル(操作や機能アクセス制御）

プロファイルについての説明資料となります。

「プロファイルはユーザ作成時に必ず1つ指定する必要があります。(変更も可能）ユーザはシステムにログイン後、設定されたプロファイルにより利用可能な機能や操作、データへのアクセスが制御されます。」

12.プロファイル(オブジェクトへのアクセス制御）

プロファイル毎に標準オブジェクト/カスタムオブジェクトへのアクセス権（参照・作成・編集・削除）を設定することができます。

13.プロファイル（設定可能な項目）

プロファイルで設定可能な項目と具体的な設定例

（一部のみ記載しているため全て説明したい場合はSalesforce公式サイトでご確認ください。）

14.プロファイル（機能・操作の権限コントロール例）

プロファイルによる機能・操作権限の制御について、画面やレコードのイメージで説明しています。

例えば、アプリケーションの表示やデフォルトの表示制御、タブの表示制御、オブジェクト毎にプロファイルで利用可能なレコードタイプの制御など

15.権限セット（操作や機能アクセス制御)

プロファイルを持つユーザに対して、当該プロファイルで保持していない権限を追加で特定のユーザだけに付与したい場合には、権限セットを利用して、ユーザに追加の権限を付与することができます。

16.権限セットグループ

権限セットを複数ユーザに対して付与したい場合には、権限セットを纏めた権限セットグループを作成して付与することも可能。　例では、権限セットグループを運用担当者Bに付与するイメージ

17.権限セットに関する補足

権限セットのオブジェクト設定（オブジェクトに関する権限の設定画面）方法（イメージ）

以下のようにオブジェクトのタブの設定やオブジェクト権限の設定、項目アクセス許可の設定が可能

18.組織の共有設定（1/3）

組織の共有設定：オブジェクト（テーブル）毎に公開/非公開の設定を行う。組織内部と外部でそれぞれ分けて設定が可能(※1)

非公開：基本的にデータの所有者のみ参照・編集が可能（例外：すべてのデータの参照権限を持つものは参照可能）

公開：公開の場合はすべてのユーザが参照・編集可能となる。公開には種類があり

（①公開/参照のみ、②公開/参照/更新可能、③公開・参照/更新/所有権の移転）

そのほか、主従関係の子オブジェクトに関しては、親の設定に依存する（親レコードに連動）を指定可能

19.組織の共有設定（2/3）

組織の共有設定を【非公開】とした場合のアクセス権限の説明例

【レコードの所有者について】

レコードを新規作成した際には、指定がない場合、デフォルトで作成者＝所有者が設定されます。

所有者は、所有権の移転ができるため、3つ目のレコードのように担当者Ｃが作成したレコードを担当者Ａに所有権を移転することで担当者Ａは当該レコードへアクセスすることができるようになります。

取引先は非公開のため、所有者のみアクセス可能（担当者Aが所有するレコードは上記のうち2つ（山田太郎、山田はなこ）について参照・編集が可能　※データ移行の際は、所有者について注意が必要

20.組織の共有設定（親レコード連動）（3/3）

主従関係の子オブジェクトで、親の設定に依存する（親レコードに連動）を指定した場合

親レコードに連動の場合には、親レコード（上記の例では取引先のレコード）に対する権限と同じ権限が子オブジェクトのレコードに対して適用されます。

そのため、担当者Aは、非公開の取引先レコードで、株式会社ABCと合同会社１２３に対して、アクセス権限があるため、その子レコードである（取引先責任者）の山田太郎、田中一郎、山本次郎の3レコードに対してアクセスすることが可能となります。

21.ロール（ロール階層を用いたレコードのアクセス権の付与）（1/2）

ロール（ユーザグループの階層を定義）を使うことで、下位ロール階層のユーザが所有するレコードを上位階層のユーザがアクセスすることができるような権限設定が可能となります。

第一階層の営業本部、本部長は第二階層、第三階層の全てのデータにアクセスできるような設定となっている。

第二階層の西日本統括部は大阪営業所のデータのみアクセス可能、東日本の場合は東京と埼玉営業所へのアクセスが可能

第三階層は、各ユーザが所有するデータのみ参照可能

22.ロール（ロール階層を用いたレコードのアクセス権の付与）（2/2）

非公開のオブジェクトに対して、ロール階層のアクセス制御を許可することで、以下のような権限設定が可能となる。

非公開オブジェクトのため、基本的にはレコードの所有者のみアクセス可能となるが、ロール階層によるアクセスを許可した場合には、レコードの所有者が所属するロールの上位階層のロールに所属するユーザは、下位ロールのユーザが所有するレコードに対して参照（または参照/編集）のアクセスが可能となる。

上記の例では、東京と千葉ロールの担当者Ａと担当者Bが所有する株式会社ＡＢＣと株式会社XYZのレコードについて、関東ロールの管理者Ｘはそれぞれ参照（または参照/編集）が可能となる、さらに上位の本社担当は、関東の管理者Xが持つ合同会社123のレコードも含め3つのレコードすべて参照（または、参照/編集）が可能となる。

23.共有ルール（レコードのアクセス権の付与（ロールを利用した場合））

ロールはユーザの上下階層のアクセス権限を拡張しましたが、横軸などのアクセス権限を拡張する場合には、共有ルールを使用します。共有ルールを使うことで、特定の条件のレコードをロールグループや公開グループ（ロールとは異なる組織にとらわれない自由なユーザグループ）に対してレコードを共有する仕組みを構築することができます。

24.共有ルール（レコードのアクセス権の付与（公開グループを利用した場合））

公開グループ（ロールとは異なる組織にとらわれない自由なユーザグループ）を使った共有ルールの設定例

25.共有ルール：補足（ロール＆共有ルールを使ったアクセス制御）

非公開オブジェクトに対して、縦のアクセス制御（ロール）と横のアクセス制御（共有ルール）を組み合わせることで柔軟な

アクセス権の設定が可能となります。

26.レコードの個別共有

ロールや共有ルールは、レコード作成時に自動的に条件に基づき共有アクセス権限を付与する仕組みですが、レコードを作成後に自身が所有するレコードを他のユーザやグループに対して個別に手動で共有することも可能です。

共有先は、ユーザ、カスタマーポータルユーザ、チャネルプログラム、パートナーユーザ、ポータルロール、ポータルロール&下位ロール、ロール、ロール内部＆ポータル下位ロール、公開グループから選択可能

27.（補足）データアクセス権限の設定の流れ

データアクセス権限の設定手順としては、まず、オブジェクト毎のレコードをユーザ全員で共有するか、しないかを検討します。

全員で共有する場合は組織の共有設定を公開とし、それ以外は一旦非公開（自分の所有するデータは自分のみアクセス可能）

とする。

非公開場合には、基本的にレコードの所有者のみしかアクセスできない（システム管理者を除く）

そのため、ロールを用いたユーザ階層の共有権限の拡張や、共有ルールを用いてユーザやグループ間での共有を定義する

2.ユーザ説明資料「機能概要説明書（Salesforceセキュリティとデータアクセス）」のダウンロード

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

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

要件定義_ユーザ説明資料_機能概要説明資料「Salesforceセキュリティとデータアクセス」（PDF版）のダウンロード

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

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

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

関係者のみ（PPT版資料）

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

参考

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

サポーターさん

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

Salesforce導入プロジェクト要件定義書_別紙4「非機能要件定義書」テンプレート

Salesforce導入プロジェクト要件定義書_別紙4「非機能要件定義書」Excelテンプレート

セールスフォース標準化推進ラボ — Sun, 23 Oct 2022 14:30:57 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供する要件定義書_別紙4「非機能要件定義書」の資料の説明とエクセル版のテンプレートのダウンロード方法を説明いたします。

PPT（パワーポイント版）のテンプレートはこちらで提供しています。

参考

1.はじめに（非機能要件の検討にあたって）

非機能要件の検討にあたっては、非機能要求事項の全体像を把握している必要があると思います。

非機能要件の検討が初めてという方は、以下IPAが提供する非機能要求グレードのエクセルから全体像とそれぞれの要求事項の中の定義を再確認しておくことをお勧めします。

IPA（情報処理推進機構）「システム構築の上流工程強化（非機能要求グレード）」より

図１「IPA（情報処理機構）非機能要求グレードの（06_活用シート.xls）「https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html」

上記のエクセルには、システム導入にあたって検討するべき非機能の全体像を確認することができます。

資料をダウンロードして全体をみていただくとわかると思いますが、非機能要件で検討するべき項目はかなりのボリュームがあります。

行政機関や金融機関など、かなりの大規模案件で、非常に高いセキュリティなどが求められるのシステム開発では、かなり詳細までこれらの全体像にたいして検討する必要が出てきますが、非機能の検討だけでかなりの期間や工数を要する作業となり、またインフラやセキュリティなど高度な専門性が求められる領域でもあるため、中規模以下の案件では、これらの中から最低限検討するべき非機能についてのみ検討・実施を行うというのが現状かと思います。

幸いなことにSalesforceはパブリッククラウドサービスのため、多くの非機能に関する要件はSalesforce側で自動的に制御、運用される部分が多いため、一般的なシステム開発と比べて検討すべき事項はかなり絞り込まれます。

※Salesforceのヘルプサイトなどを検索すると非機能要求に対するSalesforceとしての回答も記載されているものがあるので、非機能要件の検討の際にはその回答ベースに検討を行うこともできます。

上記の図でセールスフォースは、SaaS型サービスのため、ハードウェア、ネットワーク、負荷分散、障害対策など管理が難しい部分は、全てSalesforceのサービスとして管理・運用されます。

まず、基本はお客様のRFPで提示されている非機能の要求事項に対しては必ず検討対象とし、その他、権限やセキュリティなどリスクが高い項目については最低限検討すべきかと思います。

また、業務内容によっては、処理性能や高いユーザビリティなどが求められることもあるため、業務要件の整理の際に検討するとよいでしょう。

1.非機能要件定義書（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

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

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

情報種別：社外秘など

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

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

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

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

2.改訂履歴

3.本書の構成

要件定義書の別紙４として非機能要件定義書を定義していますが、プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

5.RFPの要求仕様（非機能要求）

最初に、RFPで要求されている非機能要件がある場合には、その内容を定義しておきます。

最低限こちらに記載の要件については要件定義の中で検討する必要があります。

参考

【可用性】

システム稼働率（SLA）：99.9%　サービス提供時間：24時間365日

耐障害性：ネットワーク、ハードウェア含め冗長化構成を検討し、単一障害を回避できる仕組みとすること

復旧水準：

RPO（目標復旧時点）：障害発生時点

RTO（目標復旧時間）：3時間以内

RLO（目標復旧レベル）：B2Cに関する全ての業務

【規模】　ユーザ数（会員数）：ｘｘ　/　月間登録者数：ｘｘ　/　月間アクティブ利用者数：　ｘｘ

【性能】　オンラインレスポンスタイム：3秒以内（順守率は通常時で90%、ピーク時70%程度の目標）

6.非機能要求の分類

続いては、本書で取り扱う非機能要求とその分類を定義しています。

上記のように種別１が1から10までの定義となっており、種別1の中でさらに種別2として詳細な要求種別として定義しています。

非機能要件の分類の分け方については、IPAの非機能要求グレードの整理をベースとするとよいでしょう。

纏め方や呼び方はプロジェクトや作成者によって多少異なると思いますが、それぞれのカテゴリの中で検討すべき事項が網羅されていて、わかりやすく定義されていれば問題ないです。

7.非機能要件詳細

ここからは各非機能の要求種別に応じて、具体的な要求仕様を定義します。

ユーザビリティに関する記載例

利用者（ユーザ）の定義：本システムを利用するユーザの所属、組織構成（階層）、担当業務、役割（申請の承認）、作業内容など（例）組織：本部　役割：全国各支部の活動状況の把握・分析　/　利用ユーザ：100名　ユーザ特性：Excelなどは使い慣れているがBIツールなどの利用経験なし
クライアント端末：ユーザが利用するクライアント端末（PC/スマホ/タブレットなど）、利用者、利用場所など（例）PC端末（OS：Windows10、ブラウザ：Chrome最新バージョン）、社用携帯（iPhone/Android）、タブレット（iPad）
使いやすさを求められる業務処理：システムの使いやすさを求められる業務や処理（例）システムの使いやすさを求められる業務や処理について、Salesforceのプロトタイプを作成して、システムを利用する現場のユーザの方の意見を聞きながらアジャイル的に開発を行い、UI/UXの改善を図るなど
操作性（操作のしやすさ）：システム操作について、直観的で簡単に操作可能、最小限の入力で登録可能など
入力補助、誤操作防止：不整値の入力防止や、入力候補を表示するなど
システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など

補足

これまで説明してきたフォーマットを使って要件の詳細を定義するとともに、Salesforceの非機能要件への対応方針やプロジェクト個別の対応方針など具体的な施策に関しては、上記とは別に詳細な資料を作成して説明するとよいでしょう。

例えば、可用性については以下の例のような資料を作成して説明するなど。

１．可用性（継続性・耐障害性・災害対策・回復性）

Salesforce（パブリッククラウドサービス）を利用するため、指定日時でのメンテナンスの制御はできません。

基本的にサービス提供ベンダーのサービス提供方針に従うことになります。

Salesforce社の可用性に関するサービス提供方針は、常に最新の状況を確認するようにしてください。

（１）Salesforce.comのサービス可用性

サービス提供時間：24時間365日（計画停止/定期保守を除く）

※セキュリティ対応やシステム稼働に重要な影響がある場合は、事前通知の上、緊急メンテナンスを実施する可能性有り

計画メンテナンスについては、現時点でSalesforce公式サイトを確認すると「暦月の第 1 週末と第 3 週末」と記載されています。

※リージョンやインスタンスによって実施日時が変わる可能性があります。

稼働率は過去の実績で99.9％を維持しています。現時点のインスタンスの稼働状況については、Trustサイトにて確認していただく運用となります。

https://trust.salesforce.com/ja/

継続性・耐障害性

可用性の各項目については、開発ベンダー側では制御できない内容となるため、基本的にSalesforce社の可用性に対する回答の内容を説明するだけとなります。

【重要】Salesforceは、実績として99.9% の稼働率となっていますが、セールスフォース社としては、SLAや個別契約などで可用性に関して担保するようなサービスは提供していません。（※2022年3月現在）

そのため、同社が提供するサービスとしての可用性はこのようになっていますという説明とともに、制約事項として承諾していただく必要があります。

リアルタイムのサービスの運用状況やインシデント、メンテンナンス状況については、Salesforceが提供する以下、「Salesforce Trustサイト」にて、運用担当者にて確認してもらう運用が基本となることを合わせて説明しておくほうがよいでしょう。

各サービス（機能）のステータスは色で判断することができます。

※以下、公式サイトより

参考

緑 (利用可能): このインスタンスは利用可能であり、完全に機能しています。
青 (情報メッセージあり): パフォーマンスの問題またはサービスの中断ではないインスタンスに関する情報。
紫 (メンテナンス): このインスタンスは現在メンテナンス中です。メンテナンス中のインスタンスの利用可能状況についてのメッセージが表示されます
黄 (パフォーマンスの低下): インスタンスは利用できますが、特定の機能が使用できない場合や、サービスが大幅に遅延して実行されている可能性があります。
赤 (サービス中断): お客様がインスタンスを利用できない状態です。

Salesforeのハードウェアやネットワーク構成など基本的に非公開にされているため、基本的には以下のような記述をして説明します。

Salesforceサービスは拡張性と冗長性にすぐれているため、需要の変動やユーザの増加にも対応できるうえ、長時間のサービス停止リスクも大幅に軽減されます。設計面では、ネットワークの負荷分散、アプリケーションサーバのプール、およびデータベースのクラスタ化を特徴とします。

災害対策、回復性

事業（業務）継続性の要件として、災害対策の検討がありますが、Salesforceのサービスは単一拠点（一か所）での障害によって、サービスが中断してしまわないように地理的に離れた場所に複数のデータセンターが設けられています。

またSalesforceのトランザクションは、ほぼリアルタイムで複数拠点のインスタンスに複製されています。

上記のように図やデータなどで示して説明するとよいと思います。

など。

サポーターさん

各非機能要件に対する具体的な定義例や補足資料のサンプルは別途記事を作成してご紹介したいと思います。

今回はここまでとなります。

2.テンプレートのダウンロード

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

一般公開資料（PPT版）

要件定義_要件定義書_別紙4「非機能要件定義書」_20221016_v1.0（Excel版）のダウンロードはこちら

まとめ

参考

サポーターさん

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

Salesforce導入プロジェクト要件定義書_別紙4「非機能要件定義書」テンプレート

セールスフォース標準化推進ラボ — Thu, 20 Oct 2022 03:20:45 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供する要件定義書_別紙4「非機能要件定義書」の資料の説明とダウンロード方法を説明いたします。

非機能要件の検討にあたっては、非機能要求事項の全体像を把握している必要があると思います。

1.はじめに（非機能要件の検討にあたって）

IPA（情報処理推進機構）「システム構築の上流工程強化（非機能要求グレード）」より

図１「IPA（情報処理機構）非機能要求グレードの（06_活用シート.xls）「https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html」

上記のエクセルには、システム導入にあたって検討するべき非機能の全体像を確認することができます。

資料をダウンロードして全体をみていただくとわかると思いますが、非機能要件で検討するべき項目はかなりのボリュームがあります。

また、業務内容によっては、処理性能や高いユーザビリティなどが求められることもあるため、業務要件の整理の際に検討するとよいでしょう。

1.非機能要件定義書（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

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

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

情報種別：社外秘など

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

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

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

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

2.改訂履歴

3.本書の構成

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

非機能要件定義書の目的や位置づけなどについて記載します。※不要なら削除して構いません。

5.RFPの要求仕様（非機能要求）

最初に、RFPで要求されている非機能要件がある場合には、その内容を定義しておきます。

最低限こちらに記載の要件については要件定義の中で検討する必要があります。

参考

【可用性】

システム稼働率（SLA）：99.9%　サービス提供時間：24時間365日

耐障害性：ネットワーク、ハードウェア含め冗長化構成を検討し、単一障害を回避できる仕組みとすること

復旧水準：

RPO（目標復旧時点）：障害発生時点

RTO（目標復旧時間）：3時間以内

RLO（目標復旧レベル）：B2Cに関する全ての業務

【規模】　ユーザ数（会員数）：ｘｘ　/　月間登録者数：ｘｘ　/　月間アクティブ利用者数：　ｘｘ

【性能】　オンラインレスポンスタイム：3秒以内（順守率は通常時で90%、ピーク時70%程度の目標）

6.非機能要求の分類

続いては、本書で取り扱う非機能要求とその分類を定義しています。

上記のように種別１が1から10までの定義となっており、種別1の中でさらに種別2として詳細な要求種別として定義しています。

非機能要件の分類の分け方については、IPAの非機能要求グレードの整理をベースとするとよいでしょう。

7.ユーザビリティ要件詳細

ここからは各非機能の要求種別に応じて、具体的な要求仕様を定義します。

利用者（ユーザ）の定義：本システムを利用するユーザの所属、組織構成（階層）、担当業務、役割（申請の承認）、作業内容など（例）組織：本部　役割：全国各支部の活動状況の把握・分析　/　利用ユーザ：100名　ユーザ特性：Excelなどは使い慣れているがBIツールなどの利用経験なし
クライアント端末：ユーザが利用するクライアント端末（PC/スマホ/タブレットなど）、利用者、利用場所など（例）PC端末（OS：Windows10、ブラウザ：Chrome最新バージョン）、社用携帯（iPhone/Android）、タブレット（iPad）
使いやすさを求められる業務処理：システムの使いやすさを求められる業務や処理（例）システムの使いやすさを求められる業務や処理について、Salesforceのプロトタイプを作成して、システムを利用する現場のユーザの方の意見を聞きながらアジャイル的に開発を行い、UI/UXの改善を図るなど
操作性（操作のしやすさ）：システム操作について、直観的で簡単に操作可能、最小限の入力で登録可能など
入力補助、誤操作防止：不整値の入力防止や、入力候補を表示するなど
システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など

8.アクセシビリティ

ウェブアクセシビリティ：ターゲットユーザのみではなく、本システムを利用する可能性のあるすべてのユーザ（高齢者や障碍者を含む）を考慮したデザインや操作性

9.可用性

可用性：（機器の故障・災害・アクシデントなどによる障害でシステムを停止させることなく稼働し続けること）について、（システム）継続性、業務継続性、目標復旧水準、稼働率、耐障害性、データの保護、災害対策について、それぞれの要件を確認して定義します。

継続性：システム稼働時間や停止に関して（通常運用時間、計画停止（メンテナンス）スケジュールなど）
業務継続性：可用性を保証するにあたり要求される業務範囲と条件（障害発生時のサービス切替時間など）、業務継続性の要求度合い
目標復旧水準：業務停止を伴う障害発生時、何をどこまで、どの程度復旧させるかの目標 RPO(目標復旧地点）、PRT（目標復旧時間）、RLO（目標復旧レベル）など
稼働率：明示された利用条件の下で、システムが要求されたサービスを提供できる割合（例）稼働率：99.99%
耐障害性：サーバで発生する障害に対して、要求されたサービスを維持するための要求。機器、ストレージの冗長化、ネットワーク回線、経路の冗長化など
データの保護：データの保護方式（バックアップ方式）、データ復旧範囲、データインテグリティ：改ざんや偽装を防ぎ、データの完全性と正確性が客観的に担保されていること）
災害対策：地震、水害、テロ、火災などの大規模災害時の業務継続性を満たすための要求※Salesforceがサービスとして提供している対策をベースに検討

10.規模・拡張性

利用者：本システムの稼働時点の想定利用者、利用者数、利用時間帯、アクセス方式など　※将来の見込み数も算出
業務処理量：日別・月間のオンラインリクエスト件数、バッチ処理件数、PV、アクティブ接続数、時間平均接続数、ピーク時の接続ユーザ数、同時接続数、帳票出力枚数（日別、月別）など
データ量：データ名称、データの種類、データ量（件数、サイズ）、発生頻度
データ保有期間：データの保有期間（社内規定や法令法規などによって定められている場合はその期間）
拡張性：利用者、アクセス数、業務処理量、データの増減に応じたシステム（メモリ、CPU、ディスクなど）の拡張対応

11.性能要件

オンライン処理性能：画面のオンラインレスポンスタイム、スループットなどの指標と対象機能など
バッチ処理性能：バッチ処理の最大処理件数、ターンアラウンドタイム、時間当たり処理件数の指標（通常時、ピーク時）と対象機能など

12.上位互換性

バージョンアップ：（メジャー、マイナー）バージョンアップ時の上位互換の保証に関して（保証対象の機能、互換性が保証されない機能に対する対応、検証方法など）

13.中立性

技術・製品（サービス）の利用に関して：ベンダーロックイン（特定の事業者（ベンダー）を利用し続けなくてはならなくて、他社の参入が困難な状態）を回避し、システムの中立性を担保するため、本システムで利用する技術や製品（サービス）に関しての要件※オープンで標準的なものを利用するなど

14.移行性

移行スケジュール：移行スケジュール（移行計画から本番稼働までの移行全体のスケジュールを定義）、システム停止可能期間、平行稼働有無など
展開方式：・複数拠点展開の場合の展開方式（単一拠点の場合は定義不要）、業務の展開方式（全業務一斉展開、または部分展開）
移行対象、ボリューム：移行対象（業務、システム/機器、データ）　※データに関しては、移行対象のデータ名称、データ形式、データ量（件数、サイズ）
移行リハーサル：移行リハーサルの範囲、環境、回数
移行計画（書）：移行対象に関する移行計画書の作成について（計画書に記載する内容）、コンティンジェンシープラン

15.運用保守性

運用監視：異常検知の実施有無、監視対象（システム、プロセス、DB、ストレージ、ネットワーク）、監視方式、間隔など
運用時間、時刻同期：システム運用を行う時間、（利用者や管理者に開放する時間）、時刻同期設定の範囲、システム全体を外部標準時間と同期など
運用負荷軽減：保守運用に関する作業を軽減するための要件、作業の自動化、ソフトウェア更新の自動化など
障害時運用：障害時の運用（検知方法、報告ルート、対応窓口、復旧作業の整理）、対応可能時間、代替業務運用など
運用環境：開発や試験（検証）目的の環境の用意、リモート監視の有無、対象、範囲など
サポート体制：保守対象（H/W,S/W）、ライフサイクル期間、メンテナンス役割、体制、サポート要員、操作訓練、運用報告内容に関して
その他運用方針：内部統制対応、サービスデスク設定、インシデント管理、問題管理、構成管理、への宇管理、リリース管理

16.セキュリティ

前提条件：順守すべき情報セキュリティに関する規定やルール、法規法令、ガイドラインなど
セキュリティリスク分析・診断・管理：リスク分析範囲、セキュリティ診断、リスクの管理について
アクセス利用制限：アクセス認証方式、利用者/時間制限、ネットワーク制限、権限など
データの秘匿：機密性のあるデータについて、送信時や蓄積時の秘匿（暗号化）について
不正追跡・監視：ログ取得対象、保持期間、IDS（不正侵入検知）・IPS（不正侵入防止）の検知、データ検証（デジタル署名）など
ネットワーク対策：ネットワーク制御、不正検知、サービス停止攻撃への対処
マルウェア、WEB対策：マルウェア（ウイルス、ワーム、ボット等）の感染防止、Webアプリケーション特有の脅威、脆弱性についての対策
セキュリティインシデント対応：セキュリティインシデントの早期発見、被害の最小化、復旧支援に関して

補足

例えば、可用性については以下の例のような資料を作成して説明するなど。

１．可用性（継続性・耐障害性・災害対策・回復性）

Salesforce（パブリッククラウドサービス）を利用するため、指定日時でのメンテナンスの制御はできません。

基本的にサービス提供ベンダーのサービス提供方針に従うことになります。

Salesforce社の可用性に関するサービス提供方針は、常に最新の状況を確認するようにしてください。

（１）Salesforce.comのサービス可用性

サービス提供時間：24時間365日（計画停止/定期保守を除く）

※セキュリティ対応やシステム稼働に重要な影響がある場合は、事前通知の上、緊急メンテナンスを実施する可能性有り

計画メンテナンスについては、現時点でSalesforce公式サイトを確認すると「暦月の第 1 週末と第 3 週末」と記載されています。

※リージョンやインスタンスによって実施日時が変わる可能性があります。

稼働率は過去の実績で99.9％を維持しています。現時点のインスタンスの稼働状況については、Trustサイトにて確認していただく運用となります。

https://trust.salesforce.com/ja/

継続性・耐障害性

各サービス（機能）のステータスは色で判断することができます。

※以下、公式サイトより

参考

緑 (利用可能): このインスタンスは利用可能であり、完全に機能しています。
青 (情報メッセージあり): パフォーマンスの問題またはサービスの中断ではないインスタンスに関する情報。
紫 (メンテナンス): このインスタンスは現在メンテナンス中です。メンテナンス中のインスタンスの利用可能状況についてのメッセージが表示されます
黄 (パフォーマンスの低下): インスタンスは利用できますが、特定の機能が使用できない場合や、サービスが大幅に遅延して実行されている可能性があります。
赤 (サービス中断): お客様がインスタンスを利用できない状態です。

Salesforeのハードウェアやネットワーク構成など基本的に非公開にされているため、基本的には以下のような記述をして説明します。

災害対策、回復性

またSalesforceのトランザクションは、ほぼリアルタイムで複数拠点のインスタンスに複製されています。

上記のように図やデータなどで示して説明するとよいと思います。

など。

サポーターさん

各非機能要件に対する具体的な定義例や補足資料のサンプルは別途記事を作成してご紹介したいと思います。

今回はここまでとなります。

2.テンプレートのダウンロード

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

一般公開資料（PPT版）

要件定義_要件定義書_別紙4「非機能要件定義書」_20221016_v1.0（PPT版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

参考

サポーターさん

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

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

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

セールスフォース標準化推進ラボ — Tue, 04 Oct 2022 09:24:14 +0000

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

サポーターさん

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

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

Excel版

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

PPT版

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

参考

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

３．本書の構成

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

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

４．目次

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

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

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

６．ビジネスルール一覧

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

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

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

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

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

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

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

８．添付ファイル（Appendix）

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

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

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

一般公開資料

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

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

サポーターさん

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

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

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

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

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

サポーターさん

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

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

Excel版

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

PPT版

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

参考

1.テーラリングガイド

１．表紙

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

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

情報種別：社外秘など

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

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

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

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

２．改訂履歴

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

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

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

３．本書の構成

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

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

４．目次

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

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

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

６．ビジネスルール一覧

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

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

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

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

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

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

８．添付ファイル（Appendix）

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

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

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

一般公開資料

要件定義_要件定義書_別紙2「ビジネスルール定義書」（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版テンプレート）サンプル

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

サポーターさん

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

Salesforce DevToolsを使ってオブジェクト設計書を自動生成（xgeek.net）

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

セールスフォース標準化推進ラボ — Sun, 19 Jun 2022 13:56:49 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要件定義書のテンプレート（サンプル付き）をご提供しております。

通常、要件定義書は、パワーポイントやWORDで作成することが多いと思います。今回はPPT版（ワイド版）で作成しておりますが、今後要望があればWORD版でも作成しようと思います。

サポーターさん

要件定義書のテンプレートや記載方法に関するお問い合わせも増えてきたため改めてPPT版を作成しました。ぜひご活用ください

また、今回は非機能要件、テスト要件、移行要件をそれぞれ別紙として構成しています。これらの定義書は改めて新しいテンプレートで作成して公開する予定です。

1.要件定義書のサンプルイメージとご利用方法に関するご説明

では、要件定義書のサンプルイメージを使って、作成手順についてご説明いたします。

【改訂履歴】

まず改訂履歴のページは必ず入れておきましょう。要件定義書は作成後、お客様のレビューなどにより最終FIXするまでに変更が発生することが多いため、誰がいつどのような経緯で修正したのか残しておく必要があります。

【本書の構成】

続いては、本書の構成のページを入れています。

要件定義書のファイル構成は、プロジェクトごとにお客様の意見も取り入れて、どのような構成にするか検討しておくとよいでしょう。

まずは要件定義書のフォーマットは、WORDなのか、PPTなのかを決めてください。

PPTの場合、システム機能一覧やオブジェクト項目定義書などを盛り込むと可読性が下がるため、エクセルファイルで作成し、別紙参照とするほうがよいでしょう。

以下の例では、要件定義書（本書）のPPT以外に、多くは別紙としているため本書の構成でどのファイルに何が記載されているのか一目でわかるようにファイル構成を可視化しています。

【目次】

本書の構成とは別に、今度は要件定義書全体の目次ページを作成しています。

章立てについては、プロジェクトの特性や規模により記載内容や粒度は変更してください。

非機能要件定義書、テスト要件、移行要件はそれぞれ記載内容が多くボリュームも多いため、別紙としましたが、要件定義書内に記載できる程度のボリュームであれば盛り込んでも構いません。

【はじめに】

要件定義書の作成目的を記載します。

【１．業務・システム要件（表紙）】

【1-1.システム構成】

最初に作成するシステムの全体像を提示します。（ポンチ絵レベルのものでよい）

【1-2.システム化範囲（プロジェクトスコープ）】

システム構成図の中で、システム領域の定義と今回の開発範囲（スコープ）の定義（赤枠）を定義します。

全体の中で、どこが対象で、どこが対象外か明確にわかるように定義します。細かい部分はコメントで記載します。

【システム領域と実現方式】

続いて、システム領域（エリア）の定義を行います。

領域は略称でわかりやすいものを定義するとよいでしょう。（例では、Service Cloudの略をSCとしています。）

また、それぞれの領域の対象業務とシステム化概要（説明）、利用サービス・ツールや実現方法、機能を定義します。

【1-3.業務フロー図（AS-ISモデル）】

現行の業務フロー図を定義します。最初のページには凡例を差し込んでおくとよいでしょう。

また各プロセスには番号を振って、番号に対する業務内容の説明資料を入れる場合もあります。

【1-3.業務フロー図（TO-BEモデル）】

続いては、新業務フロー図を定義しますが、現行業務フローとの違いの部分がわかるように強調表示や説明コメントをいれるとよいでしょう。

※以下のサンプルはAS-ISと同じものを利用しています。

【1-4.現状の業務課題と対応策】

現状業務の課題と対応策（施策）について取りまとめたものを記載します。

【2.システム機能要件（表紙）】

【2-1.システム機能要件（システム機能一覧）】

・業務分類（大・中・小）の分類を定義

・システム機能ID、機能名、システム機能概要を定義

・機能分類、標準/アドオン開発を定義、具体的な方法を定義

【2-2.オンライン機能（画面一覧/帳票一覧】

1.画面一覧：作成する画面の一覧を記載します。

・業務面、画面ID、画面名、概要

・画面種別（WEB・モバイル）

・利用者（プロファイルベース）

2.帳票一覧：作成するシステム帳票の一覧を記載します。

・帳票名、概要

・帳票設計（様式、サイズ、改頁条件、ページ数、頻度、履歴管理、再出力要件有無、開発有無）

・利用者（プロファイルベース）

【2-3.バッチ処理一覧】

【2-4.情報・データ要件】

１．オブジェクト一覧

・オブジェクト名、API参照名、表示ラベル、種別、区分、用途

・利用者権限（プロファイルベース）

2.オブジェクト項目定義書

オブジェクト毎に項目定義書を作成します。こちらは別紙としエクセルファイルで作成することをお勧めします。

サポーターさん

オブジェクト項目定義書は、Xgeeksのサイトで提供されているDevtoolを使って出力するのが効率的でお勧めです。

Salesforce DevToolsのダウンロードと利用方法は、以下の記事を参考にしてください。

参考

今回は、xgeek.netさんが提供する無料ツールであるSalesforce D…

【2-5.インタフェース要件】

1.外部システム連携（全体像）

外部システムとの連携方式の全体像が分かるように連携図を作成します。

2.外部インタフェース一覧

続いて、外部インタフェース一覧を定義します。

・インタフェースID、インタフェース名、処理概要、頻度、送受信区分、連携システム送受信

・処理方式（接続方式、処理区分、データ種別

・データ形式（データ形式、文字コード、デリミタ（区切り文字）、改行コード、サイズ等

【2-6.レポート・ダッシュボード要件】

1.レポート要件

・タイトル、説明、形式、表示項目、抽出条件、集計軸、レポート格納先フォルダ

・利用者（プロファイルベース）

2.ダッシュボード一覧

・タイトル、説明

・表示形式、表示項目、抽出条件、集計軸、元レポート

・利用者（プロファイルベース）

【3.非機能要件】

※今回のサンプルでは、非機能要件については別紙として、非機能要件定義書を作成する構成としている。

【4.テスト要件】

※今回のサンプルでは、テスト要件については別紙として、テスト要件定義書を作成する構成としている。

【5.移行要件】

※今回のサンプルでは、移行要件については別紙として、移行要件定義書を作成する構成としている。

【6.別紙（Appendix）】

【成果物一覧、用語集】

成果物・納品物一覧は、別紙のエクセルとしたが、ボリュームが少ない場合は、スライドに直接記述してもよいでしょう。

【クロージング】

テンプレートのダウンロード

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

一般公開資料

★ワイド版（16:9）

要件定義書（PPT版）はこちら

PDFで資料のサンプルを参照したい場合は、こちらのPDFをダウンロードしてご利用ください。

要件定義書（PDF版）はこちら

その他、要件定義書（別紙）のテンプレートが必要な場合は以下の記事からダウンロードしてください。

参考

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。

皆様の役に立つように改善していきたいと思います。

テンプレート関連の記事

サポーターさん

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