私が複数の掲示板で見たいくつかのメッセージと，最近読んだいくつかの記事によると，米Microsoftが突然Visual Basic 6.0（VB6）をお払い箱にしたために，多くの開発者は空が落ちてくるような絶望を感じているようだ。
この騒ぎは，MicrosoftがWebサイトに掲載した「Visual Basic 6.0ファミリー製品のライフサイクル・ガイドライン（Product Family Life-Cycle Guidelines for Visual Basic 6.0）」に端を発している（該当ページ）。このページは，VB6のサポート・スケジュールを定義している。それが示す通り，VB6.0は2005年3月31日に衰退への第1歩を記した。MicrosoftはVB6をメインストリーム・フェーズ，すなわち完全にサポートされる主流製品から，延長サポート・フェーズへと移行したのである。
VB6のサポートは延長フェーズへ
VB6のライフサイクルのWebページには，この移行が何を意味するかをはっきりとした言葉で規定している。一番大事な点は，この移行があなたのVB6アプリケーションが動かなくなるとか，MicrosoftがもうVB6をサポートしないといったことを意味するものではない，ということだ。唯一意味するところは，技術面では古い製品になったVB6が，引退する方向に進んでいるという事実である。
VB6に限らず，Microsoft製品のすべてはWebページ「プロダクトライフサイクル - 開発ツール」（該当サイト）で分かる通り，サポート期限が明確になっている。このWebページは開発者向けの全ツールについて製品のライフサイクルを示している。
開発者向けツールのライフサイクルを説明するWebページの方が，VB6のページよりも参考になる。理由は，VB6のサポート・フェーズ変更を適切に見通すのに役立つからである。例えば，「Visual C++ 6.0」は2004年9月に延長サポート・フェーズに移り，「Visual Interdev 6.0」（ASPやActive Server Pagesとしても知られる）は2003年9月にこのステージに移った。VB6は，現実には，Visual Studio 6.0ファミリーの中でもメインストリームのサポートから延長サポートに移された最後の製品である。だからVBのコミュニティが文句を言うことはほとんどないのだ。
移行に必要な時間は十分あった
しかし，数人の開発者は次のように主張する。「VB6とVisual Basic .NET 2002の間にある本質的な変更を考えると，VB6アプリケーションを適切に移行させる時間はなかった」と。これらの開発者はASPとASP.NETは完璧に互換性がなくASPが1年半以上前から延長サポートに移っているにもかかわらず，ASPを走らせているWebサイトがまだあることを忘れているようだ。
開発者向けツールのライフサイクルのWebページが示すように，WordとExcelのマクロの背後にあるエンジン「Visual Basic for Applications 6.0（VBA 6.0）」は2008年12月までメインストリームのサポートが続く。これは，基礎となっているVB系の多くはさらに3年間メインストリームでメンテナンスされ続けるということを示している。その後のVB6の生き残りについては，Paul Thurrott氏は米REAL Softwareの「REALbasic」を推薦している。
ご存じない人のために言うと，私は「Microsoft Most Valuable Professional（MVP） for VB6」である。そのようなわけで，私はVB6のメインストリーム・サポートを終了させ，さらにすべてのサポートを2008年までに段階的に終わらせるというMicrosoftの決定を支持する，と公に表明したい。私がメインストリーム・サポートの終了支持を宣言している理由は，見当違いのMVPたちを含む数人の開発者が，この古い製品のメインストリーム・サポートを延長させようと努力しているからだ。私の意見ではこうした開発者は，もう過ぎてしまったことを悔やんでいるのだ。こうした努力は，Windows 3.1と16ビット・プログラミングの世界に戻すよう懇願すると同じようなもので無駄である。
歴史は繰り返す
私は自分のキャリアで昔起きた2つの事件のおかげで，今回のことはかなり強く意識している。私は常にMicrosoftの開発用製品を使っていたわけではない。10年以上前に私は「Massachusetts Utility MultiProgramming System（MUMPS）」という言語を使っていた。MUMPSのことを聞いたことがない人のために書くと，この言語はFORTRANの次に標準化されたのだった（該当サイト）。
私は若手の開発者として，MUMPS関連のミーティングに参加していた。このミーティングでは，MUMPS開発者たちが標準をどう進化させるかを議論した。当時はインターネットが本当に始動する前の，クライアント/サーバー型の開発が盛んだったころだ。このミーティングで，上級の開発者が「私はMUMPSを20年前に勉強した。それ以来，私は新しい構文を学んだり，新しいパラダイムを習得しようとしたりする必要がなくなった。私は現在のMUMPSの実装が好きなので，グラフィカル・ユーザー・インターフェースをサポートするための変更が，最小限の影響を与えるだけで済むかどうか検討されるべきだと考える」と言った。VB6を自分たちのメインの開発用プラットフォームにしておきたいという開発者は，こういう態度について考えてほしい。
当時，私が働いていた会社では，すべてMUMPSベースの大きな製品を抱えていた。この会社は，この製品をテキスト・ベースのスクロールよりも，もっと人気の高かったGUIのような新しい機能を持たせるように改良するかを検討していた。その議論の中には，新規の開発はMUMPSをベースにして続けるべきか，あるいはSQLベースのデータベースとGUIの開発環境に移行するべきかどうかという懸案があった。技術リソース部門の上級メンバーが，これらの技術の詳細な比較資料を提出した。彼のプレゼンは，MUMPSがどんなに公的な標準になっているか，緊密な技術コミュニティに支えられているか，そして検証済みで確実な技術であるかを示したものだった。彼は，当時のほとんどのSQLの実装とGUIツールとは違って，MUMPSの技術は複数のベンダーがサポートしており，様々なプラットフォーム上で動作するということを論じた。
重要なのは使い慣れた道具よりも市場動向
彼はプレゼンテーションの後，鋭い観察をする上級副社長は次のように言った。「君の分析には感謝する。私は君の分析を少しも疑わないし，MUMPSが現在最高の選択肢だという君の推薦も受け入れよう。しかし，そもそもの質問は今日の時点で君に何ができるということではない。市場が動く先はどこかということだ。今後，MUMPSが技術市場を支配することはないだろうし，それに追い付きさえしないだろう。そして市場を抑えるような技術は，われわれのユーザーが要求するよりも常に大きな能力を提供するだろう。だからわれわれは，今後そういう技術に対して，てこ入れをする」と。
この2人の発言は，VB6とASPはそれ自体がソリューションなのではないということを私が肝に銘じておくのに役立った。それらはツールに過ぎず，こうしたツールは，特定の問題をわれわれが解決する手伝いをするために設計されている。古くなったツールと全く同様に，こうしたツールはすり切れていくだけでなく，われわれの作業をより楽に，よりうまくやれるようにする，もっとよいツールで置き換えられていくものなのだ。技術は進化し続ける。そして新しいツールの使い方と，一番効果的なツール群で新しい問題を解く方法を学ぶことが，われわれのビジネスである。
