本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供する要件定義書_別紙6「移行要件定義書」の資料の説明とダウンロード方法を説明いたします。
非機能要件定義書が必要な方は、こちらの記事からダウンロードいただけます。
-
-
参考Salesforce導入プロジェクト 要件定義書_別紙4「非機能要件定義書」テンプレート
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供する要件定義書_別紙4「非機能要件定義書」の資料の説明とダウンロード方法を説明いたします ...
続きを見る
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サイトにてご確認ください。
データおよびストレージリソースの監視（https://help.salesforce.com/s/articleView?id=sf.admin_monitorresources.htm&type=5）
13.移行計画書作成方針
移行計画書の作成方針では、後続の工程で作成する移行計画書に記載するべき事項を定義しておきます。
上記のように記載内容を定義することで、計画書作成に必要な作業工数の見積が可能となります。
14.環境利用方針
移行作業（UATや教育、移行リハーサルなど）について、環境の利用方針を定義します。詳細は移行計画の中で確定していくことになると思いますが、外部連携など必要な場合には連携先システムの環境情報についても事前に確認しておくとよいでしょう。
また上記の図の他に、具体的な環境情報（システム、環境名、利用用途、利用者、利用次期）について表などにまとめるとよいでしょう。
15.移行に伴う影響範囲の特定と対策
移行作業でのシステム停止や新業務への切り替えに伴い発生する業務影響などを調査し、事前に対策を検討する必要があります。
16.移行設計方針（移行ツール）
移行ツールを利用する場合の設計方針を記載します。
以下の例では、システム移行では、Salesforceの変更セットを利用したリリースを実施することと、データ移行に関しては移行専用ツールは作成せず、Dataloaderを使った手動の移行を行う方針とし、データのマッピングなどを設計段階で実施することとしています。
17.移行データ作成方針
移行データ作成方針では、基本的にシステムの上流側でデータを作成するという方針としています。
また図の例では、移行対象データの作成の流れを記載し、誰がどの作業を実施するのかを明確に定義しています。※より詳細な作業内容は移行計画書で定義します。
18.移行リハーサル実施方針
移行リハーサルの実施に関して、目的、実施内容、検証方法などを定義します。
リハーサルの実施回数なども見積工数に影響するため明確にしておくとよいでしょう。例えば、基本的に移行リハーサルは2回実施し、1回目で検出した課題や問題をクリアして2回目を実施し、予定通りの結果となった場合に終了とする。結果によっては、再度3回目移行のリハーサルを実施する。など
19.教育・トレーニング
教育の方針について、システムが変更になることの概要の説明や業務内容の変更点については、お客様から一般ユーザの方へ説明いただくとよいでしょう。
その後、システムの全体概要を説明し、実際のシステムをハンズオンで操作しながら習得していただくというやり方が一般的です。
教育の実施内容については、回数や対象者数を確認 ※1名と10名では必要な時間や講師の数が異なるので必ず確認しましょう。
また実施については、オンラインなのか、出張で現地まで行って対面でやるのかについても明確にしておきましょう。
続いて、トレーニングで利用する操作マニュアルについての章立ても確認しておきます。※作成するページ数によって作業工数の見積が変わるため。
上記のように管理者向けと一般ユーザ向けの2つを作成することが多いですが、ユーザ向けについては、複数の種類を作成する場合もあるため必要な種類を確認しておきましょう。
20.体制と役割
移行に関連する作業について、工程と作業内容ごとに各社の役割を明確にしておきましょう。
21.成果物定義
最後に移行に関する成果物を定義します。作成する成果物とその内容を記載します。
以上となりますが、上記以外に必要な添付ファイルがあれば、別紙や補足資料としてページを追加しておきましょう。
2.テンプレートのダウンロード
資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。
一般公開資料（PPT版）
要件定義_要件定義書_別紙6「移行要件定義書」（PPT版）のダウンロード
※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。
もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。
まとめ
そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。
-
-
参考ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧
サポーターお問合せ・ご要望いただいているコンテンツも頑張って作成しているので、もうしばらくお待ちください ダウンロード可能なコンテンツ一覧 提供しているテンプレートと公開範囲は以下の通りとなっています ...
続きを見る
