■2005.9.1（木）

・GLOVIA　ダイアボンド・ＮＰクロス導入

・システム監査資料作成

　

■2005.9.2（金）

・システム監査資料作成

・web購買登録

・ユニチカサカイ伝送漏れ対応

・売掛〆

　

■2005.9.5（月）

・配布当番

・ユニチカサカイ伝送漏れ対応〜PAA11戻す

・システム監査資料作成〜片山ＭＧへ

・サーバーチェック

　

■2005.9.6（火）

・売掛問い合わせ調査

・web購買・不要メールの扱いについて

・システム監査出席

・外付けドライブ購入の企画書作成

・CSV読込方法検討（DTS代替え、まずは売掛の現状調査）

・預金・運用F　銀行コンバート漏れ・相手先8件　ハンド打ち変え

　

■2005.9.7（水）

・中継エラー対応

・預金調査

・web購買登録

・ベルテルサーバー調査

・借入・利息入力のエラー・・・佐能さん調査

　

■2005.9.8（木）

・年休

　

■2005.9.9（金）

・売掛調査

・GLOVIA帳票不具合報告

・web購買登録

・午後半休

　

■2005.9.12（月）

・財務サーバー・SQLSERVERがサービス停止・・・9/9の午後からバックアップでエラー　→　床井氏対応済み

・FAX代替え宛先登録〜A〜E完了

・GLOVIAホスト・KMA11,KMA21変更

・有価証券・株数を小数点4桁から6桁・・・本番化

　

■2005.9.13（火）

・伊藤忠プラ・伝送エラー問い合わせ

・web購買登録

・ウラセ支払データ送付

・FAXエラー対応

・FAX代替え宛先登録　F〜Ｇ完了

・商売萬々歳テスト

・会員費本番化準備

　

■2005.9.14（水）

・財務・田原さんの端末・SAVエラー・・・UISにて再インストール

・預金小切手バッチ、２回流れる？？？

・FAX代替え宛先登録　H〜JA完了

・会員費システムVB6　本番化

・商売萬々歳テスト

　

■2005.9.15（木）

・FAX登録依頼票作成・大谷に送付

・FAX代替え宛先登録　JA〜KQ完了

・借入金コントロールテーブル修正

・商売萬々歳テスト、修正検討

　

■2005.9.16（金）

・ユニチカサカイ中継エラー対応

・ユニチカサカイ分支払データ送付

・商売萬々歳テスト、修正検討

・売掛銀行8/26更新分の取り込み（PBA82一時修正）

　

■2005.9.20（火）

・PBA82戻す

・PBU12臨時処理依頼

・商売萬々歳テスト、修正およびテスト・・・完了

・web購買アルファパーチェス連携会議

・FAX代替え宛先登録　〜M004完了

　

■2005.9.21（水）

・FAX代替え宛先登録　〜N32完了

・DVDドライブ設置、テスト

・文書サーバーバックアップ

　

■2005.9.22（木）

・預金Ｓ　朝バッチトラブル（借入からの連携　口座ＮＯなし　原因は不明）

・GLOVIAエラー・・・ＷＦのデータ作成処理改善を要望　今回はハンド修正後に取り込み

・9/21夜間処理　PBA08ABEND対応

　

■2005.9.26（月）

・GLOVIAエラー対応（ＷＦ分）

・ウラセ支払データ送付

・PBA08元に戻す

・サーバーチェック

・FAX代替え宛先登録　〜N完了

・web購買登録

・預金　抹消データセット調査

　

■2005.9.27（火）

・預金　抹消データセット調査＆依頼

・ユニチカサカイ・中継化作業

　

■2005.9.28（水）

・9/27　PBA08　ABEND対応

・売掛調査・検討

　

■2005.9.29（木）

・GLOVIA月次処理チェック

・PBA08元に戻す

・web購買登録

・日経ＢＰセミナー参加

　

■2005.9.30（金）

・GLOVIA月次処理チェック

・預金トラブル・・・２回目はOK。端末の問題？UISへ。

・売掛調査（プラネット誤伝送分）

　

　

　

　

作業テーマ

・借入金　預金用ファイル作成で、ときどき口座NOがスペースになる・・・佐能さん調査

・各サーバー、TIMEサーバーの設定・・・床ちゃんと相談

・web購買登録　環境・・・10/4打ち合わせ

・ユニチカサカイ・中継化

・GLOVIA　ダイアボンド・ＮＰクロス導入・・・WEBフロントの返答待ち

・NPクロス　商売萬々歳置き換え・・・10/14

・web購買・アルファパーチェスとの連携・・・アルファからの仕様書待ち

・預金データセット不要分抹消

・UFJと東京三菱の、支店コード重複の件

・前田さんの端末が遅い件・・・宮北君のテスト待ち

・GLOVIA　Tivoli・・・UIS連絡待ち

・osh041017　timeサーバー・エラーログ

・osh041018　移動プロファイル・エラーログ

・osh041018　マスタブラウザ・エラーログ

・osh041084　Win-update・エラーログ（2日おき）

・売掛Ｓの今後を検討・保守ドキュメント強化

・預金、借入金システムでDTSパッケージを別の手段にする（bcpオプションの使い方〜預金改良）

・共有サーバーの移行〜OSH26050への移行をどうするか（各自のログイン状況調査要？）

・預金　VSAMファイルのPS統一・・・決算後

・東京伝送廃止・・・相手先と確認

・売掛で、時折意味不明なエラー

・ベルテルサーバー更新の件・・・片山さんから保留と

・web購買でメール送信エラー通知を止めることができるか

　

・web購買での問題点

部署登録をどうするか

〜画面で入力も考えたが、コードが自動付番されるため、テスト側と本番が異なる可能性があるので断念。

メールが発信できない場合のエラーメールを止めることができるか

〜工場などで端末がない人（アドレス登録のない）の扱い

今期テーマ・web購買をどうやって理解していくか・・・保守再構築〜来期以降の他社展開をにらんで、住電に仕様を説明できることが目標。

　

　

未解決事項

・売掛メンテ、この端末でもできるようにする

　

■財務サーバー関係

・資料まとめ

・有価証券：サーバーサイドで実行テスト〜プロセスが残る。残っているのは帳票？

　

　

ミニ課題

■テーブルJOINの種類と使い分け等の調査

■健康管理システムを今後どうするか

（案）データをデジタル化するのではなく、PDFファイルにして保存する。

画面表示、印刷もこれで行う。

・オラクルにPDFファイルが保存できるか？

・セキュリティの考え方

　

　

テーマ別

***　酒井Ｇ長　添付ファイルより　*************************************************************

レガシーマイグレーション（Legacy　Migration）

　

１．レガシーマイグレーションとは

　

・メインフレーム或いはオフコンで構築されたシステムをWindowsやUNIXなどのオープン系

　システムに移植すること。

　

　Legacy（遺産、遺物）

　Migration（移行、移送）

　

　

２．背景

　

メインフレームを使用したシステム（レガシーシステム）は、高い信頼性、実績があるが、その反面

以下の問題がある。

　

（１）．保守、運用費用が高額で負担増。

　

　　　・オープンシステム導入によるシステムの混在化により、維持費負担が増大

　

（２）．システムの硬直化

　

　　　・システム変更の繰り返しによるＡＰ構造が複雑になり、修正や新規追加の影響範囲把握が困難。

　

（３）．２００７年問題

　

　

３．レガシーマイグレーションのタイプ

　

以上の様な問題を解消するために、マイグレーションが行われるが、その手法は以下の４種類に分類できる。

　

（１）．リエンジニアリング（リビルド）

　

　　　・ビジネスロジック（業務）のレベルからシステムを見直し、根本的にシステムを作り変えてしまう方法。

　　　・代表格はＥＲＰパッケージ導入。

　

（２）．リライト

　

　　　・ビジネスロジック（業務）はそのまま維持し、PGMをJavaやＣ言語に、ＤＢを別のものに書き換える方法。

　

（３）．リホスト

　

　　　・レガシーシステム上のＰＧＭ、ＤＢをそのままオープン系システムに移植する方法。

　　　・過去に実施した、紡織系システムがこれにあたる

　

（４）．ラッピング

　

　　　・レガシーシステム上のアプリケーションを外部システムからアクセスできるようにラッピングする方法。

　　　・この場合にはメインフレームはそのまま維持することになる。

４．レガシーマイグレーションのタイプ毎の比較

　

　

　

住商リース　レガシーマイグレーション検証

　

１．移植前環境

　

ＣＰＵ：ＩＢＭ９６７２−Ｒ１５

ＯＳ　：ＯＳ／３９０

ＤＣ　：ＣＩＣＳ／ＪＥＳ２

ＤＢ　：Ｄａｔａｃｏｍ

　

２．リホスト方式選択背景

　

（１）． ・既存基幹システムは１９９４年４月ＩＢＭメインフレームで再構築

・途中、営業ＳＦＡなどフロント回りをオープン系で追加

　

　

・導入１０年を機にシステムを見直し、既存システムが使えなくなっているかゼロから検証

　

　

・全面再構築が必要なほど陳腐化していない。

　

（２）． リライト検討

・開発工数、周辺環境との相性。テストに莫大な時間と費用がかかり、どれだけの労力がかかるか

　見えない部分があり、リスクが大きい。

（結果）

・初期コストを最小限に抑えながら、運用コストを削減するためにリホスト方式を選択。

　

３．移植後環境

　

ＣＰＵ：ＳＵＮ　Ｆｉｒｅ　Ｖ８８０（本番機）、Ｖ４８０（ＥＤＩサーバー）、Ｖ２４０（開発機）

OS　：UNIX　Solaris

ＤＢ：Ｏｒａｃｌｅ

移植ソフト：Sun　Mainframe Transaction Processing（Sun MTP)

　　　　　　　Sun　Mainframe Batch Manager（Sun MBM)

　・SunMTP・・・「CICS」のｱﾌﾟﾘｹｰｼｮﾝをSolarisｵﾍﾟﾚｰﾃｨﾝｸﾞ環境においてほぼ無修正で動作させる

　　　　　　　　　ソフトウェア

　　　　　　　　　VSAMﾃﾞｰﾀ、COBOL､PL/1言語で書かれたAPをを使い続けることが可能。

　　DB2、Oracleﾃﾞｰﾀﾍﾞｰｽｲﾝﾀﾌｪｰｽも備えている。

　・SunMBM・・・ﾒｲﾝﾌﾚｰﾑのﾊﾞｯﾁ処理をSolarisｵﾍﾟﾚｰﾃｨﾝｸﾞ環境上で再現するためのｿﾌﾄ

　　　　　　　　　JCL翻訳機能を備えている。

　

４．設計・開発期間

　

・全面再構築と比べ、基本設計〜単体テストが省力化できる。また業務は変えないため、社員教育

　がまったく不要となる。

・ただし、システム化計画、概要設計、ＩＴ基盤開発、総合テストは必要になる。

　

５．課題、問題点

　

・オープン系サーバー基盤に内在する課題（メインフレームに比べ性能、セキュリティで劣る）も移植

　しまうことになるので、基盤環境についてもオープン系では十分な検討が必要。

・ビジネスロジックは変わらないので、あくまでも次期新システム再構築へのワンステップという認識

　（住商リース）

　

（補）移行スケジュール

　

　

　

*************************************************************

■VB5.0→6.0

http://www.nms.ac.jp/nms/physics/kagawa/vb6abc/vappnd1.htm　

　

付録１．Visual Basic 5.0 と 6.0 での共通開発の方法

　

　ここ (付録１) の見出しの一覧

　

　移行の手順／共通開発の方法

　

　ここには、Visual Basic 5.0 で開発したアプリケーションソフトウェア資産 (ソースプログラムなど) を Visual Basic 6.0 用のものに移行させる手順、および両方の Visual Basic に対応できるようにする共通開発の方法が書いてあります。なお、Visual Basic 5.0 と MANDALA を併用して開発したソフトウェア資産の移行の手順、および共通開発の方法については、以下に説明があるものと基本的に同じですが､「MANDALA入門コースの手引き」に詳しい説明があります。

　

　

　ここでは、Visual Basic 6.0 がインストールされていることを前提にした説明になっています。ですから、まず Visual Basic 6.0 をインストールしてください。この際に、共通開発を目指すのであれば、Visual Basic 5.0 をインストールした OS の上に Visual Basic 6.0 をインストールしないようにしてください (同じ OS の上に無理やりインストールすると Visual Basic 5.0 が正しく動作しなくなると考えられます)。ですから、Visual Basic 5.0 と Visual Basic 6.0 は、別のパソコン (正確には別の OS) にインストールしなければなりません。そして、共通開発を目指すのであれば、両方の Visual Basic から参照できるところにソフトウェア資産を配置することが必要です。

　

　

　なお、共通開発を目指さず、以後一切 Visual Basic 5.0 を用いないと決意した場合には、Visual Basic 5.0 がインストールされていたパソコン (OS) に Visual Basic 6.0 をインストールしてもかまいません。この場合は、Visual Basic 5.0 をアンインストールしてから Visual Basic 6.0 をインストールすることをお勧めいたします。

　

(a) 移行の手順

　

　以下の手順に従うと、Visual Basic 5.0 で開発したアプリケーションソフトウェア資産を Visual Basic 6.0 用のものに移行させることができます。Visual Basic 5.0 から Visual Basic 6.0 へは、基本的に上位方向の互換性があるので移行作業は極めて簡単です。ですから、取りたてて移行作業と呼ぶような大袈裟な作業ではありません。

　

　

　なお、ここで述べる手順は、両方の Visual Basic に対応できるようにする共通開発のための準備作業にもなっています。

　

　

　作業を始める前に、次のことを知ると、移行作業の意味がよくご理解いただけると思います。

　

　

　Visual Basic 5.0 と Visual Basic 6.0 では、フォームモジュールやコードモジュールの形式が全く同じですから、これらを変換する必要はありません。しかし、プロジェクトファイルの形式が少しばかり変更されています。ですから、移行作業とは Visual Basic 6.0 用のプロジェクトファイルを作り出すことに他なりません。

　

　

(1) プロジェクトファイルの変換

　

　旧プロジェクトを Visual Basic 6.0 で開いてください。この操作をするだけで、旧プロジェクトファイルを新形式に変換することができます。

　

　ただし、新形式のプロジェクトファイルは、メモリ上に展開されるだけですから、次の保存作業が必要になります。

　

　

　

(2) 新プロジェクトファイルの保存

　

　名前を付けてプロジェクトの保存という指示を与えて新形式のプロジェクトファイルを新たなファイルとして保存してください。新しいプロジェクトファイルの名前は Visual Basic 5.0 用のプロジェクトファイルと同じにして、別のフォルダに保存することをお勧めいたします。

　

　この操作によって、Visual Basic 6.0 用の新たなプロジェクトファイルを作り出すことができるので、これで移行作業は完了となります。

　

　

　

　共通開発を目指す場合の注意事項ですが、新たなプロジェクトファイルは Visual Basic 5.0 用のプロジェクトファイルの上に絶対に上書きしないようにしてください。共通開発を行うには、Visual Basic 5.0 用のプロジェクトファイルと Visual Basic 6.0 用のプロジェクトファイルの二つが必要になります。そして、上書きしてしまうと、Visual Basic 6.0 用のプロジェクトファイルから Visual Basic 5.0 用のプロジェクトファイルを復元することは面倒です。

　

　なお、上書きさえしなければ、上記の移行作業を行っても、Visual Basic 5.0 用のプロジェクトファイルは、何の変更もされずに残ることになります。

　

　

　

　共通開発を目指さず、以後 Visual Basic 5.0 を用いることなどあり得ない場合に限っては、新たなプロジェクトファイルの内容を Visual Basic 5.0 用のプロジェクトファイルの上に上書きしてしまってもかまいません。

　

　

(b) 共通開発の方法

　

　ここには、Visual Basic 5.0 と Visual Basic 6.0 の両方に対応できるようにする共通開発の方法が書いてあります。近未来に、両方の Visual Basic を使わなければならないような事態が少しでも予想される場合には、ソフトウェア資産を両方の Visual Basic に対応したものにするのがよいでしょう。

　

　Visual Basic 5.0 と Visual Basic 6.0 では、フォームモジュールやコードモジュールの形式が全く同じです。ですから、Visual Basic 5.0 で開発したソースプログラムと Visual Basic 6.0 用のソースプログラムを別々にもつことは効率的ではありません。なぜなら、ソースプログラムを別立てにすると、変更が必要になった際に両方のソースプログラムに対して同じように手を入れなければならなくなるからです。これらを共通のソースソースプログラムにしておけば、変更は一回で済みます。

　

　

　

　共通のソースソースプログラムとして管理するには、二つの OS のどちらからも参照できるところにソフトウェア資産を置くことが必要になります。なぜなら、前述のように Visual Basic 5.0 と Visual Basic 6.0 を同じ OS の上にインストールすることはできません (無理にインストールすると Visual Basic 5.0 が正しく動作しなくなると考えられます)。ですから、Visual Basic 5.0 と Visual Basic 6.0 は、別のパソコン (正確には別の OS) にインストールしなければなりません。したがって、Visual Basic 5.0 と Visual Basic 6.0 の両方から使うソフトウェア資産は二つの OS のどちらからも参照できるようにしなければなりません。

　

　

　

　このように両方から参照できるようにするには、例えば、ソフトウェア資産を LAN で結ばれたサーバ上のファイルにするのは一法です。あるいはデュアルブートの (二つの OS のどちらを使うのかを OS のロードの際に切り替えられるように設定した) パソコンの上にソフトウェア資産を置くのもよいでしょう。

　

　

　

　このような手段を用いて、フォームモジュールやコードモジュールは、二つの Visual Basic のどちらからも参照できるところに置かなければなりません。しかし、プロジェクトファイルについては必ずしもこうする必要はありません。プロジェクトファイルについては、Visual Basic 5.0 用と Visual Basic 6.0 用の二つを別々に用いることになります。

　

　

　そして、図のように二つのプロジェクトファイルから共通のフォームモジュールやコードモジュールを指し示す (ポイントする) ようにします (前述の移行の手順に従えば、自然にこうなります)。こうしておけば、一方の Visual Basic で共通のフォームモジュールやコードモジュールに対する変更を行うと (そして保存すると)、もう一方の Visual Basic でそれらを参照したときに変更されたものが見えるようになります。即ち、変更は一回で済むことになります。

　

　しかし、一方の Visual Basic で、あるプロジェクトにモジュールの追加や削除を行った場合には、もう一方でも同じことを行うことが必要です。プロジェクトファイルは共通化することができないので、これに関する変更は一回では済まずに、それぞれの Visual Basic で行うことが必要だということです。

　

　

　

このような共通開発をなさる場合の注意事項ですが、それぞれの Visual Basic で一応テストを行うことをお勧めいたします。こう申しましたが、一方の Visual Basic できちんとテストをなさっておけば、もう一方の Visual Basic ではテストを軽くすませることができると言ってよいかもしれません。

　

　

　

　Visual Basic 5.0 と Visual Basic 6.0 とでプログラムの内容を変えなければならないことは、一般にはほとんどありません。しかし、そうしたことが必要になった場合には、条件付きコンパイル機能を活用すればよいでしょう。即ち、以下のようにプログラムを書けばよいでしょう。

　

　

　

#If VbVersion = 5 Then

　

　　(Visual Basic 5.0 用のソースプログラムコード)

　

#ElseIf VbVersion = 6 Then

　

　　(Visual Basic 6.0 用のソースプログラムコード)

　

#End If

　

　

　

　このように条件付きコンパイル機能を使う場合には、VbVersion の指定を各プロジェクトごとに行ってください。即ち、ﾌﾟﾛｼﾞｪｸﾄﾌﾟﾛﾊﾟﾃｨというダイアログボックスの実行可能ﾌｧｲﾙの作成というタブの中の条件付きｺﾝﾊﾟｲﾙ引数(D): として VbVersion = 5 または VbVersion = 6 と指定してください。因みに、この指定情報は Visual Basic 5.0 用と 6.0 用のそれぞれのプロジェクトファイルに格納されます。

　

　

--------------------------------------------------------------------------------

　

　

　ブラウザの戻る (Go Back) のボタンを押して元に戻るか、目次のページに戻ってまだご覧になっていないところに進んでください。あるいは、付録２をまだご覧になっていなければ、付録２に進んでください。

　また、アプリテック株式会社のホームページ http://www.wbs.ne.jp/bt/applitech/ のこの他の情報もご覧ください。

　

　

Copyright (C) 1995-1998 By AppliTech, Inc. All Rights Reserved.

ｅｅｅ, SSS/Win, RRR は、ウッドランド株式会社から販売されている製品です。

MANDALA は、アプリテック株式会社の商標として登録の申請を済ませています。

Visual Basic, Windows, Windows NT, ActiveX は、米国マイクロソフト社の商標です。

(ME98V644)

　

　

*************************************************************

■いつまでVB 6_0を使い続けますか：IT Pro

http://itpro.nikkeibp.co.jp/article/OPINION/20050927/221731/　

　

いつまでVB 6.0を使い続けますか

　

　

　

　マイクロソフトは今年末に開発環境の新製品「Visual Studio 2005」の出荷を始める見込みだ。すでにベータ版（日本語ベータ2）がダウンロードできるようになっているので試した方も多いと思う。

　

　実際に使ってみると，良くできていると感じる。例えば，コード片の再利用を援助する「コード・スニペット」や，リファクタリングを支援する機能などはとても便利だと感じた。また，「エディット・コンティニュー」も生産性を上げてくれるだろう。

　

　良くできていると感じると同時に，「Visual Basic（VB）ユーザー，特にVB 6.0ユーザーにずいぶんと気を遣っているな」とも感じた。それほど，VBの機能拡張が目立つ。

　

　その最たる例がMyクラスだ。これは，VBのためだけに用意したクラスで，.NET Frameworkが提供する機能の中から，VBユーザーがよく使いそうなものをコンパクトに再構成したものだ。「My」というクラスを基底クラスとしているので，どの機能を使うにしても取りあえずMy以下を探せばよい。

　

　前バージョンまでは，広大な.NET Frameworkのあちこちを探し回らなければならなかった局面でも，Myクラスを利用すればかなり省力化できる。Visual Studioが備えるIntelliSense（※1）を利用すれば，もっと便利に使える。取りあえず「My」と打ち込んでおけば目的のメソッドやフィールドを探していける。

　

　また，フォームへアクセスするコードを書くときに，宣言する必要がなくなった点もVB 6.0ユーザーへの配慮だ。VB 6.0と同じようにインスタンス化（※2）せずにフォームにアクセスできるようになったのだ。しかし，このような仕様変更は，すでに.NETに移行した人から見るとおかしなものに映るだろう。オブジェクト指向の考え方からすると，インスタンス化せずにフォームにいきなりアクセスできるということはおかしいからだ。

　

　また，私はMyクラスにも疑問を感じる。使ってみると確かに便利だが，VBユーザーのためだけにここまでする必要があるのだろうかと思った。.NET Frameworkですでに実現している機能を，他のクラスでまとめ直す必要があるだろうか。こういうことをしていると.NET Framework全体の複雑化につながりはしないかと心配になる。

　

.NETへの移行をためらうVBユーザー

　

　マイクロソフトがここまでする理由はただ一つ。とにかくVB 6.0ユーザーを.NET Frameworkに移行させたいと考えているからだろう。マイクロソフトはVB 6.0の後継としてVB .NETを投入したが，VB 6.0のユーザーはオブジェクト指向を本格的に採り入れたVB .NETの言語仕様に戸惑い，なかなか移行しようとしなかった。また，プログラム部品の基盤が.NET Frameworkに変わったことも，VB 6.0ユーザーを困らせた。基盤が全く変わって，必要な機能がどこにあるのかが分からなくなってしまったのだ。

　

　厳しい方なら「勉強して新しい環境に適応すべきだ」とおっしゃると思う。しかし，当面の仕事を片づけることが最優先になってしまうとなかなかそうも言えなくなる。このような事情から，VB 6.0を使い続けるユーザーも多い。しかし，いつまでもVB 6.0を使い続けるわけにはいかない。マイクロソフトは2005年3月31日にVB 6.0のメインストリーム・サポートを打ち切っている。ここから先は延長サポート期間となり，修正プログラムも有料になる。

　

　このようなマイクロソフトの方針に反発して，サポート延長，あるいはVB 6.0に近い形の新しいVBを求めるユーザーもいるが，そんなことが現実になるとは思わない方がよい。もはや後戻りはできないのだ。VS .NETが登場してから3年が経ち，.NET Framework上でアプリケーション開発をする人も増えてきた。いよいよ.NET Frameworkの本格的な普及が始まったのだ。

　

VB 2005は.NETに移行する最大のチャンス

　

　そこで登場するVB 2005は，VB 6.0ユーザーに配慮した新機能を搭載している。.NET Frameworkにすでに移行した人から見ると奇異に映る機能を思い切って搭載してきたのは，VB 6.0ユーザーへの最大の配慮と言っていいだろう。世間では.NET Frameworkが着実に普及している。VB 6.0ユーザーが.NET Frameworkに移行するならVB 2005が最大のチャンスとなるはずだ。

　

　それでもオブジェクト指向に拒否反応を示して移行をためらう人もいるかもしれない。しかし，よく考えてみてほしい。現在広く普及しているプログラミング言語で，オブジェクト指向を採り入れていない言語がどれだけあるだろうか。つまり，今やプログラマにとってオブジェクト指向は必修科目なのだ。

　

　それでもあなたはVB 6.0を使い続けますか。

　

　

（笹田　仁＝日経ソフトウエア）

　

※1　IntelliSense：途中まで入力すると引数の情報等がツールチップで表示されるというアレです。

※2　インスタンス化：　オブジェクト指向プログラミングで、クラスを基にした実際の値としてのデータのこと。クラスと対比して用いられることが多く、クラスを「型」、インスタンスを「実体」として説明されることもある。

　

　「オブジェクト」とほぼ同義語のように用いられることが多いが、実際にメモリ上に配置されたデータの集合という意味合いが強く、データの実体をより具体的・直接的に捕らえた用語である。

　

　例えば「名前、身長、体重」というクラスがあるとすれば、そのインスタンスは「田中、175、65」というように作られる。

　

**************************************************************