この広告は30日以上更新がないブログに表示されております。
新規記事の投稿を行うことで、非表示にすることが可能です。
広告
posted by fanblog
2018年08月26日
コミュニケーションのカギとなる「スター的存在」
組織の内外をつなぐ役割
ゲートキーパーとは門番のことです。
アレン 氏は『技術の流れ管理法』の中で、
コミュニケーション・パターンが
研究開発パフォーマンスに与える影響を調べました。
すると、どの研究開発組織にも、
コミュニケーションのカギとなる
スター的な人間がいることが分かったのです。
彼らは一般の技術者よりも
技術専門紙の読書量が圧倒的に多く、
外部情報との接触頻度が多かったのです。
このコミュニケーション・スターこそが
ゲートキーパーというわけです。
各研究開発組織には、その組織固有の文化、
考え方、用語があり、それらの違いが
セマンティック・ノイズ(意味上の雑音)となり、
外部とのコミュニケーションを阻害していたのです。
ですから、組織内部と組織外部との
コミュニケーションの文字通り門番として
機能していたのが、このゲートキーパーだったのです。
つまり、ゲートキーパーは、組織内の誰とでも
何らかの形で接触しているスター的な存在であるとともに、
組織外部との接触もきわめて多い人間だったわけです。
アレン氏は、ゲートキーパーの特徴として、
?@高度の技術者、?A大半は第一線の管理者、
?B技術系の経営者なら、ちょっと気をつければ
正確に見分けられるとしています。
ただ、ゲートキーパーとパフォーマンスの関係は
よくわかっていません。
「新しいもの好き」をどう活かすかが普及のカギ
日本では身近な普及の仕方
新しい製品やサービスは、
どのようにして社会に
普及していくのでしょう。
『 イノベーション普及学 』は、
最初の2.5%を 革新的採用者、
次の13.5%を初期採用者、
その次の34%を初期多数採用者、、、
というように分類しています。
もし革新的採用者であれば、
ある意味、実験台になることを
自ら申し出た人々なわけで、
感想であれクレームであれ、
製品やサービスの改善につながる
可能性が十分にあります。
もとろん、これから採用しようかどうか
迷っている人にも影響を与えるわけです。
ただし、 クリティカル・マスでも登場する、
この2.5%という数字は、正規分布を仮定したもので、
そのこと自体にあまり根拠はありません。
実際、音楽CD、特にヒットチャートの上位に
行くような音楽CDの売り上げは、
最初の週にピークがあるのが普通です。
要するに正規分布ではありません。
ロジャース氏の普及理論が妥当するような世界は、
最初はジワジワと広がり、
その中からマニアックな支持者が、
リード・ユーザーとなって、、、
というような世界でしょう。
日本のようなオタク文化の国にとっては、
意外と身近な普及の仕方かもしれません。
しかし、問題は技術者が リード・ユーザーの
提案を受け入れるかどうか。
何でも自前でやりたがる人達
イノベーションの妨げになる感情論
企業で研究開発に従事している技術者にとっては、
社外のマニアやオタクの存在は目障りなだけかもしれません。
かつてDECというコンピュータ会社がアメリカにありました。
1970年代、そこのミニコンピュータはUNIXを
搭載できることで人気がありました。
マニアはの自前のOSを削除して、
代わりにUNIXを載せて、
ソフト開発に、教育にと大活躍させていたのです。
しかし、当時のDECの技術者たちは、
それを快く思わず、UNIXのサポートを
拒否し続けていました。
マニアが勝手に作ってくれていたUNIX用の
ソフトを取り入れて活かさないなんて、もったい話です。
これでは、 ユーザー・イノベーションは起こりません。
こういった事例をを自前主義といいます。
NIH(not invented here)症候群という言い方もします。
自分たちで開発したものでなければ、
使いたくないという、、、
ただし、NIH症候群で有名なカッツ氏とアレン氏論文では
通常のNIH症候群とは異なり、在職年数の
長期化によってプロジェクト・パフォーマンスが
低下する現象をNIH症候群と呼んでいます。
企業内外のアイデアを活かす
アメリカで成長した企業の考え方
NIH症候群とは対極の研究開発プロセスの
お話が オープン・イノベーションです。
『 オープン・イノベーション 』では、
企業内部・外部のアイデアを結合して、
新たな価値を創造することが
オープン・イノベーションだとだれています。
しかも、その出口も多様で、
もとの会社を飛び出したり、
他の会社にライセンシングしたり、
何でもありなのです。
実は、アメリカのHDD業界でリーダー企業に
取って代わってきたのは、
こうしたスピンオフ企業でした。
ただし、こうした研究開発の在り方は、
基本的に研究開発のただ乗りを
許容しなければなりません。
優秀な研究者や技術者が、自由に大学や
企業を渡り歩いて研究が続けられるかと
問われれば、かなり無理があります。
現実には、中核の技術者が企業間を
移動する場合には、最新の機密情報が
漏れると困るので、半年とか1年とか
時間を空けるのが普通です。
企業内にあっても、ソフトウェアの技術者が、
ソース・コードを公開してしまう
オープン・ソースの開発部署に人事異動する場合には、
覚えていたソース・コードが混じると、
法的に大変なことになるので、
忘却期間として半年程度は空けさせるのが常識でしょう。
しかしそれでも、
オープンにするべきかなのだというのが主張なのでしょう。