> それには2005の知識のみならず6.0についても知っていないとできないのでしょうか？
両方を知っている人の方が遥かに効率が良いです。

たとえば、フランス語の映画があって、それを日本語に翻訳する事を想像してみてください。
日本語は達者でもフランス語は片言程度という人に、完全な翻訳は望めないですよね。
それに言語のみならず、それぞれに特有の文化についても知っておいた方が良いですよね。

コンピュータ言語でも同様です。翻訳結果に曖昧さが含まれていてはならないのですから、
両方の言語に通じているべきと言えます。また、6.0 では API が必須だったが、2005 では
プロパティ設定だけで OK …などといった場面もあるでしょうから、両方の仕様の違いを
熟知している人の方が、移行作業に有利である事は想像に難くありません。

一応、6.0 と 2005 は文法的には似通っているため、前提知識があまり無くとも、
ある程度までは読み解けると思います。問題は、コントロールの機能の違いなど、
環境に依存する部分や、「VB6 に固有の部分」の把握の度合いにあるでしょう。


・まずは、MSDN の『Visual Basic 6.0 ユーザー向けのヘルプ』を参照のこと。
・Visual Basic マイグレーション センターも必読です。
　http://msdn.microsoft.com/ja-jp/vbasic/cc707251.aspx
・VB6 登場から 10 年以上経っているので、当時利用していたコンポーネントが、
　現在は入手できない(もしくはサポートされない)可能性を考慮しておくこと。
・移行目的には、Microsoft.VisualBasic.Compatibility.DLL を参照設定して
　Microsoft.VisualBasic.Compatibility.VB6 名前空間のクラスを使うことが有効。
　(ただし最終的には、この名前空間のクラスを使わないコードに置き換える事が望ましい)
・データベース操作は大きく異なる。6.0 の ADO と 2005 の ADO.NET は別物である。
　(2005 で ADO を使うことも不可能では無いが、問題点が多いので避けるべき)
・6.0 には、「コントロール配列」という特殊なコレクションが存在する。
・文字コード変換を伴うコードと描画系メソッドの扱いが大きく異なる。
・6.0 では、オブジェクトの代入には『Set』という特殊なキーワードを使う。プロパティにも
　Get/Set/Let の 3 種があるので要注意。(2005 のプロパティは Get/Set のみ)
・Excel 操作など、いわゆるオートメーション(OLE オートメーション)の移行は鬼門。
　移行は不可能では無いが、この分野に関しては 6.0 を引き続き利用した方が問題が少ない。
・Declare を使う場合、2005 の [IntPtr] は 6.0 の Long に相当する。
・Declare を使う場合、2005 の [Integer/Int32/UInteger/UInt32] は 6.0 の Long に相当。
・Declare を使う場合、6.0 の Long を 2005 で何に翻訳するべきかは文脈依存。(通常は IntPtr または Integer)。Any 型も悩みどころ。(このあたりは VB のみならず、API の知識も要求される)


> そもそも移行というのは外観も内部設計もまったく新しく2005以降のVBで作り直す意味なのですか？
そういう場合もありますし、そうでない場合もあります。
処理内容によっては、アップグレード ウィザードにかけるだけで済む場合も(ごく稀に)ありますし、
画面制御が複雑なアプリなどでは、リメイクした方が早い場合もあるでしょう。


> こういう案件だとあまり納期まで日数をくれないなんていう噂話を耳にしたもので。
そこは現場と担当者次第なので、何が一般的という事も無いのですが、短絡的に考えれば
別言語(java、MFC等)から移行する場合よりは、納期は短縮される事が多いです。

# 逆に「VB6 でできたんだから .NET でも可能なハズ」の一点張りで、仕様変更がままならないような
# 現場では、互換性がかえって足枷になってしまった例もあるにはありましたが…それは例外として。

ただし、6.0版の仕様がはっきりしていない場合、調査工数を上乗せすべきと思います。
仕様書等がしっかりしている場合は、開発工数は大きく減らせるかも知れませんが、
行うべきテストの総工数については、そう変わらないと思います。

なお、過去の移行作業を鑑みると、日数が必要な場合とそうでない場合とがありました。

2.0→4.0(16bit) では、コンポーネントの互換性面から、それなりの手間が必要でした。
2.0→4.0(32bit) では、移行にかなりの手間がかかりました。
4.0(32bit)→5.0 では、移行の手間はやや少なかったです。
5.0→6.0 では、移行を気にする必要はほとんどありませんでした。
6.0→2002(7.0)は、初めての.NETという事もあり、移行は大変でした。
2002(7.0)→2003(7.1)は、移行の手間はほとんどありません。
2003(7.1)→2005(8.0)は、移行の手間はやや少なかったです。

問題は、バージョンを飛び越える場合ですが、6.0→2002 と 6.0→2005 を比較すると、
差はほとんどない(もしくは、2002への移行よりも若干容易)といった所でしょう。私見ですけれども。


> 6.0資産が世の中に多いのかどうかも想像がつきません。
多い現場も皆無な現場もあります。が、少なくとも私の回りには幾らか生き残っています。

また、Vista でも VB6 ランタイムがサポートされた事実を考えれば
(2002はサポートされなかったのに)、それなりのニーズがあったとみるべきでしょう。

> 移行といった場合、仕様の策定からまったくやり直すのか、
> それとも今あるシステムを見ながら単にコピー的に.NETのルールで書きなおすだけなのか、
そのどちらもありえます。経験則なので難しいところではありますが、
移行作業が膨大になれば、リプレースが有効と判断される場合もあるでしょう。

いずれにせよ、新システムを作る場合、前の機能に＋αが求められるのが常ですから、
仕様の見直しは必須となるケースが多いです。単純な置き換え部分については、当方では

・要求仕様…＋α分が無いなら、ほとんど変化なし。
・ＤＢ仕様…あまり影響しない可能性が高い。
・コード設計仕様…全面的に見直しが必要。
・入出力仕様…文字コードの扱いが異なる点に関して若干の工数が必要。
・テスト仕様…画面系は見直しが必要。
・結合テスト仕様…システム間通信がある場合は設計から要確認。

といったところでした(他社、他業態ではどうだか分かりません)。
# ＰＪ計画仕様、パッケージ適合仕様等々、いわゆる「仕様書」は
# 数多くあるので、あまり細かく述べる事はできませんけれども。


> そしてそれには6.0と2005の両方の知識が欠かせないのか、そのあたりを教えてください。
開発規模にも寄りますが、両方の知識を有する人が、最低1人は居た方が良いでしょう。
ただしチームの力量が高い場合において、片方だけの知識で成功した例を見た事はあるので、
絶対に欠かせないのかと問われると、そうとも言い切れない面もありますけれども。


> たとえば役場とか公共機関でVBによるシステムとかって使われていたりするものですか？
ありますよ。少なくとも自分は、VB4 の頃から何度かその手の開発に関わっていますし。

またかなり昔ですが、市販のCD ライティングソフトに使われていた例も見た事があります。
DLL は別言語で作られ、画面周りが VB 製でした(現行バージョンでは違うようですが)。

その他(これも最近の事では無いのですが)、富士通系の PC で、プリインストールされているゲームが
すべて VB 製のものであった物を見た覚えがあります。後はフィットネスクラブで、予約システムの
端末を除いたら、フォームのアイコンが VB アプリの物であったものとか…。