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

河本孝之(Takayuki Kawamoto)

Contact: https://plus.google.com/112326853631114362590/about

First appeared: 2009-02-11 01:39:00;
Last modified: 2015-07-22 12:24:00.

本日*の夜に弊社で対応した作業の話をしたい。もちろん案件の具体的な内容はどうでもよく、自分たちがやっている仕事の目的を整理して、何がいちばん重要なのかを確認しながら進めましょうという趣旨の話だ。

*注釈(2015): 2009年2月10日のこと。以下、本稿で「本日」と書いている場合は同様。なお、再掲載にあたって、本稿では誤記や不正確な表現を修正している。

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

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

つまりはこうだ。毎日、1,000 くらいのアクセスがある。そしてユーザは 5MB ほどの FLASH ムービーを平均して3本くらい観る。単純に言うと転送量は、一日で 15GB になる。さてそのレンタルサーバでは、1日あたり 5GB を超える転送量については、1MB あたり 15 円の超過料金が月末に加算される。しかるに、10,000 MB×15 = 1,500,000 円が月末の超過料金となる。これに、トップページやブログパーツで配信している他の FLASH ファイルの転送量も加えると、200万円の請求など当たり前である。前職で運営していたサイトでは、転送量課金に毎月 600 万円ほど払っていたから、200 万円程度の料金は想定の範囲内である。ていうか、毎日のアクセス数から計算すれば誰でも分かる。いまの同僚にも動画配信の経験をもつ人がいるので、誰に聞いても特にめちゃくちゃな金額だという印象はないようだ。

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

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

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

一つはもちろん、これがどういうサイトなのか知らなくても分かる問題だ。ドメインのプロパゲーションが数時間で完了する保証など、インターネットというネットワークには、もともとないのである。もちろん、こういう「プロパゲーション」なるものが単なる言い訳にすぎず、実は DNS の更新など瞬時に完了するはずだと主張する人々はいるが、ベキ論など言っても事実は動かない。確かに自分で利用しているドメイン管理サービスの TTL を 15 分などとするのは自由だ。しかし、他社の TTL などコントロールできない。VeriSign のように毎秒数回も更新するところがあるかと思うと、TTL の設定を数十時間に設定しているネームサーバを運用しているサーバ会社も過去にはあった。したがって、全てのコンテンツを新しいサーバに移して数時間ほど待つくらいでは、エンドユーザ(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://xxx.xxx.xxx.xxx/rc_directory

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

今回は、ディレクターも自分で PHP の本を片手に要件を理解しようとするくらいの人だったから、このような対応で落着した。しかし、往々にして社内のディレクターが代理店担当者と一緒になって、インターネットの仕組みを知っていればありえない無理難題を「クリエーティビティ」だの「サービス精神」だのと言っては急かしてくることだってある。そういう場合には、もちろん限度はあるが、彼らが本当は何をしたいのかという要求を明確にすることが解決の糸口になるかもしれない。あとは、要件を確定する際に転送量課金の説明は相手にしておくべきだろう。自分たちがオンラインサービスを無料で使いまくっているような「デジタルネイティブ」だと、インフラにどのていどのコストがかかっているのか、実はインターネット世代だからこそ考慮しない風潮があるように思う。

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Google+ Twitter Facebook