Synapse Diary

思想地図β vol.2 [単行本] 東浩紀￥ 2,000

久々に言論誌を読んだけれど、これは震災の悲劇さを思い起こさせる。いくつか考えさせられる記事があったんだけど、一番気になった@sasakitoshinaoの「震災復興とGov2.0 そしてプラットフォーム化する世界」について書く。これを読むために買ったと言っても過言ではない。

震災復興とGov2.0の関係

震災で行政機関が機能しなくなった現実があったけれど、一方でネットの世界ではいくつもサービスが立てられ、情報提供が行われた。行政のHPもアクセスが集中したりしてダウンしたが、すぐに民間業者がミラーサイトを立てたりして、普段はあまり使わない行政のHPも、いざというときには情報の信頼性が高いと思われていることが証明された。

参考：

東日本大震災で被災地の人は何を検索したのか – Yahoo!検索 スタッフブログ

行政機関の仕事に迅速性や柔軟性が乏しい、という指摘はウン十年前からあるのだろう。そこで、情報革命を経てGov2.0が登場する。よく分からないという人は、思想地図βを読むか、この記事を読むと良いと思う。

ティム・オライリー特別寄稿：ガバメント2.0―政府はプラットフォームになるべきだ

長大な500キロ圏で、これらの無数の細かい温度差をすべて受け入れ、政府がそのすべての面倒を見る垂直統合的復興策で対応していくことはほとんど不可能だ。P.146

被災地の範囲はとても広く、いろんな個別の事情を抱えている。その中で、画一的な対応となりがちな行政機関では限界がある。だからプラットフォーム化すべきだというのが記事の主旨になる。

Gov2.0をどうやって実現するか

ただ、Gov2.0と言われても、正直あまりピンと来ていない人も多いんじゃないかと思う。「税とか住民台帳とか、間違いが許されないようなシステムを民間に任せるわけにはいかないし、そう考えるとプラットフォームって何？」みたいな。

まずGov2.0で自治体が得られるメリットについて。これは、様々な市民サービス向上アプリを提供できるということに尽きるだろう。

プラットフォームでは、行政機関が提供するデータを元に各民間企業がアプリケーションを提供することになる。主にフロントサービスが中心になるだろう。これは、行政機関が苦手とする領域でもある。こうなると、行政機関が直接アプリケーションの機能に関与しなくなる。ユーザとアプリ開発者の距離が近くなるので、サービス改善のスピードが上がり、行政機関の手間も軽減される。

アプリのアイデアそのものも、行政機関が自ら考えるより多様なアイデアが実現される可能性がある。米ワシントンのApp for Democracyというコンテストでは、１ヶ月で47のアプリが応募されたそうだ。ちなみに、コスト削減は余り期待できない気がする。バックオフィス系のシステムはなくせないし、フロントサービスのいくつかを削減できる程度だと思われる。

ティム・オライリーはSDKとAPIを提供するよう提言しているが、いきなりそれは難しいかもしれない。どちらかといえば、行政が公開して問題ない生データを、CSVなど加工しやすいデータ形式で公開することだろう。

そして、ICT地域活性化協議会もちょうどガバメント2.0について検討を始めているようだ。

「ＩＣＴ地域活性化懇談会」の提言と震災復興に向けた取り組みについて：『ビジネス2.0』の視点：ITmedia オルタナティブ・ブログ

どこか先進的な自治体が、「自分のところの取り組みが一番進んでいて、標準だ」みたいなことを言ってくれないかな。岐阜もソフトピアジャパンがあるのだから、App for Democracyのように行政サービスに革新を与えるアプリを作成する取り組みがあっても面白いな。

いずれにしても、どんどん情報公開する自治体と、それを活用してサービス化するエンジニアの両方が必要だ。実現されるまでには、まだハードルが高いだろうか。

参考：

オープンガバメントのＷｅｂイメージがわかる動画4本 | Synapse Diary

ライフサイクル イノベーション 成熟市場+コモディティ化に効く 14のイノベーション [単行本] ジェフリー・ムーア￥ 2,100

「キャズム」のジェフリー・ムーアの著書。今更ながら読んでみた。企業にはイノベーションが求められているのは変わらないのだけれど、この本が秀逸なのは「企業タイプ」を整理した上で、それに合わせてどのように資源配分すれば良いかを探っているところ。

自分の本当の「コア」とは何か

本書の中でタイガー・ウッズの例が出てくるのがわかりやすい。CMやスポンサーとの提携の方が、本業のゴルフより稼いでいるんだけど、それでもゴルフに集中すべきか？と。みんな「当たり前」だと思うだろうけど、きっとこれが企業になると、「こんだけ稼いでいる事業なんだから、これに集中すべき」みたいになっちゃうんだろうな。

自分のブランドや競争力が何を源泉としているかは、とても良く考えないといけない。

コンプレックス・システム型とボリューム・オペレーション型

本書ではビジネスモデルを2つに大別している。

コンプレックス・システム型のビジネス・アーキテクチャでは、複雑な問題を解決するコンサルティング的要素が大きい個別ソリューションが提供される。大企業を主要顧客とするビジネスはコンプレックス・システム型だ。P.38

いわゆるBtoBだよね。多数同時の問題解決が難しいので、個別に注力することになる。

これとは対照的にボリューム・オペレーション型のビジネス・アーキテクチャは、標準化された製品と商取引により大量販売市場でビジネスを遂行することに特化している。企業顧客を対象にすることもあるが、ビジネスの基本は対消費者である。P.38

これがBtoC。それぞれに、対象とする問題の複雑度と、それに対する作業効率性がある。ここまでの整理はわかるんだけど、それぞれのタイプが、どういう資源配分をしたらイノベーションを起こせるのかを考察しているところに、この本の価値がある。

コンプレックス・システム型とボリューム・オペレーション型は相互依存関係にある

ボリューム・オペレーションはコンプレックスシステムが作り出した市場カテゴリーをコモディティ化する。コンプレックス・システムが次のレベルの複雑性を作ることで対応する。P.61

コンプレックス・システム型というのは、複雑な問題に対する解決策を編み出す。それが他の組織で適用できるような普遍性が生まれると、どんどんコモディティ化していく。すると、ボリューム・オペレーション型企業が参入してきてコストが下がり、コンプレック・システム型の企業は効率性が下がるので勝負できなくなる。

すると、コンプレックス・システム型はまた複雑な問題を見つけて対処する、ということを繰り返す。つまり、コンプレックス・システム型は常に複雑な問題を解決するよう努めるし、そのときコモディティ化された技術を利用した解決策を出すこともあるので、ボリューム・オペレーション型の企業と協業することになる。

イノベーションを起こすためにどこに注力すべきか

結論を言えば、コンプレックス・システム型企業とボリューム・オペレーション型企業のどちらも破壊的イノベーションにより成功することができる。もし、あなたの会社がコンプレックス・システム型であれば、顧客のニーズが大きい破壊的テクノロジーにフォーカスし、自社の製品リーダーシップの能力を顧客インティマシーの能力で補完するべきだ。一方、ボリューム・オペレーション型であれば、既に確立した市場において破壊的ビジネスモデルで勝負した方が成功する可能性が高いだろう。この場合には、製品リーダーシップの能力をオペレーショナル・エクセレンスの能力で補い、製品を早期に安定供給できるようにすることが重要になる。P.104

無駄にカタカナ語が多いので読みづらいのだけれど、要はコンプレックス・システム型は、まだ市場がないようなところに先進的な技術を用いて解決策を提示することが肝要。

ボリューム・オペレーション型は、市場がある程度あり、コモディティ化される技術と業務遂行力でイノベーションを起こす、というわけ。

自分の企業は何に注力すべきか

これを読んで見えてくるのは、まず自分の企業に合った「問題の複雑度」を見極めなければいけない。IBMがPC事業を売ったのは、PCがコモディティ化して、問題が複雑でなくなってしまったからと捉えることができる。問題が簡単であれば単価が低くなってしまったり、ビジネスモデルが変わってしまう。

SIerが複雑な問題を解決せずに、サーバ機器を入れて、パッケージ製品を導入して、運用保守でお金を稼ぐようなモデルになれば、それはおのずと単価も下がっていく。新しく複雑な問題を見つけて、そこに解決策を提示していかにと、SIerやITコンサルは生き残れない気がするよね。

あと、市場や技術がどの程度成熟されているかを考える。市場が成熟するということは、市場が既に大きい代わりに、成長性が低かったり、コモディティ化されてしまってイノベーションの余地が低かったりする。

これを読むと、例えば複数の事業を抱えている企業はどう整理すべきかとか、自分の企業や係わる市場がどの程度の成熟度なのか、という点でいろいろ刺激的。ちょっと読みづらい本だけどね。