いわゆる「オライリー論文」の正式名は、「Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル」である。技術者に対して、Web2.0的な技術開発やサービス提供の「デザインパターン」の提示を試みるとともに、経営者やサービス運営者に対して、「ビジネスモデル」の考察、刷新を迫るものとなっている。
では、Web 2.0のビジネスモデルとはいったいどんなものなのだろうか？ それ以前にそもそもビジネスモデルとは何だったのであろうか？ 本節ではこれらの疑問に簡潔に答えていきたい。
企業、団体がどのような事業活動をするかのモデルである。通常は営利法人について語られるが、非営利法人にもビジネスモデルは存在する。非営利法人とは、たまたま収支をバランスさせるように運営する組織であって、高額の給与を得ている専従者がいる場合もあるし、収入面で利益率の高い事業を展開している場合もあり、効率性の追求や技術革新のニーズなど、本来は営利法人と同等の要求が存在するはずのものだからである。
上図に示したように、この事業活動のモデルは大きく３つのモデルからなる。事業体の存在意義、社会に対する使命、活動目的に照らしてビジネスの大枠での着眼点を現す戦略モデルと、それを実現する具体的なオペレーションを記述した業務モデル(BPM: Business Process Modeling)、そして、収益モデル、の３つである。戦略モデルはターゲットとなる顧客（市場）を定義し、競合との差別化戦略につながる付加価値の内容を構造的に記述したものである。業務モデルは、その戦略を実現するための業務プロセスを描き出し、個々のプロセスにおけるオペレーションの内容、その実行方法、そして、これらの体制やプロセスの設計・構築手法を描いたものである。IDEFやUMLなど様々な手法で形式的記述が試みられているが、なかなか真に有用な表現手法は現れないようである。
狭義の「ビジネスモデル」とされることもある収益モデルは、事業活動の利益を確保する仕組みである。売り上げ拡大のための収入モデルと、原価・経費節減のためのコストモデルとからなる。１事業体だけをみて収支のモデルを描くだけでなく、その事業体につながる複数のステークホルダーとの間の結線上を、どのように具体的にお金が動くか、あるいは無料で何らかのアクションが行われたり物流、情報流が発生しているかなどを含む、全体のヴァリューチェーン(価値の連鎖)を描いてみないと、通常、最適化の方略、処方箋は書くことはできない。次節では、Webサービス(WebAPI)提供者を中心とした、様々なWeb 2.0の収益モデルの類型を描いている。
戦略モデルについては、そろそろ、類似分野で似たビジョン、ゴールを備え、「2.0化」しつつある企業のものを参考にすることもできるようになっているだろう。それ以上に、「オライリー論文」等を参考に、自社自身の戦略を見直し、「2.0化」させる、というのが一番の正攻法であり、近道ではないだろうか。
業務モデルについては、「永遠のβ版」（といいつつ"Web 2.0 for Enterprise"や業務向けSaaSの場合は数ヶ月の検証を経た後のリリース、というサイクルが残るのが通常である）を支える業務体制を考え、ITサービス提供主体への変身後の業務プロセスを考えることになるだろう。それに至る移行プロセスを考えたり、過渡期には、パッケージ型ビジネス、システム受注とSaaSとの中間的な形態を考えることもあるだろう。これらは、各企業の「2.0化」のプロセスそのものでありので、個別に考案、検証していただくことになる。
３番目の収益モデルについて、Web 2.0的な企業の傾向を分析して、いくつかの特徴を抽出してみた。
収入の多くを左右する課金モデルについては３点あげてみた。 まず、モノ（パッケージソフトの場合は"疑似物財"）の対価に準じた固定料金から、 様々な種類の従量制へ、という流れがある。サービス化するだけでWeb 2.0企業に 近づくというO'Reillyの主張（こちらの末尾） からすれば、当然のこと、ともいえる。補足として、「「使い倒した方が得」という階段関数的な特徴は残す」 というのは、例えば、ユーザ数が５人から９人まではいくらいくら、という料金設定 により、まずはユーザ数を拡大する、という目標を目指すためである。最初は効果が 判明する最小規模から始め、有効ならば徐々に利用を拡大したい、というのがユーザ の心理である。ある利用数／量の幅を定額とした階段関数的な特徴により、早期に 大規模利用に誘導することは、サービス提供者側の収入の拡大に結びつく。理に適った 戦術である。
しかし、課金体系、料金システムをいじり過ぎて、あまりに複雑で わかりにくくなってしまうと、ユーザ側が、どの選択が「お得」であるか 理解できなくなり受注できなくなったり、顧客満足度の低下をもたらすこと がある（例えば数年前の携帯電話の料金体系を想起されたい）。「納得感」 が失われ、不公平ではないか、などの疑心暗鬼さえ生まれかねない。その対策 としては、顧客ごとに利用状況の評価エンジンを動かして、「このような 利用状況ならばこちらの課金コースに変えた方がお得ですよ」と毎月顧客に レポートすることもあり得るが、それが信用に値するか検証しきれない ユーザには不満が残る。
そこで、シンプルでわかりやすいけれど、きめ細かくユーザのニーズ や納得感を反映した細かい区分のある課金体系が望ましい、となる。この 要求と、上述の利用拡大への誘導とのバランスをうまくとって、課金モデル を構築するのが良いのではないだろうか。これらに十全に配慮して料金を 決定すれば、従来の受託ソフトウェア開発、SI業のように、人月単価から はじきだした「原価積み上げ」などをやっていられなくなるであろう。 代わりに、当該のサービスの利用で得られる御利益や相場（可用性99.9% などサービスの質のついての「相場」も含む）で料金体系が決まっていく 傾向となるだろう。
サービスの提供では、インフラ提供者や課金システム提供者（クレジット カードなど）が多くの場合、分離されている。また、広告主の存在や、 次節にあげるマッシュアップ素材提供者の存在もあるため、単純に 売り手と買い手の２者で収入モデルが完結することは、まずない。 無料で情報やサービスの利用が生じるStakeholder間の関係も分析し、 再構築し、優れたバリュー・チェーンを生み出していく必要がある。
特に、ユーザ参加を進展させる方向が、Web 2.0的なバリュー・ チェーンの特徴とみなして良いだろう。単に、CGM (Comsumer Generated Media) と呼ばれるフリー・コンテンツをユーザに提供していただくだけではない。 個人ブログに貼り付けたアフィリエイトが一挙に普及したように、Web 2.0以前 には、コストが高過ぎて事実上不可能だった売り手役や仲介役を一般 消費者が演じたり、サービスの生産自体へ参加することも、典型的な Web 2.0的バリュー・チェーンと呼んで良いだろう。
Web 2.0的バリュー・チェーンを"実装"するには、チープ革命の 洗礼を受けたテクノロジーを使わねばならない。そこで、新ビジネス モデル専用に新しく業界で取り決めた"大きな規格"を使うよりは、 オープンで無料のREST APIの上で、最小限の構造データ、メタデータ の取り決めをXMLで定義する、という方針が有望となる。ソフトウェア 機能の連携は汎用品(commodity)をそのまま使う。そして、ビジネス上の 差別化要因ともなる、新しく有意義な連携はメタデータの記述内容に 応じて実質的な動作を切り替える、という仕組みをとるのである。
上述の「原価積み上げの終焉」をコストモデル設計の観点で考える と、ともかく投資額（特に初期投資！）、固定費を削減せよ、という 経営上、一見当たり前の結論に結びつく。売り上げ額の不確定要因が 格段に大きくなるのであるから、原価を極限まで抑え込もう、という 発想である。
これを、実際にWeb 2.0的なサービスのスタートアップに適用 すると、やはり、オープンで無料のREST APIの上で、最小限の取り決め をし、機能の実装は極力汎用品で済ませる、という方向性となる。 チープ革命の恩恵を最大限に受けんがためである。これらの技術の 高度なスケーラビリティである。初期投資は極限まで抑えつつ、 ユーザが「食いついてきた！（失礼）」と感じられた瞬間、Webサーバ の増設等で一気に投資する、という手法が成り立つ。
初期投資を抑える理由は、特にBtoCのWeb 2.0サービスは「まず は無料」が当然のように要求されるからでもある。業務系のサービス の場合も、従来のように大きな契約を少数とってきてそれに必要な支出 をする（コストをかける）のではなく、広く浅く、大量のトランザクション を激安コストでさばけるようなコストモデルを追求する必要が出てくる だろう。
本頁の著作権： Copyright (c) XML コンソーシアム 2007 All rights reserved. Copyright (c) メタデータ株式会社 2007 All rights reserved.