• 戻る（VB6.0からVB（.NET）へのコンバージョン）

VB6 → VB.NET 移行の FAQ を纏めています。

ストレート・コンバージョンの場合、
一般的な工程別・工数比率からテスト工数のみを積んだ

• 見積工数が新規開発の 0.4 - 0.5 倍になります。
• ＃逆数を取ると生産性は 2.0 - 2.5 倍となります。

この数字は、実績（移行見積もりの概要 の
前提の工数比率）からも合っていると思います。

問題は、

• VB6 → VB.NET の変換率であり、この変換率が低くなると、
  上記のテスト工数に加えポーティング作業工数が増加することです。

• 変換率が低くなるにつれ、テスト工数・ポーティング作業工数が増加し、
  新規開発に近い工数、場合によっては、それ以上の工数になる可能性があります。

VB6 → VB.NET 移行の総工数に、新規時の工数の
0.4 - 0.5 倍 ～ 1.0 倍 ～ 1.x 倍の幅があることです。

そのような問題を事前に検知するための変換率の調査ですが、
ポーティング作業工数については正確なことが言えないので、
正確な見積もりを出すためには、幾つかサンプリングして移行性評価を実施する必要があります。

• まず、変換率調査の段階で、
  お客様の予算に合うかどうか？があり、

• プロジェクトを進めることができる場合は、
  さらに移行性評価を実施し、見積もり精度を上げる必要があります。

準委任作業とすることで、顧客予算内に収まるサービスとすることは可能です。

一般的な工程別・工数比率からテスト工数のみを積んだ見積工数が新規開発の 0.4 - 0.5 倍

という慣例に従うのは、通常、品質保証（稼働までの責任を負う）のためです。
＃標準契約書の（検査）・（瑕疵担保責任）・（責任の範囲）の項を参照。

ポーティング作業（作業支援）のサービスと割り切り、検収頂けるなら
上記の工数を圧縮し、顧客予算内に収まるサービスを提供することは可能です。
＃注意：変換率によりポーティング工数は変わる。検収条件等は別途検討が必要になる。

補足（契約用語の最新化：「瑕疵担保責任」は無くなった）: 上記の
契約に関する記述は、2020 年の民法改正で用語と枠組みが変わっている。

【民法改正（2020年4月1日施行）】★
   旧：【瑕疵担保責任】
     → 新：【契約不適合責任】★

   主な違い
     ・買主（発注者）が請求できる手段が拡充された
         追完請求（修補・代替）／代金減額請求／
         損害賠償／解除
     ・期間制限
         旧：引渡しから 1 年以内に【権利行使】
         新：不適合を【知った時から 1 年以内に通知】★
             （通知だけでよい）
     ・「隠れた」瑕疵という要件が【なくなった】

   → 契約書のひな形（IPA モデル契約等）も
     すべて「契約不適合」に改訂されている ★

【請負と準委任の区別も整理された】
   ・請負          … 【仕事の完成】に対して報酬
   ・準委任（履行割合型）
                   … 【work したこと】に対して報酬（従来型）
   ・準委任（成果完成型）★（改正で明文化）
                   … 成果の引渡しに対して報酬
                     → 請負に近いが、
                       契約不適合責任は負わない

   → 本ページが述べる
     「ポーティング作業支援として準委任で受ける」
     という整理は【今も有効】だが、
     どちらの準委任かを契約書で明示すべきである ★

一般的にはどのくらいの変換率だと再構築したほうが良い等の指標はあるのでしょうか？

ポーティング工数次第だと思います。ただ、変換率に比例しないケースが多いので、

低めの変換率でも簡単な類似を修正していくことで対応出来るようなケースもある。

実際には、ポーティング工数がどの程度になるかの
移行性評価作業をしてもらって見積もって貰うのが良いと思います。

私が知るかぎりの移行完了例で変換率 75%-70% 程度の例があります。

上記、「簡単な類似を修正」部分を単純変換できるケースは
アップグレードウィザードを掛けた後のコードに対して
自作ツールで変換して変換率を上げることもあるようです。

65％を下回ると少々難しくなってくるように思います。

移行メモ（誤字）: 移行元の「アップグレードウィザードを書けた後のコード」を
「掛けた後のコード」に修正した。

補足（アップグレード ウィザードは既に存在しない）: この Q&A が前提とする
ツールは、Visual Studio から削除されている。

【アップグレード ウィザードの提供状況】★
   ・Visual Studio 2005 / 2008 に同梱
   ・【Visual Studio 2010 で削除された】★
     → 以降の VS では VB6 プロジェクトを開けない

【現在の選択肢】
 ① 【VS 2008 を用意して変換 → 新しい VS で開く】
     → 2 段階変換。今でも実務で使われる手 ★
     → ただし VS 2008 自体がサポート切れ
 ② 【商用の移行ツール】
     ・Mobilize.Net / VBUC（VB Upgrade Companion）
       → アップグレード ウィザードより
         変換率が高いとされる
       → 【.NET Core / C# への変換】にも対応 ★
     ・その他ベンダー各社の移行サービス
 ③ 【手動での書き直し】
     → 画面数が少ない、あるいは
       業務ロジックの棚卸しを兼ねるなら現実的

【VB6 ランタイムの現況】★
   ・VB6 の【IDE はサポート終了】（2008年）
   ・【ランタイムは Windows に同梱され、
     Windows のサポート期間中は動く】★
     → Windows 11 でも VB6 アプリは動作する
     → 「動くから移行しない」判断が
       塩漬けを長期化させてきた
   ・ただし
     - 64bit 化できない（32bit プロセスのまま）
     - 使っている OCX / COM の方が先に死ぬ
     - 開発できる技術者が枯渇する ★
     → 【リスクは年々上がっている】

【「変換率」という指標の読み方】★
   本ページの
   「変換率に比例しないケースが多い」
   という指摘は【極めて重要】である。

     ・変換率 90% でも、
       残り 10% が【アーキテクチャの根幹】なら
       （例：独自の画面遷移制御、ActiveX 依存の帳票）
       工数は跳ね上がる
     ・変換率 70% でも、
       残りが【機械的な置換の繰り返し】なら
       自作ツールで一気に片付く

   → 変換率は【スクリーニング】の指標であって、
     見積もりの根拠にはならない
   → 本ページが「サンプリングして移行性評価」を
     強く勧めているのは、この理由による ★

また、ActiveX を多く使用しているため変換率が低くなるという話を聞きました。

ActiveX は .NET に変換できないのですか？
相互運用機能を提供するラッパークラスがあれば利用可能で、
このラッパークラスは自動生成されるという記事を見かけたのですが...。

• VB 6.0 ユーザーのための VB .NET 移行ガイド - ActiveX コントロール
  http://msdn.microsoft.com/ja-jp/library/dd297724.aspx

ActiveX で変換率が落ちるというのは、

「移行先に同じ API セットを持つサードパーティ製の UI コンポーネントが存在しない」

と考えられるためです。

持っていく先の環境で、

「ActiveX Control（OCX）がサポートされるか？」

なども移行パスを検討する上で必要かと思います。

古い製品を新しい OS にインストールできないケース等もあるようなので。

自作の ActiveX や、サードパーティ製の UI コンポーネントを
無理やり持っていくなら、以下の仕組みである程度変換されるようです。

• COM

  • Runtime Callable Wrapper （COM API のラッパー生成）
    COM を参照設定すれば生成される。例えば、ADO (Interop.ADODB)

• ActiveX

  • UserControl モジュールに ActiveX Control（OCX）を D&D すれば生成される。
  • ActiveX コントロール インポータ（ActiveX Control（OCX）のラッパー生成）
    • http://d.hatena.ne.jp/punidama/20080224
    • https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.forms.axhost

補足（COM 相互運用の要点と、.NET Core 以降の状況）: 回答の指摘
（「変換できるかどうか」ではなく「移行先に同等品があるか」が本質）は
極めて正確である。技術面を補っておく。

【ラッパーの種類】★
   ・【RCW】Runtime Callable Wrapper
       .NET から COM を呼ぶためのラッパー
       → 参照追加で Interop.Xxx.dll が自動生成される
   ・【AxHost 派生クラス】
       ActiveX（OCX）を Windows Forms に載せるためのラッパー
       → AxInterop.Xxx.dll が生成される
       → ツールボックスへの登録 / D&D で自動生成
   ・【CCW】COM Callable Wrapper
       逆方向（COM から .NET を呼ぶ）

【変換できても解決しないこと】★
   ・【32bit / 64bit の壁】
       OCX は基本 32bit
       → .NET 側も【x86 でビルドする】必要がある
       → 「AnyCPU にしたら動かない」の典型原因 ★
   ・【登録（regsvr32）が要る】
       → 配布時に管理者権限が必要
       → ClickOnce / MSIX と相性が悪い
   ・【ベンダーが消えている】
       → サポートも修正パッチもない
       → 本ページの
         「古い製品を新しい OS にインストールできない」
         はまさにこれ ★

【.NET Core / .NET 5 以降の COM 相互運用】
   ・【Windows 上でなら使える】★
     → <UseWindowsForms>true</UseWindowsForms> 等と併せ、
       COM 参照も可能（EnableComHosting 等）
     → ただし .NET Framework 時代ほど
       ツール サポートが手厚くない
   ・当然ながら【Linux / macOS では動かない】
     → クロスプラットフォーム化が目的なら
       【COM 依存は必ず断ち切る】必要がある ★

移行ツールでサポートされていますか？

• Visual Studio 2008 以前に同梱されている移行ツールで
  サポートされているようです。
• ただし、ActiveX の問題や、サードパーティ製の UI コンポーネントの問題が
  考えられるので注意が必要です。

補足（VB6 Form → Windows Forms で必ず出る差異）:
「サポートされている」とはいえ、そのまま同じには動かない。

【自動変換されるが挙動が変わる代表例】★
 ① 【座標系】
     VB6 は既定が【twip】（1/1440 インチ）
     .NET は【ピクセル】
     → 変換はされるが、
       小数の丸めで【1px ずれる】ことがある
 ② 【コントロール配列】
     VB6 の Text1(0), Text1(1) …
     → .NET には存在しない
     → Microsoft.VisualBasic.Compatibility の
       疑似実装に置き換わる
     → 【この参照が残っていると "移行できていない"】と
       見なされることが多い ★
 ③ 【既定のフォント】
     MS Sans Serif → MS UI Gothic / Yu Gothic UI
     → 【文字幅が変わり、レイアウトが崩れる】★
 ④ 【AutoScaleMode】
     DPI やフォントに応じた自動スケーリングが入り、
     デザイン時と実行時でサイズが変わる
 ⑤ 【イベントの発火順序】
     Load / Activate / Shown の順序と回数が異なる
 ⑥ 【変数の既定値・型】
     Variant の廃止、Integer が 16bit → 32bit ★
     Option Strict Off のまま移行すると
     実行時まで型エラーが出ない

 → 【画面の目視比較テストが必須】である。
   本ページが「テスト工数のみを積む」としているのは
   正しいが、その【テスト工数が重い】ことの理由がこれ ★

移行ツールでサポートされていますか？

ADODB（ADO.NET以外のデータプロバイダ を参照）から
ADO.NET への移行は手動で行う必要があるようです。

補足（ADODB → ADO.NET の対応関係）: 手動移行の
見当をつけるための対応表を示す。

ADODB（COM）	ADO.NET	備考
Connection	SqlConnection 等	ほぼ 1 対 1
Command	SqlCommand	ほぼ 1 対 1
Recordset（forward-only）	SqlDataReader	接続したまま前方向のみ
Recordset（static / 切断）	DataTable / DataSet	切断型 ★
Recordset.Update	SqlDataAdapter.Update	発想が大きく異なる ★
Recordset.MoveNext	reader.Read()	ループの書き方が変わる
Field.Value	reader["列名"]	DBNull の判定が必要 ★
BeginTrans / CommitTrans	SqlTransaction	using で書く

【最大の落とし穴：DBNull】★
   VB6 は Null を Variant で緩く扱えたが、
   .NET では【DBNull.Value】という
   専用の値が返る
     → そのまま String に代入すると
       InvalidCastException
     → reader.IsDBNull(i) で判定するか、
       Nullable<T> / as 演算子を使う

【カーソルの発想を捨てる】★
   ADODB の Recordset をカーソルとして
   1 行ずつ動かすコードを
   そのまま DataReader に置き換えると
   【接続を長時間掴んだままになる】
     → 一旦 List<T> / DataTable に読み込んで
       接続を閉じる方が安全
     → 本来は【SQL 側で完結させる】のが最善

【この移行は「変換」ではなく「設計変更」】
   → 自動化が難しいのはこのためであり、
     本ページの回答（手動）は妥当である ★

再構築を行うかどうかの決め手は、最終的には工数だと思っています。

(3)、(4) で対応した場合の変換率が悪いと、
プログラム製造、単体テストには再構築に近い工数がかかると思いますが、
大きな違いは詳細設計をやり直さなければならないという点でしょうか。

移行メモ（参照の欠落）: 質問中の「(3)、(4)」は、
移行元でも何を指すかが示されていない。
VB6.0からVB（.NET）へのコンバージョン の
移行方式の選択肢を指していると思われるが、断定できないため原文のまま残した。

詳細設計（イベント仕様書相当）をやり直すパターンは、
リエンジと言うよりは新規開発の一部作業を欠いたものに近いかもしれません。

補足（移行 / リエンジ / 再構築の切り分け）: 回答の含意を
一般化して整理しておく。

【工数の増え方は「どこからやり直すか」で決まる】★

   ┌ 要件定義  ─┐
   │ 基本設計    │ ← ここからやり直す＝【再構築】
   │ 詳細設計    │ ← ここからやり直す＝
   │             │    「新規開発から要件定義を欠いたもの」★
   │ 製造        │ ← ここからやり直す＝【リエンジ】
   │ 単体テスト  │
   │ 結合テスト  │ ← 移行でも【必ず必要】
   └ 総合テスト ─┘ ← 移行でも【必ず必要】

   ストレート・コンバージョン（0.4-0.5 倍）が成立するのは
   【設計をやり直さない】場合だけである ★

【判断の実務的な目安】
   ・現行の仕様書が【存在し、保守されている】
     → 移行（ストレート・コンバージョン）が成立しやすい
   ・仕様書が【ない / 古い / コードが唯一の仕様】
     → 詳細設計の復元作業が発生する
     → 【この工数が見積もりを狂わせる最大要因】★
   ・業務要件そのものを見直したい
     → 素直に【再構築】と位置付ける
     → 「移行」の名目で始めると
       必ずスコープが破綻する ★

【現在の移行先の選択肢】
   ・VB.NET のまま（.NET Framework）
       → 最小の変更。ただし .NET Framework は
         新機能追加なし（4.8.1 が最終）
   ・【VB.NET を .NET 8/9 へ】★
       → Windows Forms は VB でも .NET 8 対応
       → ただし ASP.NET Web Forms は移植先がない
   ・【C# へ変換】
       → 技術者確保の観点で選ばれることが多い
       → VB → C# の自動変換ツールは精度が高い
         （[VB ⇔ C Sharp 変換](MS_VBToCSharpConversion) 参照）★
   ・【Web 化】（Blazor 等）
       → 実質的に再構築

Tags: 移行, .NET開発, Visual Basic