サービスビジネスを考える人のために（IT的に考える限界費用ゼロモデルについて）

最近、顧客と話をしていると、サービスビジネスの拡充について相談されることが多くなった。

単に商品を販売するだけでなく、商品を取り巻く生活や顧客体験全般にかかわることで、顧客ロイヤリティの獲得と、継続的ビジネスの獲得を狙うというコンテキストだ。

商品は、もう商品単独では存在せず、商品が置かれる風景や顧客体験、生活やライフスタイルの中でこそ意味を持つ。多くの人が望んでいることはそういうことであり、この感覚を理解できなければビジネスが成立しない時代なのだとも言える。

そして顧客とのつながりを演出する道具立ては、ITサービスとして実現することが多く、その構造は大きく2つの仕組みがあることを理解しなければならない。それは、限界費用ゼロか、そうでないかだ。（もちろん、サービス・ビジネスには様々な要素があるので、もっと幅広い論点を整理すべき。でも、特にITの構造について理解されていないことが多いので、ちょっとまとめてみました。）

限界費用という言葉は、アメリカの経済学者ジェレミー・リフキンが2015年に出版した「THE ZERO MARGINAL COST SOCIETY」（邦題：限界費用ゼロ社会）で広く知られるようになった言葉で、その後ドイツが中心になって提唱されたSociety5.0の基礎的な考え方になったものでもある。（なので本来的には社会構造の話だけどね。）

どういうことかというと、例えばある商品を10生産していたとして、次の一つ、11個目を生産する時にどれだけの追加費用がかかるのかということを指す。サービスビジネスで考えると、10人の人に提供しているサービスがあったとして、もう一人ユーザーが増えた時に増加するコストに相当する。

一般的に商品を仕入れて販売している場合、売上を上げるためには仕入れが発生する。なので、限界費用は仕入れ分に相当し、ゼロということは無い。例えばハイレベルなコンサルティング会社を設立したとして、人月単価は極めて高い構造だとしても、売上を伸ばすためには人が必要になる。なので、売上をさらに拡大するためには人件費を増加させなければならず、限界費用はゼロというわけにはいかない。

ところでYouTubeやFacebook，Apple Musicのようなインターネット・サービスを考えてもらいたい。まず利用者が増加するとコストが増えそうな気がするが、はたしてそうだろうか？

例えばブラウザで表示された画面というのは、HTMLという方式で記述されたファイルで、たいていの場合、中にJavaScriptというプログラムが組み込まれたテキストファイルとなっている。

つまりユーザーがサービスをブラウザで表示するというのは、サービス側が保存しているテキストファイルをブラウザに渡しているにすぎない。ユーザーがあれこれ文章を入力したり、画像を選んだりしている時に発生する処理は、閲覧をしているユーザーの端末上で動作しているので、サービス側の資源はほとんど使用していないわけだ。

もしこれがブラウザではなく、アプリケーションで動作しているとすれば、まさしくアプリケーションが動作しているのは端末内。

一方で、従来型の発想でシステムを構築するとどうなるか。おそらく見た目はブラウザで限界費用ゼロモデルと同じように動作するかもしれないけれど、ログインしてきたユーザー毎にサーバー資源が消費される構造になりやすい。特に、作りが悪いとユーザー毎に消費するサーバー側資源が巨大になり、利用者増がかなりのコスト増につながることが多い。

なぜこんなことが起こるのかと言うと、さきほどの限界費用ゼロモデルで開発をしようとすると、複数の異なる技術を駆使しなければならず、そうなるとエンジニアの確保が大変。なのでサーバー側の技術者だけでなんとかしようとすることが多く、その結果、サーバーリッチな構造になってしまい、限界費用は膨れ上がることになる。（Salesforce社が何年か前にユーザーインターフェースの刷新を行ったが、構造的には限界費用ゼロモデルに寄せるための改善だったように見える。Salesforceのような成功している会社も、ほんの数年前まで古い構造だったと言うこと。それくらい陥りやすい。）

要するにサービスを限界費用ゼロにするためには、それを達成するための強い意志をもって構造を根本から考え実現していく必要がある。限界費用ゼロを実現できるか、できないかは、最後までしっかりと実現していくポリシーと何をすべきかわかっている技術力の両方が必要だ。

そして大切なことは、限界費用ゼロモデルを具現化したシステムは、極めてシンプルでメンテナンス性が高くなりやすい。頑張ればシンプルになり、開発も楽。頑張れなければ開発は大変で、構造は複雑。

現代型の開発は、こうしたことを実現できるかできないかで、会社としても、エンジニア個人としても、実力は大きく分かれると言ってもいいくらいだ。

そもそも、サービスビジネスを模索する企業と話をしていると、サービスの拡大が何らかのコスト拡大につながる前提で話を進めていることが多いので、いつももう一度本質的に目指すべきことは何なのかを議論するようにしている。

実現しなければならないのは、情報提供なのか、つながりの演出なのか。顧客状況の正確な把握に基づくサービス提供なのか。それは何によって実現されるのか。一番コアになるのはアプリケーションではなく、データであり、データに対する視点なのではないか。だとするなら、適切なデータの保存の構造と、スパイク的なトランザクション急増があっても耐え抜くシンプルな構造。トランザクションを素早く処理する効率の良いアルゴリズムと構造。そして、わかりやすく端末で完結するユーザーインターフェース。そういうものがあればよく、それを限界費用ゼロとして実現することも可能であり、費用が急増するものとして実現することもありうる。（こう書くと、やっぱり構造、つまりアーキテクチャは重要）

だからこそ、ITのアーキテクチャはビジネスモデルに直結する。それを理解すべき。

なぜか。

売上の増加や利用者の増加にともない増加するコストが無いということは、売上の増加は、そのまま利益の増加に直結する。

まさしく鉄壁のビジネスモデルが完成するのだ。