VB6を使い続けること(プチ炎上したのでまとめ）
みんなVB6を使い続けていることを、こんなにも気にしているということが分かりました。プチ炎上したのでまとめです（うそ、まとめになってない）。
以前、しゃれでこんなゲームを作ってみたのですが、わたしもここ5年ぐらいはほとんどVB6を触ってないので（当時としては3年ぐらいのブランクかな）、3時間って見積もって8時間もかかってしまった（苦笑）。
これを元に、VB6か.NETか考えてみましょう。
要件によっては差が出るものもありますが、このゲームを作るには.NET（エクセルマクロにはないけど）の方が多少都合がよい。これは通常の業務システムよりも大きな差になる。
作った当時もブランクがあったので、「（VBAの）配列って……、あれ？ こんなことできなかったけ？」ってなことになり、.NETでできることがVBAでもできると勘違い（忘れてた）して、かなり大幅に後戻りしました。こんな小さなプログラムなら1カ所でも嵌ったら差が出るけれど、プロジェクトで嵌りっぱなしってことはないはずで、誤差の範囲でしょう。
余談ですが、新入社員の教育用に「ゲームなら業務システムより抵抗がなかろう」と思って「3時間で作ったる！」って宣言して作ったので嵌って悔しくってね。で、新入社員には難しすぎると大不評でした。こういう自己満足のための仕事は良くないね。
勘違いして後戻りしなかったら5時間ぐらい、でき上がったソース量からみて全盛期ならVBAで4時間ぐらいと思う。エクセルマクロに.NETが使えたらとしたら3時間ぐらいかな。
言語（開発環境）としての特性を比較するならば、不得意の人がやると、「できない＝無限大の工数」になるので、どちらにも慣れている人で比較しないと意味がない。わたしはどちらもそれなりに慣れていると考えて（異論は受け付けるよ）、差が出る機能で20～30％の生産性の違いでしょう。
もし、20～30％以上の差がつくと思うなら、単にいずれかが、わたしよりもはるかに得意か、ものすごく苦手かなだけじゃないですかね？
比べてみたら「.NETは楽だね～」って思うけれど、PCのメモリを2Gから4G(3Gしか認識しないけど）変えたぐらいの差しかない。増やした瞬間は楽に感じたり、減らした瞬間はイラっとしたりするけど、次の瞬間には忘れている。
このぐらいの差は、担当者の「能力＆慣れ」で簡単に逆転してしまいます。たとえば、.NETでやったら2時間でできるって技術者は、どこかにはいるでしょうけれど会ったことはないし、.NETが得意という技術者でも、大半は4時間じゃ無理なんじゃないかな。異論は受け付けるけど、普段の弊社の見積りは、わたし（がやったとしたら）×3 でも足らないことが……。
つまり、VB6がかなり得意な技術者なら、同じものを.NETにちょっと得意ぐらいの技術者が作っても、まだ、VB6の方が早くできます。
いずれにしても、顧客の都合を前にしたらごく瑣末な問題です。VB6も、.NETも無視できない数のユーザー（案件）があるのですから、両方できればよいし、片方を無視できると思えば無視すればよいのです。
無視するかどうかは、経営者の判断で技術者がする判断ではないと思う。技術者は必要になる日のために自己研鑽はすべきですけれど、それと顧客の便益とはまったく別次元のお話です。
もちろん、わたしは社内的にはどちらも無視することは許さないのですが（笑）、他人に変えた方が良いというほどの差はないでしょう。
ところが、同じ（最善を尽くす）感覚で見積もっても、SQLでできることはSQLで処理した方が絶対に早い。どんなに効率的に書いてもSQLの方が処理も速い。
これには、どんなにがんばっても超えられない壁がある。
こんな風にできれば、コーディング30分、テスト資料作り含めて0.5 日で終わります。一般的な開発（Java、VB6、.Net、PHP、Ruby ……）では2～5人日。0.5 日対、2～5人日って400～1000％の差になるのですけれど……。
20～30％の差が猛烈に気になって炎上するぐらいなのに、400～1000％の差が気にならない理屈が分からない（ちょっとしたレトリックが入ってますけどね）。
そもそも、VB6しかないところで、「.NETで！」言ったところで始まらないけれど、RDBMSは基本的に導入済みなんだから、ちゃんと使ったらいいじゃないですか？ 他に余計なツール（O/R何チャラとか）すらも要らないですよ。
早くできても、あまり給料に差が出ないサラリーマン感覚では分からないかもしれませんが（この給与体系が技術者にはそもそもおかしい）、たとえばタクシーと同じに考えれば分かるでしょう。目的地に着くのに何倍も時間が掛かって、何倍もの料金になる。感覚的には「右折は怖いんです」って左折だけで行けるルートを通るぐらいの差です。
顧客に提供する成果物も明らかに違うのに、プロとしてそこに問題意識がいかないのはなぜ？
もちろん、左折と直進だけで到着する目的地もあるけれど、そんな屁理屈ばっかり聞いていると、社長として金払う立場になったら猛烈に腹立つよ～～。
上流の技術者ってのは、タクシーの運転手をナビゲートする立場にあるのですが、これも左折だけでルートを探そうとする。左折だけではいけないときには、客をいったん降ろして（これが一番むかつくのね）客に横断歩道を渡らせて、対向車線にいる別のタクシーに乗せてしまうとか、目的地を変える交渉をするとか、そんな設計ができる人がすばらしい技術者って呼ばれてたりするけれど……。空気も読まず、鬼の形相で「右へ曲がれや！ コラぁ！！」って言うからな～、わたしは。
日本中の技術者にケンカ売ったかな（苦笑）。
右折する文化のない人たちにはなかなか理解できないと思うけれど、右折できる人が、右折しないタクシーに10年も乗ってたら誰でもキレると思う。
VB4のころからSQLを使っているけれど、スキルチェンジはOracle9i、SQLServer2005からのOLAP関数だけですからね（他の今後出てくるであろう、SQLの言語的な追加機能は母言語にやらせた方が効率的と思う）。VBやったり、Delphiやったり、C#やったり、Javaやったり、PHPやったり、他にもいろいろやってきたけれど、SQLはずーとわたしの中ではメインにできてきた。VB6 → .NET 程度の違いで騒ぐぐらいなら、極力、言語の切り替えの影響を排除するためにもSQLにロジック入れるべきですけど……。
この後も、SQLの方がある程度、息が長く使えると思います。
SQLが消えるなら、1000％をさらに何倍も超える生産性のものが出てくるってことですから、そのときは完全にEUCが実現されてプロが要らなくなっていると思います。
煽ろうとどうしようと、そう簡単に変わらないのですけどね。
嫌味なことを言うと、差がありすぎると儲からない。「時代の先を行き過ぎる人は評価されないもの」って慰めてたいところですが、「10年以上前の技術で喰ってるのに」って思っているので、先に行ってるつもりがまったくなく、慰めにもならない。
「技術者が社長になってもうまくいかない」って典型ですな、本当にエリック・シュミットに来て欲しい（笑）。
コメント
アイ
社長より優秀な人材に囲まれて経営できるようにもっていきたいですね！
「社長はもう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に交換すればパフォーマンスが上がるとだけ考えています。
ですからマルチコアに買い換えてもパフォーマンスが上がらないであろうVB6はお客様の心証を著しく悪いものにします。
それはずいぶんな言い方ですね。
VBだろうが、Javaだろうが、.Netだろうがコンポーネント化して再利用していますよ。
でなかったら、DLLヘルなんて気にする必要もないでしょう。
VBでできないのは継承ぐらいで、他は効率の差はあっても大体できます。
VBを使い切れてなかったから、桁違いに思うのではないでしょうか。
oumi
ちなみに、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をやっておいて損はありません。
ご忠告有難うございます。
思い当たる節あります。
私は自分に全く自信がないので、相手の理解度を確認せずに、
相手は必ず自分以上の知識や技術力があると思って発言してしまいます。
それがもとで時々会話がすれ違う時があります。
反省します。
ちょっと興奮しすぎましたので反省し、今度の記事に関してはこのコメントを最後にします。
失礼致しました。
NOCS
終わっているようなので、恐縮なんですが、温度差は開発者目線とビジネス目線の差だと。
どんな道具でも慣れた人は生産性が高いのは当然。
最新の道具が効率良いのも当然。
全ての業務が新しい道具に置換でないのも当然。
諸事情で古い環境を使い続けなければならない事もある。
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をちゃんと使っているならすぐに慣れるはずです。
そんなレベルの低い話をしているつもりはなかったし、まさかとは思いますが、そこまで噛み合ってなかったとしたら、ちょっと反省。
oumi
もっと燃やしたいスレ主の意向のようですから・・・
>VBと.Netって、継承とか、インスタンスの扱いとか、ちょっとした記述の違いぐらいでしょう。
これは、作為的に地雷おいたんですよね？
そして、これにこそインドリさん、物申してほしい（本当に）
あ～り～
>すべての変数をGlobal（Public）で宣言【しなさい】と書いてある
分かります・・・いや、分かっちゃダメですね。
ちょっとした一回きりツール（じゃなくてもかな？）ならGlobalでやります。
制御するまでもなかったり、独自な便利ツールで考えるのも面倒ですから。
いや、本題の感想を。。。
VBとか.Netとかどちらでも良いと思います。
というよりJavaでもCOBOLでも。
業務システムであれば、インターフェース、パフォなど含め総合的に品質がよければ。
品質って何？というのは省きます。一般的なものと思っていますから。
あと、コストも大事ですかね。
ランニング、イニシャル、あと開発の。
総合的に判断して何でつくるのか？というのが決まるのではないかと思います。
新しいものが便利で能力も向上しているというのも一理あります。
ただ、VBでもクラスが作れて、DLLにすれば再利用も可能ですし、何が何でも
.Netがよい！とは言い切れないと思います。
会社全体（プロジェクト全体かな？）のスキルも関係するものです。
あとは、新しいものを吸収していき、製品・・・いや、商品、サービスとして外に
出せるレベルであれば新しいものに切り替えればいいのかな？と思います。
いきなり試験的に商品にするとなると、会社として覚悟があればいいのでは。
とコラム＆コメントを読んでの感想でした。長くてすみません。
私の発言は気にしないでください。
まぁ、C#を「#include がないＣなんてＣじゃない」と毛嫌いしている
Javaerな私が大きなこと言えませんが・・・
jkl
インドリさんを相手する皆さんの懐の広さには、頭が下がります。
インドリさんの捨てゼリフ･･･ひどすぎますよね。
http://d.hatena.ne.jp/busaikuro/20090602#c1244714274
あ～り～さん、ども。
本当に、VBだろうが、.Netだろうが、Javaだろうが、COBOLだろうが、よいのです。
顧客の要件が満たせるならよいのです。
私がこだわっているのは、RDBMSを導入するならちゃんと使い切った方がいいということです。
インドリ
最後って言っておいて済みませんが、もしかして誤解しているのではと気になったことがありますので書きます。
もしかしたら誤解されたかもしれませんが、
>日本は現実を知らない＝技術を知らない人が机上の空論で設計します。
これは日ごろ生島さんがおっしゃっているSQLを忌避する方々の事です。
もしこの部分に誤解を受けているのであれば嫌なので補足説明しました。
chara
私は、ソフトウェアの開発者から、今は研究者としてやっているのですが、こういう議論でいつも感じるのは、「日本の技術者は、『計測』せずに『感覚』だけで勝負しているなぁ、ということです。
データに基づいた議論でなければ、あまり意味はなく（極論です）、感覚だけの議論は、居酒屋の議論と言われてもしょうがないと思います。
何パーセントという議論をするなら、そういうデータをとって、示すべきです。日本のソフトウェアエンジニアは、計測することをいやがる人が多すぎるような気がします。もっともっとデータを取って、定量的に議論できるようになると、米国なんかへ行って、学会でこんなデータが出てるんだぜ！とかいってかっこよく日本の開発プロセスの良さをアピールできるのですが、いかんせん、データがないと何を言ってもあいてにされません。むにゃむにゃ。。。
NOCS
>>日本は現実を知らない＝技術を知らない人が机上の空論で設計します。
>(インドリさん)
技術は知っているに超したことはないが、経営判断に細部の技術は不要。
効率のよいＳＱＬは開発を早めるが、効率の悪いSQLを大量に書かれるよりは、ＩＳＡＭで順次処理したほうが確実に安定する。
製品の品質は、開発効率ではなく、安定な品質。
安定しない.netのアプリより安定した旧VBの方を高く評価するのは、間違いではない。
ころころ言語仕様や動作仕様が変わる.netは、開発者は面白いのだろうが、長期スパンで見れば不安要素満載。
VS2003の教育が一通り終わったと思ったら、 VS2005/VS2008だという。VS2003の開発要員育成に数年費やしたあげくが時代遅れだと言うのか。
VS2003学習投資を回収せずにVS2005/VS2008へ投資しろ、しかし直ぐVS2010が出るから、VS2008は陳腐化するというのでは、イタチごっこだ。
企業は安定した収益を確保するためには、従業員に不満を強いることもある。全員に最新技術を習得して貰うのは、現実性はない。
それ以前に、最新技術が安定期に入る前に、消滅してしまう面もある。消滅するかもしれない物に費やす余裕は何所もない。
.netやJavaという言語機能は、物理実装面の話で、業務設計・論理設計のフェーズでは言語知識は足を引っ張るだけで邪魔になることもある。
大工知識や溶接技術だけでは民家は造れても高層ビルは造れない。
高層ビルの設計者は大工知識は必ずしも必要ではない。
優劣の問題ではなく知識のバランスの問題。
インドリは現場知識は相当なスキルが有るようだが、業務・運用知識が少ないような印象を受ける。
あちこちで炎上しているのもそれが原因と思われるが如何。
charaさん、ども。
おっしゃるとおりで、計測可能な案件を探しています。
ただ、研究者じゃないので残念ながら研究だけを目的にはできません。
実務者は顧客に納めなくてはならないものは研究成果ではなくシステムで、そこに研究費は乗せるわけにはいきません。
余程大きな会社の研究部門であれば、研究費を出せるでしょうけれど、実務屋からは結構批判を受けるでしょう。
それは、研究成果を出すための仕事と、顧客の満足を得るための仕事は根本的に違うからです。
NOCSさん、ども。
おっしゃるとおりです。
> 効率のよいＳＱＬは開発を早めるが、効率の悪いSQLを大量に書かれるよりは、
> ＩＳＡＭで順次処理したほうが確実に安定する。
で、私が話しているのは、SQLはVB6よりはるかに古い10年以上もっている枯れた技術で、VS2010になってもおそらく問題なく使えるでしょう。
VS2003、VS2005、VS2008と教育費を掛けるのに、なぜ一番変化の少なく、効果的なSQLの教育がおろそかなのか？
ってことを話しているのです。
saki1208
saki1208です。
乗り遅れた感が...
>> 効率のよいＳＱＬは開発を早めるが、効率の悪いSQLを大量に書かれるよりは、
>> ＩＳＡＭで順次処理したほうが確実に安定する。
>
>で、私が話しているのは、SQLはVB6よりはるかに古い10年以上もっている枯れた技術>で、VS2010になってもおそらく問題なく使えるでしょう。
>
>VS2003、VS2005、VS2008と教育費を掛けるのに、なぜ一番変化の少なく、効果的な>SQLの教育がおろそかなのか？
SQLの教育というよりは、RDBMSに対する苦手意識とかじゃないですかね。
それこそ、今の中堅以上の社員が入社した頃は汎用機は別にしても、PCではISAM
が一般的だったでしょうし、やればできるでしょうけどSQL書けない人が多いのも
事実です。若手にSQLが教えられる中堅も少ないのでしょう。
# 実際は自分たちの解らない言葉で会話されるのがいやだったりして...
ちょっと難しいSQLを書くと「見る気がしない」とかって発言が多いですもん。
わざわざ単純なSELECT文を書いてFETCHしながらループしてみたり...
# それが適している場合も極稀にありますけどね。
chara
ええと、なんとなく誤解があるかなぁなんて思ったりするので補足だけさせてください。
私は大学などの研究者ではなく、企業の研究者で、開発プロセスの改善をしたら、どれだけ生産性が上がるのか、どれだけ品質が向上するのかということを定量的に提示することを求められている立場です。
そういう立場で、見ると、日本のプログラマは、計測されることをいやがるなぁという雰囲気をすごく感じます。米国のプログラマは、Welcomeなんですよね＜計測。俺は、すごいぜ、的な。
だから、研究目的で特別に計測するのではなく、実際の現場での生産性や品質を定量的に把握するのが当たり前、ということです。お客様に、品質尺度を説明するためには、データを提示してご説明するわけで、そういうための計測です。目的は、お客様とのWin-Winにあります。
ですので、「研究成果を出すための仕事と、顧客の満足を得るための仕事は根本的に違うからです。」とおっしゃられることには少し異論をはさまさせていただきたいと思うわけです。
（十分にご承知の事だと思います。蛇足で、失礼しました。）
chara さん、ども。
> 目的は、お客様とのWin-Winにあります。
たぶん、実務者と、研究者と、お客様とWinのバランスがズレてるから、喜ばれないのだと思いますよ。
それは経営者の責任ですけどね。
saki1208さん、おはようございます。
その苦手意識は、VB6 → .Net などとは桁違い（笑）に大きなものなのですね。
VB6 → .Net のスキルチェンジに掛かったコストは、チェンジしたプロジェクトで回収できるものではないでしょう。２つ３つのプロジェクトで回収できるかどうか分かりません。
（必要経費と考えるのでしょうけれど）
しかし、SQLはそのプロジェクトで回収できるほどの差が出ます。
次からは利益に直結します。
実は簡単に乗り越えられると……。
この声はなかなか届かない。
本当は、苦手意識じゃなく「今まで何してたの？」を一度、認めなくてはならないので、それだけは避けたいということなのです。
私も分かって言ってるので、ほめられたことではないですね。
mayo
mayoです。
前回に引き続きこんなに盛り上がるコラムはすごいですね。
私の意見も一つ書いておきます。
もう見られないかもしれませんがね（笑）
今回は生産性のお話しが出ていますが
VBと.NETでは生産性が20％上がるというのは
理解できません。
charaさんの言われるように、生産性の向上を示すには
計測を行い、結果をまとめないと、議論すべきではないと思います。
その点でいえば、生島さんの「20～30％以上の差がつく」と言われるのも理解できませんし、
インドリさんの「生産性が10倍以上、上がっています。」も理解できません。
今回でVB vs .NETのコラムは終わるそうなので
どちらがいいかと思うところは、やはり.NETですね。
RFPを頂いて提案する時には工数削減もさることながら
・システムの寿命について
・セキュリティ
・稼動率
・ＤＢサーバーの隠蔽（情報漏えい対策）
・運用費（人件費込み）
など、「生産性がいいからVBでいきましょう」だけで
提案は通りません。
VBでは負荷分散、ＤＢへの直アクセスの制御などできませんよね。
VBのマイクロソフトのサポート体制は、今後もばっちりですとも言えませんよね。
VBでは.NETようにモジュールの配布が簡単にできませんよね。
上の三つはインドリさんが言われていた「出来る事は.NETの方がはるかに上」を
自分なりにわかりやすく書いたつもりでもあります。
間違っていたらインドリさん訂正お願いします。（笑）
今後、我々ＳＥ（？）に要求される事はどんどん上がっていきます。
それに対応するにも私は無理にでも.NETでの開発を行うべきだと思っています。
長文すいません。
研究と言っても、平均が取れるほど試せるものではありませんし、どのレベルでエビデンスが要求されるのか分かりませんが……。
20～30％というのは、同じものを作ったときのコーディング量の差と、IDEの出来で出しているので、両方ともに十分に慣れた技術者で比べれば、機能にもよりますが、大体そのあたりに落ち着くと思います。
SQLの方は、出来ない人は無限大の開発時間になるので参考になりません。
演習問題で15分で出来るという方が登場したので、他の言語で作ったときの差が、論理的な生産性の違いと言えるでしょう。
> VBでは負荷分散、ＤＢへの直アクセスの制御などできませんよね。
工夫次第と思いますけれど？
> VBのマイクロソフトのサポート体制は、今後もばっちりですとも言えませんよね。
本文に書いたとおりです。
> VBでは.NETようにモジュールの配布が簡単にできませんよね。
私は出来ていたので工夫次第ではないでしょうか。
出来ないと思う人は.NETでもいいと思いますよ。
私はVB6が良いといってるのではなく、要件に合えばなんでも良いということで。
「新規はダメとか」「ダメという理由がサポート云々」というのは、この業界のマッチポンプでしかないと。
個人的には、.NET使ってよ。うちのグリッドを買ってよ。
なのですけどね。
mayo
>20～30％というのは、同じものを作ったときのコーディング量の差と、IDEの出来で出しているので、両方ともに十分に慣れた技術者で比べれば、機能にもよりますが、大体そのあたりに落ち着くと思います。
この話しは、各自の感覚のものなので、否定も肯定も致しません。
>> VBでは負荷分散、ＤＢへの直アクセスの制御などできませんよね。
> 工夫次第と思いますけれど？
>> VBのマイクロソフトのサポート体制は、今後もばっちりですとも言えませんよね。
> 本文に書いたとおりです。
>> VBでは.NETようにモジュールの配布が簡単にできませんよね。
> 私は出来ていたので工夫次第ではないでしょうか。
サポート体制についてですが、.NETとVBを比べてマイクロソフトは
どちらが長くサポートしてくれる可能性が高いでしょうか？
の返答が答えになると思います。
他の二点ですが、工夫次第でできるんですよ！
ＤＢの隠蔽も、モジュール配布も、負荷分散も
いやーやったやった。
でも工夫しないといけないんですよ。
配布するにもモジュール配布プログラムを作成しないといけない。
モジュール配布プログラムのバグが発生した時には、日本一周旅行ですね。
この辺りは本当に苦労しました。
VBからASPを呼んでごにょごにょとか・・・
生島さんの言われる通り、生産性が20％向上したとしても
配布モジュールを一所懸命作成していては、あまり意味がないのでは？
それを、標準で実装している.NETがあるのであれば
それを使用するのは当たり前なのでは？
と思った意見です。
但し、一部署でしか使わないシステムなんかはVBでもいいと思います。
要望、用途に合わせるというのは正しい事だと思います。
私の例は、お客さんの要望レベルが
上がってきているのを、私自身が最近感じた為です。
特に情報漏洩対策に関してはかなりきびしいです（泣）
> 生島さんの言われる通り、生産性が20％向上したとしても
> 配布モジュールを一所懸命作成していては、あまり意味がないのでは？
それはちょっと勘違い。
.NETの方が20～30％上って言ってるのですけど……。
でも、慣れと能力で簡単にひっくり返るぐらいの差でしかないので、どっちでもお好きな方で良いと思いますよ～。大騒ぎする方が……。
mayo
>それはちょっと勘違い。
>.NETの方が20～30％上って言ってるのですけど……。
これはすいません。
私の勘違いでした。
>でも、慣れと能力で簡単にひっくり返るぐらいの差でしかないので、どっちでもお>好きな方で良いと思いますよ～。大騒ぎする方が……。
これも謝ります。
特に大騒ぎするつもりもありませんでした。
私が言いたかった事は
・VBとVB.NETを言語レベルだけで判断してしまい、
ほとんど一緒とする認識は間違っていると言うこと。
（ADO.NET、メモリ管理の向上、オブジェクト指向の完全導入など）
・.NETはVBでみんなが苦労した点を考慮して作成されているものなので
できるのであれば使用した方がいいと言う事。
・生産性の良し悪しでは今後のシステム要件は満たせないという事
これまでのコラムを読まして頂いて、その辺りの話しがなく
議論されている感じを受けたものですから。
VBを使い続けることが悪ではないと思いますが
いつかは来るサポート停止の前に早めに
お客さんも技術者も含めてバージョンアップを
するべきだと言うのが私の意見です。
led
色々な意見・視点が非常に参考になりました。
私は生島さんのコラムは、上流工程を担うものが効率化云々を考えるのであれば、お決まりの1手法に依存した見積もりをするのではなく、下流含めたの色々な視点、知識を持って最善の方法を「選択」すべきだという話だと思って読ませていただきました。
SQLも言語の一つと考えれば、要望整理段階でその仕様を満たすアルゴリズムが自分の手持ち札のなかでどれだけ早くひらめくかという話で、確かに最近の上流工程に携わっている人の中で、即そのように頭を働かせて受注したあとの社内方針の設計が出来る人が少ないように思います。
下流でも、なんで皆さんこんなにVBと.NETに拘るのかとんと解りません。
私も両方作れますが、20～30％の見積もり差に収束するというご意見はもっともだと思います。収束できなければそれは下流の質が悪いという判断です。
どんな言語だろうが、それほど詳細設計にそれほど差を感じません。
下流と上流でパックリ2つに別れちゃったおかげで、それぞれの質が下がってきているのが問題ですかね。
だから、質の悪い下流の人は「言語」にやたら拘るし、質の悪い上流の人は規模を「固定計量」してしまうから、両方にまたがる視点を持つ人はレアもの扱いされてしまうのではないでしょうか・・・・。
最後に「SQLの方が効率通い」論ですが、この手のが積み重なったときの話をサラリとされていますが、その際の効率化を設計できるレベルが下流にあるのなら、別言語でもデスマーチにはならんと思いますので、私としては1000％の差が出るのは結局上流部分で変な仕様を定義されてしまう点がデスマーチの序曲なのだと思っています。
色々考えさせられたので長文になりました。
失礼しました。
あ～り～
mayoさん
>生産性の良し悪しでは今後のシステム要件は満たせないという事
個人的な意見ですが、言語によってシステム要件が満たせない時点で
その言語は選択肢から外れるため、議論できないと思います。
要件、品質が満たせることが議論の条件かと。
>いつかは来るサポート停止の前に早めにお客さんも
>技術者も含めてバージョンアップをするべき
現行の言語、新言語で同様の要件、品質が満たせる場合、
あとはコストによってバージョンアップすべきかを判断するのでは？
費用対効果で、結構違いがでると思います。
現行の言語が品質、要件、コストすべてが勝るのであれば
今変更する必要は無いと思います。
品質、要件について、新言語なら付加価値があるとなると
コストが高くなってたとしても考えものですが。
あ～り～
追加です。
上でコメントもしましたが、私は言語はなんでも良いと思っています。
重要要素は別の部分ですから。
ただ、古いのをやめて新しいものにすべきかと考えた際の思いです。
mayo
あ～り～さん、すいません。言葉足らずでした。
バージョンアップとはVBを使い続けることに固執せず
.NET(新しい言語)を選択するというのも入れましょうと言うことです。
生島さんの事ではないです。（笑）
いまだにVB(古い技術)だけしかしない技術者、
させない企業に対しての思いです。
今すぐバージョンを上げろというわけではないです。
その他の意見については、捕らえ方考え方がありますので
これ以上のコメントは控えておきます。（笑）
mayoさん
謝られるほどのことでもないと。
mayoさんが大騒ぎしているのではなく、このコメント数がなんとも、それほどの大ネタか？とびっくりしています。
ledさん
> 下流でも、なんで皆さんこんなにVBと.NETに拘るのかとんと解りません。
> 私も両方作れますが、20～30％の見積もり差に収束するというご意見は
> もっともだと思います。収束できなければそれは下流の質が悪いという判断です。
> どんな言語だろうが、それほど詳細設計にそれほど差を感じません。
なかなか厳しいご意見ですが……ですよね～。
> 最後に「SQLの方が効率通い」論ですが、この手のが積み重なったときの話を
> サラリとされていますが、その際の効率化を設計できるレベルが下流にある
> のなら、別言語でもデスマーチにはならんと思いますので、私としては
> 1000％の差が出るのは結局上流部分で変な仕様を定義されてしまう点が
> デスマーチの序曲なのだと思っています。
おっしゃるとおりです。
一般論ですが、COBOLerが結構上流にいますけれど、彼らは業務知識はあるけれど、UIとか最悪です。SQLも勉強しません。
上流、下流じゃなく、UIをやるか、SQLをやるかどちらかにしてほしい。
あ～り～
mayoさん
各人の意見ですので謝らないでください。
こちらこそ申し訳ないです。
生島さん
言語ひとつで色々と意見があるというのがこのコラムでわかりました。
勉強になります。
そういえば、いつか「基幹システムがWebである必要が・・・」
ってコメントしてませんでしたか？
これも白熱するかもしれませんね（笑）
決して煽ってませんよ。念のため。
あ～り～ さん、mayoさん。皆様に謝罪です。
VB6なんて枯れた技術なので、それをあえて選択するところは【VB6を使い切ってるはず】という無意識の前提で話していました。
もし、【型を宣言しなくてもよい】とか、【DLL/OCXなんて作らない】というようなところを前提にしているなら、私の前提が間違っていたということです。
それでも、顧客の要件に合うなら、間違っているとはいえませんけどね。
VB6も使い切っていたら、.NETにしても、システム全体で見たら誤差の範囲に収まってしまいます。誤差の範囲でスキルチェンジにかかるコストを回収するのは大変です。
不況の中ですから、営業面を重視して決めるべきだと思います。
（顧客が、新しい物好き、サポート切れを嫌うかどうか）
SQLなら、VB6でも、.NETでも、Javaでも、PHPでも活かせるのに……。
くどいか。
mayo
すいません。最後といいながもう一言だけ！
>一般論ですが、COBOLerが結構上流にいますけれど、彼らは業務知識はあるけれ
>ど、UIとか最悪です。SQLも勉強しません。
これは同感です。あまりに的確すぎて笑いました。
saki1208
saki1208です。
>もし、【型を宣言しなくてもよい】とか、【DLL/OCXなんて作らない】とい
>うようなところを前提にしているなら、私の前提が間違っていたということです。
多いですよ。こんなとこ。
私の周りではさすがに前者はないですが、後者についてはほぼそんな感じです。
# でも前者は数年間にあったな。
# 「"On Error Resume Next"は書くなと」口を酸っぱくして何度も言ったのに
# 「予定通りに動きません」でソース見せてもらったら、各ブロックの先頭に…
意見には個人差があります
情報システムの運用管理を担当している者です。
こちらをご覧になっている方は開発者の方が多いかと思いますが生産性
(開発時のコスト)だけでなく、ぜひ実運用の立場(経営視点・実担当者視点、
運用コストを考慮)に立った開発をして頂きたいと思いましたので意見を
述べさせて頂きます。生島さまのご意見には大賛成です。
【結論】
１．言語は何でも良いが、SQL言語は活用した方がいい。
２．生産性よりも運用時の性能と品質、コストを考慮していただきたい。
【言語について】
アサインされたメンバーだけでなく保守を行う者にとって扱い易い言語
を選択して頂くことを願います。さらには5年、10年単位で扱えるものを
希望いたします。２～３年経って解説技術本が入手できなかったり、逆に
内容が古くなり使い物にならないなんてものは望みません。また、稼働
ハードウェア環境に制限がある場合、門前払いにしたいくらいです。
OSのUPDATEをしたとたんに動かなくなったり、新しいOSでその時の
ハイスペックの機器でないと動かないなんてものも望みません。
オブジェクト指向言語がよいという話しは表面上賛成いたしますが、
それは使いこなせた場合の話しであって、使いこなせる方は極々僅か
であるというふうに思います。ポリモーフィズムやデザインパターンを
使いこなすのはもちろん、MVCを活かした作り込みを期待します。
一方で、コピペやグローバル変数なんてのは以ての外です。
.NET,JAVA等々ありますが、本当のオブジェクト使いの方は数%も
いないのではないかとすら思います。使い手がその様な状況下では
例え.NETが30%生産性が良かったとしても品質に大きな不安が残ります。
VBに関しまして、かつてはオブジェクトといいながら継承すらできない
状態でしたのでオブジェクト「指向」言語とは呼びたくないです。
その点、SQL言語は数十年前の規格でもSQLだけではできないことも
ありますが、ロジック上は十分すぎるくらいの事ができます。
【処理性能について】
生産性の点での議論がなされてきましたが、処理性能も重要かと
思います。以下同一ハードウェア下で 10,000 % 処理性能を上げた
実際の事例です。
delphi1.0で書かれた月次会社業績成績処理プログラムがありました。
処理翌日に経営会議資料を提供するものです。
SQL Server6.5を使い毎月稼働しているものでした。オブジェクト
指向言語を使用しており、SQL言語も使用しています。ただ1回の処理に
5時間かかっていました。各地営業所で17時までに入力し、締切後処理を
実行いたしますと終了は22時頃になります。ところが営業所での入力
遅延や処理途中でのアベンドで再処理を致しますと終了が終電を越える
時間になってしまうことがしばしばありました。直接の担当者である
経理の方はもちろんですがシステム障害時の対応を行わなければならない
担当者である私も動向を見守らねばならず、徹夜なんて事が良くありました。
そこで改善のため改修しました。改修にあたっては極力プログラム言語で
処理しないよう心がけ可能な限りSQLで処理するようにいたしました。
使った言語はDelphi5です。言語で処理したのは主にGUI部分のみでした。
結果、処理速度は冗長に経過表示等を行ったにもかかわらず わずか
3分に短縮されました。データベースチューニングを行えばさらに
処理速度が向上したかと思います。
処理時間 5時間(300分) ---> 3分 に短縮。(10,000 %、100倍のスピード)
開発にかかった時間はおそらくテストを含め半分以下と推測されます。
品質も大幅に向上しました。何より、現場の担当者がとても喜ばれました。
改修後は帰宅前にクリックしてトイレに行って戻ってくると終了し、
処理結果の検証も行えて余裕を持って帰宅できる状態になりました。
このような結果の前では「VBと.NETが・・・」という話は足元にも及ばず、
なんでわざわざ難しく書くの? と言う方が先決かと思います。効率ではなく、
処理に応じて効果的な技術を選定して利用するというのが経営にはもちろん、
運用担当者にとってもありがたいことかと思います。技術は枯れた技術でも
新技術でも一向に構いません。性能が手がかからず効果的であることを望みます。
生産性よりも運用時の性能と品質、運用コストを十二分に検討していただく
ことを切に希望します。
運用担当者さま、ありがとうございます。
5時間も付き合わねばならなかった担当者は、本当に犠牲者ですね。
> このような結果の前では「VBと.NETが・・・」という話は足元にも及ばず、
ユーザから見れば、本当にミジンコぐらいどうでもいいことだと思います。
大体、言語の方にロジックを寄せているプログラムは、SQLに寄せれば全体の工数が半分から3分の1に、パフォーマンスは20～100倍になります。
（よっぽど下手糞が作ってると1000倍を超える差になることも）
そんなことはそれこそ10年も前から言われていることですし、私も言い続けていますが、
「とりあえず、ループさせて作って遅かったらSQLに直せばいい」
という考え方が業界では一般的です。
私には理解できません。
上流、下流という切り方の問題と、実際にプログラムをつくる技術者が「人月いくら」という売り方になるので、生産性が悪い方が儲かるということから、なかなか変わらないのです。
そんな悪習をつぶしてやる！
って思っているけれど、私の方が先につぶれるでしょう。
WEBシステムについてもそのうちに書きます。
# 「"On Error Resume Next"は書くなと」口を酸っぱくして何度も言ったのに
# 「予定通りに動きません」でソース見せてもらったら、各ブロックの先頭に…
こんなことをするところもあるのね。
これって、Stringの変数とかテキストボックスにNullを入れるとエラーが起きるのを避けてたりして（笑）
が、意味をわかってない人には怒るけれど、私もVBで下品な書き方をよくします。
テキストボックス.Text = .Fields(”項目").Value & ""
「変数を宣言しなくてもよい」、は下品を超えて問題ですが、「暗黙の型変換は便利」と意味がわかって利用するなら良いと思います。
もちろん、Null & 文字列 は 文字列 になるということを利用したものですけれど。全部にIF文書いているのを見たことがあるけれど「関数知らんのか？」ってびっくりしたな。
世の中は広い。
ジーツー
生島さんききたいです。
もし私がジーワンシステムの社員だったとして、生島さんくらいにSQLを使いこなせるようになったら、お給料いくらくれますか？
月80万円いただけますか？
どれくらいの金額が適当だとお考えですか？
また、ある会社の従業員から独立して経営者になられて、生島さんのお給料は上がりましたか？
とってもいい質問です。
そんなにはあげれないです。
給料はダダ下がりというか、ほとんど取ってないワーキングプアです。
完全に慈善事業になっています。
でも、80万ぐらいで妥当だと思いますよ。
そう評価されるように「業界を変えてやる！」って思ってやっています。
「馬鹿なやつだと笑わば笑え」って気持ちです。
saki1208
saki1208です。
意見には個人差がありますさん。
貴重なご意見をいただいていると思いますが、あえて反論させていた
だきます。
>また、稼働ハードウェア環境に制限がある場合、門前払いにしたい
>くらいです。OSのUPDATEをしたとたんに動かなくなったり、新しいOS
>でその時のハイスペックの機器でないと動かないなんてものも望み
>ません。
実現できればどんなに素晴らしいことかと思います。そのような状況
では、たとえば最近はやりの仮想環境等で構築されることをお勧めし
ます。
技術者としてもそのような制限は行いたくないのが本音ですが、基本
的に開発時に使用したレベルのOS、ハードウェア以外では動作保障
できないことが殆どです。
たとえば、ハードウェアの障害が発生した場合、メーカー製のPCであ
れば動作保障のされた部品としか交換を認めないと思います。それ
以外のものにご自分で交換されたりした場合にはハードウェアの保障
が切れますよね。極端な場合はメモリの増設等でも不可でしょう。
それで門前払いをするなら相手にしてくれるSIerはないと思います。
# 最近はこの限りではないようですが...
開発時点で出荷されていないものでテストをすることはできませんし
それに対する動作保障もできません。ましてや、OSの仕様が変われ
ばUPDATEによって動作しなくなるのは当然です。
ある程度、枯れた技術でならばそんなことはないだろうとお考えかも
しれませんが、お客様の要求は新旧織り交ぜた内容であることが
多いですよ。枯れた技術を採用した場合でもハードウェア的に許容
出来なくなったり、OSのサポートが打ち切られたり、対応するドライバ
がなく、インストールそのものが出来ない場合もあるのです。
# 私個人としては、なんとかして動かす方法はあると思いますが、
# 企業としてはそれを許容できないのです。
# だって、だれも責任とれませんから。
>ポリモーフィズムやデザインパターンを
>使いこなすのはもちろん、MVCを活かした作り込みを期待します。
ご自分でシステムの開発をされたことはありますか?もしくは、プログ
ラミングされたことはありますか?
もちろん、出来る範囲では設計でそのように検討すべきでしょうが、
プログラムはほとんどの場合、初めから完成系で出来上がるわけで
はありません。ましてや、VB6で多態性やデザパタなんて...
設計/作成している段階での仕様変更もありますし、テスト/運用中
での仕様変更もあります。たとえ仕様変更が一切発生しなかったとし
ても、初めから最終形で出来上がることはありません。
たとえOOPを駆使してもその限りではないのです。
いろいろと勉強されているようですが、リファクタリングという言葉
をご存知でしょうか?
多かれ少なかれ、プログラミング中はみんなこれを行っています。
# OOPでなくてもです。COBOLは違うでしょうけど...
しかし、最近の業界の状況としては、あまりに納期が短縮され、これ
を行う機会が殆どない状況です。
# 私の周りだけでしょうか?
お客様には基本的に関係のない話なんですけどね。orz
saki1208
saki1208です。
いや、ヤリづらいだけでVB6でもなんちゃって継承もできるし、ActiveXなんかを
駆使すればなんとなく近いことはできるのです...
普通にやったほうが手がかからなくて、誰でもメンテ出来るだけなんです。
saki1208さん、こんばんは。
たぶん、コメントのご担当者様は、自分で100倍のパフォーマンスに直されたのだと思いますよ。
それで、ものすごくSIerに不信感をもたれていて、OSのアップデートとかの話になっているのでしょう。ちゃんと話せば分かっていただけるでしょうし、saki1208さんのおっしゃることはもっともなのですけれど。
私はSIerとしてごめんなさいの気持ちと、それを納めたSIer！「出てこいや～！！」って思いが強いかな……。
saki1208
saki1208です。
後半部分はきちんと読めていませんでした。
すみません。>意見には個人差がありますさん
delphi1.0って、Ｗindows3.1?95?の頃ですよね。
その当時、GUIツールとストアドで単純なデータの追加を行う
プログラムを作成して性能比較をしたことがあります。
# 10万件だか100万件だか覚えていないですけど。
その差、なんと450倍!!
あまりにも単純な処理だったので参考にならない部分もありま
したが...
それ以来、少しでも重そうな処理は全部ストアドです。
わざわざ遅く作っちゃう間抜けもいますけどね。
sawa
うわー楽しい会話ですねぇ（まじめに）
私は社長ですが、プログラムも作ります。過去の資産引きづりのためVB6は使っていますし、VB.NET、C#.NET, PHPをお客様のニーズ別に使い分けています。
なぜこのページにたどり着いたかと申しますと
急にVB.NETで On Error Resume Next が効かなくなってしまい
調べていたところ（笑）面白かったので読んでしまいました。
また改めましてコメントさせて下さい。
wankun
まわりには、VB6erはたくさんいますが、私は良いテストツールがありRestが簡単に使えるので、.NET（3.5以上）の方が良いです。でも、Railsがフルスタックで、なかなかおしゃれに出来ているので、Rubyに心奪われています。んじゃ、Iron Rubyで.NETなんかでしょうか？？
意見には個人差があります
生島さま、皆様、
随分と間が空いてしまいすみません。諸般の事情で時間が割けなかった
次第であります。さて、反論・コメントもございますので追加コメント
させていただきます。少々読みづらく長文となってしまいますが、
開発者の方からの預ったシステムを運用する立場の者からの悲鳴位に
(ソースコード見てホントに悲鳴をあげることもよくありますが。)
受け取っていただければと思います。もちろん、OJTという名の研修
カット、人月のみによる評価、なんとなく厳しくなる納期が横行して
いるのも十分に承知の上です。運用管理の立場で、できるだけのことを
行った上でやはり問題の発生源を抑制したいとの考えからです。
仮想環境につきましては雑誌で頻繁に取り上げられる以前の2004年頃
から着手し、現在ではVMWareやXen 合わせて 20程の仮想サーバーを
稼働させています。主目的は障害時の迅速な復旧のためです。
仕方なく旧OSを稼働させなければならないというものもございますが
5%程です。基本的にはSIerに頼らず自前で構築しています。
インストールに関しましては過去からの累計で業務上だけでも様々な
OSを数百回はインストールしているかと思います。ドライバ云々と
いう話しもありますが、セキュリティ上の対応から例えばWinodws
UPDATEは当然行わなければならない状況で(それを推進する立場で)
開発時の環境維持はできません。
エンドユーザーからのパフォーマンス要求が厳しいため、ハードウェ
ア選定にあたってはメモリの速度はもちろん、バスの速度やCPU種別、
対応OS、インターフェース詳細まで確認し、普及技術で高い性能を
コストパフォーマンス良く出す様にしています。
「開発時に使用したレベルのOS、ハードウェア以外では動作保障
できないことが殆どです。」
というご意見に関しまして、それでもシステムを任されている私ども
運用管理担当者はSIerさんに扱っていただけないものを責任とって
「動かさなければならない」
のです。ハードウェアなら苦労したとしても部品入手をすれば良い
のでまだ救われます。(MACに依存したようなものを除いて。)
しかし、ソフトのバグは致命的です。最悪、再処理のためにプログ
ラムを書かなければデータ復旧ができない事もあり得ます。不具合
原因追求のためプログラムを読まなければなりません。応急処置の
ためにプログラムを修正・作成・稼働するという危険な事を短時間
で行わなければならないということもあり得ます。
それを避けるためには処理をプログラムに依存しない事が重要と
考えます。
引き継いだ時点で理想的な状況というのはほとんどありません。
幸いその辺を理解してくださっているかどうかは発注前にわかり
ますので最近では逆に力のあるSIerさんの選別(具体的には担当者
さん) ができるようになり、問題が少なくなっています。
(実力のある担当者さんは本当に僅少です。)
10,000%の処理速度向上は真に私がリファクタリング(というよりは
再作成)を行いWindows98時代(サーバー側はNT)に達成したものです。
Delphi1.0 はWindows3.1,Windows95時代のものです。
ちなみに運用管理を行っておりますが開発経験もあり、言語に関し
ましては他に機械語、アセンブラ、COBOL、VB(2.0～6.0の頃)、
Delphi、Perl、PHP等を使用しています。
仕様変更が与える影響につきまして、少なくともデータベースの
正規化を行わなければとても大変になるのは当たり前と考えます。
業務上あたり前のちょっとした出来事に対し「その変更は難しい
です。」とか「工数が大幅に増えます。」という理由をされる場合
をお見受けしますが、データベース設計をきちんと行っていれば
「了解いたしました。」と即答し、「データを変えるだけ」で
対応できる事は多々あるかと思います。
もちろん、GUI上の仕様変更はとても大変なこともわかっています。
ただ少なくとも「出力値」をみて「これ本当に正しい値なのかな?」
と不安になるような事は避けたいだけです。
仮に病院のシステムを手掛けたとして、体重から処方する薬の量を
計算するとします。また、患者さんのアレルギー情報から使用して
はならない薬をチェックしなければならないと致します。
そこに市役所の条例でGeneric医薬品を使用した場合補助が出ること
になり代替該当薬をチェックできる様に開発・・・
加えて、消費期限と在庫量を確認し事前手配のリストを作成できる
様にし無駄なコスト発生を抑えたいという要求がリリース前に他の
部署から・・・
プログラムで対処しましたらそれは大変でしょうがSQLなら比較的
簡単に必要な情報を枯れた技術で迅速に取得できます。もちろん、
そのためのデータベース設計がなされている事が大前提です。
ストアドを使う場合もカーソルを使わない様注意が必要です。
ぐちゃぐちゃ長文で書いてしまいすみません。ただ、ユーザーの
経験値は徐々にあがりSIerの実力を簡単に見分ける術を技術者
以前に身につける日もそう遠くはないと思っています。
意見には個人差がありますさん、どうも。
そうですね、ユーザの方がレベルがレベルが高いという笑えない状況も
増えてくるでしょう。
現状では、SQLで処理した方がコストがかかると主張するプロが多い
ですから、そんな現状を何とかせねばと思っています。
古い記事のコメントは他の人は気づかないので、よろしければ次に
書く記事にもコメントいただければ幸いです。
意見には個人差があります
生島様
>古い記事のコメントは他の人は気づかないので、よろしければ次に
書く記事にもコメントいただければ幸いです。
失礼いたしました。了解いたしました。
たけ
生島様
当方、個人向けパッケージソフトの開発をフリーで行っている５０過ぎのエンジニアです。このパッケージソフトは１０年ほど前にＶＢ６で開発をスタートしたもので、現在も改良を重ね食っていけるくらいの売上げがありますが、ここ数年来ＶＢ６をＶＢ．ｎｅｔにバージョンアップすべきかどうかで悩んでおりました。
今回の一連の論議の中で“後１０年位はＶＢ６が使えそうだ”、“既存のＶＢ６のシステムをＶＢ．ｎｅｔに移植するメリットはない”、“１０年後のリプレース先がＶＢ．ｎｅｔとは限らない”というのが私自身納得のいくものであり、今後もＶＢ６での開発を続けようと決心がつきました。
あえてコメントされるようなことでもないかとは思いますが数年来の悩みが消えてスッキリしましたので一言お礼を申し上げたくコメントでの投稿で失礼しますが、どうもありがとうございました。
生島様の益々のご活躍を期待しております。
たけさん、どうも。
積極的にリプレイスする必要はないのです。
ただ、営業的に顧客が新しいもの好きであったとき、取り損ねることがあり得ます。競合に勝つには「.NETも対応可能ですけれど、リプレイスしない方が安くつきますよ」という提案になる必要はありますけれど。