|
一口にユーザー事例といってもイロイロあります。定期刊行物、いわゆるザッシの記事になっているユーザー事例と、企業が広告として作るユーザー事例は目的から違っています。また、大企業では、あえてイメージ広告的なユーザー事例を作るということもあります。
では、どんなユーザー事例が見込み客を呼び込むか、チェックポイントをいくつか挙げてみましょう。イメージ広告的なユーザー事例に、営業マン的な効果が薄いことはすでに述べました。ユーザーの企業名、製品名、カッコ良く、気持ち良さそうに使っている（雰囲気をだす）ことだけしか書いてないのが、イメージ広告的ユーザー事例です。あらためて見返してもらえれば、こうしたものが多いことに気づくでしょう。あとで、その理由を述べます。
製品を紹介しているユーザー事例
次に、製品の名前や機能ばかりが前面に出て、ユーザーや、使っている様子が伝わってこないもの。実際、こういうものも多く見かけます。製品紹介も兼ねてしまっているようなユーザー事例です。ユーザー事例を読む側としては、使っている人や企業について知りたいわけで、興味の対象と、記事の中心が完全にずれてしまっています。
こうしたユーザー事例は往々にして、力の強いマーケティング部門が仕切って作っています。もしくは、マーケティング部門が内製したものだったりします。製品のことを知らせたいという作り手側の強い意向が表れるのです。「正直、ユーザーなんてだれでも良いし、どんな風に使ってもらってもかまわないけど、製品のXXXという特徴だけは伝えたい」なんて考えていたりするわけです。
読む側としては、「そんなことは、製品紹介のところで読んで知ってるよ。これでは、うちでも使いたいという気にはならないな」とか思ってしまいます。というか、特別な理由がなければ、おそらく最後まで読まれないでしょう。文章としての質も低いものが多く、そうした場合は、読んでもらうことが、製品のイメージを下げるというところにまで結びついてしまいます。作るだけ無駄どころか、作らないほうが良いということになります。
読んでおもしろいユーザー事例
そして、次のものも結構あります。「おもしろい」ユーザー事例。私などが読んで「うまい、ざぶとん１枚っ！」とか、言ってしまいそうなものもあります。ユーザーの心理や、根底にある人間ドラマのようなものが盛り込まれていたり、部署間でのせめぎあいの様子、競合他社との駆け引き、役員決済に持っていくまでの準備とかが、緊迫感あふれる文体だったり、スピード感ある簡潔な書き方で書かれていたりします。読み進めるとワクワクしてきて止まらず、一気に１０ページ以上も読んでしまったとか、読み終わって「面白かったぁ〜」などと感じたりするものです。
イメージ広告的に、こういう類のユーザー事例を使うこともあります。しかし、この類のユーザー事例では商談に直接結びつきません。“なんとなく”その商品や会社のイメージが良くなる（かもしれない）だけです。だいたい、こういうものは、熟練ライターだったり、少し名の通ったコラムニストや、広告代理店のお抱えコピーライターが書いていたりします。文章が面白いと、クライアントから気に入られるからです。さっと読めると、ツッコミづらい。有名な人だと文句言いづらい。あれこれと注文が付かなければ広告代理店は楽になるわけです。広告代理店では、クライアントが儲かるかどうかよりも、どこからも文句が出ずにすっきり仕事を進められることを重視することの方が多いのです。
専門家が笑うユーザー事例
あと、これは分野や対象製品にもよりますが、専門家に見せられないユーザー事例というのもあります。ユーザーも専門家ではない、マーケティングも専門家ではない、営業も専門家ではない、さらにライターやデザイナーだって、その製品の専門家ではない。専門家不在で作られるユーザー事例も実は多い。そして、専門家の目に触れなければ、それで良いという場合もありますが、少し知識がある人が見ると致命的な誤解や間違えが、ぼろぼろと見つかったりします。「なんだよ、ウソついてたのか」とか、「こんなことも知らないで売ってるの」などといったイメージをもたれてしまったら、見込み客が去っていくだけでなく、それまで築いた信頼関係は倒壊してしまいます。これも、プラスにならないどころか、「作らない方が良い」ユーザー事例の代表です。
社内に、いわゆる“技術者”がいない商社だとか、あまりに専門性が高くて、研究者しか、詳しい知識を持っていないとか、ユーザー事例作成プロジェクトに専門家の意見を反映させられない環境だったりとか、仕方ない場合もあります。しかし、できれば避けたいところです。もちろん最初から、専門家を参加させようという気がなかったり、技術者の意見は無視しようという考えなら、作らない方がましです。
少し横道に反れますが、技術者の意見の取り入れ方についても考えてみましょう。技術者の意見は取り入れるべきですが、そのまま反映させるというのも問題は多いです。製品や技術をアピールするよりも、問題を回避するため控えめにトーンダウンさせる技術者が多いためです。
なぜそうした技術者が多いのかというと、仕事の内容から身につけた“性分”なので、仕方がないのです。たとえばプログラマーは、特定の処理について、ありとあらゆるパターンを考え、すべてに対処できるようプログラムを作ります。滅多にないだろうという現象でも、それを漏らすことは許されません。普通は考えないことについても「想定の範囲内」に収め、その対処法を用意しておくわけです。つまり技術者として優れていればいるほど、自信のない言い回しを好むのです。
「“XXXだ”と書くと、○○機能が常に使えると思われてしまうから、“XXXの場合もある”くらいにした方が・・・」とか、ユーザーも知らなかった○○機能を使えない例外ケースを想定して、変更してくるわけです。全体を通して、こうした考えに従って変更がなされると、最初に作ったものとは大きく違った、影の薄い、何が言いたいのか分からない文章になってしまったりします。どこまで想定の範囲内にするのか、サジ加減です。書く人にある程度の専門知識があり、ユーザーの知識を補助したり、専門家からの情報をスムースに記事に反映できるというのがベストです。
役立つユーザー事例
さて、「おもしろい事例」というのと似ていますが、「読んでためになる」とか、知識や情報、ニュースなどを与えてくれる事例というのはどうでしょうか。いわゆる編集ページに掲載されている事例記事です。これを企業が作って、営業ツールとして配るとしたら、それは役立つのでしょうか。
答え：役立つ場合と、そうでない場合がある。
これじゃあ、まったく答えになっていませんね。それは、ここまで述べてきたユーザー事例の役立ちかたとは、違った形で役立つからです。
実際、私はかつて日経BP社という新聞系の出版社で、企業システムについての記事を執筆していました。書いたものによっては、取材先や製品のベンダーさんなどから“別刷り”とか“抜き刷り”とかいって、媒体で利用する以外に、該当するページだけを余計に印刷するのをお願いされたりしていました。私は記者だったので、どの程度の料金がかかったのかは知りませんが、ゼロから作るよりは安かったのでしょう。お願いされるものの多くはユーザー事例でした。
これが役に立つというのは、お金を払って載せてもらう広告ではなく、編集記事で取り上げられた、という点です。権威がある媒体であればあるほど、掲載されたことの価値が高まります。公平に判断する（はずの）記者が、注目した製品として取り上げられたんだということで、製品に“ハク”がつくのです。
なので、内容云々ではなく、“あの有名な○○という媒体の記者が注目した”という事実を営業に使いたいわけです。内容は素晴らしいとは限らないのです。
また、これは現在ですが、広告としてユーザー事例を掲載する場合でも、できるだけ編集ページに似せて作って欲しいというのは言われます。広告ということが分かると、あまり読んでもらえないからです。これは当然同意します。しかし、内容は編集記事と同じように作るのは良いとは言えません。
今でもユーザー事例を作ろうと考えている人の多くは、“お手本”として、先にあげた「おもしろい」記事と、この編集記事を頭に浮かべるようです。私にお仕事をご依頼いただく中でも、当然ながら、こうした考えが多いです。もちろん、今でもこっち側も書いていますので。業界に詳しく、専門知識もあって、しかも文章のプロが書くものなんだからということで、“お手本”として考えてもらえるのかもしれません。しかし、編集記事と広告では目的がまったく違うものなのです。
編集記事は、読んだ人がお金を払って、その対価を得るものです。掲載した製品のベンダーさんがメリットを受けるようになんて、これっぽっちも考えていません（すみません）。読者が既存のユーザーさんならば、より良い使い方のノウハウについてを解説し、検討中の読者に対しては、自分が使うのに適するのかどうか考えるポイントだったり、導入する上で注意しなくてはならない点だったり、どうすると低コストで導入できたり、運用できるのか、という点です。場合によっては、注意を喚起するために、便利だと思われて多く導入されている製品の欠点を浮き彫りにするような記事も書きます。
さて、こうした記事を読んで、ある人は、「あ、自分にも使えそうだし、ここにノウハウも書いてあるから買おうかな」とか、「新製品では欠点がカバーされて使えるようになりそうだから、検討しようかな」などと、買う気になるかもしれません。しかし、こうした人はすでにその製品を気にしていた人で、対象製品についての情報が豊富になったということに過ぎません。購買への欲求が強くなったというわけではありません。そうなるように、なんて思って書いていないからです（そう思って書いている記者がいるとしたら、その媒体は信用がなくなってしまいますね）。
つくったユーザー事例
さて、ここまでダメなユーザー事例を列挙してきました。そろそろ飽きてきたのではないでしょうか。この辺りで最後にしましょう。
ユーザー事例では、これまで述べてきたこと以上に重要なことがあります。というか、これが実は最も重要だったりします。また、このことはユーザー事例に限らず、書いている文章のすべて、言っている意見のすべてについて重要です。
何かというと、“やらせ”ではないということ。真実であるということです。実際、ユーザー事例を作るときは、相手に取材と掲載の了解をとって、それ相応のお礼をすることもあります。ユーザーにとってメリットが何もない場合など、お礼は当然かもしれません。
しかし、読者は思った以上に敏感です。また、最初から穿った目で見ているかもしれません。ユーザー事例の取材に協力している、という時点でベンダーやメーカーと仲の良いユーザーなんだ、というのは前提として考えているでしょう。“不具合が多くて動かないと告発する”記事のはずはなく、“使ったらこんなに便利ですよ”ということしか載っていないと考えるのが当然です。
読む前から内容が予想されてしまっていて、その通りだったら、まったく意味がないのです。事実を、より事実らしく伝えるというのが重要になるのです。このため、取材時にも、細心の注意が必要になります。できるだけ事実をそのまま言ってもらうようにします。製品に使いづらい部分があれば、それもそのまま述べてもらい、その欠点をどのように克服しているのか、話してもらうのです。
もちろん後で直すときに、あまりに欠点が強調されていれば、目立たないようにします。しかし、事実を曲げようとすると、胡散臭さが、一気に噴出してしまいます。「１００回やれば１回はうまくいかない。でも自動的にリトライさせてるんで、まったく問題ない」というところを、「すべてうまくいってる」と言い換えてもらったり、そのように書いてしまうと、その一箇所だけで、全体を信じてもらえなくなってしまうこともあります。
今でもあるのかもしれませんが、官公庁や教育機関、大きな病院などだと、使ってもらうことが宣伝になるし、他の何かで利益を出せているので、そこで稼ごうとは思わない。そこで、無料（か、それに近い金額）でシステムを導入する、なんてことがあったりします。そして、ある程度の期間使った（という設定で）感想を聞いて、ユーザー事例を作るというのも、実際にはあるのです。
ユーザーは、あまり使っていないので、感想も何もなく、製品を褒めるだけ。ライターには専門知識がなく、それを鵜呑みに、流麗な文章をつくる。デザイナーが、それをカッコ良いデザインにまとめる。結果できあがったのは、綺麗で読みやすいのだけど、綺麗さや読みやすさが、なおさら胡散臭さを強めるようなリーフレット。先に、私に話を持ってきてくれていれば、と叫んでしまいそうになりました。
実際、こういうのも、やりようがないわけではありません。実際作ったこともあります。事実を正直に伝えればよいのです。使ってもらって感想を聞く、というのは、裏取引でもなければ、別に悪いことではありません。その上で、正直な感想を聞いて書いてあげたほうがよいのです。あまり使わない人がいれば、なぜ使わなかったか、そしてどうなっていれば使っていたのか、そして、その方向で製品の機能強化が行われている、などとすればよいわけです。
| 
