メタモデリングブログ

モデリング、メタモデリング、抽象化、一般化、概念化、フレームワーク、問題理解、デザイン。

シェア・プラットフォーム

メッシュ すべてのビジネスは〈シェア〉になる』という本を読み始めています。

メッシュとは、本書によれば、ビジネスモデルの一種です。メッシュでは、モノやサービスを所有することではなく、シェア(共有)することをビジネスの基盤とします。たとえば、車をシェアするようなサービスです。
-----
本書で紹介するのは、スコットの例に見るようなシンプルな発想である──共有(シェア)するほうがいいものがある、という考え方だ。
-----

さて、このブログは、ビジネスではなくモデリングに関するブログなので視点をそちらに。今回は、少しだけですが、「シェア・プラットフォーム」というコンセプト(概念)に着目してみます。本書では、次のようにこのコンセプトが使われています。
-----
所有については多くのことが語られてきた。だが所有の発想だけしか持てないでいると、私たちのビジネス脳は行き詰ってしまう。実際のところ商売も、言うまでもなく私たちの社会生活も常にシェアで成り立っている。シェアを基盤とするビジネス──シェア・プラットフォーム──は探すと至るところにある。

ニューヨークでクリスマス休暇を過ごしていた私は、周囲を見回していかにたくさんのものを多くの人々がシェアしているかに気づいた。ホテル、アパート、地下鉄、タクシー、空港、飛行機、教会、図書館など全部人々がシェアすることで成り立っている。ニューヨークを憧れの大都市にしているのは、人々が利用できるシェア・プラットフォームがたくさんあるからだ。公共のものもあれば、民間ビジネスもある。

そもそも電話線、ワイヤレスネットワーク、道路、公園、美術館やニューヨーク名物の消防車だって全部シェア・プラットフォームではないか。
-----

この文章から、シェア・プラットフォームのコンセプトの正確な把握は簡単でないかもしれません。たとえば、「シェアを基盤とするビジネス」であれば、それはシェア・プラットフォームなのかどうか疑問です。

とりあえず、ここでは、例で挙げられているように「道路」や「公園」、「美術館」などは、シェア・プラットフォームであるとします。下記の図はこのことを表しています。

platform1

次に、シェア・プラットフォームというからには、より一般的になプラットフォームというコンセプトもありそうです。以下の図では、シェア・プラットフォームはプラットフォームの一種であることを示しています。
platform2

では、プラットフォームとは、どのようなコンセプトでしょうか? たとえば、"The Architecture of Platforms: A Unified View" という論文では、プラットフォームは次のように定義されています。
-----
a set of stable components that supports variety and evolvability in a system by constraining the linkages among the other components.
-----
この定義からは、いくつかの要素が見つかります。
(1) 安定コンポーネント(stable component)
(2) システム(system)
(3) 他のコンポーネント(other component)
まずは、これらが、シェア・プラットフォームではどのようにより具体的な要素として対応するのでしょうか? 例えば、「公園」ではどうでしょう? 少し、このプラットフォームの定義では一致しないかもしれません。

ちなみに、gooの国語辞書では、次のような定義が挙げられています。どれも、適切ではなさそうです。
-----
    1 電車・列車への乗客の乗り降り、貨物の積み下ろしのため、線路に沿って築いた駅の施設。ホーム。
    2 大型の無人観測衛星。
    3 車台(しゃだい)。シャーシー。また、自動車の異なるモデルで共通して使われる車台を中心とした基本的な構造のこと。プラットホームを共有することで、生産費用を圧縮できる。
    4 オペレーティングシステムやハードウエアなど、コンピューターを動作させる際の基本的な環境や設定。
-----

プラットフォームの定義に関しては、今後も考えていきたいと思います。参考書としては、まだ読んでいませんが、平野 敦士 カールさんの『プラットフォーム戦略』が気になります。

サービスバリエーションモデリング:モデルの拡張

前回は、「美人時計」と「美人天気」というサービスを例に、サービスのバリエーションのモデリングを行いました。

今回は、その時に作成したサービスバリエーションモデルの拡張例を紹介します。

サービスバリエーションモデルとは、いくつかのサービスの間での「似ている点」と「異なる点」に着目して、複数のサービスの集合を表現するものです。

このモデリングの目的は、モデルを通じて考えることで、新たなサービスの発想を助けることです。

前回作成したサービスバリエーションモデルは、以下になります。

bijin_svm4
このモデルは、「美人時計」と「美人天気」の二つのサービスを表します。これらサービスの似ている点と異なる点は、以下です。
-似ている点: 定期的に何かをお知らせする点。美人がお知らせしてくれる点。
-異なる点: 具体的に何をお知らせするのかと言う点。「美人時計」では時刻を、「美人天気」では天気をお知らせする点。

図での四角は、サービスを構成する特徴を表します。四角の上の数字の1は、その四角で表される特徴を備えることを示します。たとえば、「美人がお知らせ」という特徴は、このモデルで表されるサービスの全てが備える特徴であることを示します。

角丸四角は、特徴のグループを表します。角丸四角の上の数字の1は、そのグループの中から1つの特徴を選択できることを表します。たとえば、「時刻」か「天気」のどちかを選択できることを表します。

次に、このモデルを拡張する例を紹介します。ここでは、モデルが表現するサービスの数を増やすようにモデルを拡張します。

美人という言葉からは、女性を想像されるかと思いますが、ここでは、男性を含めて考えます。したがって、3パターンのバリエーションが考えられます。
(1) 女性のみ
(2) 男性のみ
(3) 女性と男性
このバリエーションを表現できるように先ほどのモデルを拡張したのが、以下になります。
bijin_svm5
変更点として、「美人がお知らせ」という特徴の下に新たなグループを追加しました。このグループは「女性」と「男性」で構成されます。このグループの上には「1..2」という表記があります。これは、「1つから2の特徴を選択できる」という意味です。この表記は、統一モデリング言語(UML)における多重度のコンセプトを参考にしています。

この拡張により、このモデルでは、合計6つのサービスを表現することになります。
(1)「天気」を美しい「女性」がお知らせ
(2)「天気」を美しい「男性」がお知らせ
(3)「天気」を美しい「女性」と「男性」がお知らせ
(4)「時刻」を美しい「女性」がお知らせ
(5)「時刻」を美しい「男性」がお知らせ
(6)「時刻」を美しい「女性」と「男性」がお知らせ

bijin_svm6

サービスバリエーションモデリング:「美人時計」と「美人天気」を例に

今回は、「美人時計」と「美人天気」というサービスを例に、サービスのバリエーションのモデリングを行いたいと思います。

「美人天気」というのは、美人が天気をお知らせしてくれるサービスです。携帯電話版とiPhoneアプリ版があります。

「美人天気」の前には、似たサービスとして、「美人時計」というものが出ていました。これは、美人が時間をお知らせしてくれるサービスです。 

これら二つのサービスの間には、似ている部分と異なる部分があります。これら部分のモデリングが今回行うことです。

まずは、「美人時計」のサービスモデルを考えます。サービスモデルとは、あるサービスのあるモデルのことです。一つのサービスに対して、様々なモデルが考えられます。

sm


以下に「美人時計」の特徴に着目したサービスモデルを示します。「美人時計」の特徴として「時刻お知らせ」と「美人がお知らせ」があるとしました。もちろん、他の特徴も考えられますが、詳細なモデリングは今回の目的ではありません。

jibin_tokei_sm
図での1という数字は「その特徴を備える」という意味です。

次に、「美人天気」について同様の視点からサービスモデルを考えました。
bijin_tenki_sm
「美人時計」との違いは、時刻ではなく、天気をお知らせする特徴を備えるという点です。

作成した二つのサービスモデルには、異なる点と似た点があると考えられます。
-異なる点: お知らせする内容
-似ている点:お知らせする人

そのため、ここでは、「美人天気」は、「美人時計」のバリエーションの一つであると考えます。逆に、「美人時計」は、「美人天気」のバリエーションの一つであるとしてもかまいません。ここでは、どちらのサービスが先に現れたのかという時系列は考慮しないためです。
 
次に、サービスのバリエーションという視点から、モデルを考えてみます。サービスの可能なバリエーションを表現するモデルを、ここでは、サービスバリエーションモデルと呼ぶことにします。ただ、少しコンセプトとして曖昧なので、サービス空間モデル、あるいは、サービスメタモデル等と呼んでもよいかもしれません。

svm

サービスバリエーションモデルと呼ぶ理由の一つは、サービスのバリエーションを考えるのに使うことを意図しているためです。つまり、サービスバリエーションモデルを拡張する過程を通じて、サービスの新たなバリエーションの発想を助けることを意図します。
svm2

下記の図では、「美人時計」と「美人天気」を表すサービスバリエーションモデルとサービスモデルを示しています。ここでは、「美人お知らせ」という呼び方で、サービスのバリエーションを表すことにします。

bijin_svm

 サービスバリエーションモデルでの角丸四角は、特徴のグループを表します。グループ記号の上の数字は、そのグループからいくつの特徴を選択できるのかを表します。この例では、「時刻お知らせ」と「天気お知らせ」がグループ化されています。数字は1ですので、どちらかを選べることを表します。どちらかを選ぶことは、「美人時計」あるいは「美人天気」のどちらかのサービスに対応するモデルが得られることを意味ます。

さらに、新たなバリエーションの発想を促すことを意図して、バリエーションモデルを少し改良します。抽象化された特徴を追加することで、その特徴から他の具体的な特徴を発想できることを明確にします。

 bijin_svm2

この例では、「時刻お知らせ」と「天気お知らせ」を抽象化して「定期お知らせ内容」という特徴を追加しました。「時刻」や「天気」のほかに、私たちが定期的に確認していることは何でしょうか? それが新たなバリエーションのサービスとなります。

さらには、このモデルでは、お知らせしてくれる人を「美人」に限定しています。「美人」を軸にどのようなバリエーションが考えられるでしょうか?
(1) 「美人」を抽象化すれば「人」になります。「人」であれば「美人」でなくてもいかもしれません。
(2) 「人」を抽象化すれば「生き物」になります。「生き物」であれば「人」でなくてもいかもしれません。
(3) さらには「生き物」が抽象化されれば「モノ」とできるかもしれません。「モノ」であれば生きていなくてもよいかもしれません。
(4) 「美人」を抽象化するのではなく逆に具象化(具体化)する方向もあります。「地方美人」などです。

bijin_svm3

 続きを読む
livedoor プロフィール
カテゴリ別アーカイブ
タグクラウド
QRコード
QRコード
  • ライブドアブログ