同意見です。
VB6は私が実務で一番最初に使った言語です。
余りに古すぎる。
もっと古いC言語とアセンブラはまだ使いますが、VB6は毛色が違いますよね。
VB6は思い出があるので好きなのですが、でも今の状況だと悪い面が目立ちます。
いい思い出だけを残して終えてほしいと願っています。

サポートの切れた言語を使ってくる企業とは付き合いたくないですね。
そんな企業は無いと信じたいですが…。

VB6を使っている企業といえば、印象に残る思い出があります。
これは1・2年ぐらい前の話しなのですが、Windowsを対象としたシステムを構築する仕事で使用するプログラミング言語を聞かれました。
私は候補として「C++、Java、C#、VB.NET、F#」を挙げました。
すると「普通VB6だろう」と小馬鹿にされました。
どうやらVB6を使っている会社は、VB6を使うのが常識だと思考停止しているようです。
そのメカニズムを調べると、どうやら学習をさぼりたい社員の言葉を社長が信じ切っているようでした。
その会社の社長の頭の中には、出来る社員がVB6を使うのが当たり前だという＝VB6を提案しない奴は出来ない人という方程式があるようです。
その出来事を思い出して思ったのですが、もしかしたら実務を知らない重役が騙されている、もしくはVB6でも何でもいいだろうと思っている会社がVB6を維持するケースが多いのかもしれません。
いずれにせよ、お客様の事を考えていないのは明白なのでそういった会社とはお付き合いしない方がいいですね。

『年に1,2個の言語覚えるぐらいじゃないとバカになる』とよくいってます。多階層での開発では1つの言語だけではどうにもならないことがありますし、C#なんか別の言語じゃね?ってぐらい変わりますしね。

VB6 => VB.NETの移行がもっと滑らかな物であったならば状況はまた違ってたのかなと思います。あまりにかけ離れすぎてて移行することをあきらめたって所も結構あるんじゃないかと。
労力も予算も最低限しか用意できないところでは、別部署の人間が片手間にプログラムのメンテやってたりするんだから、１から構築しなおしなんてとてもとても。

この２００６年に話題になった脱オブジェクト指向のススメ
http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html
では、「VBからVB.NET」になっても何か変わりました？生産性が上がりましたか？という強烈な批判が書かれてあります。しかし５年も経つと.NETの使うコツがわかり、その生産性は優れたものだと評価が変わってきてます。
　優れたクラスライブラリと、DataTableなどのオブジェクトをリターンさせるようなメソッドを使いこななせば、老熟エンジニアでもかなり使えます。フレームワークというものは、フォームやWEBページを作成すると自動的にクラスができ、そのなかに関数を書いていけばよい便利なものなのですから。この一年で、かなり風潮は変わってきてます。
　オブジェクト指向、アンチオブジェクト指向という宗教戦争に惑わされすに、これからは「堅実に良い品質のものを効率よく開発する」という健全なエンジニアの努力が実を結ぶでしょう。

これは疑問なのですが、「VB6からVB.NETの移行は困難」という事が常識化しています。
しかしながら、そこまで変わったのでしょうか？
私が多言語使いだから抵抗感がないのかもしれませんが、VB6は継承こそないもののプロパティといったオブジェクト指向な機能もありました。
それを考慮すれば、VB6を本気で学んだ人にとっては、移行は世間で言われている程困難ではないと思えてなりません。
感覚の問題なので真実は分かりませんが、「VB6からVB.NETの移行は難しい」という言葉が誇張され、心理的抵抗感を持ってしまったプログラマーもいるかもしれません。
もし、その言葉を鵜呑みにしてVB6から脱却できない人が居るならば、凄く不幸な事ですね。

データベースからSELECTを実行するだけでも、SqlDataAdaptor, DataSet, DataTableなどのオブジェクトをたくさん使うので、私も最初は血迷いました。それをメソッド関数使わないで、ベタで書いてしまうと、何回かデータベースアクセスするだけで、何がなんのインスタンスなのかゴッチャになって、嫌気がしてしまいます。
ところが、メソッド関数を使うコツをつかめば、.NETの世界はなんてカッコいいんだろう！と大きく変わります。

遅くなりましたが皆さんコメントありがとうございます。

>サポートの切れた言語を使ってくる企業とは付き合いたくないですね。
（てーくんさん）

そう思っていただける事が、業界にとってプラスに働くと思います。
残念ながら未だにパッケージソフト等でもVB6が利用されている事は結構ありますので・・・。

>いずれにせよ、お客様の事を考えていないのは明白なのでそういった会社とは
>お付き合いしない方がいいですね。
（インドリさん）

私も同感です。極端に言えば「アプリ・システムとして目的を果たせれば良い」という考えなのでしょうが、後々で余分な出費をユーザーに求める可能性があるなど、自分たち開発側の理屈でしかないと思いますね。

>多階層での開発では1つの言語だけではどうにもならないことがありますし、
>C#なんか別の言語じゃね?ってぐらい変わりますしね。
（Sneryさん）

そうですね。規模が大きくなると言われるような問題が出ることが増えると思います。一つの言語にこだわる理由は実際のところ、開発側でスキルを持つ人間を揃えるのが大変になるなど、内部での理由が大きいのだと思います。ただこれもユーザー側には関わりない話題のはずなのですよね。

>VB6 => VB.NETの移行がもっと滑らかな物であったならば状況はまた
>違ってたのかなと思います。あまりにかけ離れすぎてて移行することを
>あきらめたって所も結構あるんじゃないかと。
（tmsさん）

その点は確かにありますね。私も最初に移行を行ってみた際にはかなり苦労した記憶があります。言語仕様的な部分もありましたが、利用しているコンポーネントが対応していないなど、移行ツールでカバーできない部分が多かったかな、と。
ユーザー企業内で作成されている場合では、この点が非常にネックになるのは言われている通りだと思います。開発企業と異なりもっと予算やら時間やら、大変な点が多いですよね。

>オブジェクト指向、アンチオブジェクト指向という宗教戦争に惑わされすに、
>これからは「堅実に良い品質のものを効率よく開発する」という健全な
>エンジニアの努力が実を結ぶでしょう。
（みながわけんじさん）

そうですね。良い品質のものを効率よく、全く同意です。そのためにエンジニアは日々努力していくことが求められているのだと思います。

個人的に思う、VB6からVB.NETに移行しなかった理由ですが、何店か思うところはあります。

・OCXコンポーネントの対応状況
・厳密に書かずとも動作させることができるVB6の強力な仕様

OCXコンポーネントは一応ラッピングしたInteropなクラスを利用する事で、利用できることもありますがこれも「ものによる」状態です。提供しているメーカーで記載がなければ、やってみないとわからない、という点が厄介だったと思います。

もう一つはなんといっても、VB6は良くも悪くも非常に高機能だったのが理由ではないでしょうか。Variant型に代表されるようにあまり型を意識しないでもできてしまう等、パワフルで楽すぎた部分が.NETになりもう少し考えてコーディングする必要が出てきたなど、楽な部分が減った事も要因の一つかと思います。

ですが、今現在の VB.NET (VB10) は非常にパワフルで利用しやすい形に進化してきていますので、過去に断念された方がいるのでしたら、是非もう一度試してみてもらいたいな、とは思いますね。

一度.NETの開発環境に触れるとVB6には戻れない、それを体験してみてほしいと思います。

みながわけんじさん＞

＞それをメソッド関数使わないで、

メソッド関数って何ですか？

VB.NETがVB6より開発性が高い。
ということについては異論はありません。

しかし、既存のアプリケーションを新しいOSに対応させる際に、
予算がないということであれば、VB6のままというのは選択肢として
あり得ると思います。
（サードパーティ製のコンポーネントを使っていればなおさら）

ですので、個人的にはWindows 8でも動作保証はしてほしいですね。

新規開発は当然のこと、パッケージ製品であれば.NETに移行すべきとは思いますが。。。

Fukumoriさんコメントありがとうございます。

>しかし、既存のアプリケーションを新しいOSに対応させる際に、
>予算がないということであれば、VB6のままというのは選択肢として
>あり得ると思います。

その通りだと私も思います。アプリを利用する側にとっては、当然ありえる選択だと思います。残念ながらサードパーティ製品が関連すると、反対に移行するのが難しくなるケースが多くなってしまうのが難しいところではないでしょうか。

>新規開発は当然のこと、パッケージ製品であれば.NETに移行すべきとは
>思いますが。。。

ここなんですよね・・・開発側こそ移行しなくてはユーザーに不利益をもたらすことが多くなるというのに、まだまだ移行できていない企業が結構な数あると感じています。

こー最大の理由は、お金じゃないですかね。
特にパッケージというか、自社製品をカスタマイズして売ってるような場合だと、難しいかと。
技術力とか関係なしに、VB6から.NETへ移行するための予算を取れるかどうか。
.NETがVB6の上位互換だったら、ほぼ予算無しでも移行できたのだと思いますね。
なんだかんだで、VB6から.NETへの移行って結構な場所に手をいれないと駄目・・・ですよね？
どんなに簡単な作業でも、修正箇所が多ければそれだけリスクになるわけだし・・・

いや、もちろん十分な時間があったんじゃないか？という意見ももっともだと思いますが(^^;
逆に考えて、.NETじゃないと困るってな状況にならない限り、本格的な移行は始まらないとも思うのですよ。
どちらかといえばVB6を使い倒している会社ほど、移行は遅かったのではないかと・・・
都合よく、新規の話があれば、そのタイミングで移行できたとも思いますが(^^;
もしくは、十分な資本がある会社・・・ってことかな？ｗ

開発者からみれば、.NETのほうが楽だと思う人が多いでしょう。
今後のカスタマイズを考えればなおさらだと思います。

でも、客というかお金を出すほうからみたら.NETなのかVB6なのかは関係ないことも多いんじゃないですかね？
求めている機能が、求めている性能で問題なく動作するのであればいいわけで・・・
こういうのは、新しいも古いもないじゃないですか。
こーFA系だといまだにDOSのパソコンが現役だったりしますし・・・
将来のこととか考えて、移行をすすめるのは、お客のためではありますがー
現状で満足しているお客に対しては、開発側のエゴになる可能性もあると思います。

皆、動かなくなったら終わりだとわかっていて使ってるんですよねぇ。
結局、過去の資産を無視できるか、つまり、予算をだせるかどうかが最大の問題なわけで・・・
こー動かなくなるまで使うお客さんのほうが多いんじゃないかなーと思ったりする私としてはー
新しいOSで、VB6で作ったプログラムが動作しないってな状況にでもならないと、VB6製から.NET製への予算とるのは難しいと思うわけですｗ
んでもって、「内容が変わらないのに、そんなにかかるの？」とか言われるわけですｗ

・・・まぁ、全部それなりの規模のプログラムが前提ですけどねｗ

Ahfさんは、前からVB6プログラムが動かなくなってくれればーと言ってたけど・・・
本当に動かなくなると困るのは予算がないお客さんなわけで(^^;

ほらこー予算と時間を無視できれば、作り直ししたいようなものとかないですか？ｗ
昔作ったプログラムをみて、作り直してーみたいなｗ
VB6に限らず、イロイロあるんじゃないかなー
そういうこと自由にできるかどうかが、趣味と仕事の境目なんですかね(^^;;;;;

ＰＳ．
大きな会社ほど、過去の資産があって、VB6開発ができないと困るのではないかと思ったりするんだがー
実際はそうでもないんですかね、まるっと.NETに移行済みでVB6開発はお払い箱なのかな？＞IT系

とても気になるのですが、VB6を使い続ける会社のシステム設計はどうなっているのでしょうか？
VB6当時はCOMを使ったコンポーネント指向プログラミングが一般化していました。
そして、サードパーティ製コンポーネントを使用する場合、何時サポートされなくなるか分からないので隔離して設計する事が普通でした。
ですから、コンポーネントの移行で困ったら、有名どころは.NETバージョンに変更し、変更できないマイナーなコンポーネントは自作するという手法が使えました。
あと、RCWとCCWを使えばCOMと.NETは相互運用可能です。
各種SDKを使えば問題はなかったし、そもそもVB6から.NETへ移行するシステムは、システム設計そのものが変更されるからそこまで後生大事にする必要はないような・・・
それよりも、ネットワークとセキュリティがらみのシステム要件が変わる方が大変です。
移行が大変なのは実装レベルではなくて、もっとレイヤが上の方だと私は思います。
問題なのはユーザー企業の情報部門ですよね。
外部発注するのは高く予算がない。
それに加えて、日頃の激務の合間にシステムをバージョンアップさせるのは困難です。
ネットワークは「建て増しを重ねた歴史ある温泉旅館」になるし、パッケージ商品もしくはカスタム製品の古さが足を引っ張る。
それこそ、開発会社側がどうにかする問題であり、開発者がVB6でもいいやと怠けるのはもってのほかです。
あと気になるのはセキュリティです。
VB6ランタイムがセキュリティホールになります。
セキュリティホールを抱えたままバージョンアップしても意味はありません。
セキュリティ面から考えても、Windows8はVB6ランタイムのサポートを止めてほしいです。
最後に、VB6のシステムを使い続ける会社は、Windows8へ移行しないような気がします・・・

誤：隔離して設計する事が普通でした。
正：隔離する設計をする事が普通でした。

Ｓｏｄａさん、インドリさんコメントありがとうございます。

>でも、客というかお金を出すほうからみたら.NETなのかVB6なのかは
>関係ないことも多いんじゃないですかね？

全く持ってその通りだと思います。ユーザーの最大の関心事は、自分たちの目的を達成させるためにシステムを利用するのであって、システムが何で作られているかというのはそれほど重要ではないと思います。

ただ端末を入れ替えなければならないときに、浮上してくる問題なのですよね・・・。Ｓｏｓａさんが言われるように「動かなくなったら終わりだとわかっていて」使っているというのが本当のところなのでしょう。

>現状で満足しているお客に対しては、開発側のエゴになる可能性もあると思います。

そうですね、この点は非常に注意したいです。かなりどきっとしました。

>そして、サードパーティ製コンポーネントを使用する場合、何時サポート
>されなくなるか分からないので隔離して設計する事が普通でした。

ある程度のスキルを持つ企業であれば、このように設計できるのですが、
残念ながらそうではない企業も数多く・・・。

>最後に、VB6のシステムを使い続ける会社は、Windows8へ
>移行しないような気がします・・・

まだまだXPを利用するのが多いですので、恐らくは言われている通りになるかと私も思います。各メーカーがダウングレードオプションといった形で、WindowsXPをつい最近まで提供していた事もありますし。

インドリ様

>>あと気になるのはセキュリティです。
>>VB6ランタイムがセキュリティホールになります。

どの変が問題なのでしょうか、具体的に示していただけませんでしょうか。

「もうすぐガソリンが枯渇するので、電気自動車に買い替えて下さい。費用はあなた持ちです。」とか
「もうすぐ建築基準法が改正されるので、家を建て替えて下さい。費用はあなた持ちです。」とか
自分が問題なく使えているものに、買い替えを勧められた時。
どんな説明をされたなら、自分がその買い替えに納得できるだろうか。

maさん、セロさんコメントありがとうございます。

>どの変が問題なのでしょうか、具体的に示していただけませんでしょうか。

VB6ランタイムに脆弱製が発見されセキュリティパッチの適用が行われることは今まだ発生していたと思います。ランタイム単体、というよりも関連するコンポーネントに・・・というケースの方が多いとは思いますが。

>自分が問題なく使えているものに、買い替えを勧められた時。
>どんな説明をされたなら、自分がその買い替えに納得できるだろうか。

このあたりは難しい問題と思います。極論で言うならば、「全ての責任を自分で持つならば使い続けても良い」となるのではないでしょうか。
今回の話題では、開発側が自分たちでどうこうできないものを利用して商品を作成している以上、そこまでの責任を開発側がもてるのか、もてないのに継続して使い続けていて何か問題が起きた際には誰が責任をとるのか、という感じでしょうか。

サポートとはこのような事なのではないかと思います。サポート期間であるならば、何らかの問題に対して責任を負いますが期間外では責任を免れる、だからといってサポート切れの製品を使うことを禁止するものではなく、利用するならば咳には全て自己責任ですよ、なのだと思います。

卓袱台返しになるかもしれませんが。
皆様、どうしてVB6を化石のようにあつかうのですか。
メーカーのサポートが終了したら言語生命は尽きるのですか。
VB6のロジックのまま.net化して意味があるのですか。
Object思考で再設計しない限り、.netの顔をしたVB6アプリになってしまいます。
現にいくつかの製品は、.net化されてますが、中身のロジックは VB6そのものです。そんな製品を売りに来たらどうしますか。

販売目的でなく、内部で使用し、動作環境が保たれているなら使い続けるのがコストパフォーマンス的に優位です。
某所では Windows3.1/ VB2.0 アプリ現役で動作しています。
当事者は「潰れたら、新規作成するが、その費用と逸失利益のよりも、使い続けて潰れた時点での最新版で再作成したほうがトータルで安い。」
と仰っています。
これに反論できるだけのメリットを指摘できますか。

VB6がやり玉にあがっていますが、 .net1.x の製品も同じことです。 asp.net 1.x で作成されたアプリも相当数現存しています。
「新機能万歳。新機能を使わない奴は時代遅れだ」という主張にしか聞こえません。
どんなバージョンの言語であっても、業務メリットがあれば、問題視する必要はないと考えます。
OSが実行時モジュールをサポートしなくなったら、継続不可能ですが、　仮想PCで旧OSを入れて走らせることも視野の内でしょう。
VB6のメンテする人の負荷を書かれていますが、「旧言語をやりたくない」という免罪符にしか聞こえないのですが、いかがでしょう。

>AZ さん
>卓袱台返しになるかもしれませんが。

Ahfさんが
>極論で言うならば、「全ての責任を自分で持つならば使い続けても良い」となるのではないでしょうか。

といっている時点で、AZさんの意見などに収束されているんじゃないかなーと思います。
「なにで作っているか？」を気にするのは、主に開発者だと思いますし・・・
「なにで作っているか？」を気にするお客さんというのは、開発も同時にやってるとこかなと。

いや、大昔に「C++で作ってるの？やっぱりVBより凄いね」とか言われることもありましたがｗ
多くの場合、言語に対する先入観が凄い、凄くないを決定しているのではないかとｗ
いまだと先入観は「C#>C++>VB.NET>VB6」みたいな感じですかねぇ。

>現にいくつかの製品は、.net化されてますが、中身のロジックは VB6そのものです。そんな製品を売りに来たらどうしますか。

上のほうのコメントみると・・・買うんじゃないですかね(^^;
個人的にはObject指向であろうが、なんであろうが、正常に動作し、仕様変更のコストが安ければ問題ないと考えます。
実際問題として、Object信仰も先入観でうまれているような気もしますｗ
なんつーか、上下関係というか、「～がいい」とかの記事に煽られやすいのが日本人なのかなとか思ったりｗ
何事も適材適所なわけで・・・

>「新機能万歳。新機能を使わない奴は時代遅れだ」という主張にしか聞こえません。

そーいうと、「新しいことを勉強しない駄目なヤツ」というすり替え意見が生まれるわけでｗ
なにも考えずに新しいものに飛びつく人の常套句です(^^;

古い開発環境に比べ、新しい開発環境のほうが危険だと思うのは古い人間なのかもしれませんが・・・
でも、新しい開発環境が発売されても、それを実務で採用するのって、数年立ってからのほうが安全ですよね？ｗ
こー不都合がでないかどうか、確認というか、人柱待ちというかｗ
まぁ、このへんは開発環境じゃなくて新しいOSが登場したら、すぐに入れ替えるかどうかで考えたほうが共感を得られるような気がします。

>仮想PCで旧OSを入れて走らせることも視野の内でしょう。

まぁ、その環境を動作保障するのは難しいですけどねぇ(^^;

>VB6のメンテする人の負荷を書かれていますが、「旧言語をやりたくない」という免罪符にしか聞こえないのですが、いかがでしょう。

でもって、これは、「新言語をやりたくない」というすり替え意見の元になるわけでｗ

こーお客からみたコスト面で、古い開発環境での開発はどうしても残ると思うんですよ。
古い開発環境がいらなくなるのは、抱えているお客全てが、新しい環境に移行した時・・・ですよね？

・・・って書いてきましたが、ひょっとしてIT関係だと、メンテナンスに携わる人って少ないんですかね？
メンテナンスを行わないんなら古い環境を捨てるという発想もわかります、だって使わないんだから・・・
もしくは、お金をもっているお客が多いのか・・・
それとも格安でリプレースするだけ会社に体力があるのか・・・

ＰＳ．
初めて.NETが登場したとき思ったのは「VB6でネイティブになったのに、また元に戻すの？」でしたｗ
また、リバースエンジニアリングが簡単であることもマイナスイメージでしたね。
個人的には.NETがここまで勢力を拡大するとは思っていなかったですねぇ。
むしろ、ネイティブ環境が追いやられるような状況になるとは・・・
それだけPCの性能が上がったんだなと思うわけです、ハイ。

AZさん、Ｓｏｄａさんコメント有り難うございます。

>メーカーのサポートが終了したら言語生命は尽きるのですか。

この点については、Ｓｏｄａさんのコメントでも書かれている通り、
私の考えとしては「自己責任」の世界なのだと思います。言語生命は尽きていないですが、使うなら責任は自分で持ちましょう、というところですね。

このあたりはやはり難しい話題だと思います。コストについても同様で、かかるコストの中でどの部分を重要視するか、により出てくる意見は様々なものになってしまうと思います。サポートが切れている環境で問題になるのは、「その環境で重大な障害や問題が発生した場合にどうするか」、という点ではないでしょうか。

今まで発生していないから今後もそれほど発生することはないだろう、というのも一つの考え方ですし、もしかしたらとんでもない問題が発生するかも知れない、というのも一つです。どちらが正しいとかではなく、どちらも考え方としてありえると思います。

ですのでコメント中の意見には反論ではなく、それも一つの考え方として扱う物だと私は考えています。その中で私は「何かが起きた際のデメリットを重視」するので、新しい環境にできるだけ移行していくことがコスト的にもメリットがあるだろう、と考えているのです。

>>現にいくつかの製品は、.net化されてますが、中身のロジックは VB6
>>そのものです。そんな製品を売りに来たらどうしますか。
>上のほうのコメントみると・・・買うんじゃないですかね(^^;

私も同感で買う人は買うと思います。中身が重要ではなく、機能が重要と思いますし。

ちなみに私は仕事柄 VB6 案件のメンテナンスもやっていまして、簡単ながら Windows 8 上での動作検証も行っていたりします。

http://blogahf.blogspot.com/2011/09/windows-8-developers-preview-vb6.html

開発側の選択だけではなく、ユーザー側の選択肢についても調べておくのは重要だと考えています。例え提供元のサポート外だとしても、このあたりは必要ですよね。

>何事も適材適所なわけで・・・

この一言が全てだと思います。改めて私も気を引き締めていきたいです。

VB6 というところに反応。
　マイクロソフト社の設計方針として、C++（Visual C++ という開発環境）は「ソフトウェア開発を仕事にしている人」向け、Visual Basic（という開発環境）は「弁護士や医者など、ソフトウェア開発以外を仕事にしている人」向け、という違いがありました。つまり VB は、ソフトウェア開発者以外の人が、ソフトウェア開発のノウハウを持っていなくても、それなりにツールが作れる、というところを目指していたわけです。ソフトウェア開発者が使う道具としては、「どうよ？」と思いますが、ソフトウェア開発を仕事にしていない人（あえて「ソフトウェア開発の素人」とは言わない）が使う道具としては、よくできていると思います。
　これを踏まえて。「ソフトウェア開発者」が VB6 使ってどうすんの！！
　例えば、手術をするというときに、包丁やペンチが手術室に運び込まれているのを見たら、どう思いますか？という問題だと思います。
　プロパティがオブジェクト*志向*言語の特徴だとはまったく思わないけれど、VB6 は、ソフトウェア開発者が VB を使っているという現状（当時）に迎合して、開発者でも使える様にパワーアップされています。それを使うかどうかは、開発者としての心意気の問題だと思います。「オブジェクト志向なんて理解できねぇ！」とさじを投げるのか。それとも、チャレンジして、モノにしてしまうのか。
# 私が「志向」を使うのは、directed（その方向を向いている）と oriented（関心を向ける）の違いを意識したいから／して欲しいから

Jittaさんコメントありがとうございます。

>これを踏まえて。「ソフトウェア開発者」が VB6 使ってどうすんの！！

非常に手厳しいご意見ですが、ごもっともと感じます。
ご存じの通り、VB6 までの VB は Office 等でも利用される VBA に非常に近いこともあり、非開発者であっても利用しやすい環境であったと思います。そのような土壌もあり、「それなり」なアプリやシステムを作るところで満足してしまうビジネスでの開発者を、多く生み出してしまったのか、とも思えます。

開発者としての心意気が非常に大切なのも同感です。
ただ最近はそこまでの心意気を持たれた技術者の方に会う事が少なくなった様にも思えます。私自身があまり人と出会えていない、というのもありますが、それを差し引いても。

このような状況が良い将来を生み出せるとは思えませんよね。

> ただ最近はそこまでの心意気を持たれた技術者の方に会う事が少なくなった様にも思えます。
　難しいですね。。。
　たとえば、今の会社はそうでもないのですが、前にいた会社は、逆ザヤだったせいもあって余計に、コストダウンコストダウンと言われました。営業など、自社のエンジニアのほうが単価が高いからと、他社に丸投げする有様です。このような、コスト意識を叩き込まれた人にとっては、簡単に作れることが何が悪いの？！となるでしょう。
　もう一つのほう、勘違いしている人が若干見受けられますが、あちらとリンクしますが、ある物事は、べつの視点から見ると、異なった見え方をすることがあります。VB に対する見方も、「開発者として」見ると、VB を道具として開発を行うことはどうかと思いますが、コストパフォーマンスという眼鏡を通すと、立派な道具といえるでしょう。
　私は、このような眼鏡、視点をたくさん持っておくことは、さまざまな意味でプラスになると思っています。もう一つのほうで、「火星と金星」というタイトルの MSDN の記事を紹介しました。これは、読んでいただければわかりますが、男と女で関心を向けることろが違うということを書いています。しかし、タイトルを「男と女」とせずにそれらを象徴する「火星と金星」としたのは、内容である「男と女」がさらにほかのことを象徴している為だと思います。「開発者と顧客」でもいいし、「開発者と営業」でも「雇用者と被雇用者」いいでしょう。それぞれ、価値判断をするものさしが違います。少なくとも「違う物差しがある」ということを知っておかないと、お客様にとって役に立つシステムを作ることに支障があると思います。

Jittaさんコメントありがとうございます。
また、別コラムでの記事紹介。非常に参考になりました。ありがとうございます。

>私は、このような眼鏡、視点をたくさん持っておくことは、さまざまな意味で
>プラスになると思っています

全くもってその通りです。いくつになっても多くの考え方と接する事の重要性を感じています。
仕事上、プライベート問わず、多くの人と触れあい多くの考え方、視点があることを感じとり、それを自分に生かすことが、IT業界に限らず非常に大切ですね。

現在6年以上前にVB6で作成したシステムの面倒をみています。
特に問題もなく動いており、機能変更の話もないのですが、
XPのサポートが2014年4月8日に終了すると言う話を聞いてぞっとしています。

Windows7にはVB6の開発環境はインストールできないですよね？

すると、XPがつかえなくなった後で、何かトラブルがあったり、
機能変更をしたいと言われたときにどうすべきでしょうか？

開発会社の観点から考えると、「作り直しましょう」と
提案できればいいのですが、そんな予算がお客様にあるとも思えません。

2014年4月8日以降もサポートが続いていて、
VB6の開発環境がインストール可能なOSを見つけてきて、
用意しておいたとしても、いずれは、そのOSもサポート終了になる。
ということを考えると、「作り直しましょう」ということになるのですが。。。

まだ時間があるような、ないような。

SSS さんコメントありがとうございます。

私も VB6 で作成したシステムを何か所か面倒を見ていますので、お気持ちはわかります（現在も、です）。

Windows 7 での VB6 開発環境ですが、インストールできないのではなく、インストールしてもいいけど自己責任ですよ（＝サポート無）という状態です。極論すると「何があっても自分で解決」するのであれば、IDE を Windows 7 にインストールして利用しても構わないとなっています。インストールした場合の問題も Web 上で散見できますね。

私は Windows 7 でのテストは実行モジュールでのテストに限ることにしています。IDE 上でのデバッグなどは行わず、ログ出力等の方法で調査する方法を採っています。
それに伴い開発用の XP 環境はしばらく確保しておくことが続きますが・・・。

>まだ時間があるような、ないような。

時間はまだあるように思えるけど、実際にはあまり残されていないのだと思います。

今時新規開発でVB6を提案するような馬鹿企業は皆無でしょうが、VB6のサポートはついて回ります。.netから始めた若い人たちは多いけど彼らにVB6のサポートをお願いしても「絶対ヤダ！」と言います。お前たちはアマチュアプログラマか？と小一時間問い詰めたい思いです（笑）

そしてなまじVB6を知ってる自分に仕事が回って来てしまうわけで、この世からVB6が消えてくれたらどんなに幸せだろうかと心底思います。しかしなぜか大手企業に限ってVB6の巨大なサーバーサイドオートメーションを構築していたりして、しかもその保守、追加開発の見積りはこちらの言い値で決まるという営業的にはなんとも美味しい話なのだそうです。逆に.net開発は猫も杓子も状態で競合が多いので値引き合戦で赤字になることが多いそうで、泥臭く言うと金にならない。

自分の所でさえこんな感じですから、おそらくVB6で食えてる人たちは世の中少なくないでしょう。安易に次期Windowsでサポートされない方がいいなどと言ってしまうと恨みを買ってしまうかも知れません（笑）