新規サービスの制作中サイトが公開状態だった!


Webサイト制作の案件を請負えば、成果物をクライアントに確認してもらう必要があります。

 

ワイヤーフレームやビジュアルデザインのような中間成果物のクライアント確認は、ミーディングの場で画面を見せながら説明し、サイトで公開するHTMLデータの確認依頼は、自社で確認用のサーバを構築しクライアント自身にアクセスしてもらって確認するケースが多いかと思います。

 

その際、確認用のサーバを誰でもアクセス可能な状態にしておくと、公開前の情報が流出してしまうので大問題になります。

 

そのため、ベーシック認証やIP制限をかけるなどして、関係者以外は見れないようにする必要があります。

(当たり前のことですよね、、、)

 

ですが僕は過去、これが徹底できておらずクライアントに大変な迷惑をかけたことがあります。

 

自らの戒めとして、ここに歴史を残したいと思います。。。

 

案件の概要

とある教育サービスを展開している会社の新サービスの立ち上げの案件でした。

要件の一部に、更新業務はクライアント自身でたちである程度行いたいとのことだったので、CMSの導入が検討していました。

 

「ブログのような機能を設ければいけるのでは」という考えのもと、当時は、WordPressのようなCMSは存在していませんでしたが、

 

ブログといったらMoveble type!

 

というくらい有名だったMTを使って要望を満たすことにしました。

MTが得意な制作会社と手を組み、提案~デザインまでの上流工程を、僕の所属する会社が担当し、HTMLテンプレート~MT実装~公開までを僕ディレクションのもと、制作パートナーという体制で仕事をしていました。

 

問題発生

デザインまでは順調に作成し、制作フェーズに突入。

 

いきなりMT開発ではなく、テンプレートとなる主要なページを作成し、クライアントの確認を経てMTへの組込みをしましょう、という流れでした。

 

作ってもらったHTMLを、自社で用意した確認サーバにアップロードしてもらい、クライアントに確認依頼を数回出すなど、何の問題もなく進んでいました。

 

もちろん、用意した確認用サーバにはベーシック認証をかけていましたので、タイトルにあるような問題は心配していませんでした。

 

主要ページのテンプレートMTMLの作成も完了し、

 

ではMTに組み込んで出来上がったらまたご連絡します。

 

というやりとりを経て、組込みフェーズに移ってからしばらくしたある日、、、

(以下、クライアントをCとします)

 

Tel 「とるるー」

 

僕 「はい、△△△△株式会社です。」

 

C 「至急で確認したいんですが(ちょっと重いトーン)」

 

僕 「は、はい。どうぞ(不安、どきどき)」

 

C 「今、■■■というワードで検索したらgoogleに表示されてるんだけど、これはどういうことか説明してもらえますか」

 

僕 「えっ(汗)、至急確認します。お待ち下さい」

 

急いでマウスをカチカチしなじがら、検索してみると、確かに表示されてる。。。

 

なんにしてもコーディング担当してる会社に確認だな。

にしてもなんだこのドメイン???

 

僕 「大変申し訳ありません。至急調査しますので、お待ちください」

 

急いで制作パートナーに個人携帯に電話をかけ、調べてもららいました。

 

15分ほどで原因はすぐさま判明。

 

なんと、

  • テンプレート制作を別会社に発注していた(僕らには内緒だった)
  • その別会社が制作用に使っている開発サーバには、ベーシック認証をかけておらず誰でもアクセスできる状態だった。
  • さらに、URLをちょっと変えてアクセスするとこの別会社が作っているであろう別サイトの構築中のサイトも閲覧できてしまう。
  • おまけに、制作部隊はバングラディッシュにあった。

 

ということが判明。

 

icatch_.nopng

え〜、マジかよ~。

 

急いで、関係者を集めて、至急以下の対応をとることを決定し、クライアントへ説明しました。

  • Googleに該当URLの削除依頼する。
  • Googleのインデックスから削除されるようにRobot.txtに記述する。
  • バングラディッシュの確認サーバにベーシック認証をかける
  • さらに、IP制限も設ける。

 

説明後、事業部長とともに謝罪に行き、その場にいたクライアント側の技術担当者から、「念のためSSLも設定してください」というリクエストがありました。

 

制作パートナーは平謝りで、上記のリクエストにプラス、バングラデシュのHTML制作会社からすべての仕事を巻き取って対応するということで、これらすべての顛末書にまとめて、収束しました。

 

いやー、僕らの知りえないところだったとはいえ、商流上、制作パートナーの責任は、すべて発注元である僕らが責任を負っているというのを改めて体感した出来事でした。

 

この経験から得たこと

この苦い経験から、僕はプロジェクトを進める上で、以下の点を必ず確認するようにしました。

  • 社外パートナーに頼む際は、必ずこの体験を伝え、どういう体制で作業をするのかを確認する。(完全に内制するのか、別会社に発注するのかを確認)
  • 確認サーバには必ずベーシック認証がかかっていることを確認する。

 

「この体験を伝えたうえで」が非常に重要なポイントです。

 

SI会社では、二次受け、孫請けといった仕事は一般的なので、たとえ気がついたとしても、「そうなんですねー、商流は御社とだけでいいんですよね?」程度で、そこに触れることはなかったと思います。

 

Web屋も例外ではなく、二次受け、三次受けは当たり前のようにされていたので、制作パートナー側もわざわざ伝えてくることはありませんでした。

(最近では、二重派遣などは問題視されたので、そういった請負は変化していると思います)

 

でも、過去の体験を説明し、「別会社にお願いするようであればそれは教えて下さい」と伝えると正直に話してくるように僕は思います。

(顕在化したときのリスクが大きいということが伝わるからですかね)

 

まぁ、以降、同じような問題は起きていないですが、貴重な体験でした。

なかなかレアケースなので、遭遇するのは難しいかと思います。

 

昨今、オフショアがはやっており、中国だけではなく、ミャンマー、ベトナムなどに制作を発注する動きがあります。

なので、制作工程はより安価なところに移っていくことと思います。

(2015年現在、中国の値段が上がってきたので、ミャンマー・ベトナムが人気だそうです)

 

上記の問題は、お国柄の問題ではなく、プロジェクトにおいてプロジェクトマネージャーの目の届く範囲が広くなることを意味し、広くなればなるほど考慮しなければならないことが増え、手落ちの部分も出てきます。

 

WEBサービスを上流から下流までワンストップで対応することを売りにし、かつ上流工程に強いという会社は、下流をパートナーに任せることが多いと思います。

そういう会社でディレクター、ないしはプロジェクトマネージャーとして働いている方は、他人事ではないと思います。

明日はわが身です。ふんどしを締めなおしましょう。

 

終わりに

初期構築が終わったタイミングで、僕は別案件にアサインされてしまったので、その後一緒にお仕事することがありませんでしたが、その後、当時の営業が必死にくらいついて、2年後にまた別案件の発注をもらうことができるほどの関係にまでなったとのことでした。

 

結構大変だったと思いますが、仕事がなくても足しげく通っていたという話を聞いて、営業努力は報われるんだなって思いました。

 

Author:yukio iizuka
プロフィール画像
フリーランスとしてUX視点で業務支援しています。 HCD-Net認定 人間中心設計専門家 LEGO®︎ SERIOUS PLAY®︎ メソッドと教材活用トレーニング修了認定ファシリテーター Hi-Standard好きです。
http://yukioiizuka.com
mislead
MISLEADの記事に共感いただけましたら
いいねをお願いします。

コメント一覧

コメントはありません

コメントを残す

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください



       

© yukio iizuka All Rights Reserved...