ベンチャー社長で技術者で

う～ん。温故知新が私のモットーで、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にこだわり続けている会社の社長だったら、皆さんにいただいたコメントに流されて宗旨替えをすることは、まずないと思う。

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

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