2015年7月27日月曜日

意外と難しいSaaSの料金体系。どのようにすべきなのか?

新規ビジネスにとって料金設定(プライシング)というのは最も難しい悩みの一つだと感じます。料金設定を間違えてしまえば、どれだけ優れた商品であっても失敗してしまいます。

とくにSaaS(クラウド型ソフトウェアサービス)の料金設定は、まだ各社ともに試行錯誤ともいえる状況で、参考に出来る情報なども少ないように思います。

SaaSの料金体系には、ざっと思いつくだけで以下のような方式があります。
  • 初期費用
  • 月額費用
  • IDあたり費用
  • データ量あたり費用
  • 使用回数あたり費用
  • その他の従量費用
  • 料金プラン制

このなかで、罠と言えるのが「IDあたり費用」ではないかと思います。

ユーザIDの数が、ソフトウェアの利用価値と直結しているようなソフトウェアであれば、ユーザIDで課金することには合理性があります。しかし単純な顧客管理ソフトウェアなどは、アカウントを複数人で共有しても価値があまり変わらず、ユーザ数単位で課金することは顧客にとって納得性が低いものになります。

ソフトウェア業界の慣習としてユーザ数課金が行われてきましたが、多くのユーザが様々なデバイスからソフトウェアを利用する時代に、ユーザ数課金はそぐわない場合もあるかと思います。


さて、ここで可変的な料金設定にはどのような意味があるのかを基本から考えてみましょう。

IaaSと異なりSaaSでは、多くの場合は、ユーザの利用量によってコストが大きく変わるというわけではありません。

そのため顧客の利用パターンによって料金を変えるのは、より多くのお金を払っても良いと思う顧客から、より多くのお金を取るという意味になります。いわゆる価格差別やバージョニングと言われる概念です。(詳しくは「ネットワーク経済」の法則を参照)

通常は、顧客が得られる価値によって価格を変えるのが適切と思われます。

すなわち、もしユーザアカウントを増やすことによって価値が得られないのであれば、ユーザアカウントによって課金するべきではない、ということです。


データ量による課金や、従量制課金には、問題点として、どれくらいの料金がかかるのか前もってわかりにくいとか、複雑だということがあるかと思います。

データ量による課金とは、例えば、名刺管理ソフトなら、保有できる名刺データの最大枚数とか、そういったもので課金する方式です。これだと、活用している程度によって金額が変わるので、ある程度の納得感があります。

妥当性をもった予測可能な価格設定になっていれば、利用料金が変動すること自体は問題がないのではないかと感じます。(メイシーでの経験上)


料金プランの設定には注意が必要です。最近流行のSaaSですと、よく上中下みたいな3プランを用意しているものが多く見受けられます。

しかし、多様な顧客の要望にほんとうに3パターンだけで応えられるものでしょうか?

上中下で、上が月額5万円、中が月額1万円、下が月額2千円などとなると、あまりにギャップが開きすぎていて、そのあいだを望む顧客は失望することでしょう。

私は実際にOptimizelyというサービスを昔に使っていまいたが、料金プランに納得感がなくて利用継続をやめました。

複雑な料金体系であっても、細かい価格設定によって、納得感のある支払ができるようにしたほうが顧客のニーズに応えられると思います。

なぜなら、ビジネス利用されるお客様で「多少お金を余分に払ってもいいから、簡単な料金プランで分かりやすいようにしてくれ!」なんて考えるお客様は滅多にいないからです。(というか、もしそういうお客様がいたら特別プランを作成してあげればよろしい)


初期費用ですが、これは法人向け製品であれば、なるべく設定するべきだと思います。

その理由ですが、営業宣伝費用の早期回収につながることでビジネスの成長を圧倒的に速くできることがまずひとつあります。これは極めて重要です。

もうひとつは顧客にとって新規ソフトウェア製品の導入は、そもそも支払額以上に手間がかかりコストがかかるものなので、初期費用を払うことにはさほどの追加の抵抗感がないということです。

日本のお客様は、月額費用のように継続して発生する費用には抵抗感があることが多いものです。


最後に、価格設定一般の話になりますが、商品の価格は高ければ高いほど、ビジネスは楽になる、というのが私の考えです。

コカコーラやマクドナルドのように100円の物を売って儲けるのは、きわめて難しいことであり、多くの起業家にとってそのようなビジネスを作り上げるのは困難でしょう。なぜなら広告宣伝費や販売チャネル構築などの初期投資が多くかかること、大量生産と大量販売を行うには組織の能力が大きく問われるからです。

それに比べて、ソフトウェア受託開発業、人材派遣業、不動産業、コンサルティング業など、顧客単価が数百万円を超えるような商売では、超零細企業であっても生きていけますし、それどころか、ボロ儲けしてる場合すらあります。

(ただし、もちろん簡単に構築できるビジネスほど、労働集約性が高いので、商売のウマみは少なくなります。)

弊社の経験からも、通常の中小企業であれば、顧客単価は10万円を最低ラインと考えるのが良いかと思います。なぜなら顧客獲得単価は最低でも数万円はかかるからです。できれば、そのうち5万円くらいは初期費用として回収してしまえると、資金回転率が改善するでしょう。

できれば、一社から年間100万円以上の粗利を獲得できるようになれば、大幅にビジネスは楽になります。大企業のように安く沢山売ろうなどとは考えないことです。

さらに厳しいことを言うと、ソフトウェアの限界費用は0円なので、新規参入が増えれば増えるほど値段は安くなっていきます。儲けられるうちに儲けるというのは良い考えですし、価格を高くして面倒なことを引き受ければ引き受けるほど、新規参入者にやられにくくなります。

「顧客単価」を考えるだけで、ビジネスが無残にも離陸すらせずに墜落してしまうことが少しは避けられるのではないかと思います。参考になれば幸いです。


参考: ソフトウェアの価格について以前書いた記事もあわせてご参照ください。

2015年7月6日月曜日

流行のIT技術を追うのをやめたらプログラマとして成長した話

私はもともと普通のプログラマとしてキャリアをスタートしましたが、2007年くらいから脱プログラマを目指してソフトウェア起業家として経営に軸足を移してきました。

それから8年くらいが経過して思うのは、経営者として大きな成功をおさめる前に、自分のプログラマとしての実力がめきめきとアップしてしまったということです。

8年前の私は、プログラマとしては基礎力はあるものの全般的には未熟であったように思います。コードも荒削りで、とにかくかろうじて動くものを作ることに四苦八苦していました。が、いまはプログラマとしてずっと良い仕事ができています。

この8年間は、自分でコードも書いていたので、経験が増えたことによって、良いコードを書けるようになったという面も多々あるとは思います。しかし、そのあいだ技術書を読むことはすっかりやめてしまい、流行の技術などは完全無視してきました。

経営層の一員として働くので、プロジェクトマネジメント能力や総合企画力や折衝能力などがあがった面もありますが、それよりもシステム設計力やアルゴリズム力などのプログラマとしての基本能力が大きくあがったと感じています。

いま振り返って思うのは、バリバリのプログラマを目指して活動していたときは、流行の技術を追うことに必死すぎたなということです。

どうしてもプログラマというのは新しいツールやら言語やら方法論やらがでてくれば、ついつい調査してしまいますし、追いかけていないと不安になってしまいます。

その結果として、ひたすら技術書ばかり読みまくって勉強会にでまくるプログラマのできあがりとなります。

それは悪いことではないし、プログラマとしてそういうのが必要な時期もあるかと思うのですが、弊害としては、プログラマの基本能力作りがおろそかになったり、不安感にかられて軸足がふらついてしまうようなデメリットがあるかと感じます。

最悪の場合は「目の前にある現実の問題を解く」ということを軽視して、使ったこともない最新のツールや方法論ばかりを社内や顧客にむかってわめきちらす迷惑な意識高いプログラマとなってしまいかねません。

流行のツールや方法論のなかには、いろいろと筋の悪いものも含まれており、そういうものに下手にはまってしまうと悲惨なことになる場合も多々あるんですよね。また、そういった流行の技術には、変に思想性が強いものが多くて、そういう思想にかぶれることで問題解決の本質に目が行かなくなる恐れがあります。

私もバリバリプログラマ時代には、かなりの不安感を持って、押し流されるような気持ちでプログラミングをやってきました。Aという技術が理解できない自分はバカじゃないかとか、Bという技術が使えないのに生き残れるのか? など不安でいっぱいでした。

今考えれば、そんなことはどうでもよくて、自分の強みと、解くべき問題にフォーカスすべきだったんだよ!ということなのですが・・・


さて、若いみなさんはこの記事を読んですっかり老害乙とおもわれたことでしょうが、ここからさらに老害力をあげて説教モード全開でいきたいとおもいます。

技術のなかには、すぐに廃れるようなものもあれば、長く生き残っていくものもあります。私は、流行のツールばかり持てはやされる現在のプログラマ業界にかなり不安感を抱いています。

例えば、以下のような技術はこの10~20年間、本質的にはほとんど変わっていません。昔に学んだことは、そのまま今でも使えることばかりです。

  • リレーショナルデータベースのテーブル設計とSQLクエリの記述
  • アルゴリズムとその他の計算機科学
  • システムプログラミング (C言語によるプログラミングとか)
  • 基本的な業務知識(たとえば簿記会計など)
  • IPとイーサネットによるネットワーキング
  • コンピュータセキュリティや暗号理論
  • ユーザインタフェースとデザイン

これからあなたが流行の新ツール "SuperduperX"を学んだとしても、たぶんその知識は数年後には役立たずです。しかし、こうした基礎を学んでいれば、たぶん10年後もいくらか役に立つことでしょう。

そういうことに気付いてしまった私は、すっかり流行の技術を追うのをやめて、幸せなプログラマとして、毎日を目の前の問題解決に費やしています。

まあ、べつに流行のツールを積極的に学びたい人を止めるつもりはありませんが、不安感と焦燥感に駆られて、新技術ばっかりを追うことはないですよ、と。

あと自分が苦手なことがあったり、理解できないことがあったりしても、それをコンプレックスのように思う必要はないかと思います。全ての技術を使いこなせるスーパープログラマなんて、まず存在しないですからね。

流行の技術には、はっきりいって完全なデタラメみたいなものもあるので、「これ、わけわからないなー」と思ったら、自分の直感に従って無視するほうが良いかと思います。

そして、プログラムを書く目的は、あくまで問題解決のためですから、目の前の問題をどんどん解決していきましょう!

問題解決といえばワインバーグの名著「コンサルタントの秘密」ですね。唐突なアフィリンクですが、まあ、この本はなんど紹介しても足りないくらいの名著ですので・・・ やたら読みにくいですが、間を置いて三回くらい読めば分かるようになるでしょう。