| 永久プログラマー |
このところ、ハードウェアとソフトウェアが車の両輪のように、うまく歩調を合わせて、進化している。7、8年前、Windowsやページ記述言語のPostScriptに出会った時、どうして、こんな大げさなソフトウェアが必要なのか、疑問を持った。8086や68000など初期の16ビットMPUが全盛の時代に、システムサイズが600KBや1MB近い基本ソフトは、処理速度も遅く、普及するとは思えない代物であった。
4、5年前、WindowsやPostScriptが米国で定着したのを見て、｢ソフトウェアの開発には時間がかかる。ハードウェアの急速な進歩を見越して、数年先を先取りしたシステムデザインをしなければならなかったのか｣と合点した。
そして現在、開発に時間がかかるはずのシステム・ソフトウェアが、ハードウェアと同じスピードで、どんどん変化している。
新しいソフトウェアが矢継ぎ早に発表される背景には、米国を中心としたコンピュータ・サイエンスに対する基礎研究の充実と、膨大な良質のソフトウェア資産の蓄積、そしていくつかの極への開発の集中が挙げられる。極とは、マイクロソフト、アップル、IBMなどのシステム・ソフトウェア・メーカーである。
システム・ソフトウェアの変化が激しくなると、アプリケーション・ソフトウェアの開発者は、その理解のために、開発時間の多くを割かれることになる。Windowsにしても、開発キットに添付されているサンプル・ソース・プログラムを試し、入門書を読み、プログラマーズ・リファレンス・マニュアルを眺めないと、その｢思想｣は理解できない。 DOSには、思想など存在しなかったが、Windowsは明らかに思想を持っている。思想に反した使い方やプログラミングを行なうと、Windowsはぎこちない動きをしてしまう。
ソフトウェアの作成工程は、設計、開発、試験の3工程で、工数は各工程でちょうど3等分されると昔からいわれてきたが、Windowsのアプリケーション開発では、その前に｢調査｣という工程が入る。思想を理解する工程である。Windowsは、グラフィックス、テキスト操作、メモリ管理、フォント操作、デバイスドライバなどで様々な思想を持っている。DOSでは生き字引きが何人もいたが、Windowsのすべてを理解している人は、世界中探しても見つからないであろう。Windowsプログラマーといっても、開発実績を持つ特定分野のことは理解していても、他の分野については素人である。新しいソフトウェアを作る時には、Windowsプログラマーといえども、先ずは調査をして、あれこれ試してみる必要がある。
Windowsだけをとっても、たくさんのソフトウェア技術者が毎日、たいへんな苦労をしながらプログラミングしているのが、日本の現状である。その上、今後、C++を理解し、クラスライブラリの使い方を覚え、OLE2やODBCを使いこなさねばならない。
昨年のComdex/Fallで華々しくデビューしたMicrosoft Office4.0では、アプリケーションが画面上にアイコンとして表示される、新しい試みがなされている。また、Word6.0では、ダイアログ内にメニュー展開用の｢タブ｣という新しいユーザ・インタフェースが採用された。MDI(複数文書操作)、OLE(オブジェクト結合手順)などの例に見られるように、アプリケーション開発チームが実現させた基本機能を、システム側が取り込むのがマイクロソフトの通例となっている。アイコン表示やタブもその内、OSの機能として組み込まれるのであろう。Windowsの次バージョンであるChicagoで、タイトルバーの文字列表示が左寄せに変わっても、アプリケーションでは何の変更も必要ない。しかし、タブをサポートするためのは、ユーザ・インタフェースの設計からやり直さなければならない。
Excel5.0のような、3Dの立体感のあるダイアログの作成でも、Windows3.1の開発キット(SDK)を使って実現するには、結構苦労した。それが、VisualC++1.5のMFC2.5には、標準ライブラリとして入っているらしい。VC++1.5にはもっと大切なOLE2対応のクラスライブラリや、ODBCの各種ドライバも入っている。Accessエンジンもロイヤリティなしでアプリケーションに組み込んで使えるのである。開発環境も、いつになく速いペースで改善されつつある。
システム・ソフトウェアや開発言語が、急速に進歩する｢過渡期｣であるため、プログラマーは勉強の連続になってしまう。過渡期といっても、この状態が21世紀まで続く可能性があり、Windowsソフトウェアを開発しようとしても、どこから、何に手を付けて良いやら分からない状況となりつつある。高級なクラスライブラリやオブジェクト指向OS、Visual Basic for Application(VBA)のような1ランク上の開発ツールの出現など、待てば待つほど、充実した開発環境でプログラミングが行えることが目に見えている。 パソコン・ハードウェア本体の｢半年で旧型機｣と同じサイクルにシステム・ソフトウェアも突入してしまった。東芝の部長さんが言っていた｢最高のダイナブックが欲しければ、死ぬ1日前に買いなさい｣というブラックジョークが笑えなくなってきた。 最高の開発環境で仕事をしたければ、死ぬ1日前に着手しなさい｣ではプログラマーは誰も笑えない。
開発に着手したプロジェクトでは、更に話は複雑である。
A君は優秀なWindowsプログラマーである。彼は、1年半ほど前に、｢これからはC++の時代だ｣と一念発起して、マイクロソフトC/C++7.0とクラスライブラリMFC1.0を使って、アプリケーションを作り始めた。半分ほどプログラミングした時点でVisualC++1.0が米国で出荷された。その開発環境の良さやMFC2.0の高級な機能に刺激されて、VC++に開発環境を移行した。MFC1.0は、Win16APIにクラスライブラリの皮を被せただけの簡単なものである。彼はこの上に、独自の高級なクラス構築していたのだが、MFC2.0が見事にそれを葬ってくれた。MFC2.0に合わせて、モジュール構造から作り直すのに6ヵ月ほどを費やした。
そして、今、彼はVC++1.5への移行を真剣に考えている。ソフトウェアを出荷できるのは、いくらがんばっても今年の年末。その頃にはExcel5.0やWord6.0の日本語版も出ているに違いない。｢OLE2をサポートしないソフトなんて、みんなに見向きもされないのでは?｣と心配している。VC++1.5に付属しているMFC2.5のOLE2サポート機能は魅力である。独自に裸のOLE2をサポートするなど、ひとりでプログラミングを行なっている彼にとっては気の遠くなる話だ。マイクロソフトはMFC2.5でOLE2をサポートするために、2万行ものプログラミングを行なっている。これを使わない手はない。
Win32も気になる。半年も待てば、VC++2.0が出荷されて、32ビットで高速に稼働するアプリケーションが作れるであろう。Win32APIは、マイクロソフトが推奨しており、Macへの道も開かれるので、ぜひとも対応したい。このままVisualC++1.0で開発を続けるか、1.5に乗り換えるか、はた又、2.0まで待とうか。とにかく、MFC2.5のOLE2部分は使うことに決めたようである。
Chicago、Cairo、OLE、ODBC、MAPIなどの登場、そしてVisualC++の立て続けのバージョンアップで、｢僕のプログラミング・スピードより、OSや言語の変化の方が、速度が速い｣と、彼は嘆いている。今年の終わり頃には、オブジェクト指向OSであるCairoが姿を表わすであろう。すると、Win32APIよりも、はるか上位のプログラムインタフェースがクラスライブラリとして提供されることになる。完璧なソフトウェアを目指す、プログラマーの鑑のようなA君は、Cairoへの対応をすぐに検討するであろう。
こうして、プログラマーとしてA級の技術を持つA君は、プログラミングをやり続け、いつになってもソフトウェアが完成しない｢永久プログラマー｣となるのである。
Windowsプログラミング環境の変遷
| C/C++言語 | 対応API | クラスライブラリ | 対応OLE |
| C6.0 | Win16 | ||
| C/C++7.0 | Win16 | MFC1.0 | |
| VisualC++1.0 | Win16 | MFC2.0 | OLE1 |
| VisualC++1.5 | Win16/32 | MFC2.5 | OLE2 |
| VisualC++2.0 | Win16/32 | MFC3.0 | ? |
Microsoft Office 4.0 と Word6.0
Officeでは、画面右上にプログラムアイコンが常駐する。
Wordでは、｢タブ｣(見出し)という新しいインタフェースが使われている。
#10「ビル・ゲイツに囲まれて(前編)」