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

社長より優秀な人材に囲まれて経営できるようにもっていきたいですね！
「社長はもうSQLなんか書いてないで、経営に専念してください」とか言われてみたいですね！
もしそうなっても生島さんはSQL書くことを止めないでしょうけど（笑）。

アイさん、ども。

技術者というのは、経営者には向いてないのです。
今は社長は代われないけど儲かったら、ラリー・ペイジやビル・ゲイツのように社員より社長を募集します（笑）

SQLなんてどうでもよくって、そんなレベルじゃない話をしたいのですけど、今のところ、SQLが生産性の差が大きすぎるのでその差が詰まるまでは、こだわるでしょうね。

残念です。VB.NETがオブジェクト指向言語だという点を考慮していませんね。
オブジェクト指向であるという事は、ソフトウェア開発の原価管理上重要な事です。
標準作業時間を下げて経費を下げ、高い品質を維持する事が出来ます。
オブジェクト指向言語で多い誤解が「新規開発で余計に遅くなるから役に立たない」という考えです。
それがそもそも筋違いで、オブジェクト指向は「未来の標準作業時間を下げる技術」なのです。
おまけに.NETはリファクタリングより、自動テストツールなどが作れ、
バグを減らしてかなりの品質を出せます。
VB6とVB.NETじゃあ、自身でオリジナルの開発ツールを作っている事もありますが、生産性が桁違いです。
プロならば、道具でどれだけ生産性が上げられるのかという限界点を見極め、
その最高値が叩きだせる状態にするために、常に自分を鍛え続けなくてはなりません。
VBAはVBAでマスターしておけばいいことです。
それに.NETでオフィス製品は作れます。

う～ん。

そこそこ長い時間この業界に生きてきたけれど、残念ながら桁違いは見たことないですね。

どれぐらい大きなプロジェクトでどれぐらいのメリットが出ましたか？
桁違いなら、本当に業界は変わっているはずだけれど、相変わらずブラックな業界と言われていますし、桁違いの生産性のVB6を選択する会社がたくさんあるというのは私には理解できません。桁違いの生産性でこの厳しい世の中で生き残るはずはないのですが、むしろ、VB6を選択している会社の方が元気です。

ものすごくバラ色の宣伝は一杯見るけれど、せいぜい20～30％ってとこです。
このぐらいは習熟度によって簡単に逆転するので、経営者としてスキルチェンジさせるリスクを取らないのは立派な戦略です。

20～30％なら、不況の今は、赤字でも遊ばせるよりマシってプロジェクトがあるので、スキルチェンジするのにちょうどいいでしょうけれど、企業の戦略として積極的にすべきとは言えないね。

VB6から.Netへのスキルチェンジできない人を叩いている若造を見るにつけ、「弱い者が夕暮れ、更に弱いものを叩く」って風にしか見えない。

どっちもミジンコほどどうでもいいことです。

追加。

もちろん、

■ SQLができるようになるべき → 効率がよいから

■ VB6ではなく.Netへ → 新しいから、多少効率がいいから

私は新しいことに価値はない。
効率を見るべきでしょうと言ってます。

少なくとも私はリファクタリングによるメタプログラミング等により生産性が10倍以上上がっています。
やっぱり開発者は自分独自のツールを作って生産性を上げなくてはなりません。
いわゆるUNIX思想ですね。
それと、出来る事は.NETの方がはるかに上ですし、セキュリティがランタイム自体から考慮されている点などの品質面から考えると.NETを採用しないのは信じられません。
そんな私にしてみれば、VB6を新規開発で使うのは怠惰精神の賜物だとしか思えません。

書き忘れていましたが、これからはマルチコアの時代です。
マルチスレッドプログラミングが極度にしにくいVB6を採用しない事をお勧めします。

何度も書いていますが、顧客の要件に合うことが第一です。

マルチコアのCPUを搭載してください。って顧客に言ったら、業務システムの案件は取れません。

生島さんが生産性向上を体験できないわけは、設計者の問題だと思います。
日本は現実を知らない＝技術を知らない人が机上の空論で設計します。
その様な状態でまともなオブジェクト指向分析＆オブジェクト指向設計が出来ているはずがありません。
オブジェクト指向技術は未来の生産性を上げる再利用技術です。
再利用できないものばかりを作っていればコストは逆に上がります。

>マルチコアのCPUを搭載してください。って顧客に言ったら、業務システムの案件は取れません。

それは誤解です。
お客様はマルチコアなんて考えていません。
ただ新しいCPUに交換すればパフォーマンスが上がるとだけ考えています。
ですからマルチコアに買い換えてもパフォーマンスが上がらないであろうVB6はお客様の心証を著しく悪いものにします。

それはずいぶんな言い方ですね。

VBだろうが、Javaだろうが、.Netだろうがコンポーネント化して再利用していますよ。
でなかったら、DLLヘルなんて気にする必要もないでしょう。
VBでできないのは継承ぐらいで、他は効率の差はあっても大体できます。

VBを使い切れてなかったから、桁違いに思うのではないでしょうか。

ちなみに、VB6とか.NET とかはまぁ面白いからよいのですが・・

>オブジェクト指向技術は未来の生産性を上げる再利用技術です。
残念ながら未来は違う言語になっちゃってるんですね・・・
今までがそうだったように・・・
１０～１５年くらいすると、もう.NETもないんじゃないかな・・
なので、言語仕様論争としてのVB6vs.NET とか、OOPか非OOP化は戦わせても良いのでしょうけど（面白いから）、リアルレベルでの話になると、的をはずしちゃいませんかね。もしくは、会話のモデルとして想定している物が狭い世界で通用するものだけになっちゃいませんか？

>生島さんが生産性向上を体験できないわけは、設計者の問題だと思います。
>日本は現実を知らない＝技術を知らない人が机上の空論で設計します。
>その様な状態でまともなオブジェクト指向分析＆オブジェクト指向設計が出
>来ているはずがありません。
>オブジェクト指向技術は未来の生産性を上げる再利用技術です。
>再利用できないものばかりを作っていればコストは逆に上がります。

これって酷い言いようですよ・・結論に飛びすぎなんです。
例えば、
>日本は現実を知らない＝技術を知らない人が机上の空論で設計します。
これはそもそも、欧米の教育機関と社会と企業のありかたから論ぜられなければならない問題です。ですので、結論だけをこのように書くと、みんな「ギョっ」「カチーン」と来ると思いますよ。
そして、日本の社会で働いている技術者へのメッセージであるならば、このような言い方では、何も伝わりません。

>それは誤解です。
>お客様はマルチコアなんて考えていません。
>ただ新しいCPUに交換すればパフォーマンスが上がるとだけ考えています。
>ですからマルチコアに買い換えてもパフォーマンスが上がらないであろう
>VB6はお客様の心証を著しく悪いものにします。

これもです。

自分の知っている世界だけをもって、全てを型にはめようとしているように見えますよ。頭良すぎる人がはまる罠ですね。こういう人結構います。そして、こういう人ってリアルでは、相手が何を言わんとしているかを言葉だけで判断して、なかなか掴む事のできないタイプが多い。頭はものすごく良いのですが。

言語に関する造詣の深さはCodeZineもBlogも拝見して（お世辞抜きに）感服していますが、対人となるとお粗末過ぎる。
もう少し、相手の意図、相手の話している、立脚しているモデル、そういったことにも考えをめぐらしてほしいものです。
そして、レスをつけるなら議論として成り立つような配慮もしてほしいな。

（まぁ人のことを言えた義理ではありませんが）

交通整理、ありがとうございます。

私としては、噛み付かれることがなくなってきています。
立場上、ある程度仕方ないのですけれど裸の王様ですからね。

ですから、噛み付いてもらうのはありがたいことなのですけれど、噛み合わないのは困りますね。

>それはずいぶんな言い方ですね。

失礼しました、話題が面白かったのでちょっと興奮しすぎました。
申し訳ございません。
ちょっと表現がオーバーだったようです。
私はVB6の時代からADO.NETの様なフレームワークを自作し、
それに加えてLINQのようなものも自作してやっていたので、
.NETに対して愛着を持ちすぎているのかもしれませんね。
でもVB6は好きだったのでかなり使っていました。
当時クラック方法（セキュリティテスト）や拡張法まで調べていました。
それでVB6の限界にぶち当たりC++で補完していたりしていました。
その上の発言です。
VB6が好きなだけに弄りすぎて限界も感じてしまったのです。

oumi さんへ
.NETが破棄されたらその違うテクノロジーを発売日と同時に使い学ぶだけです。
VB6→真テクノロジーではなく、VB6→.NET→真テクノロジーとなるので.NETをやっておいて損はありません。

ご忠告有難うございます。
思い当たる節あります。
私は自分に全く自信がないので、相手の理解度を確認せずに、
相手は必ず自分以上の知識や技術力があると思って発言してしまいます。
それがもとで時々会話がすれ違う時があります。
反省します。

ちょっと興奮しすぎましたので反省し、今度の記事に関してはこのコメントを最後にします。
失礼致しました。

終わっているようなので、恐縮なんですが、温度差は開発者目線とビジネス目線の差だと。
どんな道具でも慣れた人は生産性が高いのは当然。
最新の道具が効率良いのも当然。
全ての業務が新しい道具に置換でないのも当然。
諸事情で古い環境を使い続けなければならない事もある。
VB6での稼働を前提としている組み込みPCもある。
どうも、最新の環境での仕事が偉いという錯覚を感じる。
仕事の関係で、VB6や.net/JAVA以外のことをしている人に失礼。
10倍の生産性!　この数字は、熟練者の比較ではない。比較対象が不明確な数字に意味はない。
100の仕事をするとき、全て.netで新規作成するより、95% 旧部品を流用し5%を新規作成するのが、トータル早い。
@IT業界の仕事は開発言語やOOPの問題ではない。業務要件を満たすか否かである。VB2で作成しても、要件見たせば、仕事は成功。
開発者のスキル習得は別問題。インドリ氏は、個々人のスキル習得とビジネスの区別をつけてから投稿したほうが、要らぬ炎上にならないかと。いままで、何度炎上しているか。
スレ主殿、このような投稿をお許し下さい。

今、調べごとばかりをしているので、コメントが入ると来てしまいます。

交通整理ありがとうございます。

> 10倍の生産性!　この数字は、熟練者の比較ではない。比較対象が不明確な数字に意味はない。

私も本文でレトリックとして使ってますけどね。私がしたらSQLにしなくても5日ってありえない数字ですから、1000％なんて関係ないのですけど（苦笑）

それはさておき、気になったのでVBについても調べて気づいたことがあります。

その昔、すべての変数をGlobal（Public）で宣言【しなさい】と書いてあるコーディング規約が存在しました。
【配列使用禁止】というコーディング規約も存在しました。
変数はVariantで宣言【しなさい】というのも、DLL/OCXを作らないどころか、クラスも作らないところも、GOTOをエラー処理以外で、積極的に使っているところも存在しました。

仮定の話ですが「VBを使い続ける」というのはそういう意味で言ってるのかな？
上に書いたようなことは、私もいくつかのプロジェクトで実際に経験してきましたけど、もし、今も存在するとしたら、私は知らなかった。

で、だから、VBがダメかっていうと、そうじゃないでしょう。

VBか、.Netか、となると簡単には変えれる問題ではないし、上のようなことがある会社なら、.Netにしたらプロジェクトが失敗するのは火を見るより明らかで、「VBを続ける方がマシ」ってことになる。

しかし、こんなのは日々の提案改善レベルの話で、今更、勉強している暇のない人たちよりも、新人君であろうとプログラマからのボトムアップで提案して変えれますし、変えるべきです。

逆に、その程度が変えれない奴が、いくら「.Netが良い」と提案しても誰も動かないと思う。

VBと.Netって、継承とか、インスタンスの扱いとか、ちょっとした記述の違いぐらいでしょう。その程度の違いを針小棒大にいう必要もない。嵌る人は嵌るでしょうが、プロとしてVBをちゃんと使っているならすぐに慣れるはずです。

そんなレベルの低い話をしているつもりはなかったし、まさかとは思いますが、そこまで噛み合ってなかったとしたら、ちょっと反省。

もっと燃やしたいスレ主の意向のようですから・・・

>VBと.Netって、継承とか、インスタンスの扱いとか、ちょっとした記述の違いぐらいでしょう。

これは、作為的に地雷おいたんですよね？
そして、これにこそインドリさん、物申してほしい（本当に）

oumiさん、ども。

「ちょっとした」に内包しておいてください。
私にはミジンコほどのことです。

>すべての変数をGlobal（Public）で宣言【しなさい】と書いてある
分かります・・・いや、分かっちゃダメですね。
ちょっとした一回きりツール（じゃなくてもかな？）ならGlobalでやります。
制御するまでもなかったり、独自な便利ツールで考えるのも面倒ですから。

いや、本題の感想を。。。
VBとか.Netとかどちらでも良いと思います。
というよりJavaでもCOBOLでも。
業務システムであれば、インターフェース、パフォなど含め総合的に品質がよければ。
品質って何？というのは省きます。一般的なものと思っていますから。
あと、コストも大事ですかね。
ランニング、イニシャル、あと開発の。
総合的に判断して何でつくるのか？というのが決まるのではないかと思います。

新しいものが便利で能力も向上しているというのも一理あります。
ただ、VBでもクラスが作れて、DLLにすれば再利用も可能ですし、何が何でも
.Netがよい！とは言い切れないと思います。
会社全体（プロジェクト全体かな？）のスキルも関係するものです。
あとは、新しいものを吸収していき、製品・・・いや、商品、サービスとして外に
出せるレベルであれば新しいものに切り替えればいいのかな？と思います。
いきなり試験的に商品にするとなると、会社として覚悟があればいいのでは。

とコラム＆コメントを読んでの感想でした。長くてすみません。
私の発言は気にしないでください。

まぁ、C#を「#include がないＣなんてＣじゃない」と毛嫌いしている
Javaerな私が大きなこと言えませんが・・・

インドリさんを相手する皆さんの懐の広さには、頭が下がります。

インドリさんの捨てゼリフ･･･ひどすぎますよね。
http://d.hatena.ne.jp/busaikuro/20090602#c1244714274