• TOP > 移行・マイグレーション > 移行見積もりの概要
  • 移行性評価作業の作業内容
  • 移行時のテスト工程の工数

• 移行・マイグレーション の移行見積もりを行う際の作業量見積もり。

• 主に、以下の移行・コンバージョン方式を扱う。

  • 環境移行（ → 環境の移行性評価作業）
  • ポーティング移行 / コンバージョン移行（ → プログラムの移行性評価作業）

何故、このようなボトムアップ見積（見積の該当節を参照）になるか？と言えば、

移行ツール開発や網羅的なチェックリストがコスパや再利用性の都合上、作成困難

なため。移行の作業項目は、本項で説明する「移行性評価作業」によって洗い出す。

コレには、一先ず、

• ビルドが通るところまで、
• 疎通が通るところまで、
• 画面が適切に表示されるまで、
• 機能が動作するようになるまで、

...と、段階的に進めて行く。

移行メモ（正誤）: 元ページの「ビルト」は「ビルド」の誤記と判断し、修正した。

補足（この段階分けの意味）: この 4 段階は、そのまま見積もりの確度が上がっていく順になっている。
ビルドが通るまでの工数は着手直後に実測できるので確度が高いが、
「機能が動作するようになるまで」は母体の仕様理解を伴うため、最後まで振れ幅が大きい。
見積もりを提示する際は、どの段階までを実測したのかを明示しておくと、後の合意形成が容易になる。

• .NETバージョンアップ移行の場合
  コチラに書かれているような手順で、実際に、「targetFrameworkのバージョンアップ」を行い、
  ビルドが通るまでに必要な作業量を見積もってみる。

• VB6.0からVB（.NET）へのコンバージョン移行の場合、
  コチラに書かれているような手順で、実際に、「ツールによるコンバージョン」を行い、
  ビルドが通るまでに必要な作業量を見積もってみる。

上記の作業には、以下のようなコードの手修正作業が含まれる。

• ポーティング移行
• 手修正有りのコンバージョン移行
• 母体理解（リバースエンジニアリング）

上記の移行性評価作業を実施して、プログラム移行の工数を見積もる。

• 各種、技術毎にポイントが異なるので注意する。

• 3RDパーティ製コンポーネント（UIコンポーネントの場合が多い）
  のサポートが無くなっていたり、インターフェイス変更があったり
  する場合に、工数への影響が大きくなるので注意が必要になる。

補足（3RD パーティ製コンポーネントのリスクは先に潰す）:
ここは移行案件で最も見積もりが外れやすい箇所である。
サポート切れの UI コンポーネントを代替品に置き換える場合、
単なる API の差異にとどまらず、イベント モデルやデータ バインドの前提が変わり、
呼び出し側の画面ロジックまで波及することが多い。
したがって、移行性評価作業では使用コンポーネントの棚卸しを最優先で行い、
「サポート状況」「移行先プラットフォームでの動作可否」「代替品の I/F 差異」を
早期に確定させておくとよい。

環境構築作業（設計と実装）。

問題があったら、環境 or プログラムの修正が必要になる。

同様に移行性評価作業を実施して、環境移行の工数を見積もる。

Tags: 移行, テスト