システム導入のためのデータ移行ガイドブック―コンサルタントが現場で体得したデータ移行のコツ (NextPublishing) [Kindle]

久枝穣

• インプレスR&D (2017年11月17日発売)

感想・レビュー・書評

[cmano8さんの感想 · 2024年4月30日]

さっと概要を掴みたかったのと、ちゃんと理解しようとしたのは初めてだったという状況に対しては、満点に近い気がする。
・ドキュメンテーション(アウトプット)の具体まであれば、満点か。
・著者のブログもかなり良さそう。というか単純に丁寧な仕事ぶりが文体やコンテンツから伝わってきて、さすが感がある。

[ヨッシーさんの感想 · 2023年8月20日]

システム導入のためのデータ移行ガイドブックを読んで


感想
移行に大事な３つの観点（業務/システム/データ）の内、データ移行に関して詳しくなった。
準備/要件定義から運用保守までの全体感を理解することが出来た。また各フェーズにおけるタスクと主要な論点やソリューションを理解することが出来た。
入門書としては良く、実際にPJに参画した時は、過去の具体的な作成物などを見れば、議論は出来そうだと感じた。


１章　データ移行タスクの全体像
移行は、業務移行、システム移行、データ移行の３つに分けられる。
例を示すと、業務移行は、「ユーザートレーニング」「旧業務の終了」「移行期間中の暫定業務対応」「新業務の開始」。
システム移行は、「新システム環境（ハード/ソフトウェア）のリリース」「資源（ソース、リポジトリ）の移送」「旧環境からの切り替え」。
データ移行は、「移行データ準備」「移行データの投入」「移行結果の検証」。投入データの確認は二段階（都度、全て投入後）で行う。

移行タスクを実施するには、事前に移行プログラムや移行手順を準備する必要がある。
準備段階で運営計画を立て、要件定義フェーズで「何を、どのように（移行方針）、どうやって（移行計画）」をまとめる。
詳細には「移行対象定義」、「移行方針定義」「アーキテクチャ定義（データクレンジング、変換、取込、検証をどのシステムで行うのか）」「移行概要計画」「設計フェーズ計画（移行プログラムの仕様、データクレンジング/検証の進め方）」
移行概要計画には、手順、スケジュール、要員割当、機器の導入スケジュール、費用見積もり、検証基準、中止基準、復旧手順を含んでおく。

設計フェーズでは、開発すべき移行関連プログラムの一覧と設計書ができる。
詳細には、「移行対象詳細化（何を何に移行するか）」「移行マッピング（キー項目明確化、編集仕様記載）」「アーキテクチャ設計（移行プログラムをどう作るのか）」「プログラム処理設計」「移行詳細計画（プログラムの使用手順をスケジュール化）」「構築フェーズ計画」。

構築フェーズでは、プログラムを作成し、単体テストを実施。個別プログラムの手順書も作成。
詳細には、「移行プログラム開発」「移行単体テスト」「移行ジョブ構築」「移行手順書作成」「テストフェーズ計画」。

テストフェーズでは「移行テスト実施」「移行リハーサル計画」「移行リハーサル実施」「移行タイムチャート作成（実施回数はアプリチームのテストに合わせるべき）」「導入フェーズ計画」。
導入フェーズでは、「移行データ準備」「移行データ投入」「移行結果検証」



２章　データ移行要件定義
移行方針の論点の例。「移行方式」「移行対象」「変換方針」「クレンジング方針」「検証方針」「アーキテクチャ方針」
移行方式は大きく３種類。一括移行、拠点/地域別移行、業務別移行。
データ検証方針は、①件数②桁・型③マスター④現新比較
データ移行概要計画では、「データ移行方針」「データ移行日」「データ移行体制」「役割分担」「データ移行リスク」「コンティンジェンシー方針」をまとめる。
設計フェーズでは、「データ検証方針の詳細」「データ移行ジョブネット」。構築フェーズでは、「データ移行手順書」「データ移行タイムチャート」。
テストフェーズでは、移行手順書やタイムチャートを見直す。


３章　データ移行設計
移行対象を詳細化した後は、データ変換設計。「項目ごとのデータ変換処理」「データの桁チェック」「データの型チェック」を行う。
マスターごとの移行注意事項の例あり。
ジョブネットを組むうえでの依存関係は、「全件処理→差分移行処理」「マスター→トランザクション」「親テーブル→子テーブル」
単体テスト計画では、実施方法と品質指標（テストケース密度とバグ密度）を設定。


４章　データ移行プログラム開発
プログラム開発のバグ分析には、直接原因と根本原因がある。


５章　データ移行テスト
本書のデータ移行テストは、プログラム間の結合テストのこと。
検証内容は、「データ移行の実施順序に問題がないか」「データクレンジングの進捗」「検証プログラムの精度向上」「処理時間測定とチューニング」「移行データをアプリテストで利用することによる精度向上」「実データでのテスト」
テストを通じて、もしくは完了した段階で、移行手順を定義したタイムチャートを作成する。
リハーサルの計画では、「移行手順は実用に耐えるか」、「処理時間は時間内に収まるか」を検証することを念頭に置く。またできる限り本番に近い状態でテストする。
時短の対処としては、SQLチューニング、DBチューニング、インフラ増強がある。


６章　データ移行リハーサル
本番移行準備としては、移行計画として詳細化したもの、準備したプログラムや手順に問題がないかを確認。
運営容量をまとめることもある。項目は、「体制」「スケジュール」「その他（コンティンジェンシープラン）」「障害対応手順」


７章　本番データ移行
本番移行の流れは、①新システム環境準備、②旧業務の終了、③オンラインの閉局、④データの断面確保、⑤現行データの抽出、⑥現行データの格納、⑦新システムデータ移行、⑧移行完了後の検証、⑨初回稼働の確認
本番移行においても、実績を記録することは大切。


８章　データ修復
本番稼働後に移行データの修復が必要になった時の場合。
データ修復の流れは、①事象と影響範囲の特定、②暫定対応、③原因分析、④恒久対応と再発防止策立案

９章　組織変更時のデータ移行対応
組織と人に関するデータが変わる。マスターデータとトランザクションデータを変更しなければならない。
データの変更方法としては、「マスターデータの変更」「トランザクションデータの洗い替え」「他システムへのアウトバウンドインターフェース」

[Singappさんの感想 · 2020年12月30日]

内容が実務的過ぎて、ユーザーサイドではなかなか学べない