リハの実施目的

  • 基本的に移行は失敗できない。そのため、リハは本番作業を確実に成功させるために行うものである

スコープ

  • 外部接続切替がどこまでできるか?要確認
    • 連携先システムも開発している場合、開発状況次第でできない可能性もあり。
    • 移行リハでできない場合、テストで担保する必要あり
  • PJ内のシステム間連携は全て可能な状態になっていることが前提
    • 特にシステム間 I/Fについては「移行リハが初回稼働」の状態にならないように計画を立てておく。
      そうしないと、移行リハでシステム間I/F連携に失敗して、先に進めなくなる可能性あり。
  • 可能であれば業務で利用するEUCツールなどもテストできるとよい

リハでの確認ポイント

  • データ投入の順序性、依存性
  • パフォーマンス
  • タイムチャートの妥当性確認

リハ実施前までにやること

  • 手順書の作成
  • 移行ツールの作成

リハ実施直前にやること

  • アプリをいつのバージョンでやるか?を検討する
  • 特に移行に関係あるDBのスキーマ定義の変更は、早めにバージョンを確定する
  • アプリのバグを把握して、移行への影響有無を確認する
    • 大抵の場合に何かしらあるため、回避方法を考慮する / 移行実施に大きな影響がなければ想定差異と捉える

注意

  • 本番の実施状況との差異を明確にしておく
  • アプリなどの業務日付が変更方法を確認し、変更しつつリハを実施する
  • 既存システムからデータ抽出が必要な場合、既存システム側に事前にデータ抽出依頼をしておく

移行リハーサル

  • 本番用の移行手順書が出来上がったのち、それをベースに時間のみ変更して実施する
  • 一括移行であれば、念入りに複数回 実施する
  • 移行リハーサルを実施する環境を用意する
  • 複数回リハーサルをやる場合には、毎回 何を目的とするか明記する
  • リハーサルと本番移行の差異を明確にして、リハでどこまでを担保できるか明確化する
  • 手順書内には 移行リハのみで実施するところ、本番のみで実施する手順を明確にしておく
  • 用意するデータが いつからいつまでのデータか?を予め決める必要あり
    • 本番移行時に必要なデータは、移行リハ時には不足した状態となる
      その為、その不足分をダミーデータで補う必要性があるか?を その後の システムテストやUATを考慮して決定する

移行リハ特有手順

  • 本番移行が複数日に及ぶ場合、その間にユーザー業務が入る場合がある
  • これは代わりに誰かが実施する必要あり
  • 変更したデータは 後続のフェーズ(STやUAT)で利用する為、必ず申し送りを行う

運用

  • リハでは必ず課題が発生するため、発生時の課題管理方法を予め決めておく。誰がどのタイミングで起票する。
  • 課題発生時の対応方法も決めておく。原因の切り分けは、こうする。アプリ起因の場合は、こうする。DB起因の場合は、こうする。
  • あるべき仕様がわからないケース。設計書と実装が乖離しているが、不具合対応を最近したものなど。何が正か?をどのように確認すればよいか?を明確にしておく

扱うデータについて

  • リハーサルは基本的にマスキングなしのデータで行うのがよい
  • ただし、メールアドレス / 口座番号 / クレジット番号など機微情報は要検討。メールアドレスは誤送信防止のため、マスキングするのが良い
  • データの受け渡し方法を確立しておく
    • 少なくとも限られた人のみが閲覧できるセキュリティにしておく
  • 各組織のルールに違反しないように注意
  • トランザクションデータは、本番移行のタイミングより 確実に少なくなる。ダミーのデータを作成するのか、不足状態で実施するのかをあらかじめ決める必要あり。
  • ダミーデータを作成するのであれば、誰がどのように作るのか?を決める必要あり
  • 作ったダミーデータは 後続のフェーズ(STやUAT)で利用する為、必ず申し送りを行う

リハ結果の確認

  • 事前に画面では何をするか?データは何を確認するか?を決めておく
  • リハ結果は そのままアプリテストに使われるため、データは出力しておく
  • データは優先度をつけて、全件 確認を行うべき。
  • 重要な業務ロジックに使われる項目や、最終的にお客様が目にする値。特に金額などは間違いがあると非常にまずいので、必ずチェックする。

リハ実施後

  • リハ結果報告を行う (計画に対して、何がじっしできて・何が実施できなかったか)
  • リハのデータを適切に保管する(ログや出力ファイルなど)