2012年04月02日

現行からのリプレース案件、マイグレ案件の注意点について

こちらは以前にも似たことを書いたことがあります。

システムの再構築について http://kiruah.sblo.jp/article/45437976.html

今関わっている案件もリプレース案件です。この案件は基本現行をそのままプログラムを変更せず
新しいハードウェアに移行するというものです。
ですが、その中に一部仕様変更を盛り込みたいというものがあります。
私は何度でも言いますが、まずは移行だけをしましょう。
その後に仕様変更を取り込むようにすべきです。

でなければ、

1. バグが現行からなのか、それとも新規に追加した仕様なのかの調査が複雑になります。
2. 工数の計算が複雑になります。なぜなら移行なのか、それとも仕様調査なのか、修正なのかどちらのテストを実施しているのかが曖昧になります。これは工数請負の場合、特にユーザ側に後々不利になります。曖昧さは、こちらのマイナスを別の理由に転嫁できてしまうためです。
3. 若手がいる場合、教育工数が非常にかかります。当然現行の知識を知り、その上で修正分を理解する必要があります。まずは現行を移行しテストさせ理解した後で、変更分を理解させるほうが教育工数が減ります。
4. 経験的にですが、スケジュールの立て方が往々にして曖昧になりやすく、これぐらいで両方できるだろうという程度のスケジュールを構築しがちです。よって、後ほど時間が足りなくなることが多いです。
5. 後戻りが簡単です。移行が完了していれば、最悪仕様変更を取り込んでいないモジュールを使い、現行レベルを維持してリプレース運用は可能です。それが同時に行われた場合、切り離しが必要か、一部機能は問題がないとしても全機能の実装完了が必要となってしまい、ユーザのビジネス機会が損なわれやすくなります。

幸いにして、今の案件は現行調査と実際の修正はフェーズを分けることを全員が認識していたため、まずは現行のリプレースのみが完了しました。
よって、その後に仕様修正分を集約し変更するだけですので、横目に見ても作業は簡単に見えます。

SIerは一気に詰め込んでしまえ!と、何でもかんでも混ぜ込みすぎます。一つ一つを順次やるほうが、後戻りも楽ですし、差分検出、過去からの不具合なのかを明確に順次トレースできます。
やり方、考え方はいつも、「急がば回れ」です。
posted by Kiruahさん at 22:00| Comment(0) | TrackBack(0) | ノウハウ
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/54758460
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック