mixiの騒動の延長で、mixiアプリが外部からアクセスしたときにmixi内で全体公開している情報へアクセスできる、という設定について、解除の動きが多数出ました。私も技術的な背景を踏まえた上で解除し、マイミクへ解除を薦めています。
それについて、こんな反応を見つけました。

最近のネットデマについて - 最速転職研究会
http://d.hatena.ne.jp/mala/20101206/1291624685

ここにプログラマやシステムエンジニアなど一般的にエンジニアと呼ばれる人々がサポート兼任できない大きな問題点があるので、今回は記事にします。

この記事で書かれていることは、全体公開している情報にAPI経由でアクセスできるようにするのは問題はない、なぜならばmixiアカウントを取れば誰でも簡単にアクセスできる情報であり、非公開の情報にはアクセスできないのだから、ということです。この指摘は非常に正しく、例示されている相手方がgmailのAPIを使用しているケースやTwitterのプロテクトと同レベルであるということも事実です。そこでこの方はこのような記事を書かれたわけですが、これがエンジニアの視点です。確かに"いまは"その指摘は技術的に正しく、何の間違いもありません。それでは、なぜこのような騒ぎになったのでしょう。いまは技術的に正しいとしてもいつ何時その仕様が変わるか判らないという危惧がユーザ側に生まれてしまったことが最大の原因なのです。

今回の騒動では「メールアドレスを入れることでマイミク申請のメールが届く」という仕様が「メールアドレスを入れることでmixi全体に公開されている情報にアクセスできる」という仕様に修正されました。それもデフォルトが許可です。現在は「あなたのマイミクがあなたの利用していないアプリを使用しているとき、そのアプリは全体公開している情報を入手できる」という仕様であってもいつ「マイミクであるなしに関わらず、あなたの利用していないアプリ経由であなたが全体公開している情報を入手可能」へ変化して、さらに最悪の場合は「マイミクであるなしに関わらず、あなたの利用していないアプリ経由であなたがmixiに入力している全ての情報を入手可能」になって、根こそぎ情報を持っていかれるかわからない、そう考えたわけです。そんなバカな、と通常のエンジニアは笑うと思います。しかし、ここまで考える発想が、技術を理解してさらに顧客心理まで踏まえた対応が必要になるサポートエンジニアの分析視点です。

人の心は技術的な正確性だけでは動きません。プログラマが兼任するサポートエンジニアはここが理解できないので「これは現時点で技術的に正しい、よって問題ない」という対応を顧客にとってしまい、さらに大きなトラブルを招くのです。今回の件も同じです。サポートエンジニアが同じ指摘をするのであれば、このような技術的に正しいから問題ないのだ、すぐに信じるのではなくちゃんと情報を入手して自分で判断しろ、という文章を書くことは躊躇われます。怒り・不安・不満の中にいる人の心情というのは技術的な正しさを指摘したところで素直に動きません。技術的に正しい対応をしていれば素直に動くのはコンピュータだけです。サポートエンジニアは技術的な背景や正しさを理解した上で、顧客にとっての最善を考えるエンジニアです。時にはいまは技術的に正しくても将来想定できる最悪の事態を踏まえてあえて現時点の技術的な正しさから外れる対応をすることも必要になります。これがサポートエンジニアをサポートを理解していないエンジニアが兼任できない理由のひとつです。

この記事はエンジニアとしては正しい反応。しかし、サポートエンジニアならば落第。そういう結論になります。

マイナス方向で話題になることの多いmixiですが、このBLOGでは最近導入された「メアドでマイミク登録」をサポートの視点から考えてみたいと思います。

mixiの流れとしては、自由登録が可能になったあと、マイミクシーをどのように探すか、というところが重要な視点になっています。自由に登録しても探す手がかりがないとリアルの友人が見つからず、退会につながるためです。このように流れで考えると「メアドでマイミク登録」というのは実に理論整然とした流れに沿って導入されている機能といえるでしょう。ところが、サポートの視点から見るとこの流れに大きな矛盾があることに気がつきます。

現在のmixiユーザは匿名での利用者がほとんどです。なぜ匿名かといえば人が激増した上に内部の情報が簡単に流出する現状では、オープンサイトと変わらないからです。そのような状況の中で、mixiでリアルの知人と交流したい場合にはお互いに別の手段でアドレスを交換しているケースがほとんどではないでしょうか。つまり、mixiでマイミクになるという行為自体が既に自分なりのフィルタを通して選別されていることになります。

ここでメールアドレスによって簡単にユーザが検索できる機能が、デフォルト有効で導入されたらどうなるでしょう。mixiでつながりを持ちたくない人に対して「mixiやっていないから」としていた人々の存在が、簡単に一番つながりたくない人に知られてしまうことになります。これはユーザへのサポートとしては最悪な状況です。これがきっかけでmixiから退会する人も現れてしまうであろう、最悪の機能導入になります。こうしたときにユーザの代わりにノーを突きつけるのがサポート担当部署の大きな役割のひとつです。

サポート担当部署というのは、ユーザからの質問に答えるだけの部署ではありません。ユーザから直接受けるクレームのみならず、日々エゴサーチを行って、自分たちのサービスがどのように外部から見られているのかを分析して、時には経営方針に対してユーザの代わりにノーを突きつける役割を果たさなければなりません。だからこそ、イエスマンを重視する日本企業ではサポートを軽視するのだと思いますが、今回も端的にユーザサポート軽視が現れた結果だといえるでしょう。

mixiが今後成長を続けていくには真のユーザサポートの確立が重要ですが、多くの日本企業がユーザサポートを軽視する中、そうした路線をとれるか、注視して行きたいと思います。

日本人は「作る」ことは大好きですが、「作った後」のことを考えないことが多いような気がします。例えば作る期間が1ヶ月だとすると作り終わった後は1年以上の期間が通常は存在しています。システムにしても製品にしても作り終わったあとをどうするか、ということが大切なはずなのですが、そこがどうも抜けているケースは多いような気がします。

日本国内の求人状況を見ているとサポート専任で募集しているのはその多くが外資系企業です。外資は日本進出に当たって、まずはサポート部隊を充実させようという考え方を採るようです。ところが、日本企業はサポートは二の次、問題が起こったらそのときに手の空いている人がやればよいという考え方が多いようで、システムエンジニアなどの募集にはかならず「提案から保守まで」という文言が並びます。

この不況の中で一味違った付加価値をつけるためには外資に見習って、保守体制の充実がキーポイントではないかと考えますがいかがでしょうか。

しばらく間が空いてしまいましたが、また更新をしていきたいと思います。


先日、とあるサービスが個人情報の漏洩をやってしまいました。
メールアドレスがCCで添付されてしまうという不具合だったのですが、サポートをよく知るものとしては、ありえない流れをたどっていましたので、ここでどこに問題があるのを点検したいと思います。

そのサービスではメールアドレスの漏洩が発覚した時点で該当サービスを「緊急メンテナンスのため」ということでいったん停止しました。その後に被害者に向けて、外部非公開のことという一文とその末尾に顔文字をつけたメールで謝罪をしました。被害者は該当サービスのユーザが集まる掲示板で全文を転載します。それを見たユーザはニュースリリースがないことを不審に思い、サポートに対して問い合わせを行います。その後、翌日午後になって、ようやくニュースリリースを掲示します。しかし、該当サービスのニュースリリースには連絡先や責任者氏名が掲載されていない不完全なものでした。

何が問題なのか。
まず、緊急メンテナンスとしてサービスを速やかに停止したまではよかったのですが、ニュースリリースもなく、いきなり被害者へ謝罪メールを投げたのは失策です。謝罪メールの送信と同時にニュースリリースも公開して、広く周知を図るべきでした。
また、謝罪メールを転載禁止としたのは無意味です。転載禁止と書いたことで却って被害者は「ふざけているのか」という思いになり、該当メールは拡散します。
さらに顔文字を載せるなどというのは言語道断です。被害者は謝罪メールで過敏になっているのに謝罪メールに顔文字を掲載するなど真っ当な企業のやることではないと断言できます。
そしてニュースリリースが遅すぎます。被害者への謝罪メールから1日経過してからでは、思い込みや噂がどんどん広がってしまい、解約者が増えてしまっている現状です。このサービスでは日ごろからサポートの質が悪いという不満がユーザの間に存在していたため、さらに輪を掛けて解約者が増えてしまったようです。

今回のケースではどうしたらよかったのか。
まず、1時間から2時間程度遅れてもよいので、ニュースリリースと謝罪メールは同時になされるべきです。さらに可能であれば、期間限定でよいので専用問い合わせ電話窓口を用意して、事態収拾に努めるべきでしょう。「被害者ではないが賠償を払え」といったくだらないクレームには対応する必要はありませんが、サービスへの不満を収集する格好の機会と捉えるのです。被害者以外は直接の被害がないので、日ごろの鬱憤を晴らすだけですが、そうした鬱憤の中に問題点がかなり潜んでいます。さらに収集した声をまとめた上で今後の改善計画をニュースリリースとして公開することで、プラスマイナスゼロくらいには持っていくことが可能です。不祥事はマイナスですが、ここで集めた声を生かしていけば長期的にはプラスにすることが出来ます。
さらに企業としての姿勢をもう一度考え直すべきです。IT系の新興企業にありがちですが、謝罪ニュースリリースに責任者の氏名がない、問合せ先がないというのはありえない問題点です。今回の問題を誰が改善するのか、顔を見せることが重要です。また、謝罪メールは真摯であるべきです。様々な場所へ転載されることを前提にしっかりとした文章を練り上げるべきでしょう。謝罪メールに顔文字なんてありえません。

こうしたことはサポートのプロを抱えていれば回避できる、当たり前の鉄則なのですが、プログラマや営業にサポートをやらせようとするとこうした点がおろそかになります。新興ベンチャーにいま一番必要なのは、サポートの最前線で5年以上のキャリアを持つ、サポートのプロによる構造改革だということがこの事例からも明らかであるといえます。

はてなブックマークボタンが新しくなりました。3つの種類から選べてブックマーク数がわかりやすくなりました。というわけで早速このBLOGでも導入してみました。

はてなブックマークの説明では単一のURLしか出来ないように見えますが、当然変数を代入してしまえばBLOGの個別記事への対応は簡単です。今回私が使用したのは以下のようなタグです。

<a href="<$ArticlePermalink URIESCAPE$>" class="hatena-bookmark-button" data-hatena-bookmark-title="<$ArticleTitle$> : <$BlogTitle$>" data-hatena-bookmark-layout="standard" title="このエントリーをはてなブックマークに追加"><img src="http://b.st-hatena.com/images/entry-button/button-only.gif" alt="このエントリーをはてなブックマークに追加" width="20" height="20" style="border: none;" /></a><script type="text/javascript" src="http://b.st-hatena.com/js/bookmark_button.js" charset="utf-8" async="async"></script>


ArticlePermalinkで個別記事のURLを変数として投入しているだけの簡単なカスタマイズです。タイトル欄があったので一応ArticleTitleとBlogTitleで記事のタイトルとBLOG名をそれぞれ投入していますが、HTMLのタイトルタグのほうが優先的に反映されるようです。

簡単にわかることではありますが、参考情報として記事を上げておきますので、悩んだ方はご参照いただき、願わくば下のボタンからブックマークしておいていただけると嬉しい限りです(笑)