趣味プロダクトといってもTumblrテーマの話。2012年からTumblrテーマをいくつか公開してきたが、それは同時にユーザーサポート業務との付き合いの日々でもあった。当初は捌けていた問い合わせも、いよいよ作業量がきびしい雰囲気になってきた。特にここ半年ほどは、なんとかしてフロー効率化や改善を試みている。ここにその4年間の振り返りを記す。
いきさつ
自作のテーマ各々はMITライセンスで公開しており、無保証である。ユーザーサポートも「してもしなくてもいい」状態だと思ってるけど、都合上サポートできるものはサポートしている。というのもTumblrでは、自作のテーマをストアの審査に出すとき「ユーザーサポート用メールアドレス」を申請しないといけないからだ。テーマガイドラインにも「ユーザーからテーマに関する質問が送られてくることは避けられません」とある。
実際、確かに避けられなかった。今までそこそこ色々な種類のお問い合わせがやってきて、それらに返事を書いてきた。以下、実際に起こった困りごとをもとに都度対処してきた記録である。当然サポートの知見も経験も一切なかったので、都度いろいろな方法を手探りしていくほかなかった。全体の方針としては、極力ローコストになる方法、手間を省いていく方法を模索した。
なお、以下「来た問い合わせに答える」立場で書いているが、逆の立場（問い合わせる側）に置き換えて読むこともできる。そのときは、同様のことを気をつけるとサポートしやすくなる。
窓口を一本化する
人にもよるだろうが、ぼくはサポートのやりとりはメールのみで行いたい。窓口として意図していないところから問い合わせが来るのを防ぐため──具体的にはTwitterのDMやFacebookのメッセージで問い合わせが来るのを防ぐためだ。DMでやりとりすると、返事をしないままツイートなどしていると印象が悪いので、ネット上での行動がかなり制限されてしまう。こうしたリアルタイム性の強いサービスは、サポートになるべく使いたくない（チャットのようなリアルタイムでサポートが行えるサービスも登場しているが、しっかりサポートコストをかけられる組織が使うべきだろう）。
もともと自分のサイトにはメールフォームを設けていたので、TwitterのBioで「お問い合わせはこちら」という感じで自サイトのフォームへの誘導を常に出すようにした。
ただし、Tumblrの テーマページ には、サポート用メールアドレスがでかでかと表示されてしまっている。そのため、フォームを介さず直接このアドレス宛に問い合わせてくる方もいる。海外ユーザーの問い合わせは大抵このメールアドレス宛で届く（余談だが、問い合わせ全体の3〜4割は海外ユーザーである。ぼくは中学英語もおぼつかないのでとにかく勘でメール書いてる）。メールでやりとりできれば窓口は一本化できている認識なので、無理にすべての問い合わせをフォーム経由にしようとは思っていない。
URLを添えてもらう
テーマサポートで最も困る（かつ頻出する）のは、「どのページのことを問い合わせているのかわからない」ことだ。例を挙げると「自分のブログのxxという画像がうまく表示されない」といったもの。手がかりはメールアドレスとハンドルネームしかない。これではURLがわからないから調査不能である。メールアドレスからブログURLを推測するなどエスパー行為を試みたこともあったが、限度がある。「URL教えてください」といちいち聞き返すのも面倒だ。
したがって、問い合わせフォームに「問い合わせたいページのURL」欄があるとスムーズに事が進む。URLがないとサポート不能なことが身に染みて理解できたので、自分が他のサービスで問い合わせるときは必ずURLを添えている。うっかり忘れそうになるけど、皆様も忘れずに添えよう。
スクリーンショットを添えてもらう
次に困るのが、「どの箇所を指しているのかわからない」である。たとえば、ボタンっぽい要素が複数個あるページで「ボタンが反応しないのですが」と言われても、どのボタンを指しているのか特定できない。ソースコードを読める人なら、「この部分！」と指し示すのは簡単だろう。しかし、皆がコードを読めるわけではない。
問い合わせ文面でしばしば造語が使われるのが、事態を難しくしている。ここでいう造語とは、（開発者の書いた）ヘルプに載っている各部名称以外の名称のことだ。同じ要素でも問い合わせる人によって「ナビゲーション」「メニュー」「メニューリスト」と呼び方にばらつきがある。ヘルプに載っている名称を使えば最も誤解なく伝えられるからそうしてくれ、と言いたいところだが、そこまでユーザーに強いるのはかなり酷である。なぜなら、自分の専門分野ではない、たとえば眼鏡の各部名称や時計の各パーツ名を正確に指し示せることはまずあり得ないからだ。
前置きが長くなったが、結局のところ「問題が起こってる場所のスクリーンショットを添えてください」と案内するのが最も無難であると思う。スクリーンショットはとにかく手がかりが多い。なんといっても、問題点の特定が簡単だ。名前がどうこうはもはや気にしなくていい。
スクリーンショットに画面全体を収めてもらう
スクリーンショットを添えてもらうとき、ちょっとしたコツがある。それは「一部ではなく画面全体を撮ってもらう」だ。この手法はTumblr（公式）が行っていて、以前不具合報告を送ったときに知った。不具合は「一部の環境でのみ再現する」類のものがかなりある。スクリーンショットに画面全体が写っていることで、閲覧環境の推測がしやすくなるのだ。Windows、Mac、スマートフォンかタブレットかはすぐ特定できるし、ブラウザが写っていれば、ブラウザ固有の問題かもしれないとか拡張機能が悪さをしているかも、とかいったことも推測できる。もちろん閲覧環境を申告してもらうのが望ましいのだが、画像があることでより正確な手がかりが得られる。
本当にテーマの問題なのか検証してもらう
Tumblrテーマは性質上、原因の特定がしづらい。「不具合だと思ったらTumblr本体側の仕様だった」「テーマの不具合だと思ったけどコードをちょっと改変したのが原因だった」このようなケースは問い合わせのなかでも相当に多くの割合を占める。さすがにTumblr側の問題や、コードの改変（カスタマイズ）が原因の崩れはサポートする気はない。しかし先に書いたように原因の特定は一見難しい。
これについては、僕が普段行っている検証方法をFAQに記すことにした。その内容はこんな感じだ:
- 別のテーマでも同様の現象が発生するか？
- YESならTumblr側の問題だからTumblrに問い合わせてほしい旨を案内する
- （HTML/CSSを改変している場合）改変しない状態でも同様の現象が発生するか？
- NOならテーマ改変が原因。その場合はサポートしない
これで検証すると、そこそこ高い精度で原因が特定できる。
特定作業はそれなりに手間がかかるため、この工程を各ユーザーが自主的に行ってもらえれば、こちらの工数はとても減る。
FAQを書く
サポートの返事を書いたら、その要約をFAQとしてReadmeに載せる。FAQは「よくある質問」の意味だけど、あまりない質問であってもとりあえず載せている。事例は多いに越したことはない。
余談：アクティブサポートについて
インターネットで困ってる人を見つけて自主的にサポートを申し出る、いわゆるアクティブサポートについては、僕は消極的である。理由の第一はそれをやるリソースがないこと、もっと大きな理由は自分の性格上向いてないと思うからだ。アクティブサポートの話題を含むユーザーとの距離感について、むかし日記に書いた。
所感
作っているテーマの大半は「普段コードを書かない人でも使える」を指向している。そのため、なんとかしてユーザーが自力で使える（迷ったとしても解決できる）案内をしようと試みてきた。一応テーマ制作時に、多くの人がつまずきそうな箇所を察知したらヘルプで丁寧めに解説したりはしている。が、読みが外れていることも結構あり、実際の問い合わせを受け取ってみると全く予想外の箇所でつまづいていたりする。（個人のプロダクトではあまりやらないが、）ユーザーテストをやるときも似たような気持ちにさせられる。
ユーザーテストやればいいじゃないか、という話はあるにせよ、対象ユーザーが陥るであろう困りごとを事前に察知する嗅覚は、何を作るときにも絶対役立つと思う。そのトレーニングをさせてもらっている感じがする。
