January 2013 Archives

■ ハイブリッッド型アプローチ

ビジネスモデル起点でビジネスサービスを企画していくわけですが、そこでいきなりビジネスサービスを浮かべるというのもなかなか難しいでしょう。ビジネスサービスというのは結局ビジネスプロセスのどこかを切り取ったものであるとも言えるので、ハイレベルのビジネスプロセスに展開してから吟味、導出を行ったほうがよいと思います。

それを、まっさらのところから始めるのも難しいものです。そんな時には参照モデルを利用するのも一策です。企業というものが登場してきてから、あまたのビジネスモデルが現出しているわけだから、そのなかから成功モデルを抽出して標準化すれば参照モデルができます。そうしたものをお手本にしたら時間の節約にもなるし、抜けがないものになるのです。そうした、参照モデルの代表的なものは次のようなものがあります。

1.VRM(Value Reference Model)
2.PCF(Process Classification Framework)
3.SCOR(Supply-Chain  Operations  Reference)
4.DCOR(Design-Chain  Operations  Reference)

こうした参照モデルは、汎用性を持たせているがゆえにわりと抽象度の高いところで止めています。細かくすればするほど個別性というか特有な要素を入れなくてはいけなくなって、カテゴライズし派生させて複雑化してしまうからです。ですから、そこからのサービスへの落とし込みは個別にやる必要があります。

その時、ハイレベルのモデルプロセスをさらに詳細に分解していくトップダウンアプローチでは限界があります。先ほど言ったようにモデルはどれにもあてはまるように網羅的な作りになっていて、どうしても冗長的ですから要らないものをそぎ落とす作業が必要になります。ではそうしたそぎ落としはどうやったらよいかというとボトムアップ的にやらざるを得ません。そのビジネスに何が必要なのかは、実際のビジネス形態から発想されるからです。

つまり、おおかたの枠組みはモデルベースでトップダウン的に固めておき、その要不要を含めた中身はボトムアップ的なアプローチでサービスを導出するというのが現実的な解であると考えています。これがハイブリッド型のアプローチです。トップダウンの網羅性であるがゆえの冗長性とボトムアップのAsIsベースであるがゆえの抜けという弱点を補完するやりかたです。

ところで、ビジネスモデルというとついお金儲けのスキームみたいな捉え方がされます。昔はビジネスモデル特許というような話題があったと思いますし、最近ではネットビジネスの広告モデルとが携帯課金モデルとか、はたまたAKB48モデルとかが喧伝されています。確かに、ビジネスモデルといえばそうなのですが、ここではもう少し広い意味でビジネスモデルと言っていますので注意してください。

ちなみに、今例をあげたものは狭い意味のビジネスモデルで収益モデルあるいは商流モデルといった表現にしています。ここにも参照モデルのようなものがあってぼくは「ピクト図解」というのを利用しています。このように参照モデルとリアルモデルをうまく組み合わせてサービス定義をしていくのが大事になってきます。
 


■ アイデア創出はジネスモデル起点で
どういうサービスにするかのアイデアを導出する具体的なやり方について考えてみましょう。アイデアというと斬新なものがパッと浮かんでくるのだと思っている人もいるかもしれませんが、そんなことはほとんどありません。ただそれでも、ぼくの場合は、寝ている時とか新聞を読んでいるときとか風呂に使っている時とかにひらめくことがあります。ですから、いつもメモ用紙と鉛筆を置いておきます。(さすがに風呂場には持ち込みませんが)最近では、iPhoneのメモに書いたり、ボイスメモに録ったりします。

しかしながら、いま言ったように全くゼロから発想するようなものはほとんどなく、もやもやしていたことが晴れるとか、もつれた糸がほぐれたといった感じでしょうか。というのもアイデアというのは、「Webサービスのつくり方」にも紹介してあるジェームス・W・ヤングの言葉のように「アイデアとは既存の要素の新しい組み合わせ以外の何ものでもないということである」ということだからでしょう。

それと、アイデアと言っても目的というか、こういうことができるといいかなあといったものがあるわけだから、手がかりがあるのである。ではビジネスサービスの場合はその手がかりは何なのだろうか。それがモデル起点というアプローチにあるように思っています。つまり、モデルを書いてそれを眺めることによってアイデアを湧出させようとすることです。最初にビジネスモデルを描くことで、そのモデルのどこの部分でどんなサービスがほしいかという観点で練ることになります。

ビジネスモデルというのは、何から構成されているのかという問題については、最近よく売れている本に『ビジネスモデル・ジェネレーション ビジネスモデル設計書』(アレックス・オスターワルダー (著 )/ イヴ・ピニュール (著 )/ 小山龍介 (訳 )/ 翔泳社)というのがあります。そこでは、ビジネスモデルの構成要素を次のように定義しています。

①顧客セグメント(Customer Segment)
②提供する価値(Value Proposition)
③チャネル(Channel)
④顧客との関係(Customer Relation)
⑤収入の流れ(Revenue Stream)
⑥主なリソース(Key Resource)
⑦主な活動(Key Activity)
⑧パートナー(Key Partner)
⑨コスト(Cost Structure)
 
これらの要素をビジネスモデルキャンバスというところ記述していくわけです。これを埋めていきながらアイデアを出していくとよいでしょう。ただ、これだと"提供する価値"の中にアイデアが詰まっていくように思えてくる。つまり、他の要素を検討しながら価値へつなげていくのが順序だと思うのである。いきなりは価値は書けないのではないでしょうか。

従って、ぼくのやり方は、どこの誰に(市場・顧客)にどんな商品(製品・サービス)をどのリソース(人・モノ・金・技術・チャネル等)を使って、どのように提供(サプライチェーン)して、どうやって儲けるか(収益モデル)をまず記述して、それぞれの強み弱みの分析結果や思いを表現したものが価値となるように思っています。

その価値を実現するのがビジネスサービスであり、そこからどんなものにするのかというアイデアを導き出すのです。いずれにしろ、ビジネスモデルをまずは書いてみて己の立ち位置を確認していてそこから発想するのが現実的で実現性の高いアイデが生まれるのではないでしょうか。
 
 
■ ビジネスサービスの企画って何?
Webサービスだと企画というのはどういうものかはわかりやすいと思いますが、さあそれではビジネスサービスの企画ってなんでしょうか。まず、一般的にやられている業務システム開発を考えてみましょう。企画なんてフェーズがあるのかという疑問が湧いてきます。スクラッチで開発するにしても、パッケージを適用するにしても、企画づくりの流れでいうと⑦のデザイフェーズから入っているように見受けられます。

要するに、データベースと画面の設計から入るというイメージでしょう。ユーザから要求をヒアリングするからそれは企画でしょうというかもしれませんが、そこには哲学とか「これが欲しい」というアイデアとかはあまりないように感じられます。サービスというのは、送り手と受け手が双方でコンセプトを共有して初めてサービスが成り立っていきます。一方的だとどこかでうまくいきません。

これまでのやり方でこうしたコンセプトの共有ということはあったでしょうか。どうも一方通行のような気がします。パッケージなんかは送り手の押し付けですし、スクラッチだとユーザのわがままを仕方なしに受けるなんてことが起きています。これから大事なことは、お互いに良いサービスを作り、使うのだという意識をもつことだと思います。

そこからは、企画の流れに示したようなステップを踏むことの必要性が見て取れます。ただ、さあアイデアを出してください、出しましょうといってもそう簡単なものではありません。現実的なやり方は、現状の問題点を探すことだろうと思います。Webサービスでも個人生活でこんなこと欲しいので何とかならないかといった発想をします。駅の時刻表はあるけど、どういう経路を行けば一番早いかを教えてもらうとうれしいなということで乗換案内サービスが出来たりするわけです。

ビジネスの世界でも基本的には同じですが、Webサービスがどちらかというと問題解決というより、もっと楽しく、もっと気分よくといったプラス方向のサービス指向ですが、ビジネスサービスではどうしても、問題があるのでそれを解決する方向が主になります。ここの処理に時間がかかるからもっと速くできるようにしたいなんてことが多くなります。

これは仕方ないことですが、これからの業務システムではサービス指向にすること、さらにプラス方向のサービス化を考えて行きたいものです。すなわち、日常の仕事がやらされてる感から、やってる感へ変えるとか、自分の仕事の成果が組織に貢献できたらみんながいいねと評価してくれるといったサービスを取り込めたらいいなあと思っています。

そのためにも一旦自分たちの足元をじっくりと見直したらいいと思います。会社はどう動いているのか、組織はどうしてあるか、どうあるべきか、その中の個人の役割は、それを実行するのにどんな障害があるのか、なぜ不機嫌な職場になっているのかといったことをじっくりと考えてみる必要があるでしょう。何となく、効率化や自動化を目的としてシステムを導入してやしませんか。そこを見直すことも企画の大きな目的でもあるのです。
 
さてこれからは企画の話になります。「Webサービスのつくり方」という本では次のように書いてあります。

Webサービスにおいて、「何を」つくるかは最も重要なことです。いくら崇高な技術を持っていても。「何を」つくるかによって、その技術が生きるか死ぬかが決まってきます。何をつくるかをしっかり決めることにより、実際に本番用のコードを書く実装の段階にも確信が持てますし、リリースした際に得られるフィードバックも活きてくるでしょう。

ここに書かれていることは、Webサービスだけにとどまらず業務システム、すなわちビジネスサービスについても言えることではないでしょうか。「WhatはHowに優先する」ということを忘れないようにしたいですね。

■ 企画づくりの流れ
何となく頭の中で思い巡らしただけでは企画は生まれてきません。それなりの型があります。次の7つの項目を決めることです。
①    哲学
②    アイデア
③    テーマ
④    コンセプト
⑤    名前
⑥    デザイン
⑦    内部設計

ここで留意しなくてはいけないのは、Webサービスとビジネスサービスでは、粒度的にレイヤーが一段違うように思います。つまり、ビジネスサービスはWebサービスのレベルのものの集合になっていると考えられます。しかしながら、上記の流れや基本的な考え方は同じように大事だということです。

ではそれぞれで見ていくと、哲学というのは、「Webサービスのつくり方」では"特定の興味に関する揺るがない気持ちのこと"と言っています。これをビジネスサービスに当てはめて考えてみましょう。"仕事を気持ちよくやりたい"ということかもしれません。あるいは、"自分を成長させてくれるもの"かもしれません。そこは会社にとって、また組織にとって揺るがないものを選択すればよいのですが、お気づきかもしれませんが、従来のビジネスサービスでこうした見方をしたでしょうか。効率一辺倒でしか見ていなかったのではなしでしょうか。哲学をしっかりと考えてから取りかかりたいものです。

次のアイデアは簡単にいえば、哲学を叶えるために「これが欲しい」というものを挙げて行くことです。そして、哲学をより具体的な形に落とし込んで狙っていくエリアがテーマになります。アイデアが出て、テーマが決まるとだんだん見えてきますよね。それを一言で表現したものがコンセプトになります。そして、名前付けをするのですが、ビジネスサービスではそんなに重要ではないと思いがちですが、意外と注意したほうがよいと思います。名は体を表すからです。

あとは、デザイン、内部設計といった従来よくやられていて、それなりの考え方がいっぱいある領域です。ここへ来ると、「何を」から「どのように」に入ってきますが、企画の段階では、あまり細かいところに踏み込まない方がよいでしょう。しっかりと「何を」つくるのかを固めることをして、その「何を」に気持ちや、思いや、願いなどを埋め込んでおくことが大切なのです。