クラウドビジネス：「ザブトンのセル生産」
こんにちは、経営コンサルタントの入野です。
先日、大企業の集まるASP・SaaSのコンソーシアムから依頼され、
事業計画の講演をしてきました。
本日はASPのビジネスモデルについて解説します。
ASPとはApplication Service Providerの略で、
会計、給与計算、在庫管理、動画配信、デジタルサイネージ、文書管理など
様々な分野で普及しつつあるITのビジネスモデルです。
ASPビジネスを立ち上げるからと言って、
本当にASP事業の１本だけしか考えていない事業計画をよく見かけますが、
あまりよくありません。
ASPのビジネスモデルは、いわゆる、「ザブトンモデル」。
ザブトンを積み上げるように売上高も積み上がるので、
一度売上を獲得すれば時間が経っても売上が落ちにくいところが
このビジネスモデルの良いところです。
しかし反面、立ち上げ初期のフェーズではキャッシュフローで苦労します。
ASPの立ち上げフェーズでは、
システム投資に大きなキャッシュが必要ですが、
まだ売上の積み上げが足りず、
キャッシュフローがマイナスの状態がしばらく続きます。
売上高が単月キャッシュフローがプラスになるラインを越えるまでは
資金繰りに非常に苦労するのがASPビジネスのパターンです。
しかし、資金調達をしようとしても、
ASPビジネスは銀行からは資金調達しにくいビジネスモデルです。
なぜなら、銀行の視点から見ると、ASPモデルとは
貸付をしたばかりの立ち上げ時期には倒産リスクがあるにもかかわらず、
単月黒字を獲得した後は資金ニーズがほとんどなくなるビジネスなので、
長期的には取引ボリュームの拡大を期待できず、
取引先としてオイシい企業ではないのです。
では、
デットファイナンスよりもエクイティファイナンスで資金調達すればいいかというと、
そう簡単な話でもありません。
どのようなサービスであっても、典型的には
ASP企業を単月キャッシュフロープラスを達成するまで支える続けるほどの資金量は
ファーストラウンド＋セカンドラウンドで約1.5億円が最低ライン。
創業メンバーの自己資金やエンジェル投資だけでまかなえる金額を越えています。
では、VC投資はどうかというと、
最近の日本のVCは約1.5億円でさえ1社単独で支えきれない財務状態です。
VCからの投資を受けられたとしても、
複数VCのシンジケーションで交渉もめんどくさい話になります。
で、結局、
多くのASP企業が実際にはどうするべきかというと、
ASP以外の日銭を稼げる事業からの売上でまかなうのです。
ASP以外の個別の案件で
日銭を稼いでキャッシュを生み出すことが重要です。
どのような個別案件を受注するべきかについては
できるだけ本業のASP事業と近い事業で、
顧客や技術・ノウハウが同じ事業であることが理想ですが、
贅沢を言いすぎるのは禁物です。
具体的には
・ システム受託開発
・ パッケージソフト販売・導入
・ コンテンツ制作：クリエイティブ系
・ 単純事務請け負い
などの「アルバイト事業」であっても、ガムシャラに日銭を稼ぐべきです。
なぜなら、ASPサービスはシステムインフラが完成しても、
顧客や市場にそのサービスが実際に浸透するには思いのほか時間がかかるから。
革新的なASPサービスであればあるほど、市場浸透に時間がかかるので、
Last man standing方式の長期戦になる覚悟で、
日銭を稼げるアルバイト事業を持ちつつ、
Burn Rateを少しでも下げておくことが立ち上げフェーズでは大切です。
ASPの事業計画書でよくある間違いは
「当社のASPサービスはすばらしいので、販売パートナーに拡販してもらい・・・」や
「当社は得意の技術開発に集中し、販売パートナーにOEM形式で提供し・・・」
など。
しかし、実際には、パートナーに販売を頼りすぎる考え方はASPではうまくいきません。
理由はいくつかありますが、一つ目の理由は、
ASPサービスの金額の低さ。
APSサービスは高くても月額50万円。
平均的には月額5万円や、もっと低い会計ASPなどは年間5万円。
パートナーにとっては、
サービスの金額が低すぎて
販売手数料を中抜きしても儲かることにはなりにくいので、
いくらサービスがすばらしくても、
販売パートナーは積極的に売ってくれないのです。
パートナーに販売を頼りすぎるとうまくいかない2つ目の理由は
ASPの販売や導入時に求められるスキルの高さ。
ASPは、服に例えるならば、
標準体型にあわせたサイズMの既製服をすべてのお客に着てもらう商売です。
ひとりひとりの客の体型にあわせてオーダーメードで作りこむシステムではありません。
客が「この服は私の体には合わない」という場合でも、
「それは、あなたがデブだから」と指摘する勇気と
服に合わせてダイエットをさせる実務的なスキルが必要です。
自社でシステムを作っていない販売パートナーは
「この服は私の体には合わない」と客に言われると、
「そうですね。服が悪いですよね」と引き下がってしまいがちです。
客をデブだと言い切ってダイエットを実行させるのは
高度な業務ノウハウとシステムに対する自負が必要なので、
直販ベンダーでないと難しいのが実情です。
そもそも、
販売パートナーに拡販してもらうつもりのASPベンダーに多いのは
テクノロジー系人員に偏りすぎているケースが多く、
システムさえ作りさえすれば、あとは机に座って腕組みしていれば儲かると
勘違いしているケースが多いです。
ASPになるような定型化された業務をシステム化するのは
特に難しいことではなく、
システム作ってから直販でバリバリ売ることが
大変で大切なのです。
自ら直販でバリバリと売り歩く発想と覚悟を強く持たなければいけないのです。
ASPはインフラ型事業なので、
大規模なシステムを大人数のシステム開発チームが作っているイメージを抱きがちですが、
実際に成功しているASP企業を見ると、びっくりするほど少人数の開発体制です。
システム開発チームが5人以上になるのは多すぎるぐらいで、
ほとんどが事実上はチーフプログラマーが1人でプログラミングしている場合があります。
大人数で分業してプログラミングを書く体制よりも
1人でASPサービスを作り上げる「ひとりセル生産体制」のほうが理想的です。
理由の一つは
RubyやPHP系の各種フレームワークの発展のおかげで、
1人でプログラミングしても高い生産性を発揮できる道具がそろったこと。
多人数の開発体制では、実際に一番時間を費やしているのは
要件定義/設計/コーディング/テストの工程間やチーム間での伝言ゲームに
時間がかかっているだけです。
ひとりセル体制では
業務要件も理解している優秀なプログラマーが
サッサと直接コーディングしプロトタイプで要件を確認しながら進めるので、
開発スピードが速く、要件充足の精度も高いのです。
一人体制が良い理由のもうひとつはプログラム変更管理のスピードと柔軟性。
開発チームが大人数の場合、
プログラマーの間でプログラム変更の影響をすり合わせしなければならないですが、
一人セル生産の場合は、一人のプログラマーの頭の中で整合性を保てるため
スピードが圧倒的に早いのです。
ASPビジネスでは、システム機能が完成したと思っても、
現状のシステム機能では十分に対応できない顧客は常に継続的に発生するので、
プログラムの変更管理を10分で完了できることと
「10分でできる」と顧客に対して言える柔軟性が大切なのです。
ASPサービスの立ち上げのために、
外部のシステム開発会社やSIerを使おうとする事業計画を時々見ますが、
論外です。
外部の人員と追加機能の見積などの事務手続きをやっている暇はないし、
どのような契約形態になろうが、外部の人員である限りは
業務要件の理解や操作性に関する高いレベルのこだわりやスピードを求めるのは無理があります。
ひとりセル体制の重責を担うためには
経営陣の一員、少なくとも、プロパー社員として活躍してもらうことが必須です。
いかに優秀な一人を見つけ、まかせられるかということがカギとなります。
本日は以上です。