Visual Studio .NETは魔法の杖か？ 株式会社ピーデー 川俣 晶 2002/07/25

---

魔法の杖シンドローム

　最近、魔法の杖シンドロームという言葉が一部で使われるようになってきた。この言葉は、恐らく、＠IT会議室でbiacさんが命名したものではないかと思う（この件に関する@IT掲示板のスレッド「ASP.NETは魔法の杖か？」）。

　では、魔法の杖シンドロームとは具体的にいったい何だろうか。ここでは以下のように定義してみたい。

• Visual Studio .NETの見掛けに目が眩んで判断力を喪失している状態
• その中でも特に、実現できないことまで実現できると思い込んでいる状態

　このシンドロームは、基礎が分かっていれば実現できないことが明らかであるにもかかわらず、「実現の仕方が分からない」とか、「正常に動作しない」という質問が多発していることから、存在が推定されたものである。特に、Visual Studio .NET（以下VS.NET）の周辺で顕著に見られるようだ。例えばJavaやVisual Basic（以下VB）が登場したときにも、このようなタイプの質問がなかったわけではない。しかし、特にVS.NETでは目立つようだ。

典型的な症例

　例えば、ある入力フォームを持つプログラムを作成するとしよう。チェック・ボックスとテキスト・ボックスが存在し、チェック・ボックスがチェックされている場合のみ、テキスト・ボックスに入力可能にしたいと思うとしよう。具体的には以下のような外見のものだ。チェックしていないときは以下のようになる。

ダイアログボックスの例

このダイアログは、上の［宛先別途指定］をチェックしたときだけ、下の［宛先］テキスト・ボックス・コントロールが有効になる（つまり、宛先を別途指定する必要があるときだけ、テキスト・ボックス・コントロールに入力可能になる）。

　ここでチェック・ボックスをチェックすると以下のようになる。

チェック・ボックスをチェックすると……

チェック・ボックスをチェックすると、このようにテキスト・ボックスが有効になり、文字列を入力できるようになる。

　このような入力フォームを作成することは難しくない。Win32 APIのC／C++レベルでダイアログボックスとして実現することもできるし、VBのフォームでも簡単に実現できる。この例は、C#のWindowsアプリケーションとして実現されている。

　有効、無効を切り替えるコードは、たったこれだけである。

private void checkBox1_CheckedChanged(object s, System.EventArgs e) {   this.textBox1.Enabled = this.checkBox1.Checked; }

　ある程度のスキルがあればだれでも書けるものである。

　では、いまの時代はWebアプリケーションがはやっているから、せっかくVS.NETも買ったことだし、Webアプリケーションとして作ってみようと思い立ったとする。ともかく、Webアプリケーションの新規プロジェクトを開くと、何やら見慣れたVBと良く似た画面になる。「なんだ、VBみたいにフォームにコントロールを並べるだけで実現できるのか」と安心して、さっそく作ってみる。コントロールを並べて、チェック・ボックスが変化したときのイベントに、テキスト・ボックスの禁止・許可を設定するコードを書き込んでみる。そして、フォームはこんな感じになったとする。

VS.NETで作成したWebアプリケーションのフォーム

VS.NETを使えばVBでのフォーム・デザインと同様に、必要なコントロールをドラッグ＆ドロップしてWebフォームを設計できる。

　イベントには以下のようなコードを書き込んだとする。

private void CheckBox1_CheckedChanged(object s, System.EventArgs e) {   this.TextBox1.Enabled = this.CheckBox1.Checked; }

　何も難しいことはない。そして、VBでそうしたように、F5キーを押して実行してみたとしよう。すると、Webブラウザが開いて、自分が作成したフォームが表示されることだろう。こんな風にだ。

作成したフォームをブラウザで表示すると……

上で作成したWebのフォームをブラウザで表示したところ。チェック・ボックスやテキスト・ボックスは正しく配置されているが、チェック・ボックスをオンにしていないのに、テキスト・ボックスが有効になってしまっている。

　この時点で、これを作った彼は大感激かもしれない。しかし、この時点ですでに彼は「魔法の杖シンドローム」の罠に落ちている。すぐに彼はチェック・ボックスのチェック状態を切り替えても、テキスト・ボックスの許可状態に反映されていないことに気付くだろう。実際、上の画面はチェックしてないのに文字入力可能な状態になっている。

　そして、彼は、「チェック・ボックスのCheckedChangedのイベントが呼び出されません!　どうすれば呼び出されるのでしょうか？」という悲鳴のような質問を、掲示板やメーリングリストに書き込むことになる。

罠はどこに潜んでいるのか？

　最初に断っておくが、これはVS.NETのバグではない。基礎がきちんとできている人なら、容易に推測可能な結末である。

　では、彼はどこで間違えたのだろうか?

　それは、Webアプリケーションがどのような構造で動作するのか学ぶことを飛ばして、いきなり従来のVB的なプログラミングの知識だけで、Webアプリケーションを記述できると思い込んでしまった時点である。Webアプリケーションとはサーバ・サイド・プログラミングであり、記述したコードはサーバ上で実行される。しかしフォームはクライアント側のWebブラウザ上に表示される。クライアント側で発生した何かの出来事が、サーバ側にイベントとして通知されるためには、サーバとクライアント間の通信が必要となる。これは一瞬で終わるようなものではなく、数秒程度の待ち時間が発生することは珍しくもない。Windowsアプリケーションのフォームでは、これらの通信は必要ないので、イベント発生は瞬時に処理できるが、それとは違うのである。

　Windowsアプリケーションならチェック・ボックスの状態の変化、リストボックスの選択項目の変化、テキスト・ボックスへの1文字入力などのタイミングでイベントを発生させ、自作コードの処理を入れるのは容易である。しかし、Webアプリケーションでは、これらの処理を入れることは現実的ではない。可能かどうか、ということなら必ずしも不可能ではなく、チェック・ボックスのAutoPostBackプロパティをTrueにすることで、チェック状態が変化したときに自動的にポストを発生させることができる。しかし、ポストを発生させるということは、サーバにリクエストを送り、新しいページ情報を受け取るわけで、データ量が多かったり、回線が混んでいたり、サーバに負荷がかかっていたりすれば、即座に結果が反映されない場合もある。今回の場合であれば、チェックを外してから結果が反映されるまでの時間、テキスト・ボックスの許可状態が変化しないだけでなく、その間にテキスト・ボックスに入力されたデータは失われてしまうのである。つまり、単に「AutoPostBackプロパティをTrueにすれば、Windowsフォームと動作が同じになる」というような、単純な話ではない。

　そのような状況から、VS.NETのWindowsアプリケーションのフォームと、Webアプリケーションのフォームは機能的に等価ではない。Webアプリケーションでは、チェック・ボックスの値が変化したことを通知するイベントは、サーバへのポストが発生した時点で発生するようになっている。逆にいえば、サーバへのポストが発生しない限り、いくらチェック・ボックスを操作しても、イベントは発生しない。チェック・ボックスが変わるごとに通信を発生させるよりも、サーバへのポストが発生したときにイベントが起きる方が現実的に使いやすいといえるのである。その意味で、Windowsアプリケーションのフォームと違う動作だからといって、間違った仕様とはいえない。

　しかし、Windowsアプリケーションのフォームと、Webアプリケーションのフォームにも多くの共通点があるのも事実である。その共通点の部分は、同じ操作で利用できた方が利用者としては使いやすい。実際、VS.NETでは、その種の共通化が実現されていて、使いやすいと感じる。しかし、それはWebアプリケーションについての勉強をせずとも、Webアプリケーションが作れるという話ではない。あくまで共通する部分の操作が共通しているだけの話で、相違する部分は異なる使い方を必要としているのである。

学ぶ手間は減らない

　VS.NETは使いやすく強力だと思うが、結局のところ、プログラマーの力を拡大するツールでしかない。つまりはかけ算で作用する。100の基礎力を持つプログラマーの力を、120に、150に、あるいは200以上に拡大してくれるかもしれない。だが、基礎すら学んでいないプログラマーの力は0である。0にどんな値を掛けても0のまま変わらない。例えば、Webアプリケーションのことを何も知らないプログラマーがVS.NETをいくら使っても、一人前のWebアプリケーションが作成できる保証にはならない。まずWebアプリケーションについて最低限学ぶべきことを学ぶ必要がある。

　そして、これはWebアプリケーションだけに限らない。Webサービスなどほかのタイプのプログラムを作成する際にも、同じようなことはいえる。また、VB 6.0の経験者は、VB .NETをすぐに使えるようになると思うが、それはVB .NETを使いこなしたことにはならない。オブジェクト指向的なプログラミングについて、しっかりと学ばなければ、思わぬところで挫折する危険が待ちかまえている。すべてのVB .NETの開発プロジェクトが、VB 6.0互換の機能だけでコーディングしているとは限らないからだ。

　このような状況から考えれば、魔法の杖シンドロームの原因と処方箋は明らかだろう。ときとして、VS.NETが絶大なパワーを発揮しているような場面を見る機会があるかもしれない。そして、自分もVS.NETを使えば絶大なパワーを発揮できるかのように思えてしまうかもしれない。だが、VS.NETは単なるツールでしかない。あくまで、人間がやることを手伝って手間を軽減してくれるだけの存在でしかない。もちろん、手間を軽減できることは素晴らしいが、それは軽減されなくても最後まで開発できるプログラマーにとってのメリットである。最後まで開発できるだけのスキルを持たないプログラマーは、VS.NETを使っても開発できない可能性が高い。つまりは、VS.NETはコーディングの手間を減らしてくれるかもしれないが、勉強の手間を減らしてくれるわけではない、ということである。これを使いこなすには勉強は必須である。

　だが、いったいどうして、VS.NETでは魔法の杖シンドロームが目立つのだろうか？ これは想像にすぎないが、最初に取り組む敷居が低いからではないだろうか？ 例えば、最初にJavaが登場したとき、JDK（Java Development Kit）をダウンロードしてコマンドラインのコンパイラを使わねばならず、だれでもすぐ使える状況ではなかった。最初にVBが登場したときは、何しろ英語版しかなく、それでも気にしないという筆者のような物好きだけが使うものだった。それに対して、VS.NETは完成度の高い統合開発環境があり、しかも日米間の発売時期のタイムラグも小さく、敷居が低いかもしれない。しかし、敷居の高低は、必要な勉強量とは直接関係ないということである。

　それでは今回は、「VS.NETは勉強する者にのみ福をもたらす」という言葉で締めくくろう。本当はどんなソフトを使うにせよ、同じことがいえるものであって、不思議な力で問題を解決してくれる魔法の杖はどこにも存在しないのである。そういう当たり前のことをふと見失うのが、魔法の杖シンドロームなのだろう。

---

川俣 晶（かわまた あきら）
　株式会社ピーデー代表取締役、日本XMLユーザー・グループ代表、日本規格協会 次世代コンテンツの標準化に関する調査研究委員会 委員、日本規格協会XML関連標準化調査研究委員会 委員。1964年東京生まれ。東京農工大化学工学科卒。学生時代はENIXと契約して、ドラゴンクエスト2のMSXへの移植などの仕事を行う。卒業後はマイクロソフト株式会社に入社、Microsoft Windows 2.1〜3.0の日本語化に従事。退職後に株式会社ピーデーの代表取締役に就任し、ソフトウェア開発業を始めるとともに、パソコン雑誌などに技術解説などを執筆。Windows NT、Linux、FreeBSD、Java、XML、C#などの先進性をいち早く見抜き、率先して取り組んできている。代表的な著書は『パソコンにおける日本語処理/文字コードハンドブック』(技術評論社)。最近の代表作ソフトは、携帯用ゲーム機WonderSwanの一般向け開発キットであるWonderWitch用のプログラム言語『ワンべぇ』(小型BASICインタプリタ)。

「Insider.NET - Opinion」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）