アプリ版:「スタンプのみでお礼する」機能のリリースについて

ソフトウェア会社入社6年目の社会人です。
今度パッケージシステムのデータ移行の仕事を任されましたが、最初から不安を感じています。

私の心配な点は、以下の点です。

・移行の経験がはじめて
・両方(移行先・元)のシステムともはじめて
・3つのシステムを1つに統合(うち、1システムはお客様からの開示資料にDB仕様がなくデータのみ)
・期間は4ヶ月
・移行対象テーブルは80くらい

過去の移行業務経験者は毎回かなり大変だそうです。
それも私よりスキルのある方ばかりなので本当にこなせるのか不安です。
上司に相談しても「みんなやってきたことだし、データの入れ替えだけだから大丈夫」といわれるだけです。
期間が短いので途中でやり方の変更などを行えないように思い、はじめに計画をしっかりたてなければと思います。
そこで効率のよい手順、気をつけるべき点等、移行業務経験者、先輩の方、アドバイスをいただけないでしょうか?

ちなみに現在は移行先システムの把握を終えて、移行元システムの把握を行っています。
よろしくお願いします。

A 回答 (3件)

・やることを項目に書き出す(文章にすると、読むのに疲れる)


・わかる範囲で、行った結果も書く(本当に実行されたか、確認する)
・項目には番号を振る(するべき順序を把握するため)
・やったことがわかるチェック欄をつける
・番号、チェック欄は、ページをめくったときに裏から見えるところに作る←重要
・必ず一度以上、その手順を実際に行う
・可能な限りバッチ処理を組み、人間の手を不要にする
・二人以上で行い、一人は全行程をチェックする←可能なら

 手順書を作り、手順通り行ったが、ページをめくるときに1枚とばしてしまった、ということがありました。そのために、裏からチェックや通し番号が見えるようにして、とばしていないことが確認できるようにします。
    • good
    • 0

多少なりともお役にたてばと思いアドバイスさせていただきます。



経験から言えば、大事なことは、以下の3点です。

(1)移行元のどの項目を移行先のどのテーブルにうつすのかをはっきりさせる

 移行元の項目すべてが、移行先テーブルに存在しているかを確認し、ない場合は、
   a.省く
   b.移行先に設ける
 かの判断をお客さんにしてもらわなければなりません。
 ヒアリングをしっかりして、移行元テーブルとと移行先
 テーブルの相関がわかる表を最初に作ったほうがよいで すよ。

(2)移行する順番
 他のtableからIDだけを参照して載せているようなテーブ ルに関しては、参照元のテーブルから先にデータを載せ なければならない等の制約はありませんか? その場合
 移行する順番が大きな問題となります。

(3)「データの取り出し方法」及び「取り込み方法」を決める。
 これは先輩によく教えてもらった方がいいと思います。
 ツールなどが部分的にでも既に存在するのであればかな
 り楽だと思います。

以下、上記の点に注意した上で私が移行作業を行ったときの簡単な手順です。

(1)ヒアリングをします(移行する項目を確定)
(2)移行定義書を作成します。
(3)必要な環境を構築します。
(4)テスト計画書を作成します。
(5)ヒアリングした移行項目・テーブル項目・
   APIパラメーターの3つをマッピングします。
   不明な点は単体テストにて確認します。
(6)マッピング表が完成次第、プログラム設計書・
   連結テストデータをつくります。
(7)プログラミング設計書に基づき、コーディングを行
   います。
(8)連結テスト・検証・プログラム修正
(9)移行順序を再確認し、実データを移行

ちなみに私が移行作業を行ったときは、API(Application Program Interface)が移行先に備わっていたのでAPIを経由して移行データを受け渡しました。
    • good
    • 0

DB仕様などは、可能な限り自動生成をさせましょう。


そして、しっかり現状のシステムを把握します。

    • good
    • 1

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!