ASP.NET Webアプリ開発の裏事情 エピソード7：「ユーザー数無限大？」エンドユーザーと闘う！ ――　想定不可能・再現不可能なトラブルを回避せよ　―― 小田原 貴樹（ハンドル・ネーム：うりゅう） 2005/05/21

Page1 Page2

筆者略歴 8年間のベンチャーIT企業勤務を経て、フリーのプログラマとして独立。専門はWebアプリケーションの設計・開発。「生涯一プログラマ」を目標に、常に中小事業者を対象とした現場に立ち続けている。互換性よりも機能性を優先してしまう、新しモノ好き。

　筆者が開発したショッピング・サイトの運用を行っているサポート・センターのオペレータさんから電話が入ってきた。

オペレータ：	「お客さまの中で、どうしてもサイトで買い物が完了しないという方がいらっしゃるんですが」
筆者：	「えっ！ ちょっとお待ちくださいね。確かめてみます……いや、こちらでは正常に完了しますけど」
オペレータ：	「何回やってもだめだということで、かなり感情的になっておられるんです」
筆者：	「えーと、どういったメッセージが表示されるか分かりますか？」
オペレータ：	「『買い物かごの中の商品が確認できません』というメッセージが表示されるそうです」
筆者：	「はっ？ そんなメッセージが表示されるようなプログラムはしていませんが」
オペレータ：	「……当社のサイトじゃないんでしょうか？」
筆者：	「たぶん、そうだと思います……」

　特定の企業のために開発され、主に企業内部のLANで使用される業務系アプリケーションの開発と異なり、インターネット上に公開するWebアプリケーションの場合には、「利用するユーザーの幅」をその公開前に特定することはできない。時間と距離を問わないのがインターネットの魅力であるが、開発サイド・運用サイドにとってみれば、「いつ、どこで、何人くらいが利用するのか」といったエンドユーザーの幅が想定できないというのは、大きな問題である。

　利用するユーザーの幅を開発段階である程度特定できる、業務系アプリケーションの開発においても、エンドユーザーの行う操作が、開発側が想定していた枠を超えてしまってトラブルの原因となることは多々ある（例えば、ユーザーが必要以上にマウスのクリックを繰り返したり、［Enter］キーを連打したりしてしまい、想定外のボタンが押されてしまい何らかの処理が実行されてしまうなど）。それがインターネット向けWebアプリケーションともなれば、エンドユーザーがどういった動作環境で利用するかも分からないし、何より、エンドユーザーと顔を合わせることもないわけで、サイトの挙動に対してクレームが上がってきても、その原因を追究するのが難しく、エラーを再現できなかったりする。

　冒頭の会話に関しては、クレームのメールを入れてきたエンドユーザーが、実は全然違うサイトを見ていたという笑い話のようなものだが、同じ商品を複数のサイトが扱っている場合などには、けっこうよくある話である。要するに問い合わせ先が違うだけなのだが、お客さまからのクレームはクレームなので、丁寧に対応しなければならなかったりする。

　だが、決して冒頭の会話のような、原因の分かりやすいケースばかりというわけではない。間違いなく開発したWebサイトを利用しているのに、どうしてもユーザーが指摘する現象が再現できないというケースも非常に多い。

　エラーの原因を特定したければ、ユーザーの動作環境や操作手順をはっきりさせることが大事なのだが、メールや電話などで相手の環境が見えない状況において、それらの情報をユーザーからすべて聞き出すのは難しい。一般的なユーザーに対して「OSは何をお使いで、ブラウザは何をお使いですか？」と聞いたところで、明確に返答されることはそれほど多くないのだ。

　結局、最終的には「電話でのご注文も承っておりますー」などという、システム開発者にとってはいささか物悲しい方法で解決するのが、一番早かったりするのである。

　ということで、今回はインターネット向けWebアプリケーションの運用時に発生しがちな、顔の見えないエンドユーザーとのやりとりのほんの一部をご紹介しよう。

例外との闘い？入力フォームは主戦場

　Webアプリケーションの開発において、最新の技術を利用すれば利用するほど、OSやブラウザ間の互換性や動作環境上の問題というのは多くなる。そういった観点で考えれば、Webシステムの開発基盤の中でも、最先端技術に位置付けられるASP.NETは、互換性の面では問題が発生しやすい技術であると考えられるだろう。

オペレータ：	「お客さまで、何度やっても自分のメールに注文確認メールが返信されないという方がいらっしゃるのですが」
筆者：	「お客さまのお名前を教えてもらえますか？」
オペレータ：	「○○○さまです」
筆者：	「……メール・アドレスが『XXXXX@yahoo.or.jp』と入力されていますね……」
オペレータ：	「何か問題があるのですか？ そのアドレスにはメールが行かないとか？」
筆者：	「い、いや、ただ単にそんなメール・アドレスは存在しないだけです」
オペレータ：	「ただの入力間違いなんですね。そういった入力間違いを防ぐシステムとかにはできないんですか？」
筆者：	「……それはとてもオオゴトになってしまうんですが……」
オペレータ：	「そうなんですか。プログラミングも万能じゃないんですね……。それとも小田原さんの能力の問題なのかしら？……ガチャッ」

　以前にもいったような気がするが、もう一度、声を大にして繰り返しておきたい。

『プログラミングは万能じゃありません！』

　というか、筆者が万能に程遠いだけなのだが、そんな捨てぜりふで電話を切られると3日間くらいへこんでしまうので勘弁してください。いや、もちろんできますよ。入力されたメール・アドレスの存在を確認する方法はいくつかあり、システム内に組み込むことも可能なのだが、それを実装するとなるとシステムのフローから変更する必要があったり、注文完了までのステップが長くなったりと単純ではないのだ。……まぁ、思い出すだけでも悲しくなってきたので、言い訳はこのくらいにしておく。

　Windowsアプリケーションとして作成された業務系アプリケーションにおいても、ユーザーからの入力を受け付けるデータ・エントリ系の画面の開発には気を使う。参照系の画面と比較して、ユーザーの操作量が格段に多くなってしまうため、イレギュラーな操作が行われてしまう確率がグッと高まるからだ。それでも業務系アプリケーションの場合には、マニュアルを作成したり、前もってユーザーに操作講習を行ったりすることによって、操作に関するかなりの問題点を解決することができる。

　だが、Webアプリケーションにおけるデータ・エントリ系の画面においてはそうはいかない。どういったユーザーがどんな操作をするかの想定ができないため、イレギュラーな操作に対する処理をでき得る限りシステム内に組み込んでおく必要がある。幸いASP.NETにはRequiredFieldValidatorコントロールなど、ユーザーが入力した文字列の内容をチェックするための「検証コントロール」が種類別に用意されており、実装も容易である。

　インターネットの普及に伴い、一般家庭でも当たり前にPCを保有している時代になってきている。そのために、ユーザー間での、PCの操作スキルや、情報リテラシーの差が、大きく開いてきているのは間違いない。

　例えば、筆者は「シニア」と呼ばれるような高齢者の方がエンドユーザー対象のインターネット向けWebサイトを開発した経験があるのだが、なかなかすさまじい入力が繰り広げられることになった。「E-mailアドレスを全角文字で入力」するなどは日常茶飯事で、「フリガナの欄に漢字の氏名を入力」したり、「郵便番号の欄に電話番号を入力」したりと、筆者の想定をはるかに超えるイレギュラーな入力が少なくなかった。

　もちろん、だからといって「エンドユーザーのPCスキルが低いのが悪い」などとは口が裂けてもいえない。インターネット向けWebアプリケーションの開発という、エンドユーザーの幅が想定しきれないものを扱っている以上、あらゆるイレギュラーな入力に対応できるように開発するべきなのだ。誤入力があるたびに、運用者側からエンドユーザーに対して連絡を取って修正するようでは、せっかく「デジタルな入力」をしてもらっている意味がない。そういうコスト的な観点から見ても、データ・エントリ系画面での入力チェックは非常に重要だといえるだろう。

　しかし、どれほど入力チェック・検証を細かくしたところで、完全に誤入力を防ぐことはできない。先ほどの会話のように、E-mailアドレスの一部分だけを間違われた場合などは正規表現による文字列チェックでは対応しきれない。結局のところ、インターネット向けWebアプリケーションの開発・運用において、ユーザーのイレギュラーな操作との闘いは終わることはないのである。

INDEX
	ASP.NET Webアプリ開発の裏事情
	エピソード7：「ユーザー数無限大？」エンドユーザーと闘う！
	1．想定できないエンドユーザーの幅
	2．Webアプリの互換性と動作環境の問題に対する対策

　

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

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