ASP.NET Webアプリ開発の裏事情 エピソード4：顧客の無理難題と闘う！ ――　ASP.NETはどこまで『ファンタジー』なのか？　―― 小田原 貴樹（ハンドル・ネーム：うりゅう） 2005/01/26

Page1 Page2

筆者略歴 8年間のベンチャーIT企業勤務を経て、フリーのプログラマとして独立。専門はWebアプリの設計・開発。「生涯一プログラマ」を目標に、常に中小事業者を対象とした現場に立ち続けている。無理難題を要求されても、取りあえず挑戦してみてしまう負けず嫌い。

　

顧客担当者：	「小田原さん、制作してもらったショッピング・サイトで使いにくいところがあってね、改善してほしいのだけど」
筆者：	「あ、問題点ですか。どういったところでしょうか？」
顧客担当者：	「お客さまから注文が入った後、ブラウザの受注管理画面で内容確認するじゃないですか」
筆者：	「ええ。入金確認とか、発送済みかどうかの確認をしてもらうための画面です」
顧客担当者：	「そこで発送済みにしたら、自動的に宅配便の送り状を印刷できるようにしてほしいんですよ」
筆者：	「……ブラウザからですか？」
顧客担当者：	「そうそう。いまは別のソフトに入力し直してるんだけど、手間なんだよね」
筆者：	「……現実的に考えまして、ブラウザの画面から直接送り状を出すのは、不可能に近いです」
顧客担当者：	「えー、ASP.NETなのに？！」
筆者：	「うっ……えっと、少し方法について検討させてください……」

　開発中、もしくは開発後に顧客から飛び出してくるカスタマイズの要望。その要望はシステムの使い勝手に直結している部分だけに、開発側としても極力応えてあげたいところだ。だが、その要望が常にシステム的に見て妥当なものであるとは限らない。むしろ「無理難題」に近いこともしばしばあり、プログラマの頭を大いに悩ませる結果となる。「無理難題」なのが労力的な問題であるならば、コストや納期の問題についてしっかりと打ち合わせをすることで解決されるだろう。しかし「技術的にどーやっても無理」な場合、これはもう顧客担当者とのコミュニケーション勝負になってしまう。

　特にこれまでのクライアント／サーバ・システム（主に、VB 6などによるWindowsアプリケーション）と比較された場合、Webアプリケーションの開発ではWeb独特の制約やルールが存在するために、クライアント／サーバ・システムでは当然の機能がWebアプリケーションでは「無理難題」となってしまうケースが多くなる。

　冒頭の会話、「送り状を印刷する」という要望は、クライアント／サーバの業務システムでは「無理難題」でも何でもない。顧客担当者もそうしたシステムを普段から利用しているので、Webアプリケーションでも可能であると思い込んでいる。だが、クライアント側をブラウザのみで処理するWebアプリケーションの場合、送り状印刷のような微妙な位置合わせが必要な印刷は、現実的に不可能に近い。要望を実現するためには別のアプローチが必要になるだろう。

　ということで、今回は特に中小規模のWebアプリケーション開発現場で、顧客から投げかけられる「無理難題」についてご紹介してみたい。ちなみに今回のキーワードは、「ASP.NETなのに？！」であったりする。

画面表示はスマートに？

　ASP.NETでは基本的に、何かしらのデータをポスト（送信）する先は、常にそのページ自身である。これは特に「ポストバック」と呼ばれるが、筆者はASP.NETの技術面における最大の特長だと思う。ASPなど、既存のWeb系システム開発言語を利用する場合、何かの処理を行いたい場合には、基本的に結果を処理するための別ページへ一度遷移する必要がある。これは、開発面から見てもユーザビリティの面から見ても、たいていの場合は冗長であると同時に操作性を損なうものだ。

　ASP.NETで開発されたWebアプリケーションでは、例えばアンケートの入力フォームにおいて、ユーザーが必要な項目すべてを入力していなかった場合、その同じページ内でエラー項目を表示させ、入力を完結させることができる。また、ユーザーがある商品を購入しようとして注文数量を選択した場合、その数量に応じた購入特典をそのページ内にメッセージとして表示させる、といったことも容易である。

　このようにASP.NETでは、「ポストバック」を利用することで、サイト内の導線を明確にでき、入力をスマートにすることができる。また、ユーザーの操作に合わせてダイナミックなメッセージを提示することで、サイトに遊び心を加えていくこともできるだろう。Webアプリケーションの開発を長く行ってきた筆者にとってみると「ポストバック」のメリットは素晴らしいものだと思うが、もちろん万能であるわけではない。

　あるショッピング・サイトの案件で、上述したような、ユーザーが購入したい商品の数量を選択すると、それに応じた特典をメッセージとして表示するような機能追加を実際に行ったことがある。その後、顧客担当者から要望が入った。

顧客担当者：	「数量に応じて特典を表示するようにしてもらって、分かりやすくていいですね」
筆者：	「ありがとうございます。購入数量が増えれば増えるほど特典が大きくなるので、それを明確にすることでユーザーも購入しやすくなったと思います」
顧客担当者：	「その点は満足しているんですけど、数量を選択すると画面が一度チラつきますよね？ あれを何とかしてほしいのですが」
筆者：	「……え？」
顧客担当者：	「いや、数量を選択した後、画面が一瞬チラつくのが気になるんですよね。スマートじゃないっていうか」
筆者：	「あの、あれは数量を選択した後に一度処理をサーバに投げまして、その結果を再表示しているので、画面がチラつくのはどうしようもないんですけど……」
顧客担当者：	「えー、ASP.NETなのに？！」
筆者：	「いや……もう、それはASP.NETでも無理です……」

　Webの世界の常識で考えれば、荒唐無稽に聞こえる顧客担当者の要望だが、一般的なWindowsアプリケーションを前提にすると、むしろ画面がチラついてしまうということの方がおかしいといえなくはない。ポストバックに加えて、ビューステートなどによる自動状態管理、そしてイベント・ハンドラによるイベント処理などにより、ASP.NETはHTTPベースのWebアプリケーションにおいても、Windowsアプリケーションと同じプログラミング・モデルを実現し、Windowsアプリケーション同様のユーザビリティを提供しようとしていると考えられるからだ。

　筆者のような開発側の人間からすれば、ASP.NETのそのプログラミング・モデルは画期的なことであり、また大きな成功を収めていると感じられることなのだが、顧客やユーザーの側から見れば「チラついてるなぁ」のひと言で片づけられてしまうのも、また自然なことだといえるだろう。しかし、ここまでくると「ASP.NETだから」という問題を大きくはみ出した、Webの根本的な仕様の問題であって、一プログラマがどうにかできる範ちゅうをはるかに超えている。

　すさまじいスピードで進化するインターネット技術の発展によって、近い将来「まったく画面のチラつかない、スマートなWebアプリケーション」の開発が可能になるのかもしれないが、現時点としては顧客担当者にできること／できないことを分かりやすく説明していくしかないといったところだろう。

INDEX
	ASP.NET Webアプリ開発の裏事情
	エピソード4：顧客の無理難題と闘う！
	1．顧客から投げかけられる「無理難題」
	2．顧客の無理難題と向き合う！

　

「ASP.NET Webアプリ開発の裏事情」

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