アイデアファーム
確認済み コメントOK 運営事務局からのコメントあり

新機能テスター(および仕様段階でのユーザーコメント)

公開前の新機能を希望ユーザーが評価検証する。

・仕組み
希望者を募り、メンバーを登録。
評価検証新機能の都度、運営サイドより選抜依頼を行う。

・守秘義務
マイネ王内に関連するコメント、外部サイトなどに記載した場合はテストメンバーから削除される場合もある。

・テストサイト、仕様公開
アクセスする際のURL, ID, PWをメッセージなどで連絡。
上記はプロジェクトごとに変更。
テストサイト構築前の仕様への評価の場合もある。

・作業
仕様評価
PDF、画像、テキストなどを読み、良い点悪い点改善点などを忌憚なく報告する。
テストサイトの場合は上記にバグ報告なども含める。

マイネ王 運営事務局
回答者: コスパ王

■2016年6月10日
デザインや使い勝手はかなり好みが分かれてしまいます。また開発はスピード重視のために事前に全てのご意見を反映することは難しいです。そのため、公開した上で皆さんからのアイデアや意見を見つつ、徐々に改善する方針です。
ただし私たちが大事だと考えたサービスや機能は、これまでどおりプレミアムコースのトライアルのような評価や、オフ会といった場で見てもらうなどして事前に評価をお願いし、ご意見を参考にしたいと思います。
バグ報告については何らかの方法を検討します。
チップについて
0
ナイス!
0

17 件のコメント
1 - 17 / 17
アイデアは悪くないと思いますが、色々な人が使ってみて賛否両論が出ると思うので、参加者を絞らず参考公開みたいな感じにした方がいいと思います
…今と変わらないか(笑)
これいいですね
正式リリース後に全員がベータテスターであったなんて食えない話です
喜んで人柱になりますよw

でも、いつの間にこんなコーナーができたんでしょうね
評価検証参加出来たら良いなと思います。

しかし、検証なので前提条件がしっかりしていないと結果が意味のないものとなるので難しいと思います。例えば先般報道されていたSTAP細胞関連と同じように検証の条件と過程が曖昧にると検証になりません。

特に企業として検証結果を発表するなら、目的にあった検証条件と検証過程でないと結果が信用出来ません。提案者様の条件だけではユーザー参加型には、なかなか出来ないかなと私は思います。
利用環境を事前登録(複数可)して、運営からは確認依頼項目を提示。
テストユーザーは各項目にチェックして、コメントなどをレポート。

運営サイドはテストの負荷が軽減されるだけでなく、開発段階での機能修正に繋がるので、一石二鳥だと思います。
テストサイトの構築が負荷であれば、仕様公開でも良いと思います。

初期の新着情報(僕が加入前)の問題とか、仕様段階でユーザーの評価が伝わっていれば、もう少し早く改善できたかも?というのが投稿のきっかけです。

開発主導で進めちゃうと、機能的に便利でも、実際の使用感とのズレが出たりするので、これをすることで「あ、そっちの方が使いやすいって意見もあるのか」ということが伝わると良いな、と思います。
ktclinf003様

はじめまして。
ご意見ありがとうございます。

提案の目的の一つに、現状への改善提案が含まれています。
実施する場合工数は、確実に増えます。

きちんと行うなら仕様段階、テスト段階など、目的に合わせたフェーズの設定などが必要になりますね。

忌憚ないご意見、ありがとうございます。
何かお気付きの事や、改善点がまた出てきましたら是非、お聞かせ願います。
absenteさん

ご意見ありがとうございます。

追加はついさっき(2016/5/25 お昼)、メンテナンスの後ですね。
absenteさんは几帳面にチェックされそうですね。(笑)
バギンズさん

ご意見ありがとうございます。

現行の流れだと

スタッフブログ王国通信→ユーザー告知

あるいは

オフ会→王国通信→ユーザー告知

というのが主な事前告知で、その後機能がリリースされています。

目的の一つはリリース前の仕様へ、実際に利用するユーザーの意見の提示ですね。
オフ会とかだと時間も限られるし、開催の機会も四半期に一度です。
おっしゃるように、事前の仕様公開はユーザーメリットはあっても、ハンドリングする方には負担が大きいです。
ただ、こういうことが実現したら、意外に面白い発見が出てくる気もします。

いずれにしても、現行のリリースはバグが多すぎる…
特定の人がテストするということなので、運営側がテスト者を集めたり、結果を収集する手間も含めて、そちらのほうが運営側にメリットがあるのであれば、すぐにでもやってもいいと思いますね。

テストしない人は、リリースされるまでは関係ないことですからね。
619_ak@mnemoさん
そんなに几帳面じゃないですよ~
たまたま見た時に見慣れないコーナーがあって覗いたら、あれ?ってww
ベータテスターって大変ですけど面白そうなので参加してみたいです

むかし、趣味のプログラムを作っていたとき環境がマイナーだっただけに思わぬ操作でハングアップさせてもらうのがありがたかった記憶があります
自分で書いて自分で動作テストってほんとに限界があるもんです
自分の頭の中にある想定外って、それは想定内なんですからww
アッカリ〜ンさん

コメントありがとうございます。

現状のリリース前の検証作業がどれほど(OS, 端末, 画面サイズなど)なのか不明ですが、軌道にのるまでのハンドリングは、大変だと思います。
(運用ルールやテストサイトの準備、テスターとのやり取りなど)

ただ、一度運用が始まれば、同時に他機種の環境での確認ができるので、提案の価値はあると思いました。

動作確認をメインに書きましたが、本当は仕様評価もあると良いなと思います。
仕様評価と動作確認では、参加の意味が変わってくるので、時間のある時に内容を追記いたします。

バギンズさんのコメントにもありますが、いまの僕らってベータテスターみたいですね。
仕様評価:仕様段階でのユーザー参加について

難しいのは、それを自分に置き換えてみた時ですね。
例えば、このコメント一つにしても、アップ前に運営に確認が必要になったら、投稿するのが億劫になります。

ではなぜ今回、そう感じてる事をアイデアラボに上げたのか?
それは影響が大きい(マイネ王全体)ことと改修コストです。

これまでのリリースを見ても、結構な確率で発表後にユーザーから疑問が出てると思いました。
オフ会などで事務局にユーザーの声が直に伝わると、費用対効果を検討して順次改修となるケースもありますが、これって結構な金額負担じゃないかと思います。

そう考えた時に、マイネ王のユーザーインターフェースなどについては、開発前の仕様を何らかの形でユーザー意見を取り入れられないかな?と思いました。

何でもかんでも一緒に考えよう、という乱暴な話ではなく、必要に応じて有志の力も活用できないかな?という想いが発端です。
新機能テスター:新機能リリース前の評価検証について

例えば具体的な運用として(かなり大雑把なイメージです)

①アクセスログで上位のOS、ブラウザーを抽出して動作確認に必要なユーザー環境一覧を作成

おそらくiOS Safariが多い気がします。

②スマフォ、デスクトップ毎にユーザー環境一覧の必須項目を選び、該当ユーザーを募集する

③テスト環境(ミラーリングテストサイト)の一時的ログインID, PWを設定し②のユーザーに公開、テスト※

※テスト項目は事前にピックアップされてる方が良い。
テストサイト内に、確認できるページを用意して、フォーム形式で機能の可不可やコメントを簡単に報告できると良いかもです。

④テストサイトにて検証、報告

⑤テスト結果集計後、不具合を開発側で確認、修正後に再度テスト実施

基本的には④と⑤の繰り返しになる可能性が高いです。
最初のバグ報告後、開発側で確認環境がある場合はそこで区切るのもありです。
謝礼など、運営サイドの懸念はあると思いますが、オフ会参加グッズでも、喜んで参加する方はされると思います。
でも運営としては、気を遣われるポイントでしょうね。

大事なのは、メンテナンス後の新機能リリース前に、リリース後の不具合が一つでも少なくなり、時間的に間に合わない場合でも事前に問題点を告知することで、ユーザーの不安を軽減できるという点です。
諸事情で議論中に間に合わず、コメントとなりましたことをお詫び申し上げます。
これから投票しようと思っています。

今回のリニューアルで私たちはまさにベータテスターとなりました。
過去のリニューアルでも同様だったようですね。

マイネ王自体ベータ版なので仕方ないのかと思っていたのですが、正式リリース後に細かな仕様変更するのであれば、導入前にやれることをやって欲しいと個人的には思った次第です。

マイネ王が良い方向へ進むには何が不足しているか考えさせられました。
おそらく動作確認の時間が取れないか、何かでこうなってるのだと思います。
賛成率計算しなきゃいけないのか(´Д`)
71.4%で検討課題にはなったようですね。
ご検討、よろしくお願い申し上げます。

運営事務局からのお願い

マイネ王メンバーの皆さんからのコメントにより、アイデアの幅が広がったり、視点を変えることでより良いアイデアになります。基本毎週実施しているアイデア確認会では、皆さんからのコメントも参考にさせてもらっています。より良いアイデアにつながるようなポジティブなコメントをよろしくお願いします。

コメントするには、ログインまたはメンバー登録(無料)が必要です。