2013-02-02

Instacodeで遊んでみた

この前みつけた、Instagramのcode版
http://instacode.linology.info/

Business Modelもかっこ良くなりました。
日本語は未対応でした。残念。

f:id:kuruma3:20130202122749p:plain

2013-02-02

スタートアップ関係の本で勉強したことをザックリまとめてみた

最近読んだ本で勉強したことをザックリまとめてみた。

f:id:kuruma3:20130202115537p:plain
ビジョンを作る。
今後、10年くらいは続けても良いなと思う気持ちがあると良い。
戦略は方向転換しても、ビジョンは代わらない。

f:id:kuruma3:20130202115545p:plain
ビジネスモデルキャンバスをとりあえず考える。
最初は妄想だと思うけど、一生懸命熟考することが大切だと思う。

f:id:kuruma3:20130202115551p:plain
リーンスタートアップ的に小さなバッチサイズで、早く繰り返し計測する。
小さなバッチサイズのイメージなので、砂時計型にしてみた。
全部の仮説は一気に通すと破裂するので、小さく砂時計の砂のようにやっていくのが良さそう。

f:id:kuruma3:20130202120429p:plain
とは言っても、上手く行かなかった場合は、リーンスタートアップで言うピボットが必要。
おにぎりから、手巻き寿司にしても、日本の心を伝えることはできる！
こんなときに、ビジョンがしっかりしていると重要なのかもね。

2013-02-01

Business::Run#run

Businessを走らせる3つのエンジンについて、リーンスタートアップに書いてあったのでメモ。
まだ、ビジネスモデルにまで落とし込めていない。。。

リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす

作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
出版社/メーカー: 日経BP社
発売日: 2012/04/12
メディア: ハードカバー
購入: 22人クリック: 349回
この商品を含むブログ (74件) を見る

1. Sticky(粘着型)

利用者が使えば使うほど、抜けられなくなるモデル。
DBに貯める系のものが多そう。
Evernoteなんかもそうだろうね。

どれだけお客さんが止めないかがRunしているかの目安。
チューニングも、新規獲得顧客、継続利用者、中断者あたりの割合をみていくっぽい

2. Viral(ウィルス型)

利用者が使えば使うほど、拡散されていくモデル。
ソーシャルの拡散力をつかったりするやつかな。
Grouponなんかがそうだね。

ウィルスがどれだけ拡散していくかがRunしているかの目安。
チューニングもウィルスの拡散力を高め、来てくれたお客さんを有料会員化していくってところになる。

3. Paid(支出型)

お金を使って、利用者を獲得するモデル。
営業マンがいたり、広告を打ったりするタイプ。
いわゆる昔ながらの方法になるのかな。

顧客獲得単価や生涯価値なんかを見ていくっぽい。

2013-01-30

Business::Run

# # Business::Run
# ビジネスモデルを実行するメソッド群
# run,tune,pivotと3つ用意した。
# ビジネスモデルをrun=テストして、問題があれば、tune,pivotを行って行く
# テスト自体は、Rspec的なもので別にまとめていく
module Business::Run

  # ## run
  # ビジネスモデルに沿って、ビジネスを実行すること
  # ビジネスを走らせれば走らせるほど、『数』が増える
  # 単純に、利用者数が増えて行くことになる。
  def run
  end

  # ## tune!
  # ビジネスモデルは基本そのままで、調整を行うこと
  # 弱いところを強化したりといったところ
  # tuneを行う目的は、測定しているデータの『割合』をかえることにある
  # tuneは主にシステムの改善などになる
  # 例) 利用者数 対 課金者数の割合を、変えたい
  def tune!
  end

    
  # ## pivot!
  # ビジネスモデル自体をいじって方向転換すること
  # 上手く行かない場合には早めに行う。
  # innovateに比べて小幅な改良のイメージ
  def pivot!
  end
  
end

2013-01-29

Business::Innovate

Business::Innovateモジュールの原型を作成

# # Business::Innovate
# 古いBusinessインスタンスから新しいインスタンスに変換する
# innovateメソッドを提供する
# innovateの中身は、
# * value主導
# * customer主導
# * channel主導
# * customer relationship主導
# * revenue主導
# * cost主導
# に分けて、各々fromメソッドとして提供する
# innovateするときに、どのfromメソッドを使うかは、メンバーと外部要因になりそう。
module Business::Inovate

  # ## innovate
  # business_new = business_old.innovate
  # 古いビジネスから新しいビジネスを作る
  def innovate
  end

  # ## innovate
  # 破壊的イノベーション
  # business.innovate! #=> business自体が新しくなる
  def innovate!
  end

private

  # ## from_value
  # * 新しい価値を創造する
  #   - Blue Ocean戦略 (nintendo スマサガ不動産 etc)
  # * 価値を高める
  #   - 後発ながらも今までの課題を全てクリアしたり( apple etc)
  def from_value
  end

  # ## from_customer
  # * フリーミアム: お客さんを複数にセグメントして、支払いを変えたり無料にする
  #   - 多くのweb系企業 (アイテム課金のゲーム, Evernote etc)
  # * マルチサイドプラットフォーム: 複数の種類のお客さんを繋ぐ
  #   - プラットフォーム型のサービス (Google, App Store, フリーペーパー, リクルート系)
  # * 今までターゲットにしていなかったお客さんを対象にする
  #   - 海外進出したりとか
  def from_customer
  end

  # ## from_ch
  # * ロングテール: マニアックな価値にもリーチできる
  #   - Amazon などのEC
  # * リーチするコストを下げる: (=マルチサイドプラットフォーム)
  #   - マッチング系サービス (kakaku.com)
  def from_ch
  end

  # ## from_cr
  # * お客さん自身にもKP(パートナー)になってもらう = ロングテール
  #   - wikipedia, cookpad, 食べログ etc 
  # * お客さん自身にCH(チャネル)になってもらう
  #   - ソーシャルマーケティング (Groupon etc)
  def from_cr
  end

  # ## from_revenue
  # * 無料にする
  #   - フリーミアム、マルチサイドプラットフォーム
  # * イニシャルをなくす
  #   - webサービス系, AmazonWebService, プリン
  def from_revenue
  end

  # ## from_cost
  # * 内部コストを下げて、価格破壊をする
  # * オープン戦略
  #   - オープンソースコミュニティの利用など
  def from_cost
  end

end

2013-01-29

Business#purpose

しばらくは、Businessモデルの各fieldについて考えながら、モデル自体をブラッシュアップしていこうかと思います。

初回は、purpose=目的から。

まず、目的と目標は分けて考えましょうということが多く言われています。

目的は、目指すべきもの。
目標は目的を達成するために、クリアすべきものって感じでしょうか。

インフラ型の企業、例えばインターネット回線を提供している、企業であれば、

目的: 世界中のどんな人でも、インターネットに接続できる社会を作る。
目標: 日本に回線を全部引く。低所得者でも使えるように、コストを下げる。

というような感じでしょうか。

さて、purposeで押さえておくべきことは、
そのビジネスがどのタイプなのかということです。

例のビジネスモデルジェネレーションには、その基準に3つを取り上げていました。

製品イノベーション型(製品品質を最大化)
カスタマーリレーション型(お客さんとの関係を最大化)
インフラ型(お客さんの数を最大化)

です。

例えば、インフラ型のエンジニアと、カスタマーリレーション型のサポートセンターが一緒になっている会社があるとします。

このとき、カスタマーリレーション型のサポートセンターからは、もっとこうしたらお客さんのためになるんじゃないかという提案が当然でてきます。
ただ、インフラ型のエンジニアは、世界中の多くの人に安価で製品を届けたいと思っているため、お客さんの個別事情は黙殺しないと整合性がとれなくなります。

そこで、目的の違いによる対立構造ができてしまいます。
こんなミスマッチを防ぐためにも一番最初に目的はハッキリさせておいた方が良いと考えています。

各タイプについて、さらに詳しく考察します。

1. 製品イノベーション型 (value型)
新しいValuePropositionを想像するタイプです。

代表は、アップルでしょうね。

小話です。
ジョブズは、一時アップルを追い出されていました。
当時のアップルは、マイクロソフトとのシェア争いを繰り広げ、完全な敗北状態でした。
で、再度ジョブズをアップルに復帰させようということになりました。

このとき、ジョブズは、『アップルが勝つためにはマイクロソフトを負かさないといけないのならば、アップルは負けるだろう』という趣旨の発言をしています。

これは、アップルはインフラ型の企業ではなく、製品イノベーション型の企業であることを意味しているんじゃないかなと思います。

製品の価値を最大化することが目的になるで、アップルの商品は、別に安くないですしね。

ミシュランで三ツ星をとるような、高級レストランもこのカテゴリーになるかと思います。

2. カスタマーリレーション型 (cr型)
お客さんとのリレーション(cr)を強化していくタイプです。

コンサルや、受注型のシステム会社がこのカテゴリーかと思います。
個人的にはあまり興味がないカテゴリーですね。

3. インフラ型 (cs型)
コストを最小限に抑え、世界中の人に安く提供するタイプです。

ネット系の企業に多いタイプだと思います。Googleやfacebookもこのタイプかな。
チェーン店系の飲食もこのカテゴリーかな。吉野家とかのインフラ型の企業が、最高の品質のための、最高級レストランとぶつからないのも目的が全く違うからでしょうね。

と、こんな感じで、ビジネスが進めば進むほど、異なる指向のメンバーが集まってしまうと、
目的が違うため、どんどん乖離がおこってきます。

そのため、一番最初に目的はハッキリさせておきましょう。
（Unbundled Business Modelという項目ではスピンオフさせましょうという内容が書いてありますが。。。）

以上、まとめです。

まずは目的（purpose）を決定する
目的（purpose）は3つの、パターンのうちどれかを選んだ方が良い

で、今回の考察を経て、Business Modelはこんな感じになりました。

class Business < Model

  # 名前
  field :name, type: String

  # ## 目的 
  # 目指すべきもので最初にきめるもの
  # value: innovation
  # customer: customer_relationship
  # cr: infrastructure
  field :purpose, type: {name: String, type: String}
  validates :purpose.type, inclusion: { in: [ :value, :customer, :cr ] }

  # 価値
  field :value #=> ValuePropositions カスタマーへの価値。何を本当に求めているんだろう？何にお金を払ってくれているんだろう？

  # お客さんのこと
  field :customer #=> Customer Segments お客さん。サービスの価値を伝える相手は誰なのか？
  field :ch #=> Channels チャネル。お客さんにどうやって価値を伝えるのか？
  field :cr #=> Customer Relationships お客さんにどうやって継続利用してもらえるんだろうか？
  field :rs #=> Revenue Streams お客さんからもらえる報酬。

  # 自分たちのこと
  field :kr #=> Key Resources 自分たちの持っているものや人は何があるのか？何が使えるのか？何が足りないのか？
  field :ka #=> Key Activities メインでやっている活動は何か？
  field :kp #=> Key Partners 協力してくれるパートナーさんは誰か？
  field :cs #=> Cost Structure 価値を提供するためにかかる費用。

end

2013-01-27

BusinessModelの定義

Intro

色々と、考察する前に、BusinessModelを定義しようと思います。

BusinessModelはMVCのModelとかけて、Business Modelとして定義していきます。
なお、このブログでは、Ruby的なプログラミング言語を用いて記述していく予定です。

さて、ビジネスモデルキャンバスによると、Business Modelは以下のように作れます。

class Business < Model
  # 名前
  field :name
  # 目的
  field :purpose

  # 価値
  field :value #=> ValuePropositions カスタマーへの価値。何を本当に求めているんだろう？何にお金を払ってくれているんだろう？

  # お客さんのこと
  field :customer #=> Customer Segments お客さん。サービスの価値を伝える相手は誰なのか？
  field :ch #=> Channels チャネル。お客さんにどうやって価値を伝えるのか？
  field :cr #=> Customer Relationships お客さんにどうやって継続利用してもらえるんだろうか？
  field :rs #=> Revenue Streams お客さんからもらえる報酬。

  # 自分たちのこと
  field :kr #=> Key Resources 自分たちの持っているものや人は何があるのか？何が使えるのか？何が足りないのか？
  field :ka #=> Key Activities メインでやっている活動は何か？
  field :kp #=> Key Partners 協力してくれるパートナーさんは誰か？
  field :cs #=> Cost Structure 価値を提供するためにかかる費用。

end