シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する
- 要件定義とソフトウェアアーキテクチャ設計
- 要件定義とクラス設計
- 要件定義とデータベース設計
- 要件定義と画面設計
- 要件定義とAPI設計
- 要件定義とバッチ処理設計
- 要件とは何か
- 非機能要件とは何か
- 要件定義を学ぶ人におすすめの書籍まとめ
- 移行要件とは何か（本記事）
- 要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】
- 要件定義と設計の関係を体系的に理解する【全体像まとめ】
TRACERYプロダクトマネージャーの haru です。
事業・業務・システムの3階層で要件を捉える - TRACERY Lab.（トレラボ）では、事業要件・業務要件・システム要件という3階層を紹介しました。
これらに加えて、システム開発では「移行要件」と呼ばれる重要な要件があります。
具体的には、システムや機能をリリースするまでの、データ移行やユーザー教育、移行期間中の暫定運用手順などに関する要件が該当します。
本記事では、この移行要件について説明します。
移行要件とは
移行要件とは、現在の状態（As-Is）から将来の状態（To-Be）へ移行する際に必要となる要件で、 BABOK（Business Analysis Body of Knowledge：ビジネスアナリシス知識体系） に定義されています*1。
移行要件は、以下のような性質を持ちます。
- 現在の状態から将来の状態に円滑に移行するための要求
- 一時的な性質を持ち、移行が完了した段階で不要になる
移行要件の内容
移行要件は、主に次の三つに分類できます。
- データ移行：旧システムのデータを欠損や不整合なく新システムに移し、業務に必要な情報が正確かつ最新の状態で利用可能になることを求める要件。
- 事業継続：移行期間中および移行直後も重要業務を中断させず、合意したサービス水準を維持できる状態を保証する要件。
- 教育訓練：新システムを利用する全関係者が稼働開始時点で必要な知識と操作スキルを習得し、業務を滞りなく遂行できる状態にあることを求める要件。
以下で、それぞれの内容を説明します。
データ移行
データ移行では、旧システムから新システムへ情報を確実に引き継ぐために、品質の確保や最新データの反映、セキュリティと法令遵守など多方面の要件を満たす必要があります。以下に、その主要な観点を示します。
1. データ品質
- 完全性：旧システムに存在する移行対象データが欠損なくすべて移行されていること。
- 正確性：移行後のデータ値が業務上許容できる誤差範囲内で正確であること。
- 整合性：参照整合性や主従関係など、データ構造上の一貫性が保持されていること。
2. タイムリーな反映
- 最新性：移行直前までに発生した更新内容が反映されていること。
- 業務開始可能性：移行完了後、予定どおり新システムで業務が開始できる状態であること。
3. セキュリティ・法令遵守
- 情報保護：移行作業中も個人情報や機密データが適切に保護され、関連法規（例：個人情報保護法）を遵守していること。
- 可監査性：移行の過程や結果が監査可能であり、誰がいつ何を移行したかを追跡できること。
4. 業務継続性
- 影響最小化：移行による通常業務の停止時間や影響が、事前に合意した範囲内に収まること。
- 復旧可能性：移行失敗時に業務を継続できるよう、復旧手順が確立されていること。
5. 検証基準
- 移行完了判定：件数一致、ハッシュ値比較など、移行完了を客観的に確認できる検証基準が明確であること。
事業継続
システム移行では、切り替え中や稼働直後も重要業務をなるべく止めないことが求められます。以下に、その主要な観点を示します。
1. 重要業務と復旧目標
- 停止が許されない重要業務が特定され、優先順位が明示されていること。
- 各業務の復旧目標時間内に収まること。
- 復旧後に最低限必要なシステム機能・データが利用可能な状態であること。
2. 継続体制と責任範囲
- システム障害時に事業を継続するための体制の確立。
- 緊急時の意思決定者とその代理者、連絡経路およびエスカレーションルート。
3. 移行期間特有の継続条件
- 移行作業中であっても、特定した重要業務が合意したサービス水準を維持できること。
- 移行に伴う一時的リスク（例：データ同期遅延、システム切替時間）に対して、事業停止を回避できること。
- 外部システムやサービスへの依存事項が洗い出され、それに起因する中断リスクが許容範囲内であること。
4. 移行後初期稼働の継続基準
- 新システム稼働直後に必要な監視・初期対応体制が整備され、初期フェーズでも事業継続が保証されていること。
- 稼働直後に発生し得る障害や性能劣化に対応する初期運用基準。
5. 検証と正式承認
- 上記要件が移行完了前に検証され、事業継続が可能であると判断する明確な承認基準の設定。
- 検証結果と承認記録が監査可能な形で保存されていること。
教育訓練
システム移行では、稼働開始時に利用者が必要な知識と操作スキルを備えていることが欠かせません。以下に、その主要な観点を示します。
1. 対象と範囲
- 新システムを運用・利用するために必要な知識や操作スキルを習得すべき対象者（業務担当者、管理者など）が特定されていること。
- 役割ごとに習得が必要な教育内容と学習範囲が明確に定義されていること。
2. 学習成果と到達基準
- 受講者が稼働開始後に業務を支障なく遂行できるレベルの知識・操作スキルを習得していること。
- 習得状況を客観的に判定できる基準（理解度評価、操作精度など）が明示されていること。
3. 実施時期と完了条件
- 必要な教育訓練がシステム稼働開始までに完了していること。
- 初期運用に影響を与えない適切な時期に教育が実施されていること。
まとめ
システム開発では、事業要件・業務要件・システム要件に加え、現行環境から新環境へ確実に移行するための移行要件を明確にすることが不可欠です。
BABOK が示すとおり移行要件は一時的な性質を持ち、データ移行・事業継続・教育訓練という三つの視点を押さえることで、切り替え時のリスクを抑えられます。
移行要件を要件定義の関係者間で共有しておけば、移行期の混乱を防ぎ、システム稼働後の安定運用へと着実につなげられます。
次回は、本連載「要件定義とはそもそも何か」の総まとめとして、これまでの内容を整理しながら要件定義プロセスの全体像を解説します。
*1:BABOKでは「移行要求」という名前で定義されている。
