地方エンジニアが感じる地方・中小企業での悩み

Windows7のXP Modeに思うVB6

»

 次期OSであるWindows7もRC版がリリースされ、実際にインストール・検証を行っている方も多いことかと思います。わたしも早速検証してみようと思ったのですが、目玉の1つ(?)であるXP Modeはそれなりな実機を用意しなければならないため、そこだけ確認できていないところなんですよね。一応稟議を申請してPCを確保しようと思っていますが、冷静になって考えると自分がかかわる案件については、「ほぼ」問題のない動作(VB6製なので完全対応は無理……)していることが確認取れているので、あまり気が乗らなかったりします。雰囲気的には、わたしが他のシステムも検証しなくてはならなさそうなのが、非常に嫌な予感満載です。

 しかしこのXP Mode。人によっては大変助かる機能だというのはわかるのですが、個人的にはあまり賛成できないんですよね。というのも、Vista以降非対応アプリ(特にわたしの勤務先ではVB6製アプリ)の延命処置として利用されるのではないか、と思えてしまうからです。

 特殊なハードやメーカーがドライバを提供しないなど、自分たちが手の出しようのない理由でXPでなくてはならない部分は、理解も納得もできます。ですが一部の心ない技術者のように「やればできるのにやらない」ので、結果非対応のままVB6で突っ走るということには、技術者として非常に憤りを感じます。

 今年に入ってから海外で行われた調査で次のような結果が公開されていました。

 InfoQ: いまだに広く使われているVisual Basic 6.0

 (その原文:Results of the Visual Basic Survey: Part 1 Language and Framework Usage

 リンク先の記事を見ると、イギリスではVB6を利用している割合が8割をいまだに超えていることが分かります。同様のアンケートを日本で行った場合、結果は恐らく似たような割合に落ち着くでしょう(実際に@ITでアンケートを取ってもらえると面白いと思います)。しかし、このアンケートに答えた方の中で、本当にどうにも手段がないことが理由でVB6を利用し続けているのはどれくらいの割合なのでしょうか。

 実際に過去の資産から現在へと移行するには、多くのコストが発生したり技術者の育成を行わなくてはならなかったりと、開発以外のレイヤーで考慮しなくてはならない問題も多いと思います。ですがWindowsXPに限らず、過去の環境というのは「いつかはなくなる」ことが決定しているものです。仮に環境を保全しているなど、何らかの手段を講じているとしても、どこかでそれを利用しなくなるタイミングは必ず発生するものと思えます。過去を維持することと、現在や未来に向かって進歩すること。どちらがコストのかかるものなのでしょう。

 技術者の教育コストがかかる、という意見は反論として必ず出てくるものだと思います。わたしがそこで不思議に思うのは、「教育コストがかからないことがありえるのか?」という点です。企業として活動している以上、人員の増加など何かしらで教育を行う必要性は必ず発生するものだと思います。過去に依存する場合と、未来へ進歩する場合とでは「教育者を用意するコスト」という個所で差が出るでしょう。ですが、「人に教育する」部分ではどちらの手段を取ろうと同じように発生する部分ではないでしょうか。

 まったく新しいことを習得する必要のない仕事であれば、このようなことを考える必要はないのかもしれません。ですがIT業界はそのような世界ではないとわたしは思っています。特にSEであるならば、常に進化し続けるテクノロジ(新旧含め幅広い中から選択を行い)を用いてユーザーのメリットとなるようなシステムを構築するのが、SEとしての条件なのではないでしょうか。

 また同業者の中からは「なぜ、Vistaのようなものを出したんだ」ですとか「.NETなんて面倒だからやめてほしい」などといった、「既存環境こそ良し」と思う方の意見も多々聞こえてきます。そして「VBやめて違う言語にしよう」とか「マイクロソフトから離れてみよう」という意見を聞くこともあります。

 わたしとしては「Vistaはビジネスに利用できない」「.NETで開発を行うにはデメリットが多い」と本当に思えるのであれば、別のプラットフォームを選択すればいいだけのことだと思っています。文句を言うだけでなく実際にやればいいのです。文句を言うだけで何も行動に移さないのであれば、この世界から足を洗うべきでしょう。

 わたしはOSや言語など「人の作成したもの」を利用して商売をしている以上、そこがどう変化していこうとビジネスでの利用方法を考えるのが真っ当な姿だと思っています。趣味で開発しているならば別ですが、わたしは仕事としてこの世界に浸かりこんでいますので、新しいバージョンが提供されればそれに対応するのが当然だと考えています。

 個人的な意見としては「ユーザーが利用するのはWindows環境なのは、しばらく揺るがない」点があるので、仕事として続けるためにWindowsプラットフォーム、そして.NETでの開発と付き合っていこうと考えています。「ユーザーはOSを利用したいのではなく、システムを利用して業務を効率よく行いたいだけだ」という記事も目にします。それは正論だと思います。ですがわたしは、自分の仕事範疇とそこに関わるユーザーにおいては「慣れ親しんでいるWindows系OSで」「システムを用いて効率よく」が、自分のビジネスにおいては適していると考えていますので、他のプラットフォームという選択肢はわたしは選ばないでしょう。

 XP Modeはありがたい機能だと思います。ですがそれがあるからといって安心せずに、早いうちに開発側も新しい環境に移行していってもらいたいものだと思います。

 いっそのこと「VB6ランタイムの動作保障をしない」ぐらいのことがなければ、今文句を言うだけの人というのは動かないのかも知れません。予想として、それでもMicrosoftのWindowsプラットフォームでビジネスを続けている人が多いとは思いますが。そのように思っているので、わたしとしてはそろそろ「動作保障をしない」という劇薬を用いた治療を行ってほしいものだ、などと思っています。

 ちなみにわたしの場合、自宅ではVistaへ移行できていません。今現在利用しているADSLモデムがVistaだと「回線接続時にアカウント認証以降進まない」、という不思議な現象が出ており、なおかつこのモデムメーカはすでに業界から撤退していてバージョンアップは絶対無理という……。

 かといって今さらADSLモデムやルータを購入するのも気がひけます。また光にしようと思っても、将来的に転居することを考えるとそれもなぁ……。

Comment(48)

コメント

cross

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

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

Ahf

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

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

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

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

mmf

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

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

arere

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

通りすがり

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

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

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

cross

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

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

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

ビガー

ビガーです。

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

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

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

インドリ

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

通りすがり

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

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

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

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

ビガー

ビガーです。

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

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

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

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

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

Ahf

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

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

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

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

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


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

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

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

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

ビガー

ビガーです。

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

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

Ahf

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

通りすがり

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

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

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

三年寝太郎

こんばんは。

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

車が良い例です。

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

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

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

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

ってことですかね。

ビガー

ビガーです。

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

>通りすがりさん

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

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

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

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

傍観者

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

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

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

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

Ahf

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

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

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

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


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

通りすがり

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

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

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

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

ビガー

ビガーです。

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

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

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

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

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

通りすがり→snowfield

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

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

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

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

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

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

Ahf

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

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

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

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

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

ビガー

ビガーです。

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

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

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

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

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

生島です。

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

snowfield

>Ahfさん

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

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

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

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

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

saki1208

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

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

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

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

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

ビガー

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

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

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

インドリ

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

インドリ

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

ビガー

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

Ahf

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

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

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

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

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

snowfield

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

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

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

ビガー

>snowfieldさん
断定的な表現は「アエテ」しています。それに対するリスク(反論)には応えるつもりなので。
また、議論のすり替えはしていない「つもり」ですが。。いままでの背景から私なりの
結論を出しているだけです。
また、ご心配いただきありがたいのですが、こんな感じの論調で普段仕事をしていたら
おっしゃる通り仕事にならないので表現には注意している「つもり」です。
ハシバシに出ちゃってるかな。。まぁ、お客様には多数のオファーをいただいていますが。

今後のこの業界のユーザSEのあり方は特に難しくなっていくでしょうからsnowfieldさんの
ような仕事への取り組み方で大丈夫なのか逆に心配になります。

JULY

cross さんの指摘していることが Ahf さんにきちんと伝わっていないような気が...

cross さんの指摘しているのは、なぜ「ルータ」を買わないのか、という問題です。「ルータ」は光だろうが ADSL だろうが関係ありません。最近は対応しているものが YAMAHA の NetVolante ぐらいしかなくなりましたが、ISDN でも構いません。

ルータは、ADSL モデムに繋げるものです。光であれば ONU に繋げるものです。PC はあくまでもプライベートな LAN に繋がっていて、デフォルトゲートウェイがルータの LAN 側の IP アドレスを指すようにするだけです。これも、大抵は PC 側の LAN の設定を DHCP の割り当てを受けるようにして置けばよいだけです。フレッツを使っているのであれば、PC に代わって PPPoE の認証をルータが行います。

だから、ルータ経由で繋げば OS は関係ありません。LAN のインタフェースを持っていて、IP が使えれば、Windows だろうが、Mac だろうが、Linux だろうが、家電製品だろうが繋がります。ルータは光回線専用のものでもなければ、ADSL モデムを置き換えるものでもありません。PC の間の設置するものです。

で、こういった機能を持ったルータが、5,000 円程度で買える、ということです。

いつも、エンジニアは積極的に新しいことを勉強すべきだ、ということを主張されていて、そのことは同感なのですが、勉強すべきことは、プログラミングだけではないと思います。

といっている私の周りにも、ネットワーク技術のことに全く無関心な人が多く、どうしてソフトウェアの開発者って、作ること以外に興味が向かないのかなぁ、と思うことはありますが。

かげながら応援している同郷のエンジニアとしては、ちょっとがっかりです。

Ahf

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

ルータの件ですが、残念ながらウチにあるのは「USB接続のみ」可能なタイプでしてそのままではルータに接続できません。JULYさんやcrossさんが言われているのは「一般的」なタイプだと思われますが、私が所有しているのはそれよりも古いタイプなんですよね(笑
今のルータには接続できないのですよ。

ちなみに物を購入できない話についてはちょっとレイヤが異なるというか。

結婚すると、費用をかける優先順位が結構変わることになるのですけど、我が家では光回線の導入というのがそれほど上位優先度にならない、というプライベートな事情です。

JULY

> 残念ながらウチにあるのは「USB接続のみ」可能なタイプ

な~んだ、それを書かないとダメですよ(^^;。

それだったら、移行できない理由が「光が使えるところとは限らない」とか、関係ないじゃないですか。「今使っている ADSL モデムが USB しか使えないやつなんで、ルータを入れようと思ったら、ADSL モデムから変える必要があるんで。で、これを換えるととなると、財務大臣の許可が...」ということですよね。

参考までに、ADSL モデム内蔵のルータだと、NTT の WebCaster シリーズにあるぐらいで選択肢はないかもしれませんね。

http://web116.jp/shop/netki/6400m/64_n_04.html

ADSL 単品でも、やっぱり NTT のものしかなさそう。

http://web116.jp/shop/netki/ms5/ms5_n_00.html

となると、15,000 円ぐらいは覚悟する必要がありますから、cross さんの「5,000 円ぐらい」では済まないのは事実ですね。

私も2児の父ですから、独身の時のようにはいかないことは、よく分かりますよ。ただ、「光回線にしないと」とは誤解です。5,000 円とはいきませんが、15,000 円ぐらいで、ADSL のまま、OS とのしがらみは無くせますよ。

Ahf

JULYさん、言葉足らずで申し訳ありません。

私も調べたのですが、入手可能な物はWebCasterシリーズだけなんですよねぇ。
中古を探せばまだあるかも知れませんけど。

ちなみにその15000円で相談した結果、現状維持となっています(笑

cross

USBのみですかぁ…そんなのありましたねぇ~
っていうかそれ言ってくれないと。

> かといって今さらADSLモデムやルータを購入するのも気がひけます。
これ読めばルーター買えば解決すると思うじゃん!

ただそうだとしても「インターネット接続の共有」とか
http://homepage2.nifty.com/spw/software/bjd/
とか、色々対策はあると思うけど…

cross

因みに、ADSLモデム、リサイクルショップでに500円位で捨てるほど売ってますよ。
自分も保守用に何台か買ってあります。

Ahf

crossさんコメントありがとうございます。
いやはや本当に申し訳ない・・・。

リサイクル系のショップですか。何店かあたってみますね。
ありがとうございます。

airwing

初めまして。
すでに議論は収束している模様ですが、いちCEからの意見として。

CE(Customer Engineer)って、過去はハードウェアを見ていればよかったんですが、今はOS・スタンドアロンアプリ・フロントエンドアプリまで面倒見させられてるのが現実なんですよね。

で、話題のXP Mode、これって「1台のハードウェアに2つのOSが乗っている状態」なのは重々ご承知だと思います。

で、このXP Modeを駆使したシステム(それってシステムと呼ぶのかしら・・・?)でトラブルが起きた場合、原因がハードなのかソフトなのか切り分けるのすら面倒なのに、ソフト側の場合Windows 7側なのかXP側なのか切り分けないといけない。

CEはエンドユーザー(顧客のシステム管理者ではなくシステム利用者です)の正面にたつのが仕事と自負しています。
そして、顧客システム管理者に相応の知識がないため(私は対官庁グループにいるため、その場合が多いです。まじめに勉強し、自社のシステムを管理されてる方々、申し訳ありません)、CEにトラブル丸投げは往々にしてあります。

何が言いたいかというと、XP Modeって、はっきり言って手間増えるだけなんですよ。
システムエンジニアを名乗る方々にはこんなモノにあぐらをかくマネだけは避けていただける様切に願います。

追記
CEの仕事の1つに「端末の初期スタートアップ」があるんですが、意味不明なシステムほどこれが手間取るようにできてるんですよね・・・。
「ユーザーごとに設定が記憶されるのに、Administrator権限じゃないとその設定ができない」とかザラなもんで、動作するシステムを一通り把握してないと現地作業すらおぼつかないのが現状です。ひどいモノはユーザーという概念のないWin9x時代の産物かと疑いたくなります。
その上「本当の最終工程(エンドユーザーへの機器引き渡し)」なので、上流工程で火を噴くともろにスケジュールに影響くらいます。
そのくせCEってPGより扱い低い(人月どころか時間単価計算です)ので、真っ先にコスト削減(=単価引き下げ)の対象になります。
全国クラスのシステム展開となると現地作業管理だけでも馬鹿になりませんが、SE「様」は「たかがCE風情が」と見下すことが多いです。
現場でシステム動かなくて真っ先に怒られるのうちらなんですがねぇ・・・。

追記2
この間、1000人クラスの利用者が使っているシステムで「ネットワークがダウンした!」と緊急コール受けて飛んでいったら、だれかがLANケーブルをループさせてた、というオチでした。
エンドユーザーのコンピュータリテラシー意識って重要だと思うんですが、これが薄いユーザー、結構多いです。
(これも官庁だからでしょうか?官庁って内部リソースに対するコスト意識がほんとに薄いです)
ちなみに、家庭内PCはルータを間に入れるだけでセキュリティ強度がだいぶあがります。数名の方が「なぜルータを入れない?」と言うのはその辺が理由です。

Ahf

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

官庁相手だと更に苦労が増えるのですね。私は官庁というか公共相手に過去少々仕事をしていたのですが、airwingさんの話よりは全然マシと思えました(笑

システムエンジニアを名乗る方々には~、というご意見には私は心から同意します。

それよりも気になるのはCEの扱われ方ですね・・・。
開発側の中に SE>PG という見方をする人が多いのですが、さらに続いて
SE>PG>CE という扱い方をしているというのが納得がいかない気持ちです。

個人的には「どれも異なるスキルを必要とする別職種」と思いますので、同格に扱われるべきと思うのですけどね・・・。

airwing

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

>それよりも気になるのはCEの扱われ方ですね・・・。
>開発側の中に SE>PG という見方をする人が多いのですが、さらに続いて
>SE>PG>CE という扱い方をしているというのが納得がいかない気持ちです。

>個人的には「どれも異なるスキルを必要とする別職種」と思いますので、
>同格に扱われるべきと思うのですけどね・・・。

どうもこの業界、「上流工程ほど偉い」という神話がまかり通ってますね。
実際は「上流を自前でやって下流を下請け任せ」な業者が多いからなんですが。

うちの仕事に「システムスタートアップ」というのがあるのですが、そこでも
「Solaris>Linux>Windows Server>パソコン」というよくわからん序列があります。
私にとってはどれも等しくスタートアップなんですが、新人君には「パソコンよりサーバ、WindowsよりUNIXのほうがすごい」と思わせる何かがあるようで・・・。
端末の大規模展開って下手すると万単位のオーダーなので、コスト削減による利益見込みおよび手戻り発生時のコスト増がハンパないのですが、どうも軽視されがちです。

Ahf

重ねてのコメントありがとうございます。

WindowsよりUNIXの方が凄いというイメージはあるところには根強くありますよね。重要なのは何をやっているか、ということだと思うのであまりプラットフォームは関係なく、いい物はいい駄目な物は駄目、とシンプルに考えるべきなのですけどね。

上流程~というのも言われるとおり違和感がありますね。
上流、下流などというから凄そうに思えますが、最終的にはどこも等しく重要なのですけどね。

River

VB6とVS2010を現在併用してBasicで開発していますが 率直に言ってVB6はすべてに速い(開発環境起動及びコンパイル時またプログラム実行時)またコーディングの容易さなど利点は多く捨てがたい かたや VS2010は すべてに遅いにつきる 以前に比べては ずいぶん速く軽くなって やっと 使いやすさの入り口に到達したぐらいなもの まだまだ我慢して 使っている人が 多いと 正直思います CPUが 過去のようにどんどん 速くならなければ 困ったことになると思っています
JITコンパイラは ただ MIcrosoftが有利で便利なだけ AOTコンパイラを使ったら
あほらしいと 正直思いますが ですので VB6は こうした環境 --本当に開発者の立場に立った 速い 軽い シンプルな開発環境が 整うまで 使いたいと思っていますが

Ahf

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

IDE 自体の速度という点では言われる通り VB6 の方が速いというのは同感です。
ですが VS2010 では非常に強力なインテリセンスなどの補助機能が用意されているのと、VB10 になり利用できる機能の便利さなどが非常に大きな差を生み出すと感じています。

例えば Threading.Tasks 関係の並列処理などが非常に簡易に記述できる事など、VB6 では難しかったことが簡単にできる、その点を踏まえても VS2010 を利用しだすと、VB6 の IDE に戻る事は私にとって厳しかったと感じました。

アプリの起動時だけは .NET という仕組み上 VB6 に負ける点はある程度存在していますが、個人的には許容範囲かなと感じます。

ぴの

.NETは1.0、1.1のサポート打ち切りが早すぎます。
Windows7ではインストールさえできないなんて…

Ahf

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

.NET 1.x 系は確かに打ち切りが早いですね。
VB6 ランタイムがまだサポートされていることを踏まえると、
もう少しサポートするか、.NET 2.0 以降への移行をもっと行いやすく
してもらえると使う側としては助かるのですよね。

ただ最近であれば、APP-V などの仮想化が比較的容易に利用できる環境に
なりつつあるので、そっちを利用して・・・という事なのかも知れません。

コメントを投稿する