何のための作業なのかを再確認しよう

それは本日、２月10日の夜19時を迎えようとしていた頃だった。そろそろ派遣社員のネットワークエンジニアが定時で上がる時刻（弊社の定時でもありますが）である。なぜか何度も同じ代理店さんから電話がかかっており、「今日はどうしたんだろう」と思っていたら、どうやら外出中のディレクターに連絡を取りたいらしい。ちょうどそのディレクターが帰社したようなので、電話も鳴り止んで暫くした頃、そのディレクターが「えぇ？！」という声を上げる。そして通話を終えると、こちらにそろそろとやってきて、次のような話をした。

なんでも、某社がいま借りている共有レンタルサーバで企画モノの FLASH ムービーを何本か配信しているらしい。先月から配信しているらしいのだが、今月になってサーバ会社から請求が200万もあったと言って、代理店の担当者が血相を変えているのだそうな。

つまりはこうだ。毎日、1,000 くらいのユニークアクセスがある。そのユーザが 5MB ほどの FLASH ムービーを３本くらい見る。単純に言うと転送量は、一日で 15GB になる。さてそのレンタルサーバでは、1日あたり 5GB を超える転送量については、1MB あたり 15 円の超過料金が月末に加算される。しかるに、10,000 MB×15 = 1,500,000 円が月末の超過料金となる。これに、トップページやブログパーツで配信している他の FLASH ファイルの転送量も加えると、200万の請求など当たり前ではないかというのが、アダルトサイトで毎月 600 万ほど払っていた会社に在籍していた僕の感覚だ。いまの同僚にも動画配信の経験をもつ人がいるので、みな特にめちゃくちゃな金額という感覚はない。

しかし代理店やクライアント（しかもクライアントの「システム」部）は上を下への大騒ぎになっていたらしい。そして、弊社のディレクターが電話を受けていたまさにそのときも、転送量はどんどん超過してゆくわけで、クライアントは同じレンタルサーバ会社の上位プランを即座に契約したそうだ。もちろん転送量無制限というスペックのプランだ。さて弊社のディレクターに与えられた「指令」は・・・

サイトを数時間で移動させよ。

これがいかにバカな指令であるかは、最低でも専門学校や初級シスアド講座などでインターネットの仕組みを学んだ人ならすぐにわかるだろう。まず、コンテンツはすぐに移設できる。その点については、（営業時間外という点を差し引くと）なるほど数時間で移設できる量のコンテンツだった。実際に僕が SCP クライアントで現行サーバからダウンロードして、新設サーバへアップロードしなおすと、約 20 分で完了した。しかし、誰でも分かりそうな問題が二つ残る。

一つはもちろん、これがどういうサイトなのか知らなくても分かる問題だ。ドメインのプロパゲーションが数時間で完了する保証など、インターネットというネットワークには、もともとないのである。確かに自分で利用しているドメイン管理サービスの TTL を 15 分などとするのは自由だ。しかし、他社の TTL などコントロールできない。VeriSign のように毎秒数回も更新するところがあるかと思うと、数日かかるようなネームサーバを運用しているサーバ会社も過去にはあった。したがって、全てのコンテンツを新しいサーバに移して数時間ほど待つくらいでは、エンドユーザ（UA）が新しいサーバにリクエストする保証などないと言ってよい。

そしてもう一つの問題は、新しいサーバで現行のシステムが動くとは限らないという点だ。実際、現行サーバは Apache 1.3.33 + PHP 4.4.8 + MySQL 4.0.2 だが、新設サーバは Apache 2.2.1 + PHP 5.2.6 (suhosin) + MySQL 5.0.24 という総換えに近い構成である。加えて前任のシステム部員がこれまた懲りずに PEAR を突っ込んでいるため、いちいちライブラリごとに依存関係を調べる必要があったし、ディレクターから話を聞くと他社の開発者もここで作業しているらしい。

数時間での移設は不可能である。同じサイトで作業している他社のスタッフは連絡がつかないらしく、勝手に移設して動かなくなると、弊社の責任になる可能性もある（クライアントにごり押しされてやったとしても、下請けの責任になることが多いのである）。ディレクターも制作部門の上長も、だんだんエキサイトしてきているようだ。もちろん、こういう逸話を書いているくらいだから、何らかのかたちで解決はしたわけだが、このような状況でディレクターが判断しなければならないことはなんだろうか。

それは、クライアントの「要望」を優先して「要求」を無視することだ。しばしば間違って説明されているが、「要望」はクライアントが望んでいることであり、「要求（requirements）」はクライアントが「自分の要望」として口や文書で表現したものだ。後者は、ウェブサイト制作・構築あるいはウェブシステム開発の多くの現場においても、あからさまに示されているという理由だけで意識の中に優先して居場所を与えられてしまい、受託担当者のディレクションやシステム設計を混乱させる場合がある。なぜなら本当に自分たちがしたいことを正確かつ十全に表現できるクライアント担当者や代理店担当者など、10人に1人もいないからだ。そして、僕らが「あーなかなかデキるな」と思うクライアントやディレクターやプログラマは、たいてい顧客が「抱いているもの」を引き出して実現するように努力するものだ。口先のおしゃべりや紙切れの文字面だけを追いかけて企画書や UML を作成している人々は、こういう場面だと役に立たないのである。

今回、急な作業の依頼なので、はじめは弊社のディレクターもメールの文言や携帯での会話内容に拘っていた。そうした緊急の場合はメールの文章が “agreement of qualification” という意味での「要件」になるからだ。しかし待て。クライアントはそういう発言や依頼文を伝えて、何を望んでいるのか。もういちど彼らが訴えている内容と現状を整理してみよう。

ディレクターと協議し始めると、すぐに向こうも気がついたようだ。要するにクライアントは「サイトの移転」や「ドメインのプロパゲーション」など要求してはいない。要求しているのは、たった一点だ。転送量を抑えて高額な請求を防ぐこと、これに尽きる。そして、プロパゲーションが完了するまで待てないとか、システムが動くかどうか分からないといったリスクを考えるよりも、何をすればクライアントの要求を解決するのか、検討するほうが有効だという結論に至った。

実際に行った対策は、簡単に言うと次のようなことだ。転送量を爆発的に増やしている原因であった .FLV / .SWF ファイルのあるディレクトリを新設サーバの同じ階層（DocumentRoot からのパスを同じにするということ）に配置して、そのディレクトリに対するリクエストを、

RedirectPermanent /rc_directory http://2xx.xxx.xxx.xxx/rc_directory

として、全て新しいサーバの同じ階層・ディレクトリへ飛ばしてしまえばよい。rewrite モジュールを使ってもよいが、転送の条件が特にややこしくない場合はこちらの方がシンプルである。もちろん、ブログパーツや他のページから FLV ファイルを読み込むときは IP アドレスではじまる URL にアクセスすることになるが、ステータスバーをいちいち見ているエンドユーザが何人いるだろうか、転送量が超過することに比べればマシな筈だという説得に、クライアントや代理店も納得していただけた。

今回は、ディレクターも自分で PHP の本を片手に要件を理解しようとするくらいの人だったから、このような対応で落着した。しかし、往々にして社内のディレクターが代理店担当者と一緒になって、インターネットの仕組みを知っていればありえない無理難題を「クリエーティビティ」だの「サービス精神」だのと言っては急かしてくることだってあるのだ。そういう場合には、もちろん限度はあるが、彼らが本当は何をしたいのかという要求を明確にすることが解決の糸口になるかもしれない。