Webアプリケーションは，作るのも大変だが運用・維持するのも大変だ。納品すれば終わり，とはいかず，構築後にも様々な作業が発生する。それらの作業を企画段階から見込んでおけば，安定した運用を顧客に約束することができる。
企画段階で見込むべき，運用と維持の作業
Webアプリケーションは，開発時のテストをクリアしたり，公開時に正常に動作すればよいというものではない。顧客との関係が継続している間は，365日24時間，つつがなく動作しなければならない。納品後，交流も年末年始のあいさつ程度になった顧客から，数年ぶりにサポート要請のメールが舞い込むこともある。
期間限定の案件でもない限り，運用中には何がしかの課題が発生する（表1）。筆者の経験の範囲内で，作業内容と見積金額に対して，顧客に理解してもらいやすいと思われるものから順番に並べてみた。あくまで，必要性に関して「理解を得られやすい」順であって，「納得して発注してもらいやすい」順ではない。
 |
| 表1●Webアプリケーションの運用・維持段階で派生する主な作業 [画像のクリックで拡大表示] |
このうち，顧客の理解が得られにくく，かつ手間のかかるのがバージョンアップ対応だ。サーバーOS，プラットフォーム，クライアント側のマシンのOS，ブラウザ，W3C仕様など，複数の不確定要素を視野に入れておかなければならない。機器のように形がないので，顧客への説明も難しい。
しかし，ことは動作や表示に直接かかわる問題だ。不具合を放置すると，ユーザーを逃してしまう。信用をなくしてしまうことだってある。企画段階で，安定運用は最低限のラインであることを，顧客と確認し合っておかなければならない。
ブラウザの差異は，永遠の課題？
Webサイトが普及し始めた当時から，ブラウザの差異は大きな課題だった。サーバーサイド処理が増えブラウザも進化し，かなり改善されてきたものの，どのブラウザでも完全に同じ表示になるわけではない。
特定のブラウザのバージョンアップに対応したことによって，過去のブラウザで表示できなくなったり，レイアウトが崩れることもある。例えば，単純なXHTMLとやCSSのWebページであっても，XHTMLの策定以前に発表されたブラウザでは，Unicodeでは＊1表示できないケースがある（シフトJISでは表示できる）。
＊1 W3C，XHTML1.0仕様書。 |
すでにベンダのサポートが打ち切られて，ダウンロードできないブラウザでも，使い続けているユーザーはいる。そういったユーザーがターゲットに含まれる場合は，Webサイト上で旧バージョンへの対応打ち切りの期日を告知して，最新ブラウザへの移行を促すメッセージを発信し続けることになる。そうなると，打ち切り日までは対応せざるをえない。
サーバーサイド処理であっても，ビジュアル・デザインは基本的にはCSSで実装するので，表示結果はブラウザのCSS対応度に左右される。ブラウザのバージョンアップによってズレや重なりが生じた場合は，各ブラウザに対してサーバーから吐き出されたコードを見て，不具合の原因を突き止めなければならない。
ただ，インライン・スタイルシートを追加して補強すれば，サーバーサイド処理で吐き出されたCSSよりも優先して適用されるので解決できないことはない。絶対座標指定のところを相対座標に修正しただけで整うこともある。
気の抜けない，プラットフォームとブラウザにまたがる対応
過去のブラウザの対応期間中に，複数のブラウザのバージョンアップがプラットフォームのバージョンアップ（開発ツールのバージョンアップとしばしばセットになるが）に前後することもある。2006年は，Mozilla Firefox 2.0とInternet Explorer（IE）7.0が相次いでリリースされた。
サーバーサイド処理のWebアプリケーションなら，基本的にはユーザーのブラウザごとに最適な結果を返してくれる。しかしそれは，プラットフォームが開発された時点で標準だったブラウザに対してである。
後方互換性により影響を最小限に抑えられたとしても，開発ツール上で変換してビルドしただけでは済まず，手直しが必要になることがある。サーバーサイド処理で吐き出されたスクリプトの解釈がブラウザによって異なるからだ。プラットフォームと対応ブラウザの，どちらが先に開発されていたかで不具合が生じてしまう。
このような不具合は，過去のブラウザへの対応を打ち切る前に，開発ツール（含プラットフォーム）と複数のブラウザがバージョンアップするというような，バージョンアップ要件が重なったときに発生しやすい。最新の環境に合わせたために，過去の環境で不具合が生じるわけだ。
筆者は，複数要件が重なることが予測される場合，1カ月以上前から，バージョンアップの日程を調整して，制作/開発/サーバー管理の各チーム・リーダーに，バージョンアップ当日の待機をお願いしている＊2。万が一の不具合が生じた場合でも，デザイン，プログラム，サーバー設定について，最短でモアベターな解決策を実行できるからだ。事前に，公開用サーバーと同じ環境に設定したテスト・サーバーでテストはするものの，それでも100％とは限らない。
| ＊2 筆者が，単独受注ではなく，デザイナー主導型プロジェクトの一員として動いている案件の場合（前連載「コラボレーションから始めよう」第1回を参照）。 |
デザインとロジックを明確に切り分け，それぞれの専門家が万全を期して作業していたとしても，必ずしも，表示の不具合の原因がデザインだとは限らないし，動作の不具合がプログラムによるものとも限らない。また，それぞれが自分の専門知識に捉われて原因を探ると，考えが固定されて逆に原因を見つけにくくなることもある。
さらに，原因を突き止めたとしても，必ずしもその原因の解決に全力を注ぐことが，最短でモアベターな解決法だとは限らない。エンドユーザーにとって支障がないと思われる程度であれば，スルーして顧客の意向を伺ったほうがよいこともあるし，根本的な解決に時間がかかりそうなら，応急処置を施した後で原因を探ったほうがよい場合もある。
また，バージョンアップにより新しい機能が追加されると，Webアプリケーションの安定性や利便性，処理の高速化のためにも，部分的な再開発を考えたいところだ。しかし，それには時間がかかる。顧客側の予算があっての話である。
つまり，バージョンアップ対応には，人手も工期も設備も必要であり，その結果，費用もかかるわけだ。
メンテナンスへの設備投資と予算計上
運用と維持の問題は，小規模事業者側の作業の進め方や設備投資にもかかわってくる。
ブラウザのバージョンアップがあると，過去に手がけて現在も運用中の案件を確認する作業に追われる。重篤な不具合があれば即座に修正し（幸い筆者はこれまでそのような事態には遭遇したことがないが），表示上の小さな不具合であれば，1～2週間の間に修正を施し，対応ブラウザの情報を書き換える。そういった作業が，案件の数だけ，一時期に重なる。
もちろん，迅速な対応が要求される。プログラマの相方は，正常な動作さえしていれば安心しているが，筆者の本業はデザイナーなので，ささいな表示のズレを見つけただけでも冷や汗ものだ。
商品販売を伴う小規模案件を数多く手がけているケースでは，バージョンアップ対応は煩雑を極めるのではないかと想像する。案件の数をこなすには，小規模事業者同士のネットワークやバックアップ体制を敷いておく必要があるのではないだろうか。
ブラウザのバージョンアップでは作業が一時に集中するが，逆にプラットフォームのバージョンアップ作業は，顧客側の予算との絡みでばらばらと訪れる。すべての案件で一斉に作業が発生することは，まずない。そのため，バージョンの新旧が重なる半年間ほどの過渡期には，両方の作業が混在する。
当然，開発用マシンも複数台必要になる。筆者の場合は，2～3年前まではWindows95，98，Me，2000の環境でのサポートを継続していたし，プラットフォームはといえば，最近ようやく，.NET Framework1.0（3世代前）のサポートが不要になったところだ。
開発ツールやプラットフォームには，1台のマシンに新旧バージョンを共存させて切り換えることができるものもあるが，旧バージョンへの機能追加やリデザインやデータベース更新などを行いつつ，併行してバージョンアップ対応を進めるとなると，プロジェクト名を変更していたとしても，同じマシンでの作業はミスを引き起こしやすくなる。
SOHOの小規模事業なら，パソコン1台で気軽に始められると考えがちだが，それは危険だ。静的なWebデザインやFlashコンテンツの制作に特化するので限り，開発環境，テスト用Webサーバー，バックアップ回線等の設備投資も考えておかなければならない。そして，設備費の一端も捻出できないような，とことん安価な概算見積ならば再考する必要があるだろう。
アプリケーションの開発技術を持つだけではなく，開発したアプリケーションを長期間にわたってメンテナンスできる体制も持っていなければ，顧客に「安心」を提供できないのではないだろうか。
新技術採用の是非と，開発着手のタイミング
開発ツールの次期バージョンの発売が間近な場合や，有力な新技術が登場したばかりで開発を依頼されると，企画書に新技術の採用について盛り込むかどうかも検討しなければならない。また，開発着手のタイミングを正式版の発売間近まで延期するかどうかは，スケジュール表にかかわってくる。
W3Cの仕様のどの段階で実装を決意するかという問題もある。ワーキングドラフトや推奨勧告の時点で，ブラウザやミドルウエアがサポートしていることもあるからだ。CSS，DOM，XSLT，XQuery等も，これにあたる＊3。
| ＊3 一方，SVGのように，ワーキングドラフト段階でプラグインが発表され，広まっているにもかかわらず，勧告後にプラグインのサポートが中止になるケースもある。 |
採用してよい技術を見極め，使うべきか見送るべきかを検討し，採用を提案するのであれば，企画書に明記する。技術に明るい顧客で「開発目的さえ達成してもらえれば，技術は問わない」という人もいれば，逆に技術に疎いことをサラリと言ってのけ，「よくわからないから，最短安価でやってくれればいい」と一任する人もいる。
後者の技術に疎い顧客とは，サーバーの初期投資と運用経費についても，討議しよう。Webアプリケーション開発当初の予算が少なく，2年目以降に売上が見込まれる事業であれば，運用経費がかかったとしても，初期投資を抑える必要があるかもしれない。逆に，初年度から投資できるのであれば，次年度以降の運用経費を抑えるほうが喜ばれるだろうからだ＊4。
開発費だけでなく，バージョンアップやメンテナンスにかかる予算も視野に入れて，長期的に見て顧客のためになる方法を検討すればよいのではないだろうか。
| ＊4 参照記事。http://coin.nikkeibp.co.jp/coin/itpro/hansoku/nc20061113_1.html |
顧客よりもむしろ開発者のほうが，新技術に消極的な場合がある。だが，初回開発目的を達成しやすく予算化できそうなら，新技術や新バージョンは積極的に採用したほうが後々のバージョンアップ回数が少なくて済むし，長期的に見れば費用を抑えられるはずだ。
筆者は，IE3.0でCSSを，IE5.0発表と当時にXMLとXSLTを採用してきたが，それで何かマズイ事態が生じたことはない。むしろ，構造とデータと表現が分離できたぶん，蓄積してきたデータを利用しやすくなった。
中堅の制作会社やシステムハウスでは，安定した古い技術を使う傾向があるようだが，筆者が知るエンジニア出身の小規模事業者の中には，そういった会社の方針と折り合わずに，SOHOを志した人も少なからずいる。普遍性や将来性のある技術であれば，迷わず採用すればよい。旧技術使用の同業他社と棲み分けができるという，事業所運営上のメリットもある。
長期スパンで予算を考え，定期メンテナンス料を算出しよう
以上のように，企画段階では，提案する機能だけ固めればよいというものではない。
個人商店や社長の鶴の一声で予算がつくような顧客でない限り，販売促進や宣伝の予算は，半期～1年前に検討するものだ。あらかじめ顧客に運用経費を知らせておかなければ，将来的にバージョンアップが必要となったとき，予算を捻出できないということになってしまう。かといって，エンドユーザーからの質問や苦情を避けたいがために無償で対応すると，メンテナンスは無償という実績を作ってしまうことになる。
そうはいっても，ベンダーからのアナウンスがあるOSやプラットフォームのバージョンアップはまだしも，クライアント側のOSやブラウザについては予測が立てにくい。
そこで，小規模案件なら納品後1～2年先，随時更新・追加されるデータベース利用の案件なら3年～5年スパンで長期運用計画を立てたうえで，現状を切り取って企画書や概算見積書に落とし込めばよい。
運用期間中に見込まれるバージョンアップ作業を書き出して，半期あるいは1年単位での平均的な予算を算出し，定期的なメンテナンス料として提出するのだ。
そうすれば，作業が簡単に済む時期と手間のかかる時期があっても，運用期間中を通してみれば，最終的には常識的な費用で作業を行ったという結果になるだろう。
