要件定義（移行）タスクの進め方の概要

今回は移行の要件定義タスクの進め方について、概要を解説します。

システム構築フェーズの最初の工程は要件定義工程です。

要件定義工程はアプリケーション開発、インフラ構築、ユーザー展開、運用保守、移行、他システム対応、それぞれの観点に対して各種要件を固め、計画を具体化する工程です。
システム構築フェーズの一番最初の工程であり、お客様との密なコミュニケーションが必要で難しい工程でもあります。

今回は要件定義工程の中でも移行で実施する要件定義を解説します。

要件定義工程は経験がものをいう上流工程ですので、上流工程に強くなりたいと思うなら、知識を吸収して機会があれば積極的にチャレンジしてみると良いと思います。

移行における要件定義では移行方針を精緻化し移行計画を策定する
1. 移行方針を精緻化し移行全体計画を策定する
まとめ

移行における要件定義では移行方針を精緻化し移行計画を策定する

移行における要件定義の作業は、移行方針を精緻化し移行全体計画を策定することです。

要件定義（移行）のアウトプット（成果物）としては、移行全体計画書になります。

それでは詳しく見てみましょう。

移行方針を精緻化し移行全体計画を策定する

移行方針は移行に関する大方針です。

移行方針は移行全体計画の概要レベルに相当するもので、構想立案フェーズにて概算見積の前提として検討します。
構想立案フェーズでは時間の制約があり、概算見積のために一部仮置きとしたり具体化できなかった部分に対して検討を行い、方針を精緻化します。

移行方針は、以下のような項目であり、方向性（どうするかの概要）を定めます。

移行対象（関係するシステム、業務）
稼働方式（一括稼働/段階稼働/並行稼働）
移行データ方針（対象となる移行データの一覧と移行方式）
移行における体制・役割分担・会議体
スケジュール（トップダウン・ボトムアップによる段取り、マイルストーンの設定）
移行テスト・リハーサル方針（移行テスト、移行リハーサルの目的・範囲・リハ実施回数・参加者・環境）
移行ツール開発方針（ツール開発の対象に対する考え方や実装方式）
移行セキュリティ方針（本番データの扱い・アクセス権限、テスト環境への導入時のマスキング等）
成果物作成方針（成果物作成における手の入れどころ・抜きどころ）

移行に関する要件全般を移行要件と呼びます。

移行要件は非機能要件の一部であり、独立行政法人のIPA（情報処理推進機構）が無償公開している「非機能要求グレード」では「移行性」と分類されています。
こちらも参考になります。

非機能要求グレード

システム構築の上流工程強化（非機能要求グレード）紹介ページ | アーカイブ | IPA 独立行政法人情報処理推進機構

情報処理推進機構（IPA）の「システム構築の上流工程強化（非機能要求グレード）紹介ページ」に関する情報です。

移行全体計画では、移行方針を具体化・最終化して移行要件・計画としてまとめ、移行の考え方・進め方を関係者と認識合わせします。

具体的には、以下のように移行要件・計画を移行全体計画書にまとめ、検討や関係者と合意します。

移行対象では、関係するシステム・業務を確定し、関係者を明確にする
稼働方式では、一括稼働/段階稼働/並行稼働のいずれを採用するか決める
移行データ方針は、対象となる移行データの一覧と、それぞれのオーナー（データの責任者）や移行方式を具体化する
移行における体制・役割分担・会議体は、スケジュールとあわせて検討し、関係者と認識を合わせる
スケジュールでは、段取り・マイルストーンを精緻化し、関係者と認識を合わせる
移行テスト・リハーサル方針は、関係者と目的や作業概要について認識を合わせを行う
移行ツール開発方針は、開発対象のSQL・Excel・バッチプログラム等を明確にし、見積を精緻化する
移行セキュリティ方針は、本番データの扱い・アクセス権限、テスト環境への導入時のマスキング等を確定し、関係者と認識を合わせる
成果物作成方針は、作成を丁寧にやるところ（本番切替のタイムスケジュール・手順など）と力を抜くところ（ツール開発の設計書など）を定義する
コンティンジェンシープランは、本番切替時にて問題が発生した際に、どのタイミングでどんな対応をして業務への影響を抑えるかを明確にし、関係者と認識を合わせる

むぅさん

移行全体計画の作業を経験する機会は少なく、また積極的にやりたがる人も少ないので、特に大きなプロジェクトではベテランの方が移行担当になることが多かったです。
大抵の人はアプリケーション開発のみに目が行ってしまい、移行をはじめとしてその他の領域は疎かになることが多いので、移行の重要性や進め方を分かっている人をみると「あっ、この人は中々の切れ者だ！」と感じます。