Uservoice を個人開発で使う（その１）

2014年12月にリリースしたストアアプリ PICT8 では、ユーザー（と開発者、自分）からの変更提案・バグ報告処理にUservoice を使用しています。

Uservoice
http://www.uservoice.com

ベータテストから数か月程使用していて、これは便利なものだなと。使ってみるのもいいんじゃないすかね？という意図で書いたのがこの記事です。
（別にUservoiceから何か貰ってる訳では無いです。頂けるのなら歓迎ですが）

PICT8で使っているUservoice
http://ddlg.uservoice.com

Uservoice とは？

Uservoice で何ができるのか、ユーザー・開発者それぞれの目線で簡単にまとめてみると、

ユーザーは、

1. 自分の提案・報告を投稿することができる
2. 他ユーザーの提案・報告にコメントで意見を付けることができる
3. 他ユーザーの提案・報告に「投票」することができる
4. 自分の提案・報告の状態が更新されると、通知を受け取ることができる

開発者は、

1. ユーザーの提案・報告を受けることができる
2. 提案・報告にコメントで回答や意見を付けることができる
3. 提案・報告の状態を管理コンソールでトラックすることができる
4. 提案・報告の処理が終わったらその提案を閉じることができる

…もの凄くざっくり言うと、提案・報告毎にスレを立てていき、解決したらスレを閉じる掲示板的な（ざっくりすぎ）。

もちろん掲示板とは違う所もあります。
幾つか例を挙げると、

ユーザーの3「他ユーザーの提案・報告に「投票」することができる」

登録された提案・報告には「投票」ボタンと、現在の獲得票数表示がついています。「この機能は俺も欲しい！」「このバグとっとと直せや！」と同意したユーザーはこのボタンで投票すると。

青いボタンを押すと投票できます。

なお、ユーザーには10票の投票権があります。一つの提案・報告に対し手持ちの全票をぶっ込んで欲しい気持ちを表すことも可能です。しかし、手持ちが0票になると投票・新たな提案はできません。提案・報告が解決した又は差し戻しになりClosed、終了すると、投じた票（権利）はユーザーに戻ってくるという仕組みです。

ユーザーが投票ボタンを押している様子（イメージ）

もちろん、機能を実装する・しない、次のバージョンにこのバグを直す・直さない、最後はアプリの責任者である所の開発者の判断ですが、どんな機能が欲されているかを知るのは大変価値のある所だろうと思います。

（個人開発ですし、誰も気にしてないけど自分は大事だと信じる所に熱量を怒涛のように注ぐ喜びというのもありますけど、今回それは別の話として）

ユーザーの１「ユーザーの提案・報告を受けることができる」

ユーザーに投稿してもらう場合、ユーザーはメールアドレスを使ってアカウントを作る必要があります。匿名掲示板に慣れた我ら日本人にはちょっとここは敷居がありますね。
ただ、Moderatedな運営をするには必要な所だろうとも思います。
ちょっと困った人についてはBanする機能もあります。「自由な掲示板」を運営する訳では無いという所です。また、ユーザーの４にあるように、ユーザーの提案にコメントが付く・状態が変わる等更新がある・管理者がユーザーに聞きたいことがある・等でその都度ユーザーに通知メールが飛ぶ仕組みです。

開発者の3「提案・報告の状態を管理コンソールでトラックすることができる」

開発者は、管理コンソールで各提案・報告がどう処理されているかを確認することができます。
各アイテムの状態変更履歴、コメント等に加え、最近の提案の処理数、処理に掛かった時間、それらから導かれるユーザー満足度などの統計情報を表示することが可能です。

Uservoice 管理画面

バグトラッキングシステムとは何が違うのか

BugzillaやCMVC、Team Foundation Server、Visual Studio Online 等、バグトラッキングシステムを個人開発でお使いの方も多いと思います。

今までのUservoice の説明を見ると、それは結局バグトラッキングシステムを外に出しているだけなのでは？ 逆に、バグトラッキングシステムの代わりにUservoice を使えるのでは？とお考えの方も居るかもしれません。

しかし、所謂バグトラッキングシステムとUservoice は似ているけど根本的にかなり違うものだなー、というのがこの数か月使ってみての感想です。

Uservoice には、バグトラッキングシステムには当然あるSeverityの設定や、提案・報告者によるReject（差し戻し）等はありません。ソースコードの変更とItemを紐づける機能も無いです。

Uservoiceの管理コンソールを見ると良く分かるのですが、Uservoiceは出自（というか現在もですが）が所謂サポートデスクシステムです。

本稿では説明していませんが、Uservoice ではユーザーからのメールでの問い合わせに対してタスクを作成し、やり取り・履歴を残す機能も使う事ができます（サポート用のメールアドレスが付与されます。PICT8 にもあるのですが特に使ってはいません）。
また、複数のメール受付担当者のパフォーマンス…メール受信から応答・クローズまでに掛かった時間の統計を取るという機能もあります。サポート「の」管理ですね。

本稿で説明しているユーザーからの提案・報告の収集とそれらへの回答もまた、サポート業務から派生したものです。この仕組みを使い、多数のユーザーから意見を集め、ディスカッションを行い、製品に反映しよう、その様子をユーザーから見えるようにしよう、というのが、今各種アプリで使われているUservoiceの使われ方だと私は理解しています。

個人開発でUservoice を使う意義

Twitterや掲示板等で「ここは○○だったらいいのにー」と提案や意見を頂く事が多いですが（有難うございます）、その場での個人的な記憶＋メモで管理していると、

• 出来上がるまでユーザーの目に触れることが無い
• それを伝えたユーザー以外には何が起こっているのか良く分からない
• 忘れがち

…と、設計・コーディング側はVSO 等でかなり管理出来ているのに比べると偉いざっくりだなぁという所がありました。
こうもう少し、固められる所はフローとして固め、流れ作業でこなしていくことは出来ないだろうかと。Uservoiceは丁度そこを埋めてくれるシステムだと思います。

上の方では長々色々書いていますが、一度使ってみれば実のところWebベースの易しいシステムです。記憶＋メモより確実に手間は減り、使いやすさは上です。
突っついていくだけで提案が見やすい形で管理できるのは、時間もリソースも足りていない個人の開発には中々いいのではないかと考えています。

※※※※※

それと、ここまで書いてきたものを眺めて…これも書いておかなくては、という事が一つあって、

個人でアプリを継続して作り、幾ばくかの収益を上げていこう…というMotivationがあった場合、一つのアプリにこういうリソースを割いてメンテしていくというのはそもそも的外れではないか、という考え方もあると思います。一つ終わったらさっさと次に移るべきでは？と。

このあたり、正直自分でも答えは出ていない部分です。

今回の例で言えば、PICT8 はそこそこ使ってもらえるだろうという見込み（希望とも言う）があり、売り切りでもあるのでユーザーからの提案・報告に対して応えていける準備が要るだろうという動機がありました。

とはいっても、実際は全然ダメでした、ユーザー数も低調でした…となると、さっさと風呂敷を畳んで次のタスクに移る事も大事だろうと考えます。本稿の趣旨とは違う話になってしまいますが。

長くなってしまった。
この記事は Uservoice を個人開発で使う（その２） に続きます。