Webサービスの「α版」はいつリリースすべきか 33
ストーリー by hylom
公開してから考えよう 部門より
公開してから考えよう 部門より
geekstyle 曰く、
個人製作のWebページだと「工事中」のコンテンツがあっても許される雰囲気があるが、（個人製作の）Webサービスだと「すべての機能が完璧に動作する事」を前提に公開しなければ叩かれるような雰囲気がある（叩かれるという言い方はおかしいかもしれないが）。もちろん「β版」として公開するのもアリかもしれないが、その「β版」もほぼ完成している事が前提になっている。
ただ、個人的には（予期できない）重大なバグ等を防ぎたいので「α版」としていくつか未完成でも公開したいと思ってる。問題なのは、「どのぐらいの完成度でα版リリースをすべきか」という事である。
見た目はあまり気にせずに最低限の機能が動く状態でリリースした方がいいのか、多少荒削りでもデザインを整えてから公開すべきか、/.J 諸兄方の意見を聞きたい。
エゴらない (スコア:3, 興味深い)
そしてそのギャップが大きければ大きいほど叩かれます。
どっちがおかしいかと言えば、一言も謳っていない機能や性能を要求するほうがおかしいし、自分の期待に沿わないという点でクレームを言うのもおかしいです。
しかしもしそういうユーザが不自然に多いとしたら、それを招く何かがあると考えたほうがいいです。
私の経験から言えば、使ってもらいたいという”欲”こそがその妙な期待感を持たせる原因だと思います。
例えば・・・・、実際にはそんなに大した機能でもないのに名前だけ妙に凝っちゃってたりとか。
ソフトは良質なのに紹介するページが妙な雰囲気を醸し出してたりとか。
「β版」と称すること自体だって、”β版の先にあるα版や上位版のような何か”を想起させるわけです。（もちろん、使う側が思い描く勝手なイメージです）
過剰な期待感を持たせなければ良いわけですが、一人でも多くの人に使ってもらいたいという”欲”があるから、知らず知らずのうちに期待感を持たせる表現になりがちで。
それを回避するには、何の期待感も生まない表現に終始したら良いです。
具体的には、センスの欠片も感じられないダっさい命名、ひたすら事実だけを列記したマニュアル、地味で無愛想な案内HP・・・・・・・・・
誰にも使ってもらわれない可能性は大ですけどね。
Re: (スコア:0)
＞β版の先にあるα版や
αはβの前にあるものじゃろ
Re: (スコア:0)
B(β)よりA(α)の方がいいよね！
って発想なのかと。
Re: (スコア:0)
Prior to β版…という意味にも文脈的にとれないなあ。
区切りがついたら (スコア:2)
公開してます。
要望や苦情などさまざまですが、個人サービスなので自分の気分で進めます。
デザイン的には半分完成くらいで公開して、意見を見ながら修正を繰り返します。
全ての要望は聞けません。
自分のサービスなんだからもっと思うようにやってもいいと思うわ。
♯ どんな気に入らない意見でも「今後の参考にさせていただきます」みたいな
♯ テンプレでも返しておけばいいよ。
♯ それでもダメな時は理詰めで対処、それでもダメならその時考えるようにしてる。
往々にしてテスターもワガママなもの (スコア:1)
Microsoftは、RCを出してから（できればβ段階でほしい）バグ報告やリクエストが飛んでくるからって、RCと製品の間にもうワンクッション作って、β相当のものをRCと称して出すことにしたんでしたっけね。今度はpre-αとかが求められてる気がしないでもない。
見た目よりも機能といいたいのがアレゲ人だけれど、アレゲじゃない人は見た目重視のほうが興味持ってくれそうってのが困りもの。
Re: (スコア:0)
数が大幅に違うのはテクニカルβは参加者が限られてるけどRCはばらまかれてるからじゃないのかな
Re: (スコア:0)
Vistaも7も8もベータどころかアルファの段階から盛大にばら撒いてたような
ユーザに負債を負わせない程度になれば (スコア:1)
いつ公開してもいいんじゃね？
叩く奴なんてそうそう見たことは無いから妄想だけど
未完成だから、というよりは
この部分は出来てるだろうと思い触ってみたら時間をムダにしてしまった、という点で叩いたりするんじゃね？
たとえば、お絵かきアプリなんかでも
データを保存できなくても、予め、目立つところに「まだデータは保存できません」と明記してあるならいいんじゃね？
時間をかけて本気で描いて、保存しようとしてメニューをよく見てみたらグレーアウト・・・なんてのは勘弁してほしい。
時間かえせと言いたくなる。
Re: (スコア:0)
じゃねじゃねうっさいよハゲ
いつものあれ (スコア:1)
β「αがやられたようだな」
γ「ククク…奴はPreRelease四天王の中でも最弱…」
δ「PreReleaseバージョンの面汚しめ…」
ε「えーと俺の出番は?」
Re:いつものあれ (スコア:3, おもしろおかしい)
ε、お前はδと争っているのがお似合いだ
間をとって (スコア:0)
人柱知人のみに使ってもらうよう限定的にα版をリリースしましょう# sタグで取消線って効かない?
# strikeタグならいけるみたいだけど
同感 (スコア:0)
そして、タレコミの
> 「どのぐらいの完成度でα版リリースをすべきか」
に対しては、その限定公開する範囲（知人、気心の知れたコミニティ）の成熟度に合わせて、と言うところになるかと。
類は友を呼ぶ、自分が知人のサービスの人柱になる上で我慢できる程度の完成度であれば、
知人も貴方のサービスの人柱になる事を我慢できるのでは無いでしょうか
Re: (スコア:0)
同意。
まず、個人製作レベルのWebサービスに対して機能が完璧になっていないと叩く相手なんて、
わざわざ構う必要はないと思うけれどね。
ただ、Webサービスは公開直後が一番注目を浴びる時期で、
その注目をどこまで引き延ばしてポジションを固めるかが勝負かと思う。
不十分な機能のα版を全体公開して、その後機能を固めたβ版を全体公開するステップだと、
注目を浴びるタイミングと、機能を最大限にアピールできるタイミングがずれてしまい、
折角のサービスが埋もれてしまう恐れもあって悩ましい。
アピールしたい機能が一通り触れる状態で全体公開すべきかと思うので、
クローズドでα版公開→一般公開でβ版公開、という流れが良いかと。
個人的には・・・ (スコア:0)
最低限の必須機能が使える程度に実装出来たらって気がしないでもないけど。
Re: (スコア:0)
というより、コンセプトが表現できたら、だと思いますね。ベータでもそうだけど。
新作アプリなんて、当然予備知識がないままユーザは接する訳で、ぶっちゃけ触った瞬間に何をするべきかがわからないとすぐに終えてしまう。
バグをつぶすとしたら、正にそこに絞るべきで、それが伝わらない状態でリリースしても前評判が落ちるだけ。
クリックしても動作しないとか、エラー画面が出てくるのは、知人以外は非難の対象でしかない。
だから、そのアプリが何をしたいか、それが表現できているか、か肝かと。
好きにすればいい (スコア:0)
叩かれるのが嫌なら公開なんてしなければいい。
叩かれたくないなんてぬるま湯な考えだから、叩かれるような品質のサービスしか作れないんだよ。
Re: (スコア:0)
俺、乱数を生成するWebサービスを考えたけど、誰か使ってくれるのかな？
# 利用者把握のため公開するというのはあるんだと思う。
Re: (スコア:0)
物理乱数なら重宝する。
http://www.random.org/ [random.org]
ベータでいいじゃん (スコア:0)
予期できない重大なバグを防ぐためのテストを
ほぼ完成したベータ版でやると何か問題あるの？
そのためのベータ版でしょ？
Re: (スコア:0)
公開する範囲を限定すればいいだけではないかな？
公開しても、パスワードロック付の孤立サイトなら、限定したメンバーに公開してテストというのはありだと思う。
未完成な状態で、不特定多数に一般公開するというのは、問題ありだと思う。一般公開するなら、実装されている範囲については、完全に実装されて正常に動作すべきで、機能確認ではなく、使いやすさやデザインの評価を目的とすべきだろう。
完全にユーザ目線の意見 (スコア:0)
柱となる中心的な機能は（βテスト等を経て）完全に完成させた状態でリリースして、
補助的な機能は「この機能はβ版です」といった注釈を付けて、
希望者のみ、同意ボタンを押させて使わせるようにして欲しい。
データが破損した場合は、バックアップからリカバリできるようにして。
これなら不具合で文句をを言う人は格段に減るのでは。
もっともβ版であることを免罪符にして、いつまで経っても
「β版ですので不具合があっても知りません」みたいな状態だと、
ユーザ的には「実質的には製品版だろ巫山戯んな！」ってなります。
ニコニコ動画は、βが凄い長かったような印象がある……。
暇なとき (スコア:0)
完成度よりも、時間とモチベーションがあって、それなりの頻度で更新できるときにあげてくれるのが、ユーザー的には良いですね。
Re: (スコア:0)
大きく分かれるのは
成功するWebはユーザー目線で耐えられる品質でリリースしてる
その場合多少の問題は容認されがち
提供側の視点でひと段落したものをリリースした場合は
あら捜しに粘着されて終始疲労に悩まされる
これが分かってない
Re: (スコア:0)
そのアンロック機構やらリカバリやらの機能をくっつける手間やそれがきちんと動く保証もしないといけないので、そういうリリース版になったらいらなくなる機能に力を注ぐよりはメインの機能を作り込むほうに時間かけてほしいかなと。
α版に完成度は不要 (スコア:0)
α→アイディアの実験
β→機能の実装
βで実装が安定したら、RCにして問題無ければ安定版としてリリースすりゃいい。
αなら、APIが増減したり挙動が大幅に変わっても許される。
βだと勝手に仕様変えるな！ って怒られてもしかたない。
そんな感じに思ってます。
googleみたいに延々とβ続けたり、pre-αみたいにどんどん自信ない方向に(語句としての)責任回避エスカレートしていくのは良く無いよ。
α版は超絶無保証実験版だ、と明記して、しょっちゅうAPI仕様変えてればいいと思うぞ。
Re: (スコア:0)
あなたが提供したい機能が最低限そろえばクローズドベータ（アルファ）でテストする。
バージョンアップする過程でユーザーファイル内に残ったバグが引き起こす最悪事態に備えてユーザー情報は、一般公開前に削除するか、編集不能に（サービス次第だがユーザーのデータをローカルにテキスト、画像、動画、音声等に保存して再アップ可能なオプションを用意する）。
Linux ではないが、バージョンアップは、細かく公開する。
くだらん問いかけだ (スコア:0)
「ケースバイケース」以外の答えが出るとでも？
「最低限の機能」「荒削り」の基準もものによっても違うだろ。
当ったときにスケールするようになったら (スコア:0)
何が受け入れられるか、品質が十分か、というのは出してみないと分からんが
幸運にもユーザーを捉えながら過負荷でサービス中断というのが損失デカいので。
逆柱 (スコア:0)
前職でオープン後から係わって黒字化を経験したサイト（別コメにあるニコ動じゃないよ）は逆柱 [wikipedia.org]とか言ってずっとベータ版にしてました。
改めて確認したところ、ロゴからβは消えているようです。
# 今職場だしログイン出来なかったけど（ぇ
で、質問に関してすでに出てる回答に付け足すことはないかな（汗
AC
α版からにしろ、β版からにしろ… (スコア:0)
某大手サイトのなかの、新規商用サービス立ち上げに関わりましたけど
…って、これ自慢したいわけじゃなくて
その時は、商用だからこそ「ビジネスモデル特許の申請が通るまで」
既知の技術とならないように技術的完成度は十分なのにリリースできなかった
別のサービスでは、「著作権の処理が終わるまで」という場合もありました
マッシュアップ要素がなく、完全に自社で完結している商用のサービスで
大手で競合が予想される業界ほど法的な手続きが公開フラグになったりする
…という、お話のために必要なのでした
タレコミは個人限定にしているので不要と言われるかもしれない
大抵そういう場合は、技術的なリソースの侵害が無いだろうと検討つけたら実装を優先して…
ライブラハックのように勝手マッシュアップした結果、（向こうの出来の悪さに起因していても）
意図せずリソースを占有して面倒が発生してたり
自分側の挙動を実装面からチェックすれば十分って認識になりがちですよね
リスクが顕在化したらどうするかなど、リスクの洗い出しを第三者の目で見れる時間
類似サービスが他社（他者）の権利を侵害していないか、（実装前に洗い出していても）
見落としている法的な側面を見直す時間を置く
ってのは、ある程度は長期運用する気があるなら大事だと思います