Web上で情報発信していたり、サービスを運営していたりという状態にある人なら、「何か失敗をして大きな問題を起こしてしまったらどうしよう」と考えたことがあると思います。

問題が大きくなり、いわゆる炎上と言われる状態になってしまうと、発端となった問題だけでなく、その問題にどのように対応したかという点も注目され、ユーザーや関係者の心象に影響を与えます。対応によって、さらに大きな問題となってしまうこともあれば、以前よりも信頼できる印象になった、といったケースもあるように見受けられます。このあたりは、顧客からのクレーム対応と似ているところがありますね。

先日、転職サービスの問題点をユーザーがWeb上で指摘し、大きな注目を集めました。しかし、運営側の対応によって、サービスの存続に関わるような大問題とはならず、うまく鎮火したようです。著名人など炎上対応のうまい個人は見かけますが、企業レベルでの対応となると、成功例はそれほど多くありません。

ということで今回は、上記の件の炎上対応について、何がよかったのか？という点をテーマにしてみました。成功例に学び、自分のサイトで問題が起こってしまった時の準備をしておきませんか。

今回、問題点が告発されたのは、はてなの匿名ダイアリーでした。
その名の通り、名前を隠して記事を投稿できるサービスです。

（参考）はてな匿名ダイアリーのヘルプ
http://anond.hatelabo.jp/help

問題の記事が公開されてから、初期対応が完了するまではわずか2日。記事の公開が日曜だったにも関わらず、驚くほどのスピードで情報が更新されていきました。

・9月25日（日）夕方に、はてな匿名ダイアリーに問題の記事が公開される
（参考）転職ドラフト経由でY社の内定貰ったけど
http://anond.hatelabo.jp/20160925170021

・同日、転職ドラフト上に初期対応の記事が公開される
（参考）転職ドラフト経由での選考における提示年収に関する問題について
https://job-draft.jp/articles/92

・9月26日（月）転職ドラフト上に、報告記事が公開される
（参考）提示年収に関する事実確認、転職ドラフトの見解と今後の対策について
https://job-draft.jp/articles/94
 

上記の通り、今回の問題に対する運営側の対応はとにかく迅速でした。問題の記事が公開された日と同じ日に、お詫びとともに「月曜に対応します」との方針が書かれた最初の記事が公開されました。月曜にはその記事の通りに、事実報告や今後の対応についての記事が公開されています。

自社に照らし合わせて、このスピードで対応ができると思った人はごくごく少数ではないでしょうか。最初の記事だけでも、問題発生をキャッチし、対応を決定し、公開する文章を作成して関係者の承認をとり、権限のある管理者にページを公開してもらう、という複数の段階を踏まなくてはなりません。

記事が公開されたのは日曜の夕方です。しかも、公開当初は問題提起をした投稿者に対する批判のコメントもあり、簡単に「即日対応が必要」と判断できるような状況でもなかったように見受けられました。（時間がたった現在からみれば、運営側の問題に多くの批判コメントが集まっており、早期の対応が必要だったことがわかりますが、これを問題発生時点で即時に判断し、対応に踏み切るのは結構難しいように見えます）

今回の件では、運営側が問題をすでに把握しており、すでに対応を進めていたという可能性もあります。しかし、まず即日に問題を把握し、何らかのアクションを取ることが望ましい、というのは確かなようです。

個人の問題提起により炎上してしまっても、その人個人の問題を解決すれば丸く収まる、という訳ではありませんよね。なぜ問題が発生したのかを把握し、個人の問題を解決するとともに、同様の問題が起こらないよう対策を取ることが求められます。今回の事件では、ここもしっかりクリアされていました。

2つめに公開された記事では。何が起こっていたのかが明らかにされ、すでに起こってしまった問題について調査の上での対応をすると明記され、今後同様の問題が起きないようにするための対策についても言及されています。

問題が多くなれば、その他のユーザーや顧客を含む、多くの人が運営側の対応に注目しています。そこには、同じ体験をしたユーザーや、未来の顧客も含まれているでしょう。ピンポイントで問題を修正するだけでなく、その他のユーザーの状況確認や、今後のための対応策についても示すことが必要となります。

炎上対応にスピードが求められるのは「多くの野次馬がいるから」という要因もあるでしょう。問題に直接関わりのない人たちが、関心を失うまでの時間は長くありません。

問題発生から初期対応完了までに時間がたってしまうと、しっかりと対応したにも関わらず、その点には注目してもらえない、という状況になることもあります。この場合、問題が発覚した時点の情報＝悪い評判ばかりが残ってしまいます。難しいことではありますが、やはり、できる限り早期に、できる限り適切な対応をすることが必要です。

そのためにできるのは、どのような問題が起こり得るかをあらかじめ知り、対策を練っておくことでしょう。たとえばオウンドメディアであれば、スタッフがコンテンツの無断転載や誤った情報発信をしてしまった場合にどう対策するのか。商品やサービスについては、現在どのような「貴重なご意見」が来ており、対応重要度（寄せられる数や不満の大きさなど）がどうなっているか、という点が「あらかじめ知っておきたいこと」としてあげられます。

大きな問題になりえることを知っておく、対応をシュミレーションしておくという一見地味な準備が、結局のところ「できる限り早期に、できる限り適切に対応する」という理想の実現のために必要なものではないでしょうか。

この記事では「炎上への対応方法」を取り上げていますが、今回の事件は「1人のユーザーとして何らかの問題が発生した時どうすればいいのか」という点についても考えさせられる部分が大いにありました。

この件でもそうだったように、Web上で多くの人が目にする大問題も、多くの場合、最初はクローズドでの個人の問合せから始まっているはずです。この段階で対応すべき、というのは簡単ですが、そうもいかないという現実がありますよね。対応すべきかどうかの判断には、注目度や影響範囲の大きさも関わってきます。

たとえば、ユーザーから修正要望がたまに寄せられる機能があったとします。実際には不具合が起こっており、しかしこの問題はごく限られたユーザーにしか発生しないという場合、担当者は改善したいと思っていたとしても、権限を持つ複数の関係者から、改善の実施許可をもらうことは難しいかもしれません。

ユーザーの立場としては「公開の場でサービス提供者を批判するようなことはしたくない」と考えてしまいがちですが、そうとばかりは言えません。外部からの圧力がかかることにより、これまで対応に踏み切れなかった改善点が、権限を持つ人のもとに届いて重要と認識される、という場合も（残念なことではありますが）可能性としては充分にあります。

商品やサービスに何らかの問題があったとして、提供側がこの点について「イヤなら使わなければいい」と思っているとは限りません。即時の対応が難しくとも「こうしてほしい」という要望は提供側にとって本当に貴重な情報ですし、公開される場所での問題提起も、時には必要です。

今回の事件は、商品やサービスを提供する側とユーザー側、どちらにとっても有意義な情報を残したのではないでしょうか。とくに運営側としては、事例に学び、しっかり準備をしておきたいところです。