地方からの戯言

あなたがvistaに移行できない理由は本当ですか？

ルーターを購入しない理由が理解できない…

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

私がVistaに移行できない理由は本当に「ADSLモデム」なんですよ。
というのもこちらでは転居先で光が必ずある訳でもなく、ADSLも必ず使える訳でもなく、ましてやそう言った物を購入したいといっても・・・。

家庭内では発言力弱すぎるので（笑

私個人としてはとっととVistaにしたいのですけどねぇ。

VB6で開発して何が悪いのか、この内容だとわからない。
.NETに移行するにはそれなりの理由があればのことだし、理由がないのなら移行しなくてもいいだろう。
.NETの利点が理解できずずっとVB6のままということなら、その開発会社はそれまでのレベルということ。

XP MODEはWindowsOSの顧客が受ける価値を考えての機能。アプリケーション開発者のエゴで、なければいいなんて言うもんじゃない。

ビジネスでのシステムの寿命という考え方が欠如しています。
モデムやルータごときを買えない個人レベルの発想であると呆れて読みました。

その劇薬としてマイクロソフトが出した答えがVistaであったと思うのですが…そしてその結果、Windoes7でXPモードが追加されたと。

一度、ご自分が関わったVB6の案件をすべて新しい環境で開発し直すことを考えて下さい。
なんなら業務プロセスや開発プロセスを含めたシステム再構築でも結構ですが、その投資に見合う経営効果や全てをやりきる時間はありますか？おそらく基本は現行システムの単純移植になることでしょう。
そうすると、誰にも喜ばれない、動いて当然、お金も出し渋られる状況になることは目に見えています。こんな開発を強要することが健全な治療だと本気で考えているのですか？

動作検証だけで済むことがどれだけマシなのか。同じシステムを別環境で開発し直すことがどれだけ無駄なことなのか。
きっとその劇薬に一番苦しむのはあなた自身だと思いますよ。

本当にわずか数千円の買い物の決定権も無いのですか？
今時光もADSLも使えない所って…、どちらへ転居のご予定なんですか？
ご自宅にPCは１台だけ？
少なくともコンピュータに関する記事を書く方の環境とは思えません。
自分はインターネットに繋ぐ時には、様々な理由からPC１台でもルータを入れる事をお勧めしています。

正直言ってあなたの話は信じられません、失礼を承知で言えばウソを付いているように聞こえます。

VB6云々の件も突っ込み所満載ですが…、こちらは通りすがりさんにお任せします。

ビガーです。

arereさんのシステムの寿命って具体的にどういうことですか？
機能拡張をつづけていくとシステムボリュームが肥大化して保守工数が
リニアにあがっていくことなどを指していますか？
批判されるのであれば、ご自身の経験からの建設的な意見を述べるべきでしょう。

通りすがりさんの意見もどうかと思いますね。
>きっとその劇薬に一番苦しむのはあなた自身だと思いますよ。
苦しむのか楽しめるのかは、進め方次第です。
BPRか否かに関係なく、システム移行というのはリスク回避を目的に現実には
段階的に進めるものです。その際に投資対効果のある要件だけ選べばよいので
(まぁココが肝ですが)、健全な治療になりえます。

システム会社としては、受注のチャンスだし、お客様にとってもある意味チャンス。
※肝である要件の詰め方だけは、コンサル雇って勉強した方がいいかも。

VB6使いたちは、今時VB6を教える事のコストはどう考えているのだろう？
今の若い子は多分.NETやJavaを始めから使っていると思います。
もしそうでなくても、近いうちにVB6って何という新人が現れると思います。
その時の教育コストはどうするのでしょうか？
VB6を教え込まれる新人が可哀相・・・

ビガーさん
いろいろ失礼なことを申し上げますので、先に謝っておきます。気を悪くされたら申し訳ございません。

arereさんではありませんが、
日本情報システム・ユーザー協会(JUAS)の「企業IT動向調査2008」では
基幹業務システムのライフサイクルが平均14年とありましたね。
外的要因（経営環境の変化）によるシステム見直しを除くと、
もっと寿命は長くなると思います。

で、進め方の方ですが、そもそも投資対効果に見合う案件であれば、
別に放っておいても勝手に行われると思います。
私が問題として挙げているのは、投資対効果にあわない案件まで
「劇薬」によって移行を強制されることです。
システム会社は仕事を受注しなければそれで良いかもしれませんが、
ユーザはどうなりますか？投資対効果に合わなくたって、そのシステムが
使えなければ本業に差し支えますので、やらざるを得ないでしょう。
そんな仕事、誰が喜びますか？と言いたいのです。

また、要件を詰めれば楽しめるとおっしゃいますが、「システム更新」という
結論ありきのコンサルは不健全（手段の目的化）ではありませんか？
そもそも要件定義や業務刷新にはかなりの工数・時間・費用が発生しますし、
このような投資・刷新を行うことは経営的に大きなリスクにもなります。
ITシステムの多くは、乱暴な言い方をすれば間接業務の効率化ツールに
過ぎないのですから、その領分をわきまえることは大事だと私は考えます。

ビガーです。

>通りすがりさん
言葉が稚拙とは思いますが、ご容赦願います。

一般論としてのシステムの寿命は、指標になりません。
システムの寿命を判断する基準をarereさんはどう考えているのかを質問しています。
JUASの調査結果で再構築しましょうという話にはなりませんよね？

>ユーザはどうなりますか？投資対効果に合わなくたって、そのシステムが
>使えなければ本業に差し支えますので、やらざるを得ないでしょう。
>そんな仕事、誰が喜びますか？と言いたいのです。
今回話題のプラットフォームの関係上、いつかやらなければならない問題です。
どのタイミングでどこまでやるかが問題なので喜ぶ喜ばないは関係ありません。

その上での進め方についてですが、
>「システム更新」という結論ありきのコンサルは不健全（手段の目的化）ではありませんか？
システム更新ですべてを対応するというのは本物のコンサルはしません。
現状のシステムモデルからあるべきシステムモデルを明確化し、本当にシステム化が
必要な個所だけ(投資対効果が見込める)をシステム化します。
ここで重要なのは、ユーザも気づいていない要件を抽出しているということです。
そのため、放っておいても勝手に行われるレベルの話ではありません。

要は、いつか誰かがやらなければならないなら、ユーザにとってもシステム会社にとっても
有益に進めることはできるのでマイナスに考えてもいいことないですよね、
というのがいいたいわけです。

たくさんのコメントありがとうございます。
本来でしたら一つずつにレスを返すべきところですが今回は申し訳ありません。

今回の文末に書くようなプライベート環境についての指摘はできれば避けてもらえると助かります。北海道ではADSLが通じない場所というのは、地味に残っているんですよ・・・。街中だから大丈夫と思っているとそういう場所が出てくるのが怖いところです。それと後は個人個人の置かれている状況が異なりますから、物事の優先順位は変わる、というところです。

XpModeについては、もともとの提供理由としても「既存資産を利用するための最終手段」的なポジションであったと思います。ですのでそれ自体が悪いとは私も思っていません。それを用いて既存のままでいこうとする「開発側」が悪いというのが私の意見です。延命処置を最初から利用するくらいなら、環境を維持する手段を別途用意すればいいと思うんですけどね。それこそシステムの寿命を考えるにあたり、最初に考えることではないですか？

またVB6で構築したシステムの再構築を、と言われましたが・・・。
それが仕事として受注できたのなら「やる」でしょう。そしてその要件として「既存のシステムと同一であること」が、ユーザーとベンダーとで幾度も議論をした結果そうなったのであれば「そうする」でしょう。そして仕事となれば全力で対応するのが基本ではないでしょうか。
※自分が要件定義から関わることができる案件であれば、私は違う路線を模索します。

JUASの調査結果として公表されているものについても思うところはありますね。
この類の調査ですので難しいのは解るのですが、どうも調査対象となっている対象企業というのが「ある程度以上の規模を持つ企業」に偏っていると思います。ですのでとらえ方としては、アンケートを行い「4000社に送付してそのうち有効な回答のあった600近くの企業が考えている事」である、というところかなというのが個人的な感想です。

最後に通りすがりさんが指摘されました、

>その劇薬としてマイクロソフトが出した答えがVistaであったと思うのですが…
>そしてその結果、Windoes7でXPモードが追加されたと

という点ですが、VistaでもVB6はサポート対象ですので何ら劇薬にはなっていなかったと思います。劇薬となったのは開発側でなく「ユーザー側」に対して負担が大きかったところだと思います。そして初期段階で報じられる悪いイメージの数々が積み重なって、企業が移行する割合は低いまま今に至っているのではないでしょうか。

長々と書きましたが、今回は皆さんが思われるところをコメントしてくださいまして非常に嬉しく思います。私の文章はとても拙いですし、読まれる方が不快に思われることもたくさんあるかと思いますが、今後もご指摘等よろしくお願いいたします。

ビガーです。

たびたびすいません。1点だけ。

>※自分が要件定義から関わることができる案件であれば、私は違う路線を模索します。
私もSIerでソフトハウスがやるような仕事を経験しましたが、役割として要件定義に
関われなくても、要件定義ができるスキルがあれば要件定義者を巻き込んで意義のある
仕事ができました。
やはりこのあたりで開発する意味が大きく変わるのでチャレンジいただきたいと思います。
※私も常に模索中です。近々、コラムニストになる予定でその内お伝えしたいと思います。

おぉ、ビガーさんも書き始められるのですね。
期待して待っています。

ビガーさん、Ahfさん
なんというか、「開発側」と「ユーザ側」という視点・立場の違い（壁）があって少し不毛な気もしてきましたが、もう少しだけ突っ込ませてください。
ちなみに、私はユーザSEに近い立場で仕事をしている者で、正直私が発注する際にビガーさんやAhfさんのような姿勢の方に受注されるとちょっと困るなぁと感じています。そこを解って欲しいので、もう少しだけ。
（ちなみにまだ経験１０年足らずの若造です。気を悪くされたらごめんなさい）

・時間と資金は有限です。開発側は要件定義をしっかりやってお金もしっかり取って時間をかけて良いシステムを作りたいと思うかもしれませんが、ユーザ側は必ずしもそうは考えてません。あくまで優先は本業なので、それに迷惑をかけずに低コスト短期間低負荷で導入することが望まれることもあります。
・現行業務上問題なく、費用対効果の見込めないものまで「劇薬」とやらでシステム更新を強要させられることに関して述べています。よって、この場合のコンサルは本物だろうがなんだろうが「システム更新」という結論ありきですし、上記のような開発を求められる結果になる可能性が高い。だから不健全だと私は思うのです。

あと、「劇薬」とVB6の対応とXPモードの関連について誤読してしました。すいません。
VB6ランタイム自体はVista・7ともにXPモード関係無く対応していましたね。ただ、実際には問題があったからこそXPモードという結論にたどり着いたのだと思いますが。

こんばんは。

古い技術の延命は、可能性を奪う。ということが主題なのではないかと思いました。

車が良い例です。

２０年前から、燃費も性能も殆ど進化していません。
コンピュータ制御が当たりまえになって、いろんな部分で精度は上がりました。
ハイブリッドなど新しい技術も出てきましたし、
これから技術革新、というか全く違う技術が導入されていくでしょう。

ですが、安定して利益を得るために、
メーカーは燃料電池も電気自動車もバイオ燃料対応もずいぶんと先延ばししてきました。
やらざるを得なくなったらやったのでしょうが、
そうならないように政治的に圧力をかけたりしてましたから、
そのツケが経済危機と環境問題の合わせ技で一気に回ってきて、
根本的に考え方を変えなければ成らない状況にきています。
つまり、追い詰められている訳です。
そして長く世界一に君臨し続けたＧＭが破綻しました。
ＧＭの破綻は技術革新に力を入れなかった(入れられなかった)事が、最大の要因です。
労働組合との関係など、複雑な問題を抱えていたのは確かですが、
過去５年、業績の良かったときでさえ、新技術への投資は殆どしていませんでしたから、
自分で首を絞めたといって良いでしょう。

恐らく、そういうことにならないように、、、、
そうなるのは嫌だ、、、
という危機感をAhfは説明したかった。

古い技術の延命はエンジニアの魂を弱らせる。

ってことですかね。

ビガーです。

面白いくらい意図が伝わっていなかったので、これで最後に。

>通りすがりさん

>開発側は要件定義をしっかりやってお金もしっかり取って時間をかけて良いシステムを
>作りたいと思うかもしれませんが、ユーザ側は必ずしもそうは考えてません。
良いシステムを作りたい以上に意味のあるシステムを作りたいと考えています。

>あくまで優先は本業なので、それに迷惑をかけずに低コスト短期間低負荷で
>導入することが望まれることもあります。
進め方に関係しますが、お客様の事情が大前提にあることはいうに及ばず。。
本来ユーザSEに要件定義のスキルがあれば、開発側からやる必要はないので
どうぞがんばってみて下さい。

>「システム更新」という結論ありき
何度もいっていますが、「必要な箇所だけ」を見極める作業が要件定義なわけですよ。
「システム更新」ありきではないと何度もお話しています。

ちなみに私は、経験7年です。

何となくですが、
通りすがりさんは
割と先進的な大企業ユーザーの仕事が多いんでしょうか？

対してビガーさんは中小規模のユーザーが多いんでしょうか？

なんとなく世界観があってないような気がしました。

二つは基本別世界のような気がします。

通りすがりさんの状況はある程度理解できました。
「本業優先」や「低コスト短期間低負荷」というのはよく望まれることのある事だと思います。勿論私も「常に」システムの刷新を望んでいるという事ではありません。

限られた予算の中で効果の高い方法を。それが私の基本姿勢です。

ですのでWindows7がリリースされたからといって、それを導入することが絶対とは思っていません。私みたいに受託開発やパッケージ開発が主体の場合は「扱えるようになるのが絶対条件」だと思います。通りすがりさんのようにユーザー側に近い場合はそうとは言い切れないと思います。

一つお聞きしたいのですが、通りすがりさんはボリュームライセンス等は利用されていないのでしょうか？新OSに移行するためのコストが既存環境の維持コストよりも高いのであれば利用するべきだと思うのですよ。
ボリュームライセンスであればダウングレード権が利用できますので、即座に新環境に移行することを回避できると思います。

最後に三年寝太郎さんがまとめてくださった
「古い技術の延命はエンジニアの魂を弱らせる」
・・・凄く言葉使いが上手いですねぇ。そのセンスが欲しいです。

ビガーさん
ビガーさんの意図はあえてスルーしている部分もあれば、正直理解できていない部分も大きいと思います。
特に解らなかったのは、以下の点です。
・「劇薬」によってシステム更新を強要させられることは健全なのか？
・要件定義にかかる時間・コストをどう考えるのか？
・対象から外れたシステム及びその業務に対するソリューションは？
最後と言ったので、答えていただかなくて結構ですが。
ちなみに私からはビガーさんの考えはユーザの立場・時間とコストの重要性・要件定義という業務を甘く見すぎというのが感想です。スキルの問題では無いので、失礼な誤解もやめて頂きたいと感じました。

Ahfさん
ボリュームライセンスでなくてもダウングレード権は行使できたような気がしますが、私の話はそれとはちょっと違います。
サポート切れに伴う新OSへの移行は、情報セキュリティの観点から基本的に避けることは困難なのです。一方で、製造ライン等では未だPC-9801のシステムとか平気で動いたりしていますが、そういうシステムはネットワークから切り離すなど一定の処置を取っています。
「劇薬」は、ネットワークに接続する必要のあるシステム全てに対応を強要することになります。

また、新しい技術は現在進めているシステムに順次適用しています。業務上問題が出た際、そのソリューションとして見直すことが基本です。まぁ、サポート期間の長さという要素が大きく、新しい技術の内容そのもので選ぶことは少ないのですが＾＾；
そんな世界もあるのです。もっと厳しい世界も山ほどあるでしょう。
よって今回のAhfさんの記事は、失礼な言い方ですが「技術革新のために戦争が起きればいいのに」と同レベルの不謹慎さを私は感じました。

＃傍観者さんの指摘はちょっと驚きです。私は社内SEだけで千人規模という製造業で社内SEや社内コンサル的な仕事をしていた経験があります。見直すと確かに推測されるような内容を書いてますね＾＾：

ビガーです。

Ahfさんすいません。。
答えてほしいようなので(これ以上コメントを増やすのはどうかと思いますが。。)

>・「劇薬」によってシステム更新を強要させられることは健全なのか？
そもそも「健全」をどのように定義されていますか？
システムというものは、あるプラットフォームが前提で作られるものです。
システム更新を強要されるようなものを受け入れてしまった代償という意味でユーザ側にも
責任の一旦はありますよね？(こういう状態にならないように社内SEがいるのではなかと)

>・要件定義にかかる時間・コストをどう考えるのか？
RFPの質により大きく変わるし、どの程度の規模のシステムが相手になるのかで
大きく変わります。まぁ、実際の現場の感覚だと優先度の高い要件を洗い出したら、
その要件の実現可能性を保証する作業が入るので要件定義だけにコストをかけるというのは
しないものです。ドキュメント上でだらだらと要件やら分析をしている人たちもいますが、
それとは根本的に違います。
通りすがりさんは、どうやって要件定義を進めているんですか？

>・対象から外れたシステム及びその業務に対するソリューションは？
「劇薬」とやらでもある日突然すべてのアプリケーションが使えなくなるということは､
現実的にありえません。対象から外すというのは、優先度を下げるという意味も含むので
後からやればよいものは後でやるというだけの話です。
意味わかりますか？

※これ以上長くなると迷惑だと思うので、来週くらいに開設される私のコラムで詳しくはお答えしますよ。(すでに通りすがりじゃないと思うので名前変えたらどうですか？)

答えは要らないって言ったのですが。。
まぁ、コメント増えすぎが望ましくないならAhfさんなりしかるべき人が消してくれるでしょう。

元々、違う世界の住人のようだし、ビガーさんに他の価値観を受け入れるつもりが無さそうだったので、答えの内容も期待してなかったのが正直なところでした。
が、ここまでご自分の理想に固執してこき下ろされると、流石にビガーさんの話にも少し興味がわきますね。コラム、期待してます。

で、私からの回答です。
「健全」とはシステムの見直しのタイミングが業務の見直しのタイミングに合わせて実施されることだと考えています。システムのサポート期間という要因がトリガーになることはリスクとして認識し、準備することも健全だと考えます。不健全そのリスクが顕在化することを待望するかような姿勢と、それに乗じた「結論ありき」のコンサルまがいの行為を指しています。

次に、要件定義ですが、業務要求（私の専門はSCM・生産計画なので、リードタイム短縮や在庫削減、製販連携強化など）に従って業務分析・課題展開し、ビジネスプロセスのAsIs-ToBeを作成し、システムの要求仕様に落とし込みます。我ながらかなり稚拙なレベルではありますが＾＾； おそらく、ビガーさんの言っている「ドキュメント上でだらだら～」といった類の、いわゆる一般的なやり方だと思っています。

３つめ、「劇薬」で突然全てのアプリケーションが使えなくなることは現実的に「ありえます」。理由はAhfさんに回答したとおりです。システムの動作に関係なくても、一時的でもセキュリティーホールを許容することは本業の事業継続の観点から許されません。

ビガーさんがどのような手法を用い、どのようなシステム開発をされる方なのか私には想像できませんが、ここで要件定義について語る以上は「＠IT情報マネジメント」の記事レベルはクリアされていることを期待しています。
では、また。次回からは通りすがり→snowfieldと名前を変えることにしますね。

PC98懐かしいですね。場所が場所ですからFC98とかでしょうか。

通りすがりさんが誤解されている点がまだ見受けられるのですが、私もサポート期間を考慮して利用する技術の選択や、対象とするプラットフォームなどもケースバイケースで変えてます。ポイントは「何を最重要とするか」かと思います。

ソリューションの導入とはいえ、社内環境全域に適用する場合と、部分的に適用する場合とで話の進み方も考え方も変わってくると思いますよ。OSの導入が目的ではなく、何か別の問題の為のソリューション導入が目的なのだと思いますし。

私の文章力の問題がかなりあると思いますが、私はユーザーにまで開発側と同様の革新を求めるつもりはあまりありません。開発側に通じる話とユーザーの現場への話は別ですよね。

・・・ちなみにコメントでのやりとりが長くなるのは「私は一向に構わんっ！」ですよ。むしろ嬉しいですねぇ。

ビガーです。

Ahfさんのお許しがでたのでもう少しだけ。

>snowfieldさん
ちょっと最近、私自身謙虚さがなくなっていますね。。(反省)
価値観は理解している「つもり」ですよ。いろいろ勉強になってます。

>「健全」とはシステムの見直しのタイミングが業務の見直しのタイミングに合わせて実施されることだと考えています。
これこそ、理想論ですね。実際にシステムの見直しなんてできてるんですか？
で、具体的にシステムの見直しって何してるんですかね？

>業務要求（私の専門はSCM・生産計画なので、リードタイム短縮や在庫削減、製販連携強化など）に従って業務分析・課題展開し、ビジネスプロセスのAsIs-ToBeを作成し、システムの要求仕様に落とし込みます。
教科書どおりのお答えありがとうございます！(嫌味ではないですよ)
＠IT情報マネジメント関連の記事って、こんな感じの表面撫でて終わっちゃうのがほとんどで、
肝心の泥臭い部分(AsIsのどの範囲を対象とするかの根拠作りとか、ToBeを描くための
実際システムを使う側の実情把握メソドロジーなど)がないんですよね。
このあたりを私の専門である金融業界をターゲットにコラムを書くつもりなのでご期待ください。
(ただ、コラムの趣旨はフリーエンジニアの実情をお伝えすることなんですけどね)

>３つめ、「劇薬」で突然全てのアプリケーションが使えなくなることは現実的に「ありえます」。
これはちょっと信じられませんね。こんなことがおきたら業務が停止しちゃうじゃないですか。
実際どのように対処されたのですか？

生島です。

盛り上がっていたので、すこし、チャチャを入れさしていただきました。

>Ahfさん

ちと遅くなりましたが、何を誤解してるんだろう・・・と少し悩んでみました。
ひょっとして、Ahfさんが指摘したいのはVB6のアプリが運用レベルで残っていることでなく、VB6で新規開発が行われていることなのですかね？
もしそうなら、まぁ憤慨する気持ちは少し解る気はします。でも、現状の.NETの導入メリットの少なさやVB6の普及度を考えると、まともに使えるマイグレーション機能の登場やXPモードのような仮想化技術の進化に期待してVB6を使い続けるという選択肢もありだとは思います。生島さんのチャチャにもありましたが、まともにSQLを使える（≒ビジネスロジックに落とし込める）技術者は確かに少ないと思いますし、JavaなどVBと違う機能を実現できるプラットフォーム「も」使えるようにするとか、プロセス管理やセキュリティなどの理解とか、やることは他に山ほどあるのでは。（うちの会社ではVB6での新規開発は認められないようになって久しいですが、個人的意見として）

>ビガーさん
謙虚さは足りてませんね。なんか、若いなぁって感じもしますが、大分失礼な発言を連発してますよ。
、、と、売り言葉に買い言葉この辺にしといて、

「健全」が理想論を指すのは普通だと思いますが、違いますか？システム見直しは業務の優先度が高いものから順にやってます。業務要求が尽きることなんて、まぁあり得ない状況なので＾＾；何をしてるかというと、要求事項を満たすためにどの部門(orシステム)にどの機能を分担させるか、その機能を満たすために現行業務(orシステム)の変更で対応できるのか刷新する必要があるのかなど、言い出すときりがありませんが、特に変わったことはやってないつもりです。

手順に対する質問については正直にそのままお答えしましたが、手順とその中の作業を混同してませんか？手順自体には泥臭さはあまり出ないものだと認識してます。また、作業のメソドロジー化は困難で利も少ない事が多いと思いますので、手順を示してくれる教科書的な記事の方が私は参考になって好きですね。

「劇薬」については、そのような事態にならないようにユーザSEを中心に頑張ってますよ。NT4.0や今ならWindows2000・Office2000のサポート切れに伴って、数年がかりで移行に関わっている人達がたくさん居ると思います。突然といっても通常は数年の猶予があるのが普通ですから。

saki1208です。
生島さんのコラムから誘導されてきました。
私は、VB6での新規開発案件反対派です。(w)

>>Ahfさん
>
>ちと遅くなりましたが、何を誤解してるんだろう・・・と少し悩んでみました。
>ひょっとして、Ahfさんが指摘したいのはVB6のアプリが運用レベルで残っていることで
>なく、VB6で新規開発が行われていることなのですかね？
コラムの文脈上はそのように記述されていると思いますが...

まぁ、それは置いといて...
技術者の教育は弊社でも問題になっていますが、基本的に自分でやるもんですよ。
会社がそういう時間を設けてくれても、勉強しない人はしません。基本的に自分のメシ
のタネですから、寝る間を惜しんでも自分ですべきでしょう。

如何せん、それで作業効率が良くなり残業が少なくなっても会社からの評価は対して
良くなりません。残念ながら、捌けなくて残業する人の方がたくさん給料を貰えるのです。

そんな会社の制度を見直すことができるポジションに就ける日が来るだろうか...
# 他力本願ではなにも改善しないので、自分たちで改善していかなければ!!

>snowfieldさん
あなたも十分謙虚さがないですよ。

で、理解しました。
あなたはエンジニアリングをついては、ほとんど無知なのですね。
エンジニアライフを購読されているならそれなりに経験があるかと思い込んでいました。
もしこの発言に腹が立つならどうぞあなたのエンジニアリング経験を教えて下さい。

で、多分あなたは社員で業務をされているから自社の業務しか知らないし、
その業務要求が途切れることに対する緊張感もない。
教科書的な資料が参考になるレベルなら、多分あなたがされているかもしれない
標準化作業も気泡なのでしょう。私の記事はどうぞ読まないで下さい。

これってCOBOLと同じ話題だと思います。
あんまりVB6を死守するとVBerと呼ばれますよ。
ちなみに、コストを言うのならば、
VB6が有効なケースは「根回し」が出来ない場合だと思います。
既存システムを変更する事の根回しが色々なコストを上回る場合のみVB6は有効だと思います。

老婆心ながらビガーさん、コラムを掲載するのですから、そんな風に怒らないほうがいいと思います。
人の意見は十人十色です。
もっと穏やかにしましょうよ。

カドありすぎですかね。意見は認めていないわけではないんですが、
エンジニアに対する目線が癇にさわってしまって。。
ご指摘ありがとうございます。

みなさん多くのコメントありがとうございます。
スタンスはどうあれ問題意識を持っている方が多いとのは嬉しい事ですね。

あのような形でチャチャを入れられるとは思いませんでした（ｗ
言われていることも理解できますしなるほどなぁ、という感じです。
こちらでのコメントのリンク先が（ｗ

私の個人的な考えは「サポートが切れたものの利用≒利用する際の責任が増える」と考えています。昔ならともかく、基盤となるOSがどんどん変遷している今、Windows環境においては枯れた技術というのが存在しにくいと思えるのです。
そしてその分利用するには問題発生時の責任がつきまとい、サポートのある言語での開発よりもリスクは高まると思います。

もちろんそのようなリスクは「そうそう発生するものではない」という見方もあるとは思いますので、VB6などを利用する選択もアリだという事は理解できます。ただ、私としては一人の開発者としてその選択は自分達だけでなく、それを利用するユーザーにもデメリットが多くなるのではないかな、という気持ちです。

難しいところですよねぇ。

最後に。
Ahfさん、ちょっと脱線してしまって申し訳ございません。不適切と思ったら削除して下さい。

ビガーさんへ
私は確かに未熟です。自覚してます。私もSEの端くれのつもりでしたが、あなたの指すエンジニアリングが一体どのような業務か私には想像も出来ません。
ただ、仮にもエンジニアを名乗るなら以下の３点くらいは守って欲しいなと思います。
・推測しか出来ない状況で、裏付け無く（自己の価値観のみで）断定をしない
・上記断定に基づいた、勝手な理論展開や論点のすり替えをしない
・他者のやり方・考え方を批判することに基づく自己肯定をしない
他人事ながら、フリー（個人事業主）としてやっていけるのか、少し心配になりました。
ただ、ここまで言うからにはそれなりの理論やノウハウをお持ちのことと思いますので、公開されたコラムはありがたく読ませていただこうと思ってますよ。

では、また。
＃生島さんのコラムにも「通りすがり」さんがいますが、私とは別人です。