予算さえあれば、新規作成 or 完全移植してしまうのがベターなのだが、多くの場合予算の関係で VB6 の業務アプリをそのまま使い続けることがある。旧来の PC（Windows 2000やXPも含む）にインストールされている VB6 の業務アプリを専用機器のまま使う（あるいは、PC から吸い上げて仮想モード内のみで使う）方法もあるのだが、いくつかのネックがある。
- 既存バグが解消されない
- 新規システムと接続できない（修正できない）
- 既存PCの CPU 速度に引っ張られて遅い
こともあり、 VB6 の業務アプリから何らかの形で引っ越したいところなのだが、予算がない、あるいは既存の業務アプリが複雑怪奇すぎるための引っ越しの予算が掛かかるかもしれない、という理由から、なんとか既存 VB6 コードを弄ろうとする。それは試算は試算なのだから、工場の機械よろしく使い潰すのがベターともいえる。
で、まったく移行予算が取れない場合は論外なのだが（社内等で VB6 のまま弄るしかない）、なんらかの予算が取れれば移行を外注することも可能ではないか？…という「仮定」のもとに考察してみる。
移行先のフレームワークを考える
VB6 の業務アプリの場合、C/S 方式が主なものになる。SQL Server か Acesss にデータを集めるために（当時の予算枠の具合で SQL Server か Access かが決まってくる）、ODBC, RDO, ADO を使って VB6 からデータベースサーバーへアクセスする。ユーザーが入力する画面では、旧文化オリエントのコントロール、スプレッドシートが使われていることが多い。実際、2002年頃に VB.NET が出てから、VB6 から VB.NET へ移行するために、各種の既存コントロールを .NET 化させたものが発売されている。ただし、VB のコンバートツールがあるものの、これらの .NET 用のコントロールまで網羅してくれてはいない。あくまで標準的なコントロールのコンバートのみとなり、スプレッドシートでかなりの部分をあれこれしている場合には、自動コンバートしたときにもアレコレしないといけないという「手間」が掛かってくる。イコール、移行予算が跳ね上がるのである。
また、2002年当時であれば、VB.NET や .NET の業務アプリも素朴なフレームワークなものが多かったのだが、今となっては、VB6 で作ったフレームワークをそのまま VB.NET に持って来るとコーディングの効率の悪さやメンテナンス性の悪さも引きずってしまう可能性が高い。たとえば、RDO や ADO で延々と SQL を書いている部分は、今であれば LINQ に直してしまうのが望ましい。特に Entity Framework と組み合わせてしまうと、INSERT/DELETE/UPDATE のコードはほぼ1行で済んでしまう。
また、当時から PC での C/S アプリをブラウザ形式の WEB アプリにすることが盛んであった。失敗には終わったが、Java アプレットや Siverlight、Flex のようなブラウザ上でのコンポーネントに移行してしまうというパターンもいくつかある。となると、既存の VB6 の C/S 形式のアプリを、何も考えずに C/S に直すというのもちょっと問題がある。潤沢ではない限られた移行予算となる場合は、
- 移行時のコード量が、元のコードよりも大幅に減り、開発時間を減らす。
- 移行時のテスト期間を何らかのツールを使って、大幅に削減できる。
という点に注視する必要がある。たとえば、移行コード量が移行前のものと同じでしかないのであれば、開発期間も同じぐらいかかり、単純に同じ程度の開発/移行コストが掛かるという見積もりになる。移行予算が潤沢に取れればよいが、そうもいかないであろう。IT 業者としては、新しい機能を盛り込むという理由を付けて、それなりの予算を取りたいところであるが、移行を頼む側から言えば、「同じ機能を実装してくれればよい」ので、余分に予算を取りたいわけではない。ある意味では、移行前も移行後も「同じ機能」でしかないので、できることなればい移行はゼロ円で済ませたいところなのだ。
一般的にソフトウェアは、劣化しないものとされているが、そういう意味では長期でソフトウェアを資産とするには、経年劣化があり資産価値がゼロになるということだ。このあたり、IT業者も非IT業者もあまり真面目に考えていない。
なので、旧来の VB6 の業務アプリは、OS がサポートから外されている、既存バグを直す人がいなくなっている、という理由から新しい業務アプリに移行するのが主な理由になる。そうなると、既存の VB6 と使用感は変わらないほうがよい。つまりは、「既存の VB6 アプリを Xamarin でタブレットアプリに移行しませんか？」というのはムダである。できることなれば、そのままでいいのだ。既存の不具合は直したいところだけど。
そうなると、移行先のフレームワークは限られてくる。ユーザーの特に新しくない使用感に合わせるためには、
- VB6 業務アプリで C/S 風に使える
というのがベターである。この場合、ブラウザでぽちぽち入力するのも許容範囲であれば、
- 現状の C/S をそのままのシステム移行
- 内部で Web API を利用する C/S 方式へ移行
- ブラウザ方式に移行
というパターンに落ち着く。既存の VB6 では RDO/ADO 等が使われているが、C/S 方式であっても EF+LINQ を利用する（コード量やテスト効率を含めて）、あるいは C/S でストアドプロシージャ等が使われていれば Web API/REST に移行するのもよいだろう。画面が多少パタパタしてもよいのでれば、HTMLを使ったブラウザアプリ（ASP.NET、PHP など）でも構わない。少なくとも、既存の C/S 方式をそのまま自動コードのコンバーターを使って移行するのは得策とはいえない。
移行先のプログラム言語を考える
2002年当時、VB6 から自動コンバートすると VB.NET のコードが出力される。今でもそうだけど、VB6 から C# へのコンバートはされない。先の理由から、自動コンバート自体おすすめできないので、なんらかの手作業による移行が必要になる。手作業であるから、移行できるコード量と、移行後のコード量というのが開発/移行コストに大きくかかわってくる。
既存の VB6 のコードで、標準モジュール（いわゆるライブラリ）が多ければ、*.bas なコードをそのまま VB.NET に持ってきても良いだろう。モジュールのままでもよいし、適当なユーティリティクラスでラップしてしまってもよい。特に複雑なロジックが入っているのであれば、*.bas なコードをそのまま流用できるならば、移行的にはかなり楽になる。
…ハズなのだが、実は、VB6 業務アプリでロジックが重要ということはあまりない。科学計算を必要とするとか、ブラックボックス的な業務ロジックを組む場合には、既に C++ であったり、C# に移行してしまったり、ストアドプロシージャで整理されていたりするので、VB6 自体には *.bas で移行する部分はほとんどないといってよい。*.bas なコードを眺めると、文字列の編集だとかデータのコンバートだとか、いまであれば .NET クラスライブラリに入っていそうなものばかりである。なので、VB6 だから VB.NET が有利である、というプログラム言語が同じであるというメリットはかなり低い。
そうなると、プログラム言語は、C# であっても VB.NET であっても構わない。C# の場合 VB6 から IF文や FOR文を移行するときにかなり書き替えなければいけないのだが、LINQを使うとかラムダ式をつかうとかイベントを多用するとか、を考えると VB の冗長なところが面倒だったりする。
なので、移行先のプログラム言語は、プログラマ自身が得意と思われる（チームが得意と思われる）言語がよい。C# か VB.NET のどちらを選んでもよい。まして、ブラウザアプリに切り替えてしまうのであれば、PHP でも十分なはずだ。
データベースを考える
C/S 方式の場合、サーバーにデータベースを据えることが多い。実際、VB6 での業務アプリの場合はサーバー側は十中八九 SQL Server となる。SQL Server のカラム名が日本語であったり、ひとつのテーブルのカラム数が50位あったり、正規化が不十分だったりすることは多いのだが、実は、データーベースの寿命はデスクトップアプリのそれよりも長い。
となれば、データベースの構造は、目をつぶってそのまま使うのひとつの方法である。よほどひどいモノでない限り、SQL Server のものを SQL Server のまま扱うのがよいだろう。このほうが EF + LINQ との相性もよいからだ。
ただし、EF を使うときに制限があり、テーブルに「主キーがひとつ」必要になる。LINQ が主キーを頼りに SaveChange するためなんだが、これはADO.NET Model のデザイン対象となるデータベースを仮に作ってしまい、主キーを付けることで回避できる。
印刷/帳票機能を移行する
旧来の VB6 では印刷機能が貧弱であったため、旧文化オリエントのスプレッドシートやレポートツールを使っていることが多いのだが、現在もそれを使い続けないとけない理由はない。
- PDF に直接出力する
- Excel や Word に出力する
- HTML形式で出力する
最終的に紙に印刷するにしても、.NET から PDF に出力するライブラリはたくさんある。データをリスト形式で印刷するならば、HTML 形式を通して印刷してもよいだろう。
また、Excel や Word であらかじめテンプレートを作っておいて、データを埋め込む方法もできる。こうすると、微妙なフォントの大きさや印刷位置の調節をあらかじめ Excel や Word 上で確認することができる。
移行時の予算を考える
先に示した通り、現状の機能を移行する「だけ」なので、発注側にとって移行コストはゼロ円が望ましい。しかし、実際のとこころは資産価値が減少するのであるから、使い続けるためにはなんらかのコストを掛けるのは否めないというところだろう。
目安として、移行コストは新規開発の予算の半分から1/3といったところだろう。これは、機能はそのままでの移行案件の場合、
- 要件定義、設計工程を省くことが可能
- テスト工程で、正しい動作（既存の業務アプリ）が確認できる
ことになるためだ。多少の既存バグを修正する場合はよいのだが、移行時に機能追加をする場合には、その分のコストは別途見積もるのがよい。
また、これ以下の予算しか取れないばばあいは、コードを修正するような移行は諦めて、仮想環境への移行など延命処置に切り替える。この場合、当然のことながら VB6 の内部コードを弄ることはしないので、既存バグは既存バグのまま残ることになる。どちらを選択するかは顧客が選ぶことなる。
移行スケジュールを考える
大抵の IT プロジェクトの場合、予算が決まればスケジュールが決まる（人月で割るから）なのだが、VB6 からの移行の場合は、それは当てはまらない。というのも、単純に安めの移行予算を人月で割ってしまうと、超短期なスケジュールになってしまい納期遅延が必至になってしまうからだ。なので、移行スケジュールは、予算とは関係なく3か月から半年程度取ってしまうのがベターだ。
半年のスケジュールとなると、通常開発であれば（中小企業にとっては）相当な金額になってしまうものだが、実はフルタイムで移行プロジェクトに関わらなくてもよい。いや、むしろフルタイムで関わってしまうほうが移行プロジェクトのリスクが高くなってしまうとも云える。
プロジェクトの各タスク/WBS/チケットを出した後は、適当に順番にこなしていくのが移行プロジェクトを推進するときのノウハウになる。というのも、機能だけ移行する場合は、機能追加などの要件の調査や概要の再設計などが必要ないので、一種のウォーターフォール的な開発にバラすことができる。つまり、ひとつのチケットに対していつ開始していつ終了しても全体コストが変わらないパターンとなる。
適用条件としては、
- 大幅な機能追加がないこと。「移行」だけに専念でき、要件定義、設計はそのままとする。
- 既存のシステムが正常に動く（既存バグは除く）こと。
ということになる。この範囲であれば、顧客との交渉を減らすことのができ所謂コミュニケーションコストを減らせる。そして、週報等も省略し、適度なマイルストーンのみを配置する。全体的に緩くスケジュールを組み、別のプロジェクトと平行にこなす（保守プロジェクトとか）ことにより、チケット駆動開発が有効に働く。
これらの条件が揃ったときに「移行プロジェクト」の成功率は格段にあがる。
