Hatena::ブログ(Diary)

public static void main

誰かが困って検索したときに助けになる話題を書いていければと思っています。

2009-01-14

[][]個人で運用するWebサービスの限界を考える

個人が作成したWebサービスの数はここ数年で爆発的に増えています。

サーバ自体の導入コストも低下してきており、レンタルサーバでもPHPのようなスクリプト言語が使えるものが珍しくなくなり、Ruby on Railsのような開発速度を向上させるフレームワークも登場してきて、今後も個人が運用するWebサービスは増加をしていくでしょう。


個人Webサービスの寿命

今回考えたいのは、そういった個人で運用するWebサービスの終了するときについてです。

Webサービスは作ってからが本当のスタートで、開発者は開発にかかったコスト以上に運用するために時間的・金銭的・精神的にコストを負担していくことになります。なので、自分の払うコストに見合わないと思ったらサービスの終了を考えるのは当然だと思います。

つまり作った人一人がやる気をなくしてしまえばどんなにいいサービスでも一瞬で消えてしまうということです。

最近上場したGREEですが、当初個人で運営していたときに「管理人さんが死んだらサービスはどうなるんですか?困ります!」的なコメントをユーザからいただいたと言う話を聞いたことがあります。極端な話になりますが、作った個人が事故や病気で亡くなったりしてしまってもそのサービスは終了してしまいます。

開発者である個人が自分のサービスへ関われなくなったそのときがWebサービスの寿命となっていしまうということ。これが個人で運用するWebサービスの限界なのではないかと考えます。


止めるのは作った人の自由?

個人で作ったものなのだから好きなときに止めてもよいではないかという意見もあると思います。

ちょっとした検索サイトやジェネレータやマッシュアップのようなサービスであれば人気があれば代替となる似たサービスはあると思いますので、それもありだと思います。そもそも、そういう系のサービスだとサーバさえ確保できればメンテナンスはほとんどいらない場合もありますのでただ放置しておくという選択肢もあるかもしれません。

ただ、CGM的な要素やコミュニティ要素を持ったサービスにおいては、それまでサービス内でユーザが作ったものやそのコミュニティは立派な財産だと思うので、作った人の一存で終了させてしまう前に、どうにか延命の方法を考えて欲しいと個人的には思います。

ひろゆきが2ちゃんねるを譲渡したって話も今回書いたようなことを考えて決定したのかもしれないなと思ったり。とはいえ、2ちゃんねるの場合は複数人が運用に関わっているのでどうとでもなりそうですが。

たくさんのユーザがいるサービスを止めてしまうと、ユーザはサービスを使えなくなると言う不利益をこうむりますし、開発者としてもこれまで成長させるのにかけたコストがもったいないと思います。


サービスを延命する

個人が運用を止めようと思ったときにサービスを延命するために選択可能な方法で、私がぱっと思いついたものは3つあります。

一つ目は、先ほど話したGREEのように起業すること。ビジネスとして成立しうるサービスまで成長させられるのであればこの選択肢もありだと思います。でもそこまで収益性の見込めるサービスは大量には生まれてこないし、起業することを面倒に思う人も少なくないでしょう。

二つ目は、カヤックでは作ったサービスの売却ページを作ったりしていますが、こんな感じでサービスの売却を考えるのも一つの手だと思います。数年前だとライブドアなどに買収されるのがサービス開発者としての一つのゴールのように思っていましたが、現在は個人が作ったものを買ってくれる企業はあまり見かけなくなった気がしますね。

三つ目は、誰かにサービスの管理を譲ること。熱心なユーザであればボランティアでもいいのでサービスを手伝いたいと思ってくれるかもしれません。

どの方法でも言えることは、一人でやることには限界があるので誰か他の人を巻き込もうとすることがサービスの寿命を伸ばすことにつながるということです。

OSSの隆盛により、ソースコードのレベルでは他の人とコストを分かち合うことが一般的になってきましたが、サービスのレベルで他の人とコストを分かち合うことが今後一般的に見られるのかどうかが気になるところです。

2008-07-30

[][]そろそろ「こうなる。」について一言言っておくか。

ちょうど一週間前の23日に、私が開発に参加している予測コミュニティ「こうなる。」のリリースを行いました。今日レイアウトを修正したので、是非アクセスしてみてください。

f:id:Kishi:20080730180132p:image

URLはhttp://kouna.ru/とサービス名と一緒なので、覚えやすいのではないかと思います。



「こうなる。」を作った理由

もともと、研究室で次期衆議院選挙の予測市場shuugi.inというサービスを提供していて、そこの経験を生かしてさまざまな事象に対して予測ができるサービスを作りたい、というのが出発点でした。

しかしながら、提供する側としてはもっと多くの人に利用をしてもらいたいのですが、予測市場は仕組みが少し難しいので参加の敷居が少し高くなってしまいがちです。そもそも、予測をするということがユーザにとって楽しいのか、という疑問もありました。

そういった懊悩を払拭してくれたのが、群衆の叡智サミット2008でのパネラーの方々のお話やブログの記事などのやりとりでした。

ユーザ同士の取引の繰り返しというフィードバックによって、みんなが無意識に思っていることが数値化できるのであればとても面白いサービスになるのではないかと現在では思っています。

参加者同士が予測を通じてコミュニケーションを行い、互いに未来のことを考える力を高めあっていけるサービスになっていければ、そして得られた結果が群衆の叡智として多くの人にいい意味で影響を与えていければなあと思います。

参考:


「こうなる。」の特徴

  1. 自分の興味のある事象についての予測を立てることができる
  2. もともと合った株取引に近い仕組みのトレード方式に加えて、競馬のようなベット方式、実験的なシンプル方式を選択可能
  3. 予測への参加度合いによって増加するKP(こうなるポイント)によって立てられる予測の数が決定される
  4. Twitterのようなミニブログに似たコメント機能
  5. コメントに対する「参考になった」ボタンでのフィードバック

ユーザのホームページでは、自分の参加している予測でのコメントとウォッチ対象となっているユーザのコメントを参照することができます。

Twitterでいうフォローを「ウォッチ」という名前にしたのは、ユーザ同士が「お前観測範囲狭いな」という会話ができればというid:youzakaによる発案です。

あと、Twitterでkounatterというユーザを作って情報を発信していますので、お気軽にフォローしてください。


今後の予定

利用方法がわかりにくいとの指摘があるので、その辺りの改善をまずやっていきたいと思っています。

あと、一部の情報はRSSで現在提供しているのですが、どこかの偉い人がPost APIのないサービスはクソだといっていたので、近いうちにAPI提供をしたいと思います。



Wicket勉強会で話すよ!

「こうなる。」はJavaで開発されており、プレゼンテーション部分にWicketというフレームワークを利用しています。

今週の金曜の8月1日に開催される第一回Wicket勉強会でサービスの紹介と開発時に気づいたことなどについてLTで話す予定です。参加される予定の方はよろしくお願いします。

勉強会自体は会場の収容人数をオーバーしている状態なので、新しく参加することは出来ないのですが、発表資料のほうは後でアップできればと思っています。



そんなわけで、今後とも「こうなる。」をよろしくお願いします。

2008-04-30

[][][]モバイル向けのWebサービスのユーザ登録方法メモ

物は試しとモバゲータウンとニコニコ動画のモバイル版に登録してみたのですが、携帯電話だとキャリア公式のサービスかメールマガジンぐらいしか登録したことがなかったので、個体識別番号を使って登録する方法は初経験でした。

今後、携帯電話向けのサービスを作るときに参考になりそうなので、それぞれの登録方法をメモしておきます。

ちなみに私が使っている携帯電話のキャリアはdocomoです。

モバゲータウン

  1. 携帯電話の個体識別番号を送信
  2. 自分の生年月日などの情報を入力
  3. 確認
  4. 空メールを送る
  5. 自分のメールに送られてきたURLにアクセス
  6. 登録完了


ニコニコ動画

  1. 空メールを送る
  2. 自分のメールに送られてきたURLにアクセス
  3. 携帯電話の個体識別番号を送信
  4. パケホーダイ・ichの契約状況を公開
  5. 自分の生年月日などの情報を入力
  6. 確認
  7. 登録完了

5のところで、入力ミスをして前の画面に飛んだときに入力項目が消えていたのでここは直して欲しいです。

ニコニコ動画の場合、PCでも登録している場合は紐付けの設定もできます。



その他気づいたこと

メールアドレスを入力するよりは、空メールを送ったほうが早いというのは携帯電話的でよいと思います。モバゲーとニコニコで空メールを送るタイミングが前後していますが、個人的には後者のほうが入力のストレスがなかった気がします。

生年月日の入力は、プルダウンじゃなくてyyyyMMddの形式で入れるようになっているのが、目に付きました。PCでも生年月日だけじゃなく、IPやメールアドレスの入力などで入力フォームが細かく分かれていると入力しにくく思っています。バリデーションする側からしてみれば、分けた方が正規表現が簡単になるかもしれませんが、入力する側からすれば一つの入力フォームで入れられるほうがユーザビリティが高く感じられます。

空メールのところで指定受信向けの注意が必ずついているのですが、今でもこれが原因でうまく受信が出来なくて文句を言っている人もいるのですかね。

メールアドレスは基本的に、サービスから情報を受け取るためだけに使い、ログインには個体識別番号を使います。個体識別番号を利用すると、気軽に複数アカウントを取ったり、入退会を繰り返すということを防ぐことが出来るので、ある程度のユーザの一意性を確保できるのがよいですね。ちなみに、Willcomがこういったサービスで使えないという話はよく聞きますが、個体識別番号が送信できないようになってるかららしいです。

2008-01-24

[][]データの視点から見たWebサービスの種類

データの視点から見ると、Webサービスは大きく2種類に分けることができます。

1つ目が、ユーザがコンテンツを追加していくサービス。SNSやSBM、Wikipediaのようなサービスが代表的な例になると思います。サービス開始当初はデータがなくても問題ありません。

2つ目は、大量のコンテンツを元にユーザに情報を提供するサービス。GoogleやYahoo!のような検索エンジンやbuzztterKizasiがあげられます。サービス開始の前にある程度のデータの蓄積が必要になります。


ユーザ追加型サービス

こちらほうが一般的によく作られるWebサービスです。アイデアさえあれば、作ることができるので、初期投資をそれほど必要せず、企業や個人でもこういったサービスを公開している事例は少なくありません。

基本的にユーザに集まる場を提供するサービスなので、人が集まらなければサービスとして機能しませんので、いかに人を集めるプロモーションができるかが成功の肝となります。

ニコニコ動画、Twitter、Mixiぐらいアクセスがあるとどうやってスケーラビリティを確保するかが重要になってきますが、普通は最初からサーバが落ちるほどのアクセスがあることは滅多にないので、ユーザの増加にあわせて対策をしていけばよいのではないかと思います。


事前収集型サービス

研究開発の成果によって実現されたサービスが多いです。

データを加工したり、検索したりするためには、まずデータの確保が必要になります。そのため、自社で前者のサービスをやっていてデータを持っている企業以外は、最初にWeb上をクローリングしたり、集めた大量のデータを保持するためのストレージが必要になるので、多くの初期投資が必要になってきます。

また、テキストマイニング、情報検索などの技術や現実的にサービスとして公開できる速度で処理を行うようにする必要があるので開発にも時間がかかります。

注意すべき点としては、一発芸のようなサービスになってしまう可能性があることがあげられます。研究開発ベースなのでニーズよりもシーズよりなアイデアが多く、そのためリリース当初は注目されても長期的に使われないサービスが多いように感じます。


事前収集型サービスを促進するWeb API

去年当たりからWeb APIが注目されるようになり、事前収集型サービスのネックであった大規模データの問題が、マッシュアップという形で解決されるようになりました。

少し凝ったことをしようと思うと、やはり自分でデータを蓄積する必要が出てきますが、Web APIはRSSのようなXMLの形で情報を提供してくれるので、以前に比べると情報の収集が容易になりました。そのため、以前は時間をかけて集めていたデータが、すこしプログラムをかじったことのある人ならば簡単に収集できるようになり、Webの研究の分野においては研究者とそれ以外の人を隔てる障壁が少し低くなったように思います。


終わりに

事前収集型サービスのもう一つのネックは、データを蓄積してWebサービスに利用することが著作権法上問題になる可能性があるということです。国内検索エンジンを作っても今の著作権法だと使えないので改正する必要があるという話もありますし、GoogleやYahoo!大手の検索エンジンのサーバは日本には置いていません(厳密には海外にサーバを置いていても問題があるようですが)。

最近リリースされたサービスでもいくつかWeb上のデータを蓄積するタイプのものがありますが、海外にサーバを確保するのはコストがかかるので、対策はしていないのではないかと思います。リスクがあることを念頭にサービスを公開する必要がありますが、こんなことを開発するときに悩みたくないので、ぜひ著作権法を改正してほしいものです。

2008-01-11

[]衆議院選挙予測市場Shuugi.inをリリース

私が開発に参加している「shuugi.in」が本日リリースされました。

去年実施した参議候補者、サブドメイン&メールアドレス発行所のコンテンツの一つであった予測市場の衆議院選挙バージョンです。

予測市場とは、市場メカニズムを使うことで未来の予測を行う、集合知の仕組みです。

前回の経験を踏まえて改善を行っていますので、ぜひご参加ください。

取引の仕組み以外で注目してほしい機能

  • 銘柄の情報やコメントなどをAtomで取得できます。
  • コメントに、はてなスターがつけられます。
  • Twitterに市場情報をPostするボットがいます。
  • 各市場のブログパーツがあります。

2007-09-27

[][]「リクナビCAFE 人脈BANK」がすごすぎる件について



no title



日本ではあまりないビジネス向けのSNSで、アイデアは非常にいい感じのサイトなのですが、URLに管理番号を使っているらしくすごいことになっています。

たとえば、以下は新規登録のページです。

https://jinmyaku-bank.cafe.rikunabi.com/CSP/CSP02/CSP021101.jsp


CSP021101.jspというファイル名もアレですが、CSP/CSP02というよくわからないディレクトリ構造になっています。

ちなみにCSP021101.jspを削ると404になります。

番号を適当に変えても404になるので、連番で振っているわけではないようです。

ログインして、適当にページを移動すると、CSP02がCSP04になったりします。



まあSNSなので、はてブみたいにURLを直接打ち込んでアクセスするようなことはなさそうですから、URLのユーザビリティはあまり意識する必要はないのかも知れません。

また、下手にURLを推測してアクセスされないようにすることも狙っているのかもしれません。

しかしながら、このような命名規則だとシステムを開発する人たちはものすごく大変だったのではないでしょうか。

ディレクトリ構造もファイル名も意味がないので、ちょっとした修正でも管理番号を調べる必要があるので、プロジェクトの管理コストが高くなりそうです。

以前どこかでモジュール名だけでなく変数名も管理番号をつけて管理しているプロジェクトの話を読んでネタかと思っていたのですが、会社によっては本当にこういう管理をしているのですね。



あとHTMLソースを見たところ、POSTするときは自分自身に投げるようにしており、他のページもJSPであることから、JSPのみで実装しているようです。

HTMLに不自然な空白があるので、そこでGETとPOSTの判定やバリデーションなどを行っているのではないかと思います。

JSPで書くとサーブレットのように再配置する必要がないので後からの修正が楽になるというメリットがあります。

しかし、見た感じではPHPを勉強した人が最初に作るような、MVCを意識していない設計になっていそうな気がします。

サイトを保守する会社が変わったらえらいことになりそうです。



参考

ユーザインタフェースとしてのURL – U-Site

2007-08-01

[]「あわせておしらセ!」

no title

がリリースされたので貼ってみました。

ほかの使っている人を見てみましたが、2ちゃんねるのまとめサイトの記事が結構多い。

単純に文章量が多いのでまあ仕方ないといえば仕方ないんですが、なんとかしたいところです。

2007-07-26

[]ニコニコ市場(仮)ランキング

RSSがNot found...

修正されてた。

ニコニコ市場

2007-07-20

[]今日のニュースオントロジーはもっと評価されるべき

47NEWS今日のニュースオントロジーは非常に面白いと思うのですが、いかんせん置いてある位置が非常にわかりにくいのでもったいないです。

今日のニュースオントロジーは、直近のニュースに出てきたキーワードつながりを可視化します。

47NEWSが始まった当時はトップページからリンクが張ってあったのですが、その当時もわかりにくかったです。

今日久しぶりに見に行ったら、no titleの隅のほうにおいてありました。

なんという不遇の扱い。

やっていることは面白いので、もっと目立つところに置けばいいのに。

あと、画像じゃなくてFlashとかAjaxで表示して、単語をクリックすると記事が引っ張ってこれるとなおよい。

2007-07-18

[]Livedoor Readerで

MashupediaのRSSを購読しているんですが、ほぼ毎回Yahoo! APIコンテストの記事が未読の記事となります。

この現象は私だけ?