Hatena::ブログ(Diary)

回答こそ我が人生!! (ウソ このページをアンテナに追加 RSSフィード

日記内案内板
(日記は次のセクションからです)

 カテゴリによる記事一覧は、こちらからどうぞ。

 また、文字列による記事検索は、右側サイドバーの『日記の検索』からどうぞ。


2005-06-13

[] sasadaのアイデア提案成績と期待配当

 2005-6-13正午時点でのデータです。

 sasadaが提案した全アイデア(くっつけ元除く。以下同様です)の実装率は 20.6%です。これがアイデア提案者としての成績です。


 また、sasadaが提案した全アイデアの予想配当倍率は0.73です。sasadaの手持ちあいぽんの実態はそんなもの。1.00を切っているので、要望出しに専念すると そのうち手持ちの あいぽん がなくなります。投資で稼がざるを得ない実情が分かって悲しいです。


 なお、sasadaが提案したアイデアが終了した時点での配当倍率の平均は1.46です。名前買いする場合の目安にでもしてください。

集計データ

終了? 状態 件数 件数×倍率
未終了 要望中(x0) 35 0
未終了 検討中(x2) 0 0
未終了 検討中(x3) 0 0
未終了 検討中(x4) 2 8
未終了 検討中(x5) 0 0
終了 却下(x0) 3 0
終了 キャンセル(x1) 8 8
終了 他の方法(x1) 2 2
終了 実装済(x2) 11 22
終了 実装済(x3) 2 6
終了 実装済(x4) 0 0
終了 実装済(x5) 0 0

合計数字

 Σアイデア件数 = 63

 Σ終了件数 = 26

 Σ実装件数 = 13

 Σ(終了件数×倍率) = 38

 Σ(全件数×倍率) = 46

終了済みのみを対象とした成績

 決定済 実装率(実装件数 / 終了件数 * 100) = 50.0%

 決定済 配当倍率(終了件数×倍率 / 終了件数) = 1.46

全アイデアを対象とした成績

 終了率(終了件数 / アイデア件数 * 100) = 41.3%


 実装率(実装件数 / アイデア件数 * 100) = 20.6%

 配当倍率(全件数×倍率 / アイデア件数) = 0.73

 実配当倍率(終了件数×倍率 / アイデア件数) = 0.60

[] (sasadaの)アイデア提案は儲からない

 いや、sasada限定の話なんですが・・・。

 idea:2639の追加コメント

sasada 『(100アイデア出すようなユーザーはポイント長者) 私は63件提出26件終了で1.46倍。終了してないもの込みで0.73倍。』

sasada 『途中で ?I を引退すれば設けて終われそうですが、継続利用だと度々破産します。私がバカなだけ?』

との書き方は分かりにくかったかもしれませんね。すんません。

 私の実績ベースの話なんで、平均より劣る人間をサンプルにしても仕方ないかもしれないんですが。。。


 上のセクションに追記したんですが、私の実配当倍率(終了件数×倍率 / アイデア件数)は 0.6です。

 これがどういう事かといいますと、私が1000pt所有していて、1件10ptの提案を(十分な期間をかけて)100個行ったら、手元には約600ptしか回収できないということです。

 ちょっとだけ解説しますと、100個のうち41個(410pt分)が決着して1個アタリの平均配当が1.46倍なので、603ptが手元に残る勘定です。残りの59個のアイデアは要望中か検討中で、市場に590ptが出回っていることになります。


 このループは継続的に続きますので、次のサイクルでは600ptが360ptに、その次のサイクルでは216ptに、と手元のあいぽんが減っていきます。(市場に出回るあいぽん=アイ株は増えていきます。要望提出数より要望終了数のほうが少ないことに留意が必要です)

 結果として、いずれ手持ちのあいぽんが10ptを切って、アイデアを出せなくなります。それからしばらくは待ちの一手で、今後は配当が出るのを待って次のアイデアを出すことになります。


 1件当たり14ptから15ptの配当があるはずですから、1配当があるたびに1個か2個のアイデアを出せる、という慎ましい生活です。

 私の場合、一つの要望が叶うまでの平均時間は半月から一ヶ月程度ですので、(他にまったく何もしない・できないとして) 一・二ヶ月の間に3つの要望が出せる生活ですね。

 これが、『継続利用だと度々破産します』という一文に込められた意味です。


 私は到底満足できないのですが、これは「要望が通らない愚か者は市場を去れ!!」というメッセージなのでしょうか(哀)

P.S.

 「adramineさんのアイデア期待値」を拝見しました。

 これが標準なら、はてなアイデアの提案活動は立派に成立します。

 どうやら、「要望が通らない愚か者は市場を去れ!!」というのが正解かもしれません。(^^;

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

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

はてなの全サービスにわたって、多くのユーザーから効率的に要望を集めるにはどうすればよいか。

この仕組みを考える中で、まず思いついたのははてな質問箱

http://www.hatena.ne.jp/faq/

のような仕組みです。各サービスごとにカテゴリーが分かれていて、そのなかに要望投稿フォームがあり、要望が投稿されるとメールが送信されて、社内で処理をする、という仕組み。

こうすれば、要望の窓口を一元化して多数の要望を集約できることが見込めますが、一度登録された要望の管理にまだ問題が残ります

例えば毎日投稿される要望が30件あるとして、1日に実装可能な要望は5件しかないとすれば、残りの25件は実装待ちかペンディングか却下になります。こうしたものを効率的に管理できなければ、数日間で未処理の要望が溜まりに溜まって破綻してしまうことは明らかです

とのこと。

 私、下書き中だったんですが、不具合・バグ管理システムとして、これをお勧めするつもりでした。

 ちなみに、こんな下書きでした。(清書する気が失せたので(笑)このまま掲載します。 )

下書き

 とりあえず、不具合報告と要望は分けて考えます。

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

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

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

 だから、

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

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

付記

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


 サービスを提供する立場として、不具合を直すのは当然のことだと(ユーザーサイドとしては)考えます。出来る出来ないは別にして、「対応させていただく」という姿勢が大事だと思います。そこが要望に対する姿勢との違い。

 だからこそ、要望(実装の義務なし)と不具合(道義的に修正するべき)を同じシステムに乗せるのは難しいです。

 おそらく、不具合管理システムが要望管理を兼ねることは可能*1でも、その逆は大変難しいと思います。

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

フットノート(日記は前のセクションまでです)

 カテゴリによる記事一覧は、こちらからどうぞ。

 また、文字列による記事検索は、右側サイドバーの『日記の検索』からどうぞ。


はてなカウンタ→

はてなプレビュー→ 809301