2009-02-07
拡張課金 ― どうすればサラリーマンがWebアプリで稼げるのか
リリースチェッカーの現状
リリースチェッカーへの寄付の募集を始めてから4か月あまり。累積の寄付額は1600円です。
リリースチェッカーに関しては、Amazonの紹介料と寄付を受ける以外に収益化方法が思いつかない*1ため「たまに黒字になれば嬉しい」ぐらいの気持ちで運営を続けようと思っています。
Webアプリの収益化に挑戦したい
次に作ろうと思っている(そして製作がなかなか進んでいない)Webアプリでは、個人的に興味のあるアーキテクチャスタイル(REST、非同期)を利用しつつ、収益化に注力するつもりです。
別に貧乏なわけではありません(え?)。ただ稼ぎたいのであれば、携帯アプリやiPhoneアプリを作ります。私はWebアプリを作るのが好きなので、好きなことで稼ぐ手段を模索したいわけです。いつリストラされるか分からないご時世ですし。
会員制にする
リリースチェッカーはユーザ登録不要で、それが売りのひとつです。ただしこれは、収益化という観点だけでみれば誤った設計を選んでしまったと思っています。「ユーザ」に「課金」するのが収益化の定石だろうからです。
サラリーマン運営者には月額課金は無理
そうすると「どのように課金するか」が課題になります。まず思い浮かぶのは月額課金ですが、私のようなサラリーマンには、この方式は難しいと思っています。決済の仕組みを用意するのも大変ですし、Webアプリの障害が起きた日には、返金やらクレームやらの対応で本業どころではなくなるかもしれません。
ではどうすればよいのか
そこで思いついたのが「拡張課金」です。RPGを想像してください。倉庫に50個までアイテムが置けるとします。大工に200ゴールド払えば80個に拡張できます。この考え方をWebアプリに応用するのです。
ニコニコ動画を例にします(あくまで例です)。マイリスト登録上限の初期値が100件だとします。その上限を100件増やすのに100円課金するのです。上限を増やすたびに課金します。いったん拡張したら元に戻さないのがキモで、それが月額課金方式との違いです。
拡張課金方式であれば、銀行振込で支払いを受けることができます。入金を確認してマスタデータをいじれば対応完了です。Webアプリの障害が起きたとしても、利用期間に対する支払いではないため、それほど問題にはならないでしょう。
すでに世にあるアイディアかもしれませんが、思いついたので書いてみました。まる。
拡張課金の定義(以下、2009-02-11追記)
(私が勝手に決めた)拡張課金の定義は下記のとおりです。
- 機能拡張のたびに課金する方式である
- 支払い期間中のみ機能拡張が有効になるタイプの課金(例:月額課金)ではない
- 無料ユーザー/プレミアムユーザーのような区別は不要
RPGの倉庫をまた例にします。
- 月額課金の例
- 月20ゴールド払っているうちはアイテムが80個置ける。支払いを止めると50個しか置けなくなる。
- 拡張課金の例
- 一度200ゴールド払えばアイテムが80個置けるようになる。二度と50個には戻らない。さらに200ゴールド払えば100個置けるようにもなる。
たとえば、はてなダイアリーには有料オプションがありますが、これは月額課金です。私の意図する拡張課金ではありません。
サラリーマンには拡張課金が向いている
本業以外の時間でWebアプリを開発・運営して収益を上げたい私(サラリーマン)にとっては、月額課金より拡張課金が向いているのではないか、というのが本記事の主張です。
理由は前述のとおりで、障害発生時の返金・クレーム対応に時間を割きたくないからです。少なくとも私には高可用性を担保できる自信がありません。レンタルサーバが落ちたらどうしようもないですからね。
*1:「広告に頼れば?」という指摘があるかもしれませんが、そうしたくないのは冒頭でリンクした記事に書いたとおりです