IT@RIETI

e-Life Blog

※本プロジェクトは、終了しております。

競争ルール戦略

情報家電のネットワーク化が進み、通信を生かした用途が広がってくれば、放送、通信、遠隔医療、遠隔教育などサービス事業者のサービスを実現するための一定のハードやソフトの仕様の共通化が必要になる。その際、情報家電全体のアーキテクチャデザインの育成に失敗すれば、サービス事業者はPCにこぞって流れ、情報家電としての競争力を失う可能性もある。 本当に大切なことは、メーカー同志の技術競争ではなく、ネットワーク化後の情報家電に「何が出来るのか？」、「それはどういうシステムとサービスをどう組み合わせているからなのか？」を、消費者や各種サービス事業者にしっかりと提案しサービス参入を促進することではないのか。これらを実現するための方策を提示する。

2004年10月24日　ToBeモデルという考え方

先週のエントリでは、ビジネスと技術を結びつけるために、間に抜けている作業がたくさんある、っというご紹介をさせていただきました。僕の堅い説明より、Neonsさんの説明の方がずっと分かり易いので、再度、引用させていただきます。

これまで放送コンテンツと数種類のプライベートコンテンツを扱う商品しか担当したことのない
メーカーの担当者が、異なる伝送路から降ってくる多様なコンテンツに対応しようとしても、
資料の9Pにあるようにコンテンツと技術の間を全く考えずに、一気に突っ走ってしまう。
その結果、一体誰が使ってくれるのだろうかと首を傾げてしまうようなユーザー不在の機能が
搭載されてしまい、失敗に終わるというケースが周りでよく散見される。
コンテンツと技術の間を埋める、「消費者行動」、「機能・データ」、「サービス」のレイヤーを
意識した新機能の策定プロセスは、まさに今求められている要素だと思う。しかし、
こういった観点で新商品を考えられる部署がメーカー内では見当たらない。
戦略部は既存商品の数年後の市場を予想して、リソース配分を決めているだけだし、
企画はそれに従って具体的な商品ラインナップと仕様を考案しているだけである

だから、コンテンツが具体的な技術に辿り着くまでに、ビジネスアーキテクチャ、データアーキテクチャ、アプリケーションアーキテクチャそれぞれについての分析と整理を経て、テクノロジアーキテクチャを語る必要がある。

今週ご説明しようと思うのは、市場の可視化に当たっては、そういう縦軸的展開に加えて、時間軸でみた横軸的展開も重要だということです。この時間展開を明らかにしていくために、EAの世界では、AsIs（現状）モデルとToBe（理想）モデルという言葉をよく使います。これって、現状と理想ってだけなんですけれども、ミソは、理想が、本当に「理想」だということなんです。この点について、少し踏み込みたいと思います。

日本人って、実は、理想（ToBe）モデルを書くのって、すごい苦手なんです。どういうことかって言うと、大半が、諸制約条件を考えて具体的に実現可能な「○か年計画」を書いてしまうからなんです。他のプレーヤーが制約条件を積極的に取り払ってくれないと実現できないモデルは書かない。

例えば、自動車免許証の更新を考えてみましょう。技術的に考えれば、既に予定されている運転免許所のICカード化はもとより、免許更新に必要な検眼、講習ビデオの視聴など多くの作業は、完全に民間にアウトソースできるものです。加えて、そのアウトソース会社が、何も自動車免許だけを扱う必要はありません。船舶、航空機、ダイビングその他様々なライセンスのトータルな管理機関になっても良いし、それを経て一つのICカードにライセンス機能を統合化していっても良いし。また、別の方向性としては、ETCのサービスや道路交通情報提供サービスなどと提携して、トータルな交通情報サービス機関などになっても良いでしょう。そういうWebサービスに対する潜在的ニーズは既に相当あると思います。

でも、相手はお役所ですから（苦笑）、運転免許データ管理のアウトソースなんてやると思います？船舶や航空機とライセンスが一緒のカードに載るなんて、すぐに認めそうですか？そこにETCもまざちゃって、そうするとクレジットカード決済機能なんかも混ざっていって、なんて、この数年に実現しそうですか？ちょっと「○か年計画」のゴールに書くにも憚られますよね。。

もう一つ、別の例を挙げれば、例えば、お役所の統計データだって、理想を言えば、省庁横断的に完全一元管理。できれば、民間にその公表管理を全部アウトソースして、民間事業者が色々な民間独自のサービスと合わせて提供するようになれば、もっと便利になりそうですよね。だけど、そういうデータ自体の公表や作成・管理は、役所はなかなか手放しそうにもない。

夢物語としては色々言えるんですけど、実際に達成しようというゴールを書こうとした瞬間、自分では解決できない制約条件があって、すごく手前で止まってしまう。EAの世界では、それをToBeとは呼ばないんです。とにかく、最初は、制約条件があっても良いから、ToBeを書いてしまう。その上で、「次期モデル」を書くんです。

これが案外大事なことは、ToBeモデルを具体的に書いてみると、次期モデルでやっておかなきゃいけないことが案外たくさんあるってことなんです。システムの本格的な更新って、そう毎年するもんじゃありません。したがって、10年にせいぜい2度か3度。でも、例えば、さっきのライセンス管理の話でも、3年後にそうなるkって言われたら「？？？」ですけれど、10年後も、今のまま、バラバラのライセンスカードを山のように財布に詰めてって、そういう世界なんですかねえ、っと。
で、もし10年後に本気にそういうサービスを実現したいと思えば、他方で色々な制度改革が必要になりますけれど、並行して3～5年後に更新するシステムの中でも、基本的な認証基盤をそれぞれのライセンスシステムが共有するとか、ライセンスを付与する個人の認証番号の体系をあらかじめ統一しておくとか、それぞれのシステムがレガシーからオープンベースのDBに移行しておくとか、いろいろな作業があると思うんです。そういう仮想・理想モデルを書いてみると分かることって、結構たくさんあるんですけれど、日本って、制約条件があってダメそうだとなると、書いてみることもしない。

夢はもっと具体的に書いてみましょう。まずは、それをオープンにしてみましょうっって、そういう作業ってどこかでいると思うんです。もちろん、ある意味各企業にとってのビジネス戦略そのものですから、そう簡単には全てはオープンには出来ません。でも、それを参照モデルって言う形で中和して、世に示していくことは出来るのではないかと思うんです。

というわけで、次は、いよいよ参照モデル本体の話に入っていきたいと思います。

Recent Entries

This work is licensed under a Creative Commons License.

2004年10月24日掲載