優れたシステム設計に要求される
プロダクト選択のバランス感覚
首都圏コンピュータ技術者協同組合
秋月 巌 AKIZUKI,Iwao
失敗するプロジェクトの遠因には，ニューテクノロジーの無理解によるものが少なくない． 各ベンダーが提供するテクノロジーの持つ意図を正しく理解しないでシステム設計に入ることは，コストの増大につながるばかりか「使えないシステム」をつくりだす理由になる．
まるっきり，動かないシステムは論外としても，現在，進行中のプロジェクトの成否は，設計時の細かい配慮に依存する部分が大きい． しかし，テクノロジーの有効無効を判断をするときに汎用的に使えるセオリーは少ない． 多くの機能が，トレードオフによって新しい能力を獲得しているからである． ニューテクノロジーがもたらす正の部分と負の部分を正しく比較検討することが，プロジェクトを成功に導く秘訣になる．
| ニューテクノロジーと新製品 |
|---|
昨年後半から今年にかけての一年間，私はMicrosoftの新製品を中心とするニューテクノロジーを懸命にサポートしてきた．
特にインターネット上で稼動するデータベースシステムを設計する上で，使える技術に限りがあった昨年の段階では，常に最新のソリューションを採用する必要があったという事情もある．
Active Server Pagesを最初に採用したときは，調査と同時進行でベータリリース版を使って開発し，納品時に始めてリリース版をインストールしたりした．
いくら必要性があったとはいえ，こういうのは正しいプロジェクトとはいえない．
リリース版の発売を待ち，十分な評価をしてから，現実のプログラムに採用するのが正しい姿勢である．
使えるテクノロジーがそろいつつある今年の後半以降は，続々と提供され続けるテクノロジーに対して批判的に接するようにしている．
新しいものを追い続ける行為に疲労を感じてきたことによるのも事実だが，いつまでもテクノロジーのための実験を続けているわけにはいかない，という危機意識によるものが大きい．
この一年間，確かにMicrosoftが提供した製品やテクノロジーには有用なものが少なくない（表1）．
Internet Explorer3.0，Internet Information Server，Active Server Pages，CABファイルによるインターネットダウンロードサービス，そしてActiveXコントロールが作成できるVisual Basic 5.0，ActiveX Documentsなどは，それぞれが，あるいは互いに融合しながら，真に有効なソリューションのヒントになり得る．
|
表1：最近一年で発表されたプログラミングに関連のあるMicrosoft の新技術
|
ここに列挙したのは，すでにリリースされている製品と技術である．この後に多くの未発表技術が登場を控えているわけだが，既発表の技術だけを使っても，斬新で効果的なシステムを作るアイデアには事欠かない．しかも，これらの製品に関しては，障害も含めてすでに評価を行ない，結果として，十分に使えるマテリアルであるという印象を持っている．
特にInternet Explorer3.0は，豊富にアイデアが盛り込まれている優れたブラウザである．開発者の目からみて，このブラウザがNetscape Navigator2.0やHot Javaと並ぶ画期的なブラウザであることは疑いようがない．配布され始めた当初，このブラウザが持つ本当の能力は理解されていなかったように思う．確かに既存のテクノロジーをインターネット用に流用しただけのことなのだが，HTTPベースでバイナリモジュールを動的にダウンロードし，ローカルマシンにインストールして実行してしまうというのは大技である．従来の技術を応用したことで，早期に使える技術として実装できたことの意味も大きい．OLEはInternet Explorerによって，有意義な活躍の場を得たといえるだろう．
ActiveXと銘打った製品は，すべてがInternet ExplorerとIISに帰結する．それはすなわち，Visual BasicとActive Server Pagesに行き着くということでもある．これらVisual Basicをベースとする言語によって開発されたプロダクトが，Windowsプラットフォーム上の各所で稼動するのが，Microsoftが描いている構図である．
もっとも，Internet Explorerが業務システムを構築する上で安定した環境であるかというと，話は別問題になってくる．VBS1.0のモジュールはバグだらけだし，他のツールをインストールすると何の予告もなく，ver2.0に変更されているのも問題である．CABファイルによるダウンロードはしばしば失敗する上，Internet Explorerの妙なキャッシングメカニズムによってプログラムの実行に失敗することも多い．
インターネットという不安定な環境で動作するということが，せめてもの免罪符になるだろうか．今まで，人々にもっとも馴染みの深いコンピュータとは銀行のキャッシュディスペンサーであったが，これがインターネットに代わり，コンピュータが常に正しく動作するという誤解がとけることを祈るしかない．
今まで「コンピュータのような」という直喩は「正確で確実な」ということを意味していたが，これが「運がよければ，すばらしい効果を発揮する」というイメージに代えてくれることをWindowsとインターネットに期待しよう．そうすれば，ユーザーに「コンピュータなのにどうして？」と問われることもなくなるだろうから…
| DCOMとTransaction Server |
|---|
有用なテクノロジーのリストに，DCOMとMicrosoft Transaction Serverを加えるべきかもしれない．しかし，筆者はこのメソッドに対してはまだ，明確な評価を持っていない．クラスタリングと並んで，今後，Windows NTがスケーラビリティを獲得するのに必須のアイテムであることは間違いない．Microsoftが大規模システムの導入事例を作りたがっていることも知っている．また，技術者として，これらを応用したシステムを開発したいという希望もある．
しかし，この技術を必要とするような現場には立ち会ったことがない．それは，私が主に中小規模のシステム開発を行なっているベンダーだからだろう．もっとも，大規模システムのソリューションを行なう業者だったとしても，今の時点では大事をとって使用を避けるに違いない．
この判断の根拠は，直感以上のものではない．本誌5月号の巻末誌「Back Office Magazine」において，私はTransaction Serverを評価している．サンプルコードを変更し，テストを行ない，少なくともRemote OLEよりも，はるかに速く安定している感触を得たのは事実である．評価をした範囲において，製品としてのTransaction Serverを避ける理由は見当たらない．
にも関わらず，現場での使用を躊躇するのは，テスト環境と現場環境との差によるものが大きい．1トランザクションの数が500件以内で，優秀な管理者がセキュリティ管理を行ない，他のアプリケーションが何もインストールされていない環境でシステムを稼動させるならば，DCOMを使用したシステムは，問題なく動作するはずである．DCOMが製品として出荷されている以上，それがある特定の環境上で動作することに疑いはない．
|
COMインターフェイスのネット ワーク最適化 |
|---|
図1：DCOMはネットワークをプログラミングインターフェイスがまたぐ
|
DCOMを使ったシステムを作成する上で問題になるのは，ネットワーク用に最適化したコンポーネント設計のノウハウを，私を含め多くの人が持っていないことである．COMをそのまま分散できるのが，DCOMのセールストークのはずだが，単なる分散配置だけでは，有効な性能を得ることはできない（図1）．分散のための負荷分散が常にネットワークのオーバーヘッドを大きく超えなければ，導入する価値は少ない．それを解決するためには，洗練されたインターフェイス設計がどうしても必要になる．優れたインターフェイス設計とは，優れたコンポーネント分割であることに他ならない．
ある特定の動作をコンポーネント化するということは，動作の中に必ずインターフェイスが介在するということである．コンポーネント化することで，従来できなかった処理が可能になるということではなく，単にプログラムの一部分が再配置可能になるだけのことでしかない．インターフェイスが正しく既定されることにより，コンポーネントが移動しても，呼び出し側は同様の処理を期待することができる．これは構造化によって作成されたサブルーチンの存在と同じ立場にある．
それがプログラミングのインターフェイスである以上，何らかのデータがやりとりされることになる．パラメータがなく，ただ処理を実行するだけならば，それはコンポーネントというより，特定のタイミングで起動されるアプリケーションに過ぎない．このパラメータのやりとりがネットワークを経由するところが，COMとDCOMの最大の違いになる.当然，ネットワーク経由のデータ転送は，ローカルでの作業のように安定した通信環境を求めることはできない．
特にパラメータにオブジェクト変数を設定する場合は問題が複雑になる．インターフェイスを経由するデータがオブジェクトによって隠蔽されるからである．このあたりのノウハウの集積が，今後，行なわれていくことで，COM/DCOMが使えるテクノロジーになっていくことを期待するしかない．
| 分散処理のデメリット |
|---|
|
図2：相互依存しているため，1台が停止すると システム全体がストップする 
|
ベンダーが喧伝している，コンポーネントを分散させれば性能が向上するかのようなうたい文句は疑った方がよい．
分散化のデメリットは，システムがネットワークに依存することによる不安定化だけではない．
分散化されたシステムが正常に機能するには，それぞれのタスクが割り振られたマシンのすべてが正常に動作している必要がある（図2）．
システムを構成しているマシンの台数に比例して故障率は上がるわけだから，単純に計算すると，2台に分散したシステムの障害発生率は，単体時の2倍ということになる．
それをフォローするためにクラスタリングするというならば，マシンはさらに2倍必要な計算になる．
1台のサーバーでできる処理を4台で行なうというのは，どこかコンセプトに間違いがあるような気がしてならない．
確かにマルチティアシステムは上手に設計することで，既存のマシンのスペックを上回る処理性能が期待できる．
CPUの処理スピードに限界がある以上，そのような手段をこうじることで，より高いトータルパフォーマンスを得ようとするのは，テクノロジーが進む方向として正しいに違いない．
しかし，考えてみてほしい．
我々は現在，PentiumUという高速なプロセッサを10万円以下の価格で入手できる．
このプロセッサは，一般的なデータベースシステムならば，24時間で何千万という単位のトランザクションを実行することができる．
もちろん，実際の業務では，これでも不足する場面も多いだろう．
しかし，その場合にWindowsというプラットフォームを使うことが間違っていないかどうか検討する必要もある．
| コンピュータを巡る複雑な環境 |
|---|
Windowsプラットフォームを使う限り，すべてのクライアントマシンで正しく動作するシステムを作成することは難しい．
最大公約数を高いレベルで満たしてくれるならば，それで納得するしかない．
問題は，最大公約数がどのあたりにあるかを，いかにして判断するかである．
メーカーのカタログには，それが完璧な製品であることがうたわれているため，ユーザーや上司がその採用を強制してくることもある．
この判断があやまっていたとしても，責任をとらされるのは担当SEであるのが現実である．
つまり，ある技術が有効かどうかの判断は，すべてSEの自己責任において行なうことになる．
ユーザーとソフトハウスを巡るトラブルの多くは，このあたりの認識が一致しないことから発生するものが多い．
それを防ぐには，エンジニアサイドが正しく現実を把握し，それをユーザーに説明する必要がある．
|
図3：Windowsの実装レベルが低いために， 現実と理想の間にズレが生じている 
|
製品やテクノロジーに関する情報を得るために，雑誌やWebサイトから情報を得る努力は必要である．
努力によって，いくらかのリスクを避けることができる．
そして，システムの構築を成功させるために何よりも必要な配慮は，導入する技術に対して臆病になることである．
このことは，常に意識しておいても無駄にはならない．
Windowsを無条件で信じるのではなく，Windowsをあくまでも疑いつつ，慎重に導入することで深刻な障害を回避できるようになる（図3）．
現在のユーザーは雑誌などによる情報によって必要十分以上に知識を持っている場合が多い．
しかし，それらはベンダーの宣伝によって，判断を誤っていることが多いのも事実である．
誤解によるシステム構築の失敗を回避する指摘ができることこそ，現在，専門家に求められている能力だといえる．
また，エンジニアがテクノロジー指向に走ることも危険な兆候である．
アーキテクチャとして美しいテクノロジーと，現実的な解を提供するテクノロジーの差を区別する判断力も重要である．
ユーザーが知識に振り回されることが多いのとは違った意味で，専門のエンジニアが情報に振り回されることもあるのである．
| JavaとActiveXの構図 |
|---|
美しい解と現実的なソリューションとの違いは，現時点におけるJavaとActiveXについてもあてはめることができる．
Javaの美しいアーキテクチャと，クロスプラットフォームという高邁な思想を“宗教”とするならば，私もまた信者の一人だということになる．
しかし，一年も前からJavaのフルサポートを表明しているにも関わらず，私はまだ実際に使うプログラムをJavaで記述したことがない．
Symantec Visual Cafe Proのエキスパートシステムで，アプレットを生成しそのコードを解析したに過ぎない．
それに対し，後発のテクノロジーであるActiveXコントロールやActive Server Pagesを使ったシステムならば，すでに，いくつも作成し納品している．
この現実は単なる象徴ではない．
どんなに疎まれようと，Microsoftがもっとも現実的なソリューションを提供するベンダーであることは確かなのである．
その尖兵が，常にVisual Basicであることは，本誌を読んでいる方ならばご存知だろう（図4）．
図4：ツールの位置づけ
|
JavaとActiveXの間にある差異は，社会主義と資本主義の差を思い起こさせる． もし，この印象が正しいならば，マーケティング上の分はActiveXにあることになる． もっとも，60年代の知識人が，今日の資本主義の隆盛を望んでいなかったように，多くのエンジニアは，ActiveXの勝利を望んでいないだろう． 私は今年のVBITSの初日最後に行なわれたパネルディスカッションにおける聴衆の反応を見て，その確信を得ることができた．
| 言語の時代 |
|---|
Javaが真に有益なビジネスツールになるには，もう少し時間がかかりそうである．しかし，Javaはいずれ大きく結実するだろう．これは，Microsoftの妨害がはっきりとした形を現わしてきた今日でも，断言することができる．Javaを単なる言語だというならば，それは市場の動向を誤ることになる．OSが単なるOSと呼ばれていた時代が，ついこの間であったことを思い出すべきである．ユーザーは将来，オペレーションシステムが何であるかよりも，Javaアプレットが動作するかどうか，あるいはPコードでコンパイルされたVisual BasicアプリケーションやActiveXコントロールが動作するかどうかという基準でマシンを選択するようになる（図5）．あるいは，構造上難しいが，Visual BasicがJavaアプレットを生成するようになるかもしれない．
図5：アプリケーションの実行モデルの変換
|
-
現在のOSによる覇権が，OS自身の機能によるのではなく，アプリケーションの選択肢によって維持されていることを考えれば，このような結論に到達するのは自然である．短い歴史の中でアプリケーションはOSによって機種依存から脱却したが，今度は言語によってOS依存から開放される．
誰も，いつまでも支配されたままでいたいわけではない．Javaによるムーブメントは，テクノロジー的なブレイクというよりも（実際，Javaには本質的に新しいものはない），Windowsプラットフォームからの解放運動だといった方が的を射ている．
そして，プログラムが言語によって記述されている以上，言語から開放されることは難しい．最後は言語にいきつくのである．開発者にとっては，ますます楽しい時代がくるではないか．
| プログラムの複雑化を解消するためのコンポーネント利用言語の時代 |
|---|
高機能を達成しようとして，開発中のプログラムが複雑化していくことは止むを得ない事態である．しかし，現在の高度な開発ツールを用いるならば，設計は極力シンプルにするのが好ましい．ツールの特性を理解し，ツールに依存した設計を工夫する必要がある．ユーザーは多機能を要求してくるかもしれないが，ユーザーにしたって多機能で動かないシステムよりは，機能が少なくても動作するシステムを望んでいるという意味では，開発者側と利害は一致している．
開発ツールの理解が必須になったために，今日ではプログラムの書けないSEの存在する余地は少なくなりつつある．理屈を知っているだけでは，プログラミングによる障害がどの辺りで発生するかを見極めることは難しい．
Visual Basicを筆頭とするRADツールには適不適があり，向いていない処理を実装するためには，向いている処理を実装するのに比較して膨大な工数が発生する．それを回避するためにサードパーティからコンポーネントが発売されているわけである．結果として，コンポーネントの使用はシステムの構成をシンプルにするのに一役買うことになる．システムの簡略化は，そのまま安定化にもつながる．もっとも，コンポーネント自身に障害があった場合は，かえって回避法がなくなるため，調査は慎重に行なう必要がある．
結局，トラプルを防ぐためには，一にも二にも調査だということになる．
| 最適化戦略とデータベースシステム |
|---|
システム全体からすれば，今日のマシン環境ならば，最適化のために多くの策を弄するべきではない．マシンがコードを実行する便宜を図るよりは，人間がコードを読んだり，開発効率を優先にした方が結果的には得るものが大きい．開発者は，あるプログラム処理を行なうために，自分がいかに楽をするかを考えるべきであって，自分の知的な好奇心を満たすために労力を費やすべきではない．
また，構造化などにより，コードの冗長性を省くことにもそれほど大きな意味があるわけではない．確かに，冗長性の少ないコードは保守性を高め，メモリの消費を控えるかもしれない．しかし，最新のエディタを用いれば機械的な変更は瞬時に終了するし，プログラマの努力によって節約されるメモリは，Windowsのメモリリークよりも少なかったりする．
しかし，データベースシステムにおいて発生するパフォーマンスの問題は，プロジェクトの成否を決定する要因になる．インデックスの設定を初めとするデータベースシステムの最適化戦略は，データベースの設計時に慎重に考慮される必要がある．
結局は，できる限り簡便に作成しておいたものを，完成後，必要に応じて作り直す方が全体の効率が高いことが往々にして見られる．限られたリソースで作成している限り，システムは完全になることはないのだから，どこで割り切るのかが重要な判断になる．
しかし，ストアされているデータが多い場合のデータベースは，神経質に扱っておいて間違いはない．ソースコードの最適化によって1秒の処理時間を0.1秒につめられるかもしれないが，データベースの最適化はインデックスの設定ひとつで1時間の処理を1分につめることすら可能になる（図6）．
図6：クエリーの最適化による処理時間の節約効果
|
-
同じ機能のシステムでも，データが多い場合と少ない場合とでは，システムの構造が大きく変化する．
また，設定する予定のインデックスによってSQL文の書き方がかわってくる．
インデックスがデータの編集入力時のオーバーヘッドと引き換えに参照時にパフォーマンスをかせいでいることは忘れてならない．
また，各RDBMSは独自のオプティマイザを備えていて，見かけ上のパフォーマンスを確保するが，そのためのアルゴリズムに関する資料は，誰もが手に入れられるというわけではない．
たとえば，Microsoftの膨大な英文Webサイトのどこかにあるからといって，それが一般的な情報であるということはできないだろう．
| まとめ |
|---|
回避しなければいけない障害が多すぎるという意味で，システム構築は以前よりも現在の方が難しくなってきている．
RADツールの発展によってプログラムが誰でも開発できるようになるというのが迷信であったことに，すでに皆が気付いている．
また，新しいテクノロジーが増加するにしたがって，消えていくテクノロジーもまた増えているのである．
スキルはわずかな間に陳腐化し，新しい技術は習得する間もないうちに新しいバージョンによって不安定化する．
これらの狭間で，波乗りのようにニューテクノロジーと付き合っていくのは，良心的で責任感のあるエンジニアにとって楽なことではない．
そして，トラブルを回避するために必要な最適化のための情報が，オブジェクトによって隠蔽されてしまっている．
この事実は，コンポーネントがブラックボックス化し，トラブルの回避方法が提供されなくなってきていることをしめしている．
つまり，トラブルは発生する前に回避するのが懸命だということになる．
そのためには，安定稼動した実績のある方法だけを用いるのが確実だが，すでにそれだけでは対応できなくなるところまで顧客の要求は高度化している．
結局，どのあたりで妥協するかのバランス感覚が，今日のシステムを作成する上での重要な要素なのだろう．
VB Magazine ライブラリ | Visual Basicコースホームページ
int21 ホームページ | PCDN ホームページ
