う～ん。温故知新が私のモットーで、OSの実装レベルから古い技術も学んでいますが、積極的にVB6を使う理由がどうしても分かりません。
未だに私はVB6よりも古いアセンブラやLISPなどを学んでいますが、
VB6は積極的に使う場面が思い浮かびません。
アセンブラやLISPは特徴がありますが、VB4.0から出発した私ですらVB6にそれ程の特徴があるとは思えません。
明らかにVB.NETはVB6を包合しています。
それでもVB6を使い続けるわけは、お客様の事よりもその会社の都合ではないかと思えてなりません。
新規開発でVB6を採用するとエンドユーザーににどんなメリットがあるのでしょうか？

こんばんは。いつも楽しくコラムを拝見させて頂いています。
私は中小企業の社内SEですが、なぜ基幹システム（販売管理、生産管理など）が
WEBシステムである必要があるのか理解できません。

社内SEなので、システム保守にかかるコストを肌で感じているのですが、
正直、社内SEの立場から見るとVB6と.net、ぶっちゃけどっちでも良い
という感覚です。
（SQL一発で抽出し、その後の処理はだいたいどの言語でも一緒になるので…）
それよりも生島さんが一貫して言われているSQLの方が重要だと感じています。
私も微力ながら、社内に応援に来てくれた外部のエンジニアの方々にSQLの
大事さを伝えていっています！
これからも頑張ってください！

saki1208です。

私は新しい案件でVB6を採用するという考えは愚かだと思います。
既存の仕掛け(概ねパッケージ化されている)の流用等でベンダ
側から見たメリットはあるでしょうが、エンドユーザ側からの視点
で明らかなメリットは皆無ではないでしょうか。
目先の費用は低く抑えられることがあるかもしれませんが、長期
的にみた場合はどこかで.NETへの移行を検討しなければならな
くなるでしょう。サードパーティ製のツールを使用する場合などで
は基本的にほとんど作り直しでしょうし、結局、最初に掛った金額
位を数年後にはまた支払わないといけないでしょう。

使い捨てのシステムなら良いですが、今後を考えるとVB.NETを
選択するべきでしょう。
VB6は、当然サポートも終了していますし...

直近のプロジェクトのいくつかではVB.NETを採用していますが、
明らかに.NET前と後では生産性にも差がある気がします。
#　私自身はC#を採用したいのですが...

最近.NETに慣れてきてVB6で開発するのが億劫です。

ArobatのOLE又はDDEを解説しているサイトを公開している者です。
私はいまだにVB6の環境を持っています。今は仕事上で提案する事はありませんが、VB6が今でも完成度が高い開発環境だと思っています。個人でツールを作る時はVB6を使用します。
理由はVB6言語はMSのOffice製品のVBAに流用出来ることです。この逆もしかりです。よってVB6と言うより、VBAにこだわります。結果的にVB6につながります。サンプルを提案するときはVBA(=VB6)言語で示します。
.NETはすばらしい言語かもしれませんが、完成度ではイマイチの様な気がします。特に.Frameworkが事前にインストールしていなければいけないことに非常に不満を感じます。バージョンの違いも有るし、OSは少し重くなるし、WindowsUpdateの時はやたらとサイズの大きなファイルのダウンロードが出てきます。これには我慢が出来ません。しかも.NET 2008 を覚える前に既に .NET 2010 の話が出ています。いつになったら完成した環境が出来るのか疑問に思います。

自分で調査した訳ではありませんが、現在でもヨーロッパ周辺では８割の開発者がVB6を使用している聞いたことがあります。細かい事を気にしすぎる日本人から見たら驚く割合と思いますが、私には何故か納得出来るような気がします。

MSのOffice製品がマクロに.NETをサポートしたら気持ちが変わるかもしれませんが、今のところいまだにその気配すら見えないのでVBA(=VB6)を支持します。
と言うより言語は道具ですからシステムとその時の用件に合えさえすれば何でもイイと思っています。それとコストパフォーマンスも。

一個人の意見です。

APサーバの位置付けが単なるUIとDBサーバ間でデータを経由するだけという
とらえ方をされていますかね？
APサーバというかAPサーバ内のプロセス設計は、基幹系システムでは、非常に重要です。
なぜなら業務トランザクション境界方針、プロセスのスケールアウト方針、
セッションフェールオーバー方針、アプリケーションデータキャッシュ方針など
システムアーキテクチャのポリシーの大部分がAPサーバに位置づくところで
決めるのが適切でそれによりセキュリティや変更要求に強いシステムとなるためです。

まぁ、言語がなんであろうが、このあたりの設計技術が基幹系では肝なんですが、
そもそもお客様的には「できて当たり前」という風潮がちょっと物悲しい感じです。
そのあたりのジレンマはありつつも質の良いシステムを作りつつ、真に喜ばれるものを
目指していきたいですなぁ。

皆様、コメントありがとうございます。

VB6のメリットは、顧客（の情シス）がメンテナンス出来ることが多いことです。

「顧客にこれからは.Netですから、.Netを覚えてください」

っておかしいでしょう。
まぁ、顧客から.Netを指定してくることも、Javaを指定してくることもありますけどね。

個人的には、noriさんのおっしゃるとおりVBAはポイント高いです。
VBAはコードジェネレータとしては無敵ですし、エクセルは入力にも表示にも使えます。

で、MR.CBR さんのおっしゃるとおり、SQLにだけビジネスロジックが入っていれば、どんな言語になっても大差はありません。

C/Sでも作り方しだいですよ。
C/Sでクライアント側にロジックを入れるとクチャクチャに
なりますけどね。
キャッシュはクライアントに持った方がやりやすいし。

ブラウザ（閲覧ソフト）で入力するというのはナンセンスで、
外部に公開するからこそメリットが生まれるのでけれど、
セキュリティの問題でインターネット接続を許してない環境
でもWebでやったりするんだから、全く意味が分からない。

流行っているからの理由で提案しているとしか思えないのが
結構あります。

saki1208です。

noriさん
>.Frameworkが事前にインストールしていなければいけないことに
それは、XP以前のOSでVB6のランタイムをインストールしなければならなかったこと
と同じではないですか?
新しい技術や機能、言語にあわせて開発環境も進化するのですから、新しいツール
が出荷されるのはしょうがないのではないでしょうか。確かにもう少し互換性があれば
と思うことはありますけどね。
# ただ、VB.NETでは構文の互換性と引き換えに非常に回りくどく、冗長な記述をす
# ることが多くなる気がします。ただ、この部分についてはもともとVBを使用していた
# 開発者の要望も多く採用されているのでしょうけれど。
# C#を使用してもフレームワークを使用して記述する分にはソースを見て理解でき
# ないようなことはないと思うのですけれど...
# なぜか嫌がられる。

生島さん
>VB6のメリットは、顧客（の情シス）がメンテナンス出来ることが多いことです。
このケースでは、お客様の指定でVB6で作るのでしょうから、選択肢はないのでは
ないですか。提案として、.NETでは?とお伺いを立てるケースはあるでしょうが、基
本的には顧客の意見を尊重するべきでしょうし。
ただし、基本的に自分たちでメンテしたものの面倒は自分たちで見てもらいます。
# 相談にはのりますけどね。
# 相談を受けるケースではVB(.NET以前)であるが故の論理的なバグの解決依
# 頼が多かったりします。最近は、VB6の開発環境を保持しておくのがだんだん
# 難しくなりつつあり、頭痛のタネにもなっています。
# もちろん、仮想環境で残すことも考えられるのですが、すべての環境を残すの
# は難しいですね。

MR.CBRさん
>私は中小企業の社内SEですが、なぜ基幹システム（販売管理、生産管理など）が
>WEBシステムである必要があるのか理解できません。
"MR.CBRさんサイドからの要件ではなくて"ということですよね。私も反対です。
多分、プログラムの配布や管理コストを考えた場合にC/Sに比べて安価であると考
えているのでしょうけれど、Web以外にもやり方はいろいろあると思います。

まだまだ出来て100年たたない産業ですし、システムの中身については基本的に
手作りな部分が殆どです。
如何にしてよりよい品質のものを安価に提供できるかをいつも考えていますが、ま
だまだですね。
# 基本的には自分が楽をしたいだけでしょうけど。
# 楽をするために苦労するのは厭いませんよ。

配布問題を言うのならばVB6を使用した際に発生するDLLヘルはどうするのでしょうか？
.NETはDLLヘルをほぼ解決しているだけ配布後のトラブルは少ないと思います。
それに、Windows Updateで.NETランタイムはインストールされます。
配布は確かに面倒な問題がありますが、Windows Updateで配布されるものは結構ユーザーもインストールしやすいと思います。
あと、サポートが切れた物を使い続けて、セキュリティホールをつかれた時はどうするのでしょうか？

saki1208です。

連投すみません。

ちなみに、今でもVB6のプロジェクトも抱えています。
# しかも、現在進行形からお守りまで複数件。
でも、現状維持では満足していませんよ。

たとえVB6を使用した開発であっても、今までのVB6/VBAでの経験、C#やVB.NET
での経験を総動員して、少しでもミスの少なくなるような開発手段/手法を考えます。

その上で開発者サイドからの「VB6」の選択肢はないかなぁと...
顧客都合はしょうがないとしても、会社/上司/同僚の都合でVB6で開発されたもの
おもりもさせられる立場としては、そろそろ勘弁してほしいと思います。

saki1208です。

インドリさん
>配布問題を言うのならばVB6を使用した際に発生するDLLヘルはどうするのでしょうか？
私ですか?
私はあくまで「VB6継続」反対派ですが...

これもありましたね。

最近はないですが、昔は業務システムを使用するPCに勝手にインストールされた
アプリケーションのせいで、呼び出しくらったりしましたねぇ。

紛らわしくてごめん。
これは一般論で、saki1208さんに言ったのではありません。

DLLヘルとかあまり経験がないので……。
配布は配布用のプログラムをあらかじめ書いていますから、サーバにおくだけですし、それこそ、これだけ枯れてくれば心配ないですね。

業務システムでVB6で実現できなくって、.Netでは実現できるって仕組みがほとんど思いつかない。
WPFとか「これで高くなるならやめてね」って私のところでは100％の顧客が言うね。安くなっても喜んでもらえるかどうか……。

本当にヤバいセキュリティホールなら、マイクロソフトも対応せざるを得ないし、何千万（何億かな）というユーザに10年運用に耐えている仕組みと、2年しか運用されてない仕組みと、どちらが安全でしょう。
「10年運用に耐えている」という実績に勝るモノって、ほとんど新しいものを売りたいがためのイイワケだったりしますからね。

弊社ではビジネスロジックをSQLに入れてしまうので、言語はパラメータの受け渡ししかしない。言語は何でも同じ。
（今頃、Delphiとか始まるかも……ってぐらいこだわりがない）

こだわりがないから、指定がなければあえてVB6も選ばないけれど（笑）

>こだわりがないから
これ技術者がなくしたらマズイですね。
最近の記事からもSQLに強いこだわりがあるとも取れなくなってきたし。

かくいう私も言語に対するこだわりが日々薄れつつあるのが。。

生島さんはじめまして。
いつも楽しませて頂いております。

全体的な論旨には賛成なのですが、ミスリーディングを誘うというか、我田引水な記述が気になりました。
もちろん、VB6に甘いという意味で。

私Macユーザですので、VB(正確にはExcelVBA)には思い入れがあるのですが、その私から見てそう感じました。(ので、投稿しました)

>VB6なんて、後10年ぐらいは大丈夫じゃないかと思います。
私も多分大丈夫と思っていますが、積極的に大丈夫であると太鼓判は押せないですよね。
10年後の現場の技術者に、VB6を使える方がどれだけ居るかも不安です。

>サポートが切れている枯れた技術と、出始めのバグだらけの開発環境
現在の.Netは「出始めのバグだらけの開発環境」というほどではありませんよね。

>.NETでないと実現できない課題がなければ、VB6でもかまわない。
1. VB6でないと実現出来ない課題も(多分)無い
2. 今後発生する課題を.Netの方が楽にクリアできるかもしれない
　　逆もありえますが、どちらに可能性があるかといえば・・・
3. ライセンスの入手は困難では？
　サブスクリプションに加入するしかないような。
　(探したことはありませんが)普通に購入できるものでしょうか？

>DLLヘルとかあまり経験がないので……。
「あまり経験がない」のであれば、VB6に甘くなるのもむべなるかな、という感じです。
「よく経験した」人からすると、これがないだけで.Netの価値はとても大きいですよ。
　自滅ならともかくとして、他社システムのインストーラでこれが発生した日にはもう・・・
　この1点だけでも、.Netは「開発側」「受け入れ側」の両方にメリットが大きいと思います。
　.NetF/Wのインストール自体は、他の方が指摘されています通りですから、それほど大きな問題にはなりませんし。

4,5年くらい前に書かれたのであれば、かなり妥当な内容だと思います。
そのくらい遡れば、
・枯れてないし
・ノウハウも蓄積されてないし
・人の確保も難しいし
・開発環境/実行環境に問題あり
ではありましたから。
(4,5年前という数字は特に根拠の無い個人的な感覚です)

ところで非常に余計なお世話ですが
>本当にまったく分からないのが、「基幹システムをWebで構築する」
>ことです。
これ自体は賛成なのですが、複数の話題は複数の記事としてアップされたほうがよいと思います。
生島さんは議論がされたい方(ですよね?)ですから、プログラム同様、記事も関数化して頂いた方が論旨が絞れて良いと思うのですが...

すみません。
一点追加で。
何の生産性も無い書き込みですが
「VB6が枯れている」のは「.Netに置き換わったから」ってだけのような気がします。
いや、だから何だというわけではないのですが、もしみんなが
「VB6が枯れているから」という理由でVB6に回帰して.Netが廃れるようであれば、MSがVB7を出してくる(=枯れなくなる)だけのような気が...

もちろんそんなことはないんでしょうけどね。
本当に何の生産性もなくてスミマセン。

>本当にヤバいセキュリティホールなら、マイクロソフトも対応せざるを得ないし、

既にサポートが終了しており、マイクロソフト自身が何度も警告していますのでそれは無いと思います。
もしかりに「かなり」の場合緊急対処するとしても、エンドユーザーがハックされた時の損害はサポートしてくれる筈がありません。
セキュリティを甘く見てはなりません。
VB6で何でも出来るというのは間違いではないけども、それはどの言語でも同じです。
例えば、VB6やJavaでもバイナリを吐くようにすれば（一種のコンパイラを作れば）OSでも実装出来ます。
しかし生産性が問題になってきます。
それにセキュリティは.NETの方が絶対に上です。
VB6って中途半端すぎるんですよね・・・
積極的に進める特徴がありません。
どうせならば、C言語＋アセンブラで作った方がいいです。
その方がスピードという利点があります。
言語の考え方についてですが適材適所だと思います。
複数言語使えばいいと思います。
でも、複数言語使う人は少ないんですよね・・・
どうもIT会社の都合でエンドユーザーに迷惑をかけている気がしてならないです。

.Netなら問題が起きないって……。
それも言えないでしょう。

本当に.Netでないと出来ない、VB6ではまずい業務って、私には思いつかないのです。

それを変えるのは、こちら側の都合しかない。
こちら側の都合としては、継承できないとかいろいろとありますけどね。
こちらの都合を顧客に押し付けてはいけないのです。

DLLヘルなんて、起きることがわかっているなら先に対策すればよいわけで、ちゃんと気を配ってたら起きないと思うのですけどね。

枯れている枯れてないという基準ではSQLなんてとっくに枯れた技術で、ちゃんと使い切ったほうがいい。枯れているけどまだ使ってるのですからね。

私は本当に言語にこだわりはないです。
Cobolはやらんけどね。

1年ほど前、ASP（.Netじゃない）の案件にかかわったことがあるのですけど、選んだ理由が自分たちが楽するために選んだパッケージがASPだったからというもので、これは最低でしたね。

そういうのではなく、顧客本位で選べばよいと思います。

そこまでへたっぴな日本語書いてないと思ってるだけに、びっくりするくらい意図が伝わってなくてショックです。
退散しますね。
失礼しました...

DLLヘルは非常に危険かつ厄介な問題です。
何故ならば、自社と関係なく他社のソフトをインストールするだけで起こるからです。
自社だけが気をつけていても発生する問題なのです。
それが原因で長らくWindowsはインストールが怖いと言われてきました。
ですからマイクロソフトも苦労してDLLヘルをほぼふさいでいるわけです。
余談ですがSQLはまだ枯れていません。
SQL:2003（XMLを追加）＆SQL:1999（オブジェクト指向を追加）を完全に使いこなしている人を見たことがありません。
それにまだSQLはバージョンアップすると思います。
SQLとVB6じゃあ将来性は勝負にならないと思います。
私は元々VB使いだったので愛着はある程度ありますが、
だからといってVB6を理性的には庇いきれません。

VB6については今年の5月に累積パッチが出ています。
やはりMicrosoftがやばいと思った問題点はキチンと対応していますね。

DLLヘルについては自分が使っているDLLについてはアプリケーションフォルダに
インストールするようにMSIで設定するだけで解決してます。

>>インドリさん
SQLとVB6を比較している人はいないと思いますよ。

#　SOAPをかじった時はVB.netのほうが多少楽だと感じましたが
#　総合判断でVB6のほうが使い勝手がいいです。お客さんも.netは
#　理解してくれないし。

DLLヘルはCOMのバージョン問題もあります。
インストーラだけで解決できないと思います。

それに、サポートが終わった言語でエンドユーザーに納品するという事は、
今後の将来を捨てた事を意味すると思います。
マイクロソフトの動向を考えると、何時かは.NETへ移行せねばならないのに、新規でVB6を採用するという事は、お客様に廃品同然のものを売りつけ、
それ以後「修理できないから作り直し」という詐欺的商法ではないでしょうか？
お客様だって「最初から分かっていたのならば初めから.NETにしてくれ」と思うことでしょう。
知らないお客様を騙しているか、学習するというプロとして当たり前の行為を放棄して怠惰精神でお客様に売りつけているだけという気がしてなりません。
これってやっていることはCOBOLerと同じです。
COBOLerを非難しておいてVBerを擁護するというのは論理的におかしいと思います。

私の会社でも新規案件は.netで開発していますが、これまで構築してきた
基幹システムはVB6で構築(500本以上のプログラムあり)しており、
社内SEの立場からすると、メンテナンスや保守が煩わしいというのが本音です。
(.net、VB6、Excel・AccessVBAの混在)

私の会社は中小企業ですが、以前に数億円かけて基幹システムを汎用機から
オープン系(Oracle＋VB6)に代えました。正直、今後10年はシステムを刷新
する事なく、VB6をメンテナンスし続けていくと思います。(.netに刷新する
だけのメリットも予算もない)

私も.netを使用して新規開発をしていますが、正直、あんまりVB6より
優れている！生産性が高い！と思う事がありません。
(SQLをある程度駆使して開発しているからでしょうか？)
基幹システムの開発生産性・保守性に絞った上で、.netがVB6より勝っている
事ってなんでしょうか？(今後10年はVB6をメンテナンスしていく立場なので、
MSのサポートがないという回答はあまりうれしくありません…)

今現在で「新規」でVB6を使うというのが現実的にあるのですね。。
VB6と.NET。お客様は業務がまわれば、どっちでもいいが当然本音でしょう。

お客様の事情はとりあえず置いといて、VB6と.NETはエンジニアの視点からすれば
個人的には大変革だと思います。
VB6はオープンソースが流行る前の技術だったため、フレームワークを作るのに
大きなコストがかかっていたと想像しています。
そのため、細切れのモジュールが群をなしてしまい、メンテが大変になっている。

一方、.NETではspring.netやnhibernateなどのオープンソースプロダクトを流用できる上、
ジェネリクスやアトリビュート(Javaではアノテーション)はこれらのフレームワークを
拡張するのにとても適しています。
また、ADO.NETのDataSetやLINQという思想はドメインモデルの問題点を補完する
優れたものだとも思います。

要するにフレームワークをほとんど最初から作り直せるような案件でないと.NETの魅力は
引き出せないけど、VB6新規よりはどう考えても良い選択だと思いますね。

すみません。
長くなるので次に書きました。

過激？なので却下されるかな（笑）

ちょっと失礼。今ふと思い出したのですがVB.NET2008はバージョンが9となっています。
このことから単純に考えて、VB6はただ古いバージョンというだけの様な・・・
これって「古い言語のバージョン使っても動くぜ」と同義なんじゃないかな？
そりゃ、動かそうと思えばどんな言語でも作れます。
だけど、古い言語のバージョンをお客様に薦めるのは如何なものかと。

多分主のような人は、
どこまでいっても金抜きで面倒を見るタイプなのかも知れないですが、
組織だった規模のビジネスの話ではないですよね。

多分釣りやって楽しんでいるんだとは思いますが。

通りすがりさん、はぐらかしてすんません。

DLLヘルってのは、自分でやったらどうしようもないお馬鹿だし、たとえば、GrapeCityさんなどのツールで起きる組み合わせは過去にあったのかもしれませんが、幸いに経験は無いです。
そういえば、VB5のとき自分でやって叫んでいる人もいたな。

私が作っていた配布用プログラムは、ファイルサーバ上に最新のDLLを見つけたら起動時に自分で登録しなおす機能を作っていたので、互換性が外れても再起動したら直るようにはしていましたけどね。
何かの都合で一回ぐらいその機能を使ったような気がします。

枯れているからこそ、DLLヘルは今更起きないだろうし、理由が分かっていたら対処できるじゃないの？
よっぽど訳の分からない海外の古いソフトを入れられたら起きるのかもしれませんけど、まぁ、私の顧客にはそういうことをする方は幸いいなかった。

VB6のサポートが切れたのはIDEだけで、ランタイムはまだまだ先（2017年ぐらいまでは続くらしい）ので、IDEなんて十分すぎるぐらいテストされてますし、そこに問題があっても開発者にしか影響でないし、まぁ、大丈夫でしょうと太鼓判。

人の問題もむしろあまっているぐらいいますし、VB6を使っていた会社ならライセンスも余っているはずです。
GrapeCityさんなどのツールが問題かも知れませんが、売ってくれると思いますよ。

VB6に現在も十分に存在意義があるし、サポートが切れたからってMSの戦略に乗っかるおりこうさんはおそらく日本だけ。
それでも、VISTAへの乗換えが進まなかったところを見ると日本も……。

インドリさん
べつに薦めろと言ってるわけではなく、良いか悪いか要件を見て判断すべきで、古いからといってすなわち悪いということは言えないということです。
顧客にとって、要件を満たせば、古いかどうかはどうでもよい話です。

ビガーさん
現実問題、新規案件とはいえないかもしれませんが、まだまだありますよ。
関連会社の仕事で、SQLも使わないVB5をVB6にアップしていく仕事が現在進行形だったり（苦笑）
世の中広いな～。

MR.CBRさん
その使い方なら、.Netは使わない方がよいかも。
10年後リプレースする先は.Netじゃない可能性が高いから（何になっているかは神のみぞ知る）割合的に.Netの資産が一番中途半端ってことになりかねない（笑）
SQLが廃れてなければ大した問題じゃないけどね。

傍観者さん。

趣味は石鯛釣りです。何年も行ってないな～。

> どこまでいっても金抜きで面倒を見るタイプなのかも知れないですが、

そうかもしれない。

> 組織だった規模のビジネスの話ではないですよね。

～ん。

> SQLも使わないVB5をVB6にアップしていく仕事

は、日本でも10傑には入る大手SIerの案件ですけどね。
大事なのは顧客の要件で、枯れている方が安全って考える人も確実にあります。

世の中の失敗プロジェクトで、古くて失敗したと、新しくて失敗したと、どちらが多いか検証してみたら、言うまでもなく「新しくて失敗した」です。
枯れた技術は、何が出来て、何が出来ないかハッキリ分かっているから、ものすごくローリスクです。

.Netがリスクが高いと思うほど、難しいとも思えないけれど……。

こんなに盛り上がっているとは・・。（汗

>本当にヤバいセキュリティホールなら、マイクロソフトも対応せざるを得ないし

そうです。対応しています。去年も。

Microsoft:「 (http://support.microsoft.com/kb/926857/ ) [MS08-070] Microsoft Visual Basic 6.0 Service Pack 6 ランタイム拡張ファイル セキュリティ更新プログラム (2008 年 12 月 9 日) 」

>サポートが終わった言語

いえいえ、現実面では終わっていません。終わらせません！

Microsoft:「2008 年 4 月 8 日現在、Visual Basic 6.0 IDE のサポートは終了しています。ただし、マイクロソフトは依然として、アプリケーションと共に配布される一部のランタイム拡張ファイルをサポートしています。」

>DLLヘルなんて、起きることがわかっているなら先に対策すればよいわけで、
>ちゃんと気を配ってたら起きないと思うのですけどね。

そう、エンジニアの基本姿勢。
でも過去に大失敗して、社長に頭下げさせたけど1度有り。（恥

>Cobolはやらんけどね。

COBOL、やってました。
今でも出来ます。

>>SQLとVB6じゃあ将来性は勝負にならないと思います。
>SQLとVB6を比較している人はいないと思いますよ。

後者に1票。

皆さん、話の次元が高いですね。
今でも、Windows98やWindowsME(！)が業務で堂々と使われていますよ。Windows98で.NET動いたかな？

スイマセン。
独り言です。

お客サイドから見ても新規でVB6はやっぱりおかしいかと思います。
何時か.NETへ移行せざるを得ないのですから、その時の費用が余分にかかります。
お客は知らないから何言語でもいいと思っていますが、
お金が要ると分かっているものを売るのはどうかな・・・

それはさておき、COBOLは駄目でVB6は良いという理由が分かりません。
結局は感情論なのかな？

COBOLが悪いなんて言ったこと無いですよ。
私がやらないだけの話で、Javaや.NetでCOBOL風に使うな
って言ってるだけです。

汎用機を使うと年間何億という保守費が掛かったりします。
リプレースした方が大幅に安くなることが多いのでここでも、
顧客側に立って考えるべき。

ってのは変わりません。

MR.CBRさんのところにも書きましたけれど、10年使う気なら、
VB6 → .Net(2008?) → xxxx

10年後のリプレース先は.Netとは限りませんから、別に今、
乗り換えようと、乗り換えなかろうと将来に掛かるコストは
変わりません。

noriさん

IDEなんて開発者にしか関係ないので、サポート切れと騒ぐほどのものでもないですしね。

私はほとんど.Netですが、VB5 → VB6の案件を担当している社員もいます。この案件は（皆さんも使ったことがあるかもしれない）コンシューマ向けのシステムで、大手の案件です。

大手でもサポートが切れても大騒ぎしないところもあるみたい。
あのぐらい大手なら、本当に問題が起きたら政治的にMSに文句言うんだろうけどね（笑）

これだけのユーザが使い続けていたのですから、まぁ、問題なんて出尽くしていると考えてよいのですけど。

う～ん。その理屈を言うのならば、VB4でもいい、C#1.0でもいい、いやBASICでもいい・・・という風に何でもOKになりませんか？
どの言語でも基本的に何でも実装できます。
しかしだからといって「動けばなんで作ってもいいだろ」という態度は、
プロとして如何なものでしょうか？
耐震偽装や食肉偽装事件を連想します。
これは職業倫理的問題なのではないでしょうか？
それに、初めからJavaか.NETかC/C++にしておけば将来の移行も楽だと思いますが・・・

あっちもこっちも、結構抽象的な話題で、なぜみなさん盛り上がれるのか私には謎ですが。（まぁ抽象的なので言いたい放題かな）
それはさておいて

なぜ基幹システム（販売管理、生産管理など）がWEBシステムである必要があるのか。といった類の話がちらほら見えています。

この答えは「考えるな！感じろ！」
いや嘘です。

もし、旧テクノロジで（つまり、現システムと同じテクノロジ）
「今までよりもっと効率のよいシステムが作れます」
なんていうと、
「おまえんとこのチョンボだろ？なんで最初からそう設計できないわけ？」
なんていう結末に陥ることが多々あるでしょう。
疑念をもたれたら最後、もう何を言っても無駄です。
刷新しないシステム開発が世の中に殆ど無いのは、このあたりが大きいかも。

もし、新テクノロジで
「今までよりもっと効率のよい新しいシステムが作れます」
なんていうと、
「ほ～、費用対効果はどうなんだね？」
なんて、なりやすい。

まぁそれだけですな・・・・
外国の物や新しい物をありがたがるという民族性も多少はあるかも・・・

oumiさん、ども。

ちょっとチャチャ入れただけのつもりなんですけれど、何が皆さんを突き動かすのでしょうね？
次はもっと炎上するか……。

> もし、新テクノロジで
> 「今までよりもっと効率のよい新しいシステムが作れます」
> なんていうと、
> 「ほ～、費用対効果はどうなんだね？」
> なんて、なりやすい。
>
> まぁそれだけですな・・・・
> 外国の物や新しい物をありがたがるという民族性も多少はあるかも・・・

これはあたってますね。
本文に書きましたけど、私自身、90年代の後半に「イントラネット」の言葉の流行に乗って提案したことあるし、客が新しいもの好きなら新しいものを提案します。
古いものは嫌いなのですから、顧客の利益に合ってますからね。

インドリさん。

新しいかどうかではないのです。
顧客にメリットがあるかないかです。

鳴り物入りの新テクノロジーがどれだけ消えていったか。

たとえば、C#1.0はVB6より後に登場して、VB6より先にお亡くなりになったわけで、新しいもの大好きな技術者が、顧客の利益でなく、自分の好みで提案してしまったために、顧客に迷惑を掛けるなんてことは枚挙に暇がない。

自分のメリットしか考えてない。← これこそ食品偽装につながるひどい話。

古いことが悪いのではなく、新しいことに価値があるのでもないわけです。
何が出来るかに価値があるのです。

>何が出来るかに価値があるのです。

そこなんです。
明らかに.NETの方が出来る方が多いにも関わらず、バージョン9（VB.NET）を無視して使い続ける・・・
そこまで固執する意味はあるのですか？
単純にバージョン9であるVB.NET2008を使えばいいと思います。
ちなみにC#3はまだ使われています。
みんなC#1.0なんて使わないのは3があるからです。

> 明らかに.NETの方が出来る方が多いにも関わらず

何が出来るかは、要件を満たすかということです。
必要の無いものは要らない、VISTAが売れない理由もそこにある。

.NetにもVB6にもこだわってないです。
現実的にどちらも世の中で使われているのですから、どちらも出来ればいいだけの話。

読んでいくうちに「ビートたけしのTVタックル」を思い出しました。

国会議員が激論をしている最中に、どこかの評論家が
「(怒)政党の話はもうどうでもいい。国民の目線で話をしろ！(怒)」
国会議員、全員沈黙・・；。

生島さんが言いたいのは国民(顧客)の事をだと勝手に想像しています。
政党(言語)を重視していると国民(顧客)が見えなくなってくる。
大事なのは国民(顧客)です。

エンジニアの仕事は素人の顧客を正しい方向に教育し、
それに合ったシステムを提案＆構築する。
※↑当たり前すぎる内容ですが。（汗

なんて、エラソ～に事を言いましたが、現実面ではなかなか難しいのは確かです。自分の首を自分でしめる事にならないように、先々の事も考えないといけない。適材適所に対応しないと顧客が逃げる。
仕事も無くなる。　※<-これが一番困る。

話は変わりますが、やっぱVBAが一番ですよ。（ｺﾗｺﾗ
Access,Word、Excel,VB6にも使えるし、VB.NETにも(不)完全なコンバーターが着いているから将来性も安心。Excel等のIDEはVB6や.NETのIDEと９０％以上同じですから、開発が楽です。顧客でExcelをPCにインストールしてない、なんて事は無いから、.NET云々の話をしないで「Excelを使って出来る様にしましょうか？！」なんて顧客に提案するとほとんどOKです。実際は中でサーバーとやり取りしているなんて顧客はもちろん知らない。知っていても気にしない。バグが出てもその場で即座に調査＆対応できる。

※話がどんどん逸れて行く・・。

.NETが将来的にはイイ事は判っているが、まだまだ課題があるのは確かだと思います。で、私は基本的に楽なVBA(=VB6)で逃げています。　※<-卑怯者！

こんなコメントは、有りですか？

saki1208です。

noriさん
>.NETが将来的にはイイ事は判っているが、まだまだ課題があるのは確かだと
>思います。で、私は基本的に楽なVBA(=VB6)で逃げています
理解してそういう逃げ道を作っておくのはありでしょう。

問題はVB6しかできないからVB6で!!ってやっちゃう人たちだと思うのですが。

みなさん、設計思想や言語仕様の有用性なんかは論外なんですかね？
正直、同じ話題が延々と続いているだけでコメント数が多い割に実りが少ないように感じます。

ちょっと気になったのが、生島さんの大手SIerがお客様でVB5→VB6というケース。
お客様の事情や古い技術の低リスクは確かに魅力でしょうが、エンジニアの立場に
立ってみればモチベーションはダダ下がりと思います。担当者に一度聞いてみては？
Rubyが注目されている要因も結局エンジニアが楽しく開発できるから。
これは品質に非常に影響します。古い技術(VBは枯れてはいないと思う)の延命は
現実的に考えると負の循環に陥る気がしますね。

noriです。

>問題はVB6しかできないからVB6で!!ってやっちゃう人たちだと思うのですが。

スイマセン。
周囲にそんな考え方で仕事している人、多いです。
「仕方が無いな～」と言いながら、心で「(怒)できないんだったら、勉強しろ！」と叫んでいます。常日頃、「できない」と言う言葉はエンジニアとして言ってはいけない言葉だと、言っています。「教えてもらってないから」と言う者もいますが、マジで手に力が入ってしまいます。

VBAが一番とはいわないけれど、三番ぐらいかな（笑）
業務に合えばダントツ一番ですし、合わなければ使えない。
PDFを使うというのはいい感じですね。
偶然、まとめでVBAのことを書きましたけど、これも明後日ぐらいの公開かな。

エンジニアのモチベーションというのは大変な問題なのです。
（ここには書けない、なかなか難しい問題があります）
とは言え、モチベーションだけでは食えないしね。

ビガーさんって金融系じゃなかったでしたっけ？
金融系は一番保守的ですよね。
私はもともと金融系で、それもあって嫌になって起業したんですけど。

金融系は、まぁ、Javaを選ぶところが多いのですが、VBを使っていたところは、.Netに移行したがらない傾向が強いです。（関西だけかな？）

なんだ、ちゃんと理解されていたんですね。
意地の悪い・・・

さて、レス及び次の記事もあわせて見ていたのですが、正直
・なるほどねー
・そうかなぁ？
両方あったりします。
このあたりは前提条件が理解出来ない限りそんなもんだろうと思うのですが、とりあえず最後に一点。
「VBのプログラマはあまるくらい」について。

システム系の業界(?)はおおざっぱに
・SI系
・Web制作系
・社内情シス
の3種類と認識しているのですが、Web制作系におけるVB(A)の認知度は、びっくりするくらい低いですよ。
VBA便利なのに。
大体、私と同年代(30ちょい)だと2割、20代だと1割行くかいかないか。
※VBSは除外します

なもんで、VB使える人の調達なんてかなりさっぱりです。
使える人がいると私よりかなり年上(=高単価)が殆ど。

でも、エンジニアの母数に占めるWeb系の割合は既にそれなりでしょうし、Web系の会社が業務システムを構築することも結構多いので「VBのプログラマがいなくなる」と言える自体は十分そこに迫っていると思います。

正確には
　・居場所が極端に偏る
　・居ても年齢(=単価) が高い
ため「現実的にいないに等しい」という感じで想像してますが。

ブログ主さんが偏った場所に迷い込んだら、多分唖然としますよ。
ま、そういう世界もあるということで(笑)

通りすがりさん、ども。

曲がりなり（まくり）に社長なので、いろんな会社とお付き合いがあります。
Web系ならここ、制御系ならここ、デザインならここ、翻訳ならここ、人だしならここ、などなど、自社で全部やろうとはしません。

会社として（当面の）リスクを取らずにVB6に偏らせる戦略をとるところもあります。長期的にリスクがあると思うかもしれませんが、「少なくなってくる」と心配されるように現実的に減ってくるなら、リプレースするときに「解析を手伝って」ってなります。

たとえば、弊社でCOBOLからJavaへのリプレース案件をはじめていますが、COBOLは他社にお願いします。得意な会社（本当のプロ）を集めた混成チームでやりますよ。

以前はメインストリームだったわけで、将来はスキマとしてこだわり続けるところは生き残ります。（当然、紆余曲折はあるよ）
つまり、VB6を続けるのは悪いこととは言えないのです。

弊社のように何でもやる会社はあまりよくない（笑）

技術者目線で考えると……。
若い人が嫌がる気持ちも分からなくないですが、そこは提案力を社内で発揮すべきでしょう。
自社を口説けん奴がどうやって顧客を口説くのかってね。

かくいう私も自社（ってかずっとフリーですが）を口説けなかったから、起業したくせに（苦笑）

追加。

もし、私がVB6にこだわり続けている会社の社長だったら、皆さんにいただいたコメントに流されて宗旨替えをすることは、まずないと思う。

たぶん、弊社のように何でも手を出す会社より、そういう偏ったこだわりの会社の方が強い。

私も分かっててもスタンスを変えないしね。

何かコレ関連のコラムが増えていてビックリ。
私の今の専門は証券(特にデリバティブ関連)です。銀行とか保険は未経験なんですわ。
証券は結構アグレッシブですよ。とくにシステムアーキは面白い。
この関連のコラムも見て思いましたが、技術者はもっと大事に扱った方がいいですね。
私は、はじめに従業員満足、それにより顧客満足を向上できると思います。
そういう風土を持った会社に入り込んできましたが、やっぱり「強い」と感じました。
自分たちのエゴではなく、いい意味でチャレンジ(リスクヘッジをきちんと計画)している。

ツキナミですが、従業員が生き生きしている会社はこっちが元気をもらえるので好きです。
(こんな結論あり？)

証券会社ですか、確かに同じ金融でも毛色は違いますね。
銀行でもデリバティブ（キャップ・フロア・スワップションなどなど）を扱いだしたときにやりましたけど、恐ろしく保守的でした。

従業員満足度は上げたいのですけれど、弊社はミドルクラスがいないのでなかなかギャップが埋まらず難しいです。
誰か社長を立てて、私がミドルクラスにならないと、私が思っている会社にはならない。
しかし、融資残高０になるまではそれも叶わない……。

あまり掘り下げるのもどうかと思いますが、ファンドラップとかＦＸですね。
生島さんの保守的の意味がわかりませんので具体的にお願いします。

私の関わった案件では、バッチは日に10分程度のフル稼働(365日24時間)だったので
バッチも当然マルチスレッド、オンラインのアーキもアグレッシブに変更可能なよう
概念モデルやユースケースから実装までのトレーサビリティは重視されつつ、
日々リファクタリングしていくような感じでした。

胴元(銀行)に入っていこうと思っているんですが、暗雲たちこめてますかね？昔の話？

保守的というのは、ウォーターフォール以外に考えられないし、提案の機会は与えられないとか……。

あとびっくりするのは単体テスト。
画面はすべてキャプチャーして印刷し、表示エリアすべてにチェック印を押す。
もちろん帳票も。
途中で蛍光ペンになりましたが、テスト結果だけでダンボール何箱分あったかな。
蛍光ペンも何ダースの単位でなくなりました。

後半は馬鹿高いSEも総動員して、マーカーでチェックするだけの仕事を延々と。
とってもエコじゃないことをするのです。

なるほど。私のキャリアは大手SIerの社員から始まりましたが、テスト証跡の質は
生島さんのおっしゃっているのとほぼ同じでした。
単に安心したいがために無駄なもの作らされていると感じた時期もありましたが、
意味のあるものへ少しずつですが変えていけたと自負しています。

「提案」という形だと仰々しい感じがしてしまい相手によっては気分よく思わない人が多いので
やっぱり地道に誘導する作業にはとても価値があると最近とくに実感しています。

チェック印を押しても、見てなかったら意味がない。
そんなやり方では逆に見なく（意味を考えずに手だけが動く）なりますから形式だけになっちゃいます。

でも、COBOL時代に一回決めたら変わらない、意味より形式が大事というのは私には耐えれませでした。

ビガーです。

いろいろと批判的な内容を好き勝手に発言させていただいていますが、
経営者としての生島さんの姿勢にはいつも感服しています。
これからも個人的な異論は発しつづけると思いますが、応援しています。

無駄なコメントを多くしてしまい、失礼しました。

ありがとうございます。

でも、それは間違ってるな。
経営者は儲けてナンボ、決算書は通信簿ですがオール１ですよ……。

本物の経営者は、自分を殺して利益を取りに行くべきです。

終了している話題かつ若干ずれた内容で恐縮ですが、ちょっと気になる情報があったのでコメントいたします。

noriさんの
>現在でもヨーロッパ周辺では８割の開発者がVB6を使用している
>聞いたことがあります。

これを読んだときに、日本・米国・欧州はそれぞれシステム投資の概念が違うような話を聞いたことがあるなーと思ったのです。
そうなると当然、システムの平均寿命も違うわけで、採用しうるテクノロジーの優先順位も変わるわけでして・・・
※ソースが無かったので、タイムリーにコメントが出来ず

以下記事にて、システム投資の概念の違いについてまとめられていました。
>欧米人なら爆笑するレベルと言われる日本企業のIT投資
http://it-ura.seesaa.net/article/122104434.html

欧州についての言及が無いのは気になりますが、面白い記事だと思いますよ。
(タイトルと違い日米比較)

放牧民さん、ども。

システム投資はしっかりするけれど、VB6は使い続けると考えたら……。

何ができるかで選んでいるということでしょうね。アメリカは8割ということはないと思うけれど……。VB6から.NETに乗り換えるのではなく、Javaに乗り換えたところも多かったと思います。

VS2005ぐらいになってだいぶよくなりましたけれど、VS2002、2003ならVB6の方がはるかに出来がよく安定性も高かったしね。新しいかどうかに価値はなく、しっかり評価して選んでいるということでしょうね。

お初です
なんだか、やたらアツイですねぇ…

私も「作る対象に合わせて言語を使えばいい派」ですね

仕方が無いところもありますが、どうも最近は
特に技術者達が業界に踊らされているだけの様な気がします

VSよ、そんなにバンバン バージョン変えるなよ と（笑
まぁVS2002の頃、仕事で作ったソースがさっくり消えて泣きましたし
VS2005がやたら使いやすくて、びっくりでしたけど

ここではVB6は枯れたと言われていますが、私はそうでも無い気がします
少なくともActiveXに関しては、VB5から作れるようになっていましたが
今まで関わって来た仕事で、作って使ってる所はありませんでした

むしろ私が作って「便利ですよー」と布教していたくらい（笑

たしかに普通にありモノを貼り付けてロジック埋め込むより
工数は余分に発生します
（機能単位の切り分けも、ちゃんとやらないといけないですし）

ただ、開発もテストもオブジェクト単位から出来る
後々の管理が（ちゃんと管理していれば）ラクと
かなりのメリットがあるはずなんですけどねぇ　甘いのかな？

そうそうDLLヘルは
なぜか書かれていないですが（当たり前の事なのでしょうか？）
マニフェストファイルを作り、任意のディレクトリに該当DLLを入れる事でも
回避できます

マニフェストファイル、作るのメチャクチャ面倒ですが

VB6は、枯れてはいるかもしれないが
まだ使われていない美味しいところがいっぱいある と言うのが
私の個人的評価です

VB.netは、仕事上で派生・継承をちゃんと使うことが出来るのなら
ある程度の省力化は期待できると思います
（きちんとベースを設計している事が前提条件になりますね）

ただ、そこまでやるのなら 正直C#でもさして変わらないですし
C#も仕事として、そこまでやっているのか疑問なんですが…
（Javaは…　どうなんでしょう）

.netの テスト用などの評価ツールもいっぱい出ています
確かに使えそうなのですが、実際そこまで出来る作業って
あまり無い様な気がします

と言いますか、今のVB.netって
Cライクなマクロが作れるようになったのでしょうか？

マクロとヘッダーファイルが作れるのではないかと
出る時に期待していたのですが
無かったことに落胆していた方だったので…

しかし、そもそも そんなにVB系の案件ってあるんです？
もうそろそろバイト始めないと、生きて行けない位 仕事がないのですが
（もう、最近自虐ネタ的になって来ました…）

amigaさん、お初です。

VB6でマニフェストファイルでできたんですね。
個人的には互換性をしっかり管理しておけば、余程のことがない限り関係ないと思うけれど……。

弊社ではVB6の案件は、この先ないと思いますけれど……。
VB6だから、.NETだから、は全く関係ないですね。

仕事は本当に減ってきましたね。
弊社もいつまであるか分からん（苦笑）

・VB6とVB.NETは、名前こそVBとついて(、そして一応バージョンも受け継いで)いるものの、根ざしているものが全く違うと思います。

・加えて、「VB6を使い続ける選択肢」について言及する上で、あまり他の言語との仕様の比較をしてもしょうがないのではないでしょうか。

・古いものと新しいものを比べて、どっちがどれだけ優れている(or 優れていない)という話は、本題にとってプラスではないように思います。

以上の3点を話の筋に加えてしまうことで、この話が単なる新しいものに対する恐れと、いたずらなアンチテーゼに聞こえてしまって、本筋でおっしゃっていることは容易に同意できるのにも関わらず、反発を招いているような。

私は一個人としてVB6を忌み嫌っておりますが、VB6を全てに優先して廃する必要性は無いと考えています。おっしゃるとおりランタイムは今後も長いサポート期間を持ちますし。

私はC#やJavaの合理性やバグの入り込みにくさから、それらの言語を推しますが、それはあくまで一個人での新規開発場面においてのみ、です。
新しい言語に多くの人材が対応できるようになるのは、えてして時間を経てからですし、対応しきれぬうちから新しいものへの探求ばかりしていては、本業がおろそかになってしまうでしょう。

何より、私が携わっている基幹業務をはじめ、「会社が開発するもの」は規模が大きく、そのぶん寿命が長くなりがちです。
今関わっているプロジェクトも、10年前にゼロからの再開発が始まって、いまだ同じシステムに継いでは足して、を繰り返している次第。それでなんら無理は生じておりませんし、要は開発を如何にうまく行うか、であって、言語によるところではないのでしょう。
長いシステムでは、20年のサイクルを持つため、いまだCOBOLで動いている、というところもあります。
そして、そういったサイクルは運用上(おそらく)とても大切なものだと思いますし、それをぶち壊すほどの「必要性」は、今のVB6の立ち位置からは感じられません。

ただ、ここ2年以内にサイクルを迎えるプロジェクトがあったとすれば、私は"是が非でものVB6脱却"を進言しようと思っています。
ただそれは、VB.NETへの推移ではなく、むしろJavaでの開発を進言するものですが。

一企業でしかないMSの度重なる気まぐれにいちいち付き合うのも体力を使うものですから・・・。

ベンチャー企業の社長さんをされてるかたに、入社3ヶ月の人間がおこがましいことかもしれませんが、コメントの荒れっぷりが心底もったいない、と思いましたので、僭越ながら長文で失礼させていただきました。

kyohさん、どうも。

コメント欄が荒れるのは半分釣ってるわけですし、楽しんでますので良いのですけどね（笑）

主旨は「選択するのは顧客目線で」ということだけすので、そこを分かっていただければ十分です。

最後のWindowsと呼ばれるWindows10で、VB6がサポートされています。
結果的に、Windowsでは永遠にVB6は無くならないでしょうね。
私のところでも、VB6の開発はまだまだ現役ですよ。

投稿から10年が経過しましたが、VB6はますます健在です。
2019年8月のWindows UpdateでVB6,VBA,VBScript 系で配列関連の不具合が生じましたが、
MSは即座に修正プログラムをリリースしています。