ASP.NET Webアプリ開発の裏事情 エピソード8：Webサイトのリニューアルと闘う！ ――　1年に1回リニューアル！？ 「ユーザーの飽き」との闘い　―― 小田原 貴樹（ハンドル・ネーム：うりゅう） 2005/09/17

Page1 Page2

筆者略歴 8年間のベンチャーIT企業勤務を経て、フリーのプログラマとして独立。専門はWebアプリケーションの設計・開発。「生涯一プログラマ」を目標に、常に中小事業者を対象とした現場に立ち続けている。ASP.NET 2.0が正式公開されたら、リニューアルの嵐になるのではないかと恐れている今日このごろ。

　エピソード7からすっかり間が開いてしまい、お待ちいただいていた読者の方がいたら大変申し訳ない。決してサボっていたわけではないのだが、別の記事を書かせてもらったりしているうちに、いつの間にか夏まで終わってしまっていた。基本的に「兼業・遅筆・シングルタスク」の三重苦を抱えていて、本当にいつも遅くなってごめんなさい。反省します。

　さて、言い訳はこのくらいにして、今回はWebサイトに付きものの「リニューアル」との闘いをご紹介しよう。

「年に1回リニューアル」が基本です！？

　インターネット向けWebアプリケーションを納品した、クライアントの経営者との打ち合わせで。

経営者：	「小田原さん、そろそろウチのサイトも公開してから1年が経つよねぇ」
筆者：	「ええ、アクセス数も順調に伸びてきています」
経営者：	「そうそう、問い合わせも増えてきて、売上にもつながってきていると聞いているよ」
筆者：	「ありがとうございます。何とか効果が出まして安心しました」
経営者：	「それでね。その効果をさらに上げるためにも、そろそろリニューアルしたいんだよね〜」
筆者：	「えっ！ たった1年でリニューアルするんですか？」
経営者：	「うん、だって飽きてきたんだもん」
筆者：	「あ、飽きてきましたか……。いや、もちろんやらせていただきますが……」

　Webアプリケーション、特にインターネット向けのWebアプリはとにかく「風化」が早い。Webサイト運用の基本的な作業として「定期的な更新」が挙げられているように、必要な業務を処理するためのツールとして用いられる業務アプリケーションと異なり、インターネット向けWebアプリケーションは「情報提供の場」としての役割が大きいからだと思われる。

　業務アプリケーションの場合には、一度開発したら最低3年〜5年は同じものを利用することが一般的だろうが、インターネット向けWebアプリケーションをそんな期間作りっぱなしのままにしているとしたら、確かにそれは大問題であろう。

　Webサイトの効果を向上させるためには、新規ユーザーのアクセスを集めること以上に、リピーターに定期的に訪問してもらうことが重要だといわれる。月に1回Webサイトに訪問するリピーターがいるとしても、まったくサイトの情報が更新されなければ、翌月には同じようにアクセスしようとは思わなくなるだろう。定期的な情報の更新・メンテナンスはWebアプリケーションの運用においては絶対条件なのである。

　だが、「リニューアル」ということになると話は変わってくる。インターネット向けWebアプリケーションのリニューアルというのは、全ページに渡るデザイン面の刷新を含む、大幅な改訂作業であるからだ。

　しかも「リニューアルしよう」ということになれば、機能の拡充や冗長な操作の見直しなど、プログラム面の大幅な変更も要求されることが多い。ふと気が付けばリニューアルというよりは、新しいWebサイトを作っているのと何ら変わらないだけの作業量になったりする。

　サイト運用に関するノウハウ本などを読んでいると、「Webサイトはすべからく年に1回はリニューアルをするべきである」なんて書いてあったりする。これは、冒頭の会話に出てきているようにユーザー側が「飽きてしまう」という問題が前提として存在しているからだろう。いかに情報を定期的に更新していようと、見栄え（デザイン）が変化しなければ、人間というのは段々と飽きていってしまうようだ。

　初めてサイトを訪れたユーザーはともかく、何度もサイトに訪問してくれる、ある意味ありがたい存在であるリピーターからすれば、20回も30回も同じ枠組みのものを見るのはおっくうになってもおかしくはない。

　だが、1年に1回必ずリニューアルをしなければならないとなると、制作側としては少なからず苦痛に感じる。それなりの料金や期間がもらえるのならば仕事として喜べるのであるが、リニューアルの場合には新規構築時と比べて、作業量的にはそれほど変わらないにもかかわらず、料金や期間は大幅に少なくなることが少なくない。インターネット向けWebアプリケーションの効果を上げるためには必要だと分かっていても、なかなかしんどい話なのである。

機能改善要求が止まらない

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

オペレータ：	「サイトのことでいろいろと直してほしい個所があるんですけど」
筆者：	「はい。どういった点でしょうか？」
オペレータ：	「まず、注文が入ったあとに送られてくるメールの件名に、通しの注文番号を入れてほしいです」
筆者：	「はい、件名に通し番号ですね。分かりました」
オペレータ：	「次に、注文申し込みの中で、備考を入力できるようにしてください」
筆者：	「備考の入力をできるように……ですね。分かりました」
オペレータ：	「あと、獲得したポイントを画面上で分かるようにしてほしいというメールがお客さまから入っているので、そちらも修正してもらえますか？」
筆者：	「……えーと、ポイントを画面上で分かるように、ですね……」
オペレータ：	「あと、やはりサイトを会員制にした方が顧客情報を統一できて……」
筆者：	「ちょ、ちょっと待ってください。まだ、あるんですか！？」
オペレータ：	「ええ、あと3つほどありますけど……」
筆者：	「……打ち合わせに訪問させてください……」

　インターネット向けのWebアプリケーションというのは、結局のところ「ホームページの1種」にすぎないわけなのだが、実際の運用に携わるオペレータから見れば、日々の業務にかかわる「ツールの1種」でもある。

　そのため、不具合があれば業務遂行の妨げになってしまうし、少しでも効率よく作業が行えるように改善していきたいと考えるのも自然なことだろう。その辺りは一般的な業務アプリケーションに対する感覚と何ら変わることがない。

　ただ、業務アプリケーションと異なるのは、サイトの向こうに「エンド・ユーザー」が存在しているという点である。サイトの不具合や機能性の問題で、エンド・ユーザーからクレームが入ってくれば、そこはお客さまのご意見であるので最優先で解決しなければならない。

　また、昨今のインターネット向けWebアプリケーションは、機能面においてもさまざまなユーザビリティが要求されているため、これも「サイトの効果」をより高めるために、機能改善要望が発生するのも当たり前のことだといえる。しかし、前回でご紹介したとおり「想定しきれないエンド・ユーザー」の要求に応えていくことは、なかなか骨の折れる作業なのである。

　一方、機能改善要求や修正依頼を出してくるクライアントのオペレータや担当者、経営者といった人たちは、当たり前のことではあるが、プログラムに関しては素人である。

　そのため、自分たちが依頼している作業の中で「何が大変で、何が簡単か」という判断が、専門職であるSEやプログラマとはかみ合わないし、たいがいのものがすべて簡単だと思われている節がある。上述の会話でも、15分で終わりそうな修正と、1カ月かかりそうなカスタマイズまで一緒になっている。

　この「機能改善要求に対する温度差」というのが意外とあなどれない問題で、全部が簡単だと思っているからこそ、どんどん修正依頼が出てくることになる。だが、制作側に取ってみれば「手間＝コスト」であるし、複雑なカスタマイズ作業をあまりいい加減な要件定義で制作するわけにもいかないので、慌てて打ち合わせに赴くことになったりする。そして見積もりを出すと驚かれたり、不審そうにされたりするのもお約束なのである。

INDEX
	ASP.NET Webアプリ開発の裏事情
	エピソード8：Webサイトのリニューアルと闘う！
	1．「年に1回リニューアル」が基本です！？
	2．最新技術が気になってしょうがない

　

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

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