PR

 Webアプリケーションの公開後に,デザインの変更や掲載データの追加・修正・削除といった,更新作業が必要になることがある。それらの作業を,開発者と顧客のどちらが行うかは,画面遷移や基本設計や見積もりに少なからず影響する問題だ。顧客側の更新作業を実現するなら,企画段階からその仕組みを考えておく必要があるからだ。

顧客自身で簡単な変更ができるようにするための条件

 前回,プラットフォームやブラウザのバージョンアップを見越して,企画段階から,運用と維持について考えておく必要があることを強調した。だが,企画に影響する運用段階の作業は,バージョンアップ対応だけではない。

 機能追加やリデザインや大規模なデータベース更新ほどではない,ちょっとした更新作業が頻繁に生じることも多い。テキストの一部変更や写真の差し替え,色やレイアウトの一部変更,数十件程度までの簡単なデータの変更や追加といった作業だ。

 ところが,Web技術やデータベースに疎い顧客にとっては,CSSやプログラムを開いてコードを書き換えたリ,未経験のデータベース・ソフトに触れるなど,手に余る作業だ。

 そこで,小規模事業者は,顧客との関係を大切にしたいがために,更新作業を一切合財引き受けることが多い。しかし,(手間がかかる割りに)しょせん無償のサービスになりがちだ。

 顧客にしても,ほんの数個所変更したいだけなのに,メールで済まない場合はいちいち打合せを行わなければならない。たった数個所のテキストの変更でも,反映までに時間がかかる。突発的で急を要する作業であっても,土日や連休前に依頼しようものなら,休み明けまで持ち越す恐れもある。

 そこで,顧客が出来ることは顧客自身の手で行う―――内製化とアウトソーシングの分担を刷り合わせて,顧客と業者のいずれにもメリットがある方法を探る姿勢が,Web制作者には求められている。

XMLを利用すれば,設備は不要で,理解もしやすい

 顧客が更新作業を分担するには,気軽に,安心して,日常業務の範囲内で作業に取り組める方法が必要だ。その方法は,次の条件を満たす必要がある。

1) 顧客が,英字のタグやソースコード,データベースソフトに触れる必要がない
2) 特別な設備が不要
3) 入力ミスを二重三重に防ぐ方法がある

 これら三つすべての前提条件を満たす方法の一つとして,ぜひ活用を薦めたいのがXMLだ。表1に,XML利用によって,顧客側でも更新可能となる例をあげてみた(断っておくが,表1の内容は理論上可能なことを挙げているのではなく,筆者が実装経験のある作業の一部だ)。

表1●顧客側更新の可能な作業の一例
表1●顧客側更新の可能な作業の一例
[画像のクリックで拡大表示]

 まず,CSSやデザイン・コードやプログラム・コードの中で,変更可能性の高い値をピックアップし,XML形式の設定ファイルとして別個に作成する。これをプログラムに読み込んで処理すれば,顧客がXMLデータを変更するだけで,Webに掲載するデータや,ユーザー・インタフェース・デザイン(ビジュアル・デザインを含む)を変更することができる。

 また,発信するだけの小規模データベースに限っては,通常ならデータベース・ソフトに格納するところを,XMLファイルで代替することもできる。顧客はデータベース・ソフトに触れることなく,XMLデータを変更するだけで,データベースの中の文字列,年月日,数値等のデータを更新できるというわけだ。

 このようなXMLを利用した更新方法には,大きく分けて,図1のように2種類ある。

図1●顧客側更新の実施と,Webに反映されるまでの流れ
図1●顧客側更新の実施と,Webに反映されるまでの流れ
[画像のクリックで拡大表示]

 一つはWebフォーム上から直接更新する方法だ(図1左)。5~6年前までは,Web上のフォームから入力した内容が反映されるまでに数秒かかっていたが,回線とマシンのスペックの向上で,いまや瞬時に反映されるようになった。

 もう一つは,ローカル・マシン上でデータを更新してから,Webサーバーにアップロードする方法だ(図1右)。業務用ローカル・アプリケーションのXML対応度が向上し,データをXML形式でエクスポートできるツールが増えているので提案もしやすい。特殊分野の案件で,適当な既存アプリケーションがない場合のみ,更新用ローカル・アプリケーションの開発を提案すればいい。

 Webフォームを使う方法のメリットは,なんといっても顧客側に求められる技術が一切ないことだ。デメリットは,Webフォームの作成費や工期が余分にかかること。そして,気軽に更新できるために,入力前の内容確認がおろそかになり,さらに入力後の確認がずさんであれば,誰かが気づくまで,間違ったデータが一時的にでも公開されてしまうことである。

 ローカル・マシンで更新用データを作成する方法のメリットは,基本的に,Webフォームの作成費と工期がかからないこと,そして何といっても,入力ミスを防ぎやすいことだ。アップロードというワンクッションをはさむことで,複数の顧客側社員による入力前の内容確認体制が守られやすい。デメリットといえば,慣れるまでは多少手間なことぐらいだろうか。

 XMLなら,日本語タグが使えるから顧客にもわかりやすい。なにしろ単純なテキスト・ファイルなので,Windowsのメモ帳のようなテキスト・エディタでも開くことができる。特別な設備は不要だ。

 テキスト・エディタで直接XMLデータを変更する方法では,開始タグと終了タグが1セットになっていなければエラーになることを説明して,アップロード前にInternet Explorerで開いて,きちんとツリー表示できているかどうかを確認してもらえば,タグの不整合から生じる不具合を防ぐことができる。

 また,Microsoft Excelなどのソフトでデータを作成して,XML形式でエクスポートすることもできる。日常業務で使い慣れているツールなら,覚えなければならない手順はごくわずかだから抵抗感も少ない。万全を期すなら,あらかじめひな型となるXMLファイルや,スキーマ・ファイルを提供しておけばよい。

 ただし,顧客側更新が有効なのは,フラットかつ定型でノード数が100個程度までのデータ―――例えば季節ごとにWebサイトの配色や画像を変える,毎月のお奨め商品情報を差し替えるなど―――に限られる。階層構造が複雑でノード数も多いXMLファイルを,XMLの知識のない顧客が作成したり編集すると,入力ミスを特定することが難しく,プログラムの誤動作を引き起こしかねないので危険だ。

顧客側更新が必要なケース,不必要なケース

 更新作業を分担する方向でコンセンサスが得られたら,企画段階から更新を反映させる仕組みを考えておこう。

 その仕組みの設計と実装は,概算見積に影響する。作業積算方式で見積もる場合は*1,画面遷移や基本設計がある程度固まらなければ,プログラミングにかかる工数を計算できないからだ*2。

*1 作業積算方式の見積の必要性と概要については,連載「コラボレーションから始めよう!」の第5回 キケン度100%プロジェクトを参照。
*2 企画書と更新作業分担の関係と提出時期については,連載「コラボレーションから始めよう!」の第7回 短納期・低予算のときこそ問われる,開発者の「良心」の図1をクリックして表示される詳細な図の【C】基本設計/企画書,【C】基本設計/画面遷移図」を参照。

 一部をXML化することにより,プログラミング工数が増減する(工数が減ることもある)。Webフォームを作成する場合は,その費用を計上しなければならない。また,更新作業費の一部は,当然,見積もりから省く必要がある。もっとも,どのような案件でも,顧客側更新が有効なわけではない。業者側が1から10まで担当したほうがよいケースがある。この見極めが肝心だ。

 納品後,半年以上に渡って運用し,開発工期に企画設計を練るゆとりがあるケースでは,顧客側更新を考えてみよう。利用期間が納品後半年程度までで,将来的にプログラムやサイト内データの再利用の可能性がない案件では,顧客側更新まで考える必要性は,まずない。もし,更新が必要になったら,業者側がその都度対応すればよい。

 もう一つ,短納期超特急の単発案件がある。小規模事業者には,顧客側から,のっぴきならないお願いという形で,利用期間は長くて数カ月,工期も2週間前後といった案件が持ち込まれるものだ。そのような案件では,デザインについては顧客側更新に対応する必要性はないが,掲載するデータの変更については顧客側更新に対応したほうがよい場合もある。

 例えば,イベントやセミナーのWebサイトのように,運用期間は準備~開催期間中に限られるものの,開催要項データの変更が大いにありうる,といった案件だ。公開直前に,顧客側担当者でさえ予測不可能な変更が生じることすらある。そこで,開催要項だけを,顧客側で変更可能な設計にしておく。顧客も業者もお互いに安心できるというものだ。

顧客側で更新するメリットの例

 一つ具体例をあげてみよう。ここでは,「技術セミナー参加希望者を募集するサイト」をテーマとして,顧客側更新のメリットを説明する。

 普通,こういったサイトでは,参加希望のユーザーは,セミナーの詳細情報を掲載したページにアクセスしてくる。ユーザーは受講したい講座にチェックを付けると申し込みフォームのページに進み,必要な情報を入力する。そのデータはデータベースに登録され,受け付けた申し込み内容がWeb上に表示される。さらに主催者(開発側から見れば顧客)とユーザー双方に,申し込みを受け付けた旨のメールが自動配信される。よくあるアプリケーションなので,どのような流れになるか,おおよそ理解できると思う。

 ここでポイントとなるのが,セミナーの詳細情報を表示するページだ。ここでXMLファイルを使う。具体的には下記のように,詳細データを記録したXMLファイルを作成しておき,プログラムで読み込んで表示すればよい。ただし,このとき“受付”属性値については表示しない。

<?xml version="1.0"?>
<セミナー情報>
	<講座 受付="受付中" 講師="日経太郎" 講座名="Web技術の
       行方" 教室="大会場" 時間帯="午前の部" 定員="150">
	  2007年からのWebサイト制作技術とIT社会の関わりに
             ついて,日経太郎先生が,熱く語ります。
             ~以下,講座内容の説明略~
         </講座>
	<講座 受付="受付中" 講師="鈴木花子" 講座名="ITエンジ
           ニアの心得" 教室="A教室" 時間帯="午後の部" 定員=
             "50">ITエンジニアの知っておくべき基礎技術について
              ,鈴木先生が具体例を交えて語ります。
             ~以下,講座内容の説明略~
	</講座>
	<講座>~</講座>繰り返し
</セミナー情報>

 このようにしておけば,XMLファイルのデータを変更するだけで,表示されているデータも変更できる。「日経太郎」先生の都合がつかず,他の先生が代役を務めるなら,“講師”属性値を変更するだけで済む。顧客は講師名や専門分野を把握しているから,開発者がデータを変更するのと違い,入力ミスも生じにくい。わずかなデータの変更なら,開発者より顧客自らが行ったほうが簡単なことが理解できるだろう。

 データをXMLファイル化するメリットはもう一つある。

 このようなWebサイトでは,各講座の受講希望人数が定員に達すると,申し込みを打ち切る必要がある。そこで,定員に達した段階で自動的に受付を中止するプログラムを実装したいと思うだろう。

 ところが,これだけWebが普及していても,まだ主催企業に置いてある申込用紙に記入してもらったり,電話やファクシミリで受け付けることが,往々にしてある。「断れない人からの誘い」「勢い」「その場のノリ」といった人の気持ちの問題があるからだ。こういったWeb以外の申込みルートがあると,完全な自動化はできない。Webフォームからの申し込みデータと,それ以外の方法で受け付けたデータを集計する作業がどうしても必要になってくる。

 では,どのようにすればよいかといえば,申し込みフォームのプログラムに,条件分岐処理を記述しておけばよい。“受付”属性値が「受付中」の講座については,講座名を表示して選択可能とし,定員に達したら属性値を「満席」に変更する。そして,「満席」になった講座については,選択用のボタンを非表示にして,「定員に達しました。次回開催時のご参加をお待ちしております。ありがとうございました」などと表示すればよいのだ。

 以上のような方法をとれば,ささいな工夫ではあるが,顧客側担当者が自らXMLファイルを修正して,アップロードするだけで小さな変更に対応できるようになる。

 このような作業が,顧客側で本当に可能なのか?といぶかる向きもあるかもしれない。すべての顧客に通用するのかどうかはわからないが,筆者は過去に同様の方法を採用したことがある。顧客側担当者に操作手順を文書化して渡し,公開前にダミー・データで30分ほど操作を体験してもらっただけで,スムーズに運用することができた。

 ここでは,掲載するデータの変更方法を例としてとりあげたが,先の表1のように,ユーザー・インタフェース・デザインに関係する変更も可能だ。XMLデータは,Flashでも読み込んで処理することができる。本稿では取り上げないが,関心のある人は,自分が得意なプラットフォームでXMLファイルを扱ってみると可能性が見えてくると思う。

顧客側更新の実現のために,業者側に求められること

 顧客側の更新を可能にするWebアプリケーションは,デザインとプログラムの両面からアプローチしなければ開発できない。複数の事業者が協力して案件に取り組む場合,各事業者は,XMLという共通の言語でコミュニケーションをはかると,作業がスムーズに進むだろう。

 デザイナーは,企画段階から,斬新で利便性のあるインタフェースを,プログラムによって実現できないかを考えてみよう。ユーザー・インタフェースの設計とプログラムとは切っても切れない関係にある。各ページのリンク関係以上に詳細な画面遷移図の作成は,XMLの構造―――読み込み保存するファイルだけではなく,一時的に構築するツリーも含む―――が固まらなければ難しい。

 また,プログラマは,XMLファイルを扱うコーディング方法を会得しておく必要がある。類似の処理を手がけた経験があればこそ,突発的な仕事の依頼にも余裕をもって対処できる。プログラミング期間を短縮できれば,余った工数を顧客側更新を可能とする設計と実装にあてることができる。プログラミングに費やせるのは1~2週間といった,変更対応設計には厳しいケースであっても,日ごろから手持ちのサンプルを増やしておけば,顧客側更新の可能性は高まるだろう。

 チームやコラボレーションによる受注ではなく,一人の小規模事業者が単独受注する場合も同様だ。デザイン系出身者であれ,エンジニア出身者であれ,顧客から見れば,どちらも「開発依頼先」でしかない。

 デザイン系事業者は画像処理ソフトを使うだけでなく,顧客がよく使うソフト(例えばMicrosoft Office)に親しんでみて,顧客側更新の可能性を考えてみよう。また,エンジニア出身者は,顧客側担当者が技術に疎かったとしても,丁寧に操作を指南し,顧客側のWebに対する認識と能力を高められるよう,歩み寄る姿勢を持ちたいところだ。

 現在の仕事の手を休めて(それが難しいのは,お互いさま),顧客に利便性を提案する方法について,思い巡らしてみるのもよいのではないだろうか。