ASP.NET Webアプリ開発の裏事情エピソード8:Webサイトのリニューアルと闘う!―― 1年に1回リニューアル!? 「ユーザーの飽き」との闘い ―― 小田原 貴樹(ハンドル・ネーム:うりゅう)2005/09/17 |
|
Page1
Page2
|
最新技術が気になってしょうがない
本Insider.NETフォーラムの記事を読みながらの社内での会話。
筆者:
|
「……近いうちにVisual Studio 2005がリリースされるんだよ」 |
デザイナー:
|
「そうなんですか。デザイン作業が便利になってるかしら?」 |
筆者:
|
「うん、大幅に良くなっているようだねぇ。しかもASP.NETも2.0にバージョン・アップして大幅に機能も開発性も上がってるみたいなんだよ」 |
デザイナー:
|
「良いことですね」 |
筆者:
|
「で、かなり良くなってるから、これまでに制作したサイトもリニューアルした方がいいんじゃないかなぁ?」 |
デザイナー:
|
「は?……それって簡単にバージョン・アップできるんですか?」 |
筆者:
|
「いや、本格的に作り直すようになるね」 |
デザイナー:
|
「……それって、単に小田原さんがASP.NET 2.0に触ってみたいだけなのでは?……」 |
筆者:
|
「……いや、そんなことは……あるけど……」 |
Webアプリケーション開発業界の技術進化は、まさしく日進月歩である。1年もあれば、まったく新しい技術やノウハウが当たり前のように普及していることは珍しくない。最先端の魅力的な技術が常に発表され続けており、開発者は常に選択の必要性を迫られている。「古い技術=悪い技術」ということではないのだが、「新しい技術=魅力的」であることは誰にも否定できないだろう。
新しい技術には既存のサイトにアドオンするようなものもあり、これは選択さえすれば導入は比較的容易である。たが、根幹から作り直しを要求されるような新しい技術を選択したいのであれば、リニューアルという作業が待っていることになる。
筆者のようなASP.NETにすべてを賭けている技術者の場合、1.0から1.1への移行というのはそれほど問題にならなかった。既存のソースがほとんど流用可能であり、開発環境の移行がメインであったからだ。
だがASP.NET 2.0への移行というのは、筆者の私見では、なかなか大変な作業になりそうに思われる。もちろん既存のソースがまったく無駄になるということはあり得ないだろうが、ASP.NET 2.0(そしてVisual Basic 2005)で提供される豊富な機能を十二分に活用したければ、構文レベル、インターフェース・レベルでの抜本的な作り直しが必要だと考えている。そこまで作り直すなら、もう「サイトのリニューアル」という形で移行するしかないだろうと思われ、いまから頭を悩ませていたりするのである。
せんだって、Insider.NETフォーラムに「特集:Ajax+ASP.NET」という記事が公開された。詳細は記事本文を読んでいただきたいのだが、筆者は気になってしょうがない。これは決して「新しい技術」というわけではないそうだが、自分にとって未知の領域にある技術・ノウハウというのは何とも魅力的である。特に「Ajax」は、Webアプリケーションのユーザー・インターフェイスの機能性を大幅に改善できそうな技術であるため、「あのサイトのあの部分に適用すれば……」などと考え始めると止まらなかったりする。
サイトのリニューアルを促してしまう要因として、新しい技術の登場というのは顧客もエンド・ユーザーも関係ない話であるのだが、「技術者のさが」としては無視できない問題である。多分に「新しい技術が触りたい」という自己満足の部分もあり、それだからこそ最も難しい選択を迫られる闘いだといえるだろう。ちなみに筆者の場合は、極端に負け続けの分野であったりする。
割り切ってリニューアル。解決策はそれほどない。
Webアプリケーションの開発・メンテナンスを業務として行う限り、リニューアルやバージョン・アップとの闘いに解決策はない。何といっても「できるならした方がよい」のであるから、サイトの効果向上のためにも割り切ってリニューアルした方が賢明である。
ただ、すべての場合に置いてリニューアルという大掛かりな作業が認められるとは限らない。そういった場合には以下のような妥協策を考えておくことが大事かもしれない。
-
「飽きの問題」については、目立つ部分を限定的にリニューアルしてみる
-
「機能改善要求の問題」については、効果・効率を念頭に置いて作業に優先順位を決める
-
「最新技術の問題」については、制作者側で選択しスケジュールを決めてしまう
まず1については、例えばWebサイトのトップ・ページだけを大幅にデザイン変更することで、リニューアル風味を醸し出す、といったようなことになる。多分に「逃げ」に近い気はするが、ユーザーの目から見ればトップ・ページが変わっているだけでも、大きく変化したように受け止められるだろう。トップ・ページの変更だけで済めば、全体のリニューアルと比較すると作業量はわずかなものであり、期間・コストともに抑えることができるはずだ。
2に関しては、ある意味「すべての要求を受け入れることはできない」ということである。これは日々の運用・メンテナンスの段階でも重要なことだと思うが、さまざまな機能改善要求に優先順位を付け、優先度の高いものから改善していく。
前述したとおり、顧客、エンド・ユーザー側では要求している機能改善に必要となる手間が判断しきれないことが多いため、制作側である程度誘導する必要があると思われる。もちろん、一番重要なのは顧客の意向であるが、あらゆる機能改善をすべて実施することが顧客にとってよいことだとは限らないだろう。
3については、最新技術の動向を見ながら、制作者が自分自身でリニューアルのタイミングを決めてしまうということになる。筆者の場合は、根幹技術であるASP.NETのバージョン・アップが最も影響の大きいものであると考えているので、各サイトの次回リニューアルはASP.NET 2.0が実際に公開されてからにしようと決めている。
これは、その段階での抜本的なリニューアル作業が最もユーザー側にメリットを提供できると思っているからだが、この部分の判断は技術者ごとに異なるであろう。自分自身にとって重要だと思われる技術の提供が、その人自身の開発面でのパラダイム・シフトではないだろうか。
■
リニューアル/バージョン・アップとの闘いは、Webアプリケーションを開発・運用していれば必ず発生してくる問題である。しかし、そうした作業を要求されるということは、現状の成果に満足感を持ってもらえているということなので、ありがたい話でもある。
今回紹介したようないろいろな要因が、Webアプリケーションのリニューアル要求を生み出すことになるのだが、可能である限りにおいてはどんどん行うべきだと筆者は考えるがいかがだろうか?
一度開発したWebアプリケーションを、改善・改良できるチャンスが与えられることは技術者みょうりに尽きることである。よりユーザビリティに優れたWebアプリケーションを目指して改善し続けるために、自らが率先して闘いの場に臨めるよう、筆者共々努力していただければ幸いである。
INDEX | ||
ASP.NET Webアプリ開発の裏事情 | ||
エピソード8:Webサイトのリニューアルと闘う! | ||
1.「年に1回リニューアル」が基本です!? | ||
2.最新技術が気になってしょうがない | ||
「ASP.NET Webアプリ開発の裏事情」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|