Web制作をしていると、大なり小なり顧客との間でトラブルが発生することがある。トラブルの火種は、どこに転がっているか分からない。もしかしたら、意識なく自分から知らない間に撒き散らしているのかもしれない。

数年間に、あるWebサービス開発の受託業務を請け負った際、請求書を叩き返される、という経験をした。15年以上Web制作の仕事をやっていて、請求書を受け取れないと、目の前に叩き返されたのは初めてだった。

支払いを遅延したり、渋る人というのはいるが、面と向かって請求は受け付けないと言われるケースはあまりない。未納品であるならまだしも、サイトを顧客の許可を得て公開して、それで支払いができないというのは、不条理というものだろう。

この話は、実際にあった話をデフォルメしてフィクションとして書いてみた。トラブルが発生するまでに経緯や火種となったことについて、ひとつのサンプルとして読んでいただければと思う。

Webサービス開発を請け負うことになったきっかけは、Webサイトからの問い合わせだった。Webサービス開発実績のある会社に、新しいWebサービス開発の依頼をしたいと思っている、という内容だ。

その当時は、どんなWebサービスでもリリースすると注目を浴びるほど、Webサービスをリリースすることが流行っていた。最近では審査も厳しくなってきたSNSのAPIを使って、とにかく大喜利のようにWebサービスを、個人や企業が競い合うように開発していたのだ。

Webサービス開発ブームに乗って、リリースしてはプレスリリースを打ちまくっていたので、注目されていたのだろう。Webサービスやコラボしようなんていう相談は結構貰っていた。

先方は、サービスの詳細を説明するために、わざわざ来社してくれるという。アポイントを取って数日後、来社したのは社長とフリーのプランナーだという方の男性2名。今回のサービスの立ち上げのために、会社を設立しようとしているのだという。

話を聞いてみると、サービスの仕組みとしては開発できないことはないが、納品までの期間がかなり短く、ほぼデバッグのバッファはないようなスケジュールであった。
このスケジュールでは、完成できるかどうかがギリギリのラインとなり、品質の保証なんて出来ない、ということは正直に伝えた。

しかし、どこの制作会社でも断られてきたのか、それでも良いからやって欲しい、と食い下がってくる。スケジュールは絶対に提示したままで進めて欲しいと言う。

その時にすぐに対応できるエンジニアは1名、Webサービス開発につかうプログラム言語のPHPは、ほぼ未経験の社員だった。

この時点で受注しなければ良かったのかもしれないが、当時は人海戦術で人を増やして仕事を増やそう、というオーナーのひと声で、仕事がないのに社員を大量に雇ってしまい、とにかく仕事を取らなければやばい状況だった。

仕事を請けるのにあたって、スケジュールはきついから、デバッグなどの協力はして欲しい、多少リリース後にバグ改修が発生するのは容赦して欲しい、ということは念入りに伝えた。何回も念を押した。

そして、制作費用の値引きはなしのこちらの出値、ただし制作前の着手金の支払いは難しい、という条件で業務提携し、発注書を発行してもらった。
Webサービスの開発なので、制作費もそこそこあるので、発注書を貰った時点で経営陣のひとりとしては、ほっとしたのを今でも覚えている。

この時は、久々の大きな案件を受注できたということで、社内の雰囲気も前向きな感じがした。担当の女性ディレクターは、初のシステム案件なので、モチベーションも高まっていた。

仕事がないのに社員ばかりが増えると、社員にやらせることを探さないといけない。会社は自発的に動ける人を求めがちだが、仕事も何もない状況で、自発的にやることを考えて動ける人なんていないのだ。
いや、いたとしても創業間もないどこの馬の骨とも分からない会社には、そんな優秀な人材はやって来ない。

人材不足で悩む会社が多い中、人材過多で悩む経験をした人間も珍しいだろう。

この時は受注したこともうれしかったが、受託制作という社員に割り振れる仕事がしばらく発生することにも安堵を覚えた。

制作に入ると、連日連夜深夜まで制作作業が続いた。休日出勤や泊まり込みの日もあった。スケジュールが短いからと言っても、顧客は妥協することなく、意見や要望は出してきた。しかし、その分譲歩するところは譲歩し、多少のバグなどには目をつむってくれていた。

この時は顧客と協力してサービスを作り上げている、雰囲気がまだあった。
しかし、予想もせず突然にトラブルの火種に火が付いた。

事の発端はSNSだった。

会社のWebサイトに掲載しているTwitterアカウントで、エンジニアが愚痴をツイートしたのを、顧客がみていたのだ。ツイートしていた愚痴は恐らく社内に向けたものだったのだろう。しかし、顧客にとってみると、自分たちに対して言われているようにも見える。

証拠としてキャプチャーされたTwitterの画面が添付されたメールには、「これをみたら電話をください」とだけ書かれていた。

電話をしたくなかったのは言うまでもない。

下手に弁明をするよりは、素直に謝ろうということで、後日オーナーと共に謝りに行った。なんとか直接謝罪をすることで、この時は誠意を感じて矛を収めてくれたように見えた。

そしてサービスは出来上がった。出来たというよりはリリースした、という方が正確かも知れない。
ほぼ無理矢理リリースしたので、細かいバグは操作をすればするほど出てくるような状況だった。

顧客がどんどんバグを見つける中、エンジニアは改修するだけで手一杯、改修が終わってないのに、次々と発見されるバグにパニックになっていた。
パニックというのは伝染するもので、品質チェックをしていたディレクターも、自分が発見するより先に顧客が発見するバグの数が上回っていくことにパニックになっていた。

パニックとなったディレクターは、バグ修正の中に仕様変更が入っていると、仕様変更なのでできません、と率直にメールで顧客に伝えていた。
相手を慮るような余裕はなかったのだろう。
文面はストレートに「できない」ということだけを伝えていたようだ。

このメール対応が最後の大爆発に繋がるとは、この時、誰も予想していなかった。