先に書かれてしまいました(^^;

hatena.i clip

　「予測市場で要望を吸い上げる2」より。

はてなの全サービスにわたって、多くのユーザーから効率的に要望を集めるにはどうすればよいか。
この仕組みを考える中で、まず思いついたのははてな質問箱
http://www.hatena.ne.jp/faq/
のような仕組みです。各サービスごとにカテゴリーが分かれていて、そのなかに要望投稿フォームがあり、要望が投稿されるとメールが送信されて、社内で処理をする、という仕組み。
こうすれば、要望の窓口を一元化して多数の要望を集約できることが見込めますが、一度登録された要望の管理にまだ問題が残ります。
例えば毎日投稿される要望が30件あるとして、1日に実装可能な要望は5件しかないとすれば、残りの25件は実装待ちかペンディングか却下になります。こうしたものを効率的に管理できなければ、数日間で未処理の要望が溜まりに溜まって破綻してしまうことは明らかです。

とのこと。
　私、下書き中だったんですが、不具合・バグ管理システムとして、これをお勧めするつもりでした。
　ちなみに、こんな下書きでした。(清書する気が失せたので(笑)このまま掲載します。 )

下書き

　とりあえず、不具合報告と要望は分けて考えます。
　当たり前ですが、ユーザーの立場から考えれば、要望 (現状をより良くする為の行為)と不具合報告(原状を回復する為の行為)は全然違います。

  • 要望は実施されると嬉しいけど、不具合は直らないと困る。
    • 要望は楽しめるけど、不具合はそれどころじゃない。切実。
  • 要望はユーザーの都合だけど、不具合は運営側の都合。
    • 不具合に関しては、ユーザーの手間をなるべく省くべき。
  • 要望も不具合も永遠に無くならない。でも不具合の数は多くないはず。
    • 『ユーザーから寄せられる不具合を修正したいと思うけれど、開発工数が足りずに不具合の登録スピードに追いつけない』等ということが起こってる筈がない(笑)

　まぁ、不具合処理にユーザーが求めるのは、対処のスピードや確実性、迷惑をこうむったユーザーへのフォローであって、お楽しみ要素じゃないです。
　だから、

  • 不具合報告のスピードアップ
    • 各サービスの各画面から少ないクリック数で不具合報告フォームへ。
    • サービストップや各画面のヘッダに不具合報告フォームへのリンクを。
    • ヘッダを消せるダイアリー・グループ日記は、MENUモジュールとabout画面にもリンクを。
  • ユーザーの手間の削減
    • 不具合報告フォームのベースは「はてな質問箱」の「お問い合わせ」フォームで良いと思いますが、ユーザー名とメールアドレスはログイン情報から取ってきて欲しいです。
    • カテゴリーはリンク元のサービス(URLの引数とか)から取得できますよね。
    • フォームの入力要素は「タイトル」(35文字w)と「お問い合わせ内容」だけでOK。公式ダイアリーのコメント欄に書ける程度の内容がフォローできれば十分なので。でも、タイトル以外の文字数制限は緩めに。迷惑をこうむって慌てているユーザーに文章を練る義務があるとは思いません。不具合に関しては、内容理解の負担は運営側が負うべきだと思います。
  • 不具合のマネージメント
    • メールの内容をスーパーあしかに(笑)
      • 処理を受け付けたことは素早く連絡。
      • 不明な点はすぐに問い合わせる。
      • 処理に掛かったことも連絡できれば安心。
      • 処理終了の連絡。
      • 公開できることはWEB上に掲載。(不具合タイトル、状態、受付日、終了予定日、担当者とか)
      • 以上を(箱を移動するたびに)自動処理できれば最高。
    • 却下すべきは素早く却下
      • あいぽんとか関係ないので『これは仕様です』も可(笑)
      • 『本件については要望管理システムを御利用ください』も可。
  • 不具合処理
    • はてな様内部でどんな形態が能率UPにつながるのか、外側からは分かりません。よって省略(^^;
    • 憶測で一つだけ指摘しておくと、メールを受理した時点で即時対応可能な人材の中からメンテ責任者(とバックアップ)を決定するべきだし、できるシステムであるべき。実作業を誰が行うにしてもゴーサインやリリースの判断に遅延が出てはいけませんし、報告してくれたユーザーへの返事や公式アナウンス等も漏らしてはいけません。ちゃんと出来ていると信じてますが、ここは大事ですので念のため。

みたいな方向でデザインすればいいのかなぁ、と思います。

付記

　下書き(だったもの)は以上です。


　サービスを提供する立場として、不具合を直すのは当然のことだと(ユーザーサイドとしては)考えます。出来る出来ないは別にして、「対応させていただく」という姿勢が大事だと思います。そこが要望に対する姿勢との違い。
　だからこそ、要望(実装の義務なし)と不具合(道義的に修正するべき)を同じシステムに乗せるのは難しいです。
　おそらく、不具合管理システムが要望管理を兼ねることは可能*1でも、その逆は大変難しいと思います。

*1:今回は無理との判断のようです。