いろいろな人がビジネスモデルという言葉を使っています。ビジネスモデル特許の問題が議論になって以来,概念として注目されるようになってきたわけですが,一般に世の中で使われているビジネスモデルという語と,要求開発アライアンスを含めてIT業界や情報システムの世界でビジネスモデルというときとでは,少し違った意味合いがそこに込められているようです。
まず,世の中一般に流通しているほうのビジネスモデルとは,うまくビジネスを行うためにはどうすればよいのか,より儲かるためにはどんな商売の仕組みを考えればよいのか,を具体的な仕掛けとして提案したものを指します。「儲かる仕掛け・儲ける仕組み」と言ってもよいでしょう。企業家,例えば新たに会社を起こして一旗揚げてやろうと考えているベンチャー経営者は,誰もがここに知恵を絞っているでしょう。これが狭義のビジネスモデルです。
そして,ビジネスモデル特許と言う場合には,この狭義の定義のさらに限定された一部分が権利として保護されるということになります(国によりこの限定の仕方が微妙に異なるようです。また英語圏では,ビジネスモデル特許という表現は無く,business methodのpatentという言い方が普通のようです)。
一方で,ある会社や組織でどんな風に業務が行われているのかを理解したい,あるいは今後どのように業務や組織を改変してより望ましい経営に進化させるのかを検討したい,異なる組織同士をうまく協業させるための課題を総合的に見極めたい,といったニーズがあります。どれも経営や業務上の組織のあり方(構造と振る舞い)を全体として理解したい,というケースです。
こうした,いわゆる“見える化したい”というニーズに応えるには,“ではここでビジネスモデルを作ってみましょう”という手段を取ります。これが広義のビジネスモデル,要求開発御用達のビジネスモデルということになります。
経営がきちんと回っているのか,商売のどこかに課題はないか,メンバーの役割や組織の構成に歪みはないか,業務フローに無駄や不具合は含まれていないか,情報の流れや管理に問題はないか,組織の構造や業務の仕組みを変えたらどこにどう影響が出るだろうか──こうした問題を考えたいときには,やはりその対象組織の「全体的な仕組み」を『システム』としてとらえ直して,それをモデルとして記述します。
ここでシステムというのは,コンピュータや情報システムということではありません。あくまでも論理的な視点,理系の目でそこで行われている物事をきちんと整理・抽象化して,一種のミニチュアが作れるように記述してみましょう,ということです。そのビジネスのミニチュアのことをビジネスモデルと呼ぶわけですね。
ですから,狭義のビジネスモデルが,儲け方・儲かり方の部分に焦点を合わせてその部分に特化したミニチュア作りを目指しているのに対して,広義のビジネスモデルは,儲け方を含めより広く継続的な企業組織や業務の仕組みを対象としてミニチュアを考えるわけです。それぞれはスコープに違いがあるだけと言えるでしょう。
しかし,広義のビジネスモデルといえども,いつでもすべての側面を総合的に取りあげて幅広く何でも企業を見える化すればよい,というわけではありません。必ず,その企業の経営者や利害関係者にとっての共通の目標と,そこから導出される共通の関心事というのが見出せるはずですから,そこを外さないことが大切です。
また,時間やリソースといった制約の元で,コスト意識を持ってビジネスモデリングに取り組まないと,だらだらといつまでも何となくモデル構築を続けてしまい,成果が出ないという,いわゆる「モデリング中毒」に陥りがちですから気をつけましょう。
その意味で,狭義のビジネスモデルに限定すれば,モデリング中毒に陥る心配はないとも言えます。竹村健一氏ではありませんが,ビジネスの「これだけ」を絞りに絞り込んだものが狭義のビジネスモデルだと言えます。狭義のビジネスモデルに関して,以下のように,いろいろな人が定義を試みています。
- 経営資源の組み合わせ方
- 企業が様々なビジネスを生み出すための基盤
- 顧客価値を作り出すための基本的な仕組み
- ビジネスの主要な特徴の表現
しかし,いろいろ見た中で最も的確だなと感心,納得したのは,書籍「オープンソリューション社会の構想」(国領二郎 著,日本経済新聞社 発行)の以下の定義である(立ち読みで記憶した直後にメモしたもの*1から起こしているため,正確な引用ではないのをご容赦ください)。
- (1)誰に,どんな価値を,提供するのか
- (2)その価値をどのように,提供するのか
- (3)提供するために必要な経営資源をどんな誘引のもとに,集めるのか
- (4)提供した価値に対して,どのような収益モデルで対価を得るのか
この定義をよく観察すると(国領氏自身が言っているわけではありませんが),以下のように,各項目はほぼ正確に5W1Hの要素に対応します。
- (1)は,What/Why=何を価値・サービスとして(サービスバリュー・ゴール)とWho/When=誰に対して(コンテキストとステークホルダー)
- (2)は,How=どのように提供するか(プロセス)
- (3)は,With What=どんな経営リソースを(コンセプトとリソース)とHow Well@Where=どう工夫して(ソリューション)
- (4)は,How Much=価値の対価をどう得るのか(バリュー,コスト,時間,クオリティ)
実は,筆者はここ数年,ビジネスモデルをどのような視点(ビュー)で整理すべきかについて検討を進めており,それを「(4+1)×1ビューのビジネスアーキテクチャ」というフレームワークにまとめています。簡単に言うと以下のようなものです。
図1●(4+1)×1ビジネスビューのイメージ |
1から4までの各項目は,ほぼこれらの四つないし五つのビュー(視点)に相当することがわかります。この(4+1)×1ビジネスアーキテクチャは,全く国領氏の定義とは独立に,システムアーキテクチャとの相似性から逆算してビジネスモデルにソフトウエア類似のビューを適用して整理したものだったため,この対応関係を見出したときには非常に驚きました。再度対応関係を整理すると次のようになります。
1. | +1ビュー | Why/What = 何を価値・サービスとして(サービスバリュー・ゴール) |
2. | 第2ビュー | Who at When = 誰に対して(コンテキストとステークホルダー) |
3. | 第3ビュー | How = どのように提供するか(プロセス) |
4. | 第1ビュー | With What = どんな経営リソースを(コンセプトとリソース) |
5. | 第4ビュー | How Well at Where = どう工夫して(ソリューション) |
6. | ×1ビュー | How Much = 価値の対価をどう得るのか(バリュー,コスト,時間,クオリティ) |
このように,国領氏のビジネスモデル定義をヒントにすると,狭義のビジネスモデルと広義のビジネスモデルという区別にそれほど大きな違いがあるわけではないことも明瞭です。その区別は,あくまでもフォーマルなモデル記述が伴っているか,対象のスコープが最小限の儲ける部分かより広い組織範囲かどうか,の違いに過ぎません。
広義のビジネスモデルをUMLやBPMN(Business Process Modeling Notation)などで表現する場合にも,やはり狭義のビジネスモデルの六つのポイントをいつも意識しておくことが重要です。そして,(4+1)×1ビューは,それをいつでも忘れず意識しながらビジネスをする(モデリングも含めた経営や業務の遂行全般)ための強力なツールになることでしょう。
今回は,(4+1)×1ビューについてはきちんと説明する余裕はありませんでしたので,以下に簡単に各ビューの目的と要点をまとめておきます。(4+1)×1ビューのビジネスアーキテクチャについては,またの機会にお話できればと思います(ぜひ近刊の『戦略マップによるビジネスモデリング』(内田 功志,羽生田 栄一 著,翔泳社 発行,2007年6月発売予定)をご参照ください)。
表1●(4+1)×1ビジネスアーキテクチャの各ビューの内容象限 | ビュー名 | 5W3H | 要点 | 成果物 |
1 | ビジネスコンセプト (概念) |
with What | そのビジネスで中核となる概念や経営リソースを表現 | ビジネス分析モデル(ドメインモデル) |
2 | ビジネスコンテキスト (文脈) |
for Who at When |
そのビジネスに関わるステークホルダや組織,経営環境を表現 | 組織モデル,環境モデル,ビジネスルール |
3 | ビジネスプロセス (業務) |
How | そのビジネスのワークフローや業務手順を表現 | ビジネスワークフロー(ビジネスUCモデル一部) |
4 | ビジネスソリューション (解法) |
How well at Where |
そのビジネスの業務改善・IT化を踏まえたあるべき姿を表現 | BUCモデル(Tobeビジネスワークフロー),ビジネス設計モデル,システムUCモデル |
+1 | ビジネスユースケース (物語) |
What/Why | ビジネスのゴールやシナリオ,ビジネスが提供する中核サービスを表現 | ビジネスゴール,ビジネスUCモデル |
×1 | ビジネスバリュー (価値) |
How much | その組織体やビジネスの目的と価値目標,コスト,時間などを表現 | ビジネスビジョン,戦略マップ,価値xコスト表 |
(羽生田 栄一=要求開発アライアンス) |