嗜好品分野の低迷脱出の鍵はイノベーティブな活動…


 よく知られているように、嗜好品分野は全体にみると低成長が続いている。筆者は、この状況を、この分野における企業の研究開発活動が沈滞している兆候と見ている。新製品開発数、研究開発費、研究員数などを指標にすれば決して研究開発活動を抑えている傾向は見えないが、少なくとも、産業発展に大きく寄与したアウトプットがあったかどうかで研究開発活動を評価すれば、この業界は停滞しているといってよいだろう。研究開発のインプットを減らさないのに産業が停滞しているとすれば、企業の研究開発マネジメントに問題があると見るべきだ。この問題は、おそらく新商品を出し、小売における棚をとりあえず維持しておこうという姿勢に由来しており、根が深いと思われる。

 挑戦的な風土をつくるに際して注意すべきは、組織的動きのスピードである。古い体質の産業は研究開発組織に柔軟性を欠いている場合が多く、試行を是認する仕組みを導入しても、その動きは鈍いままだったりする。これでは、動きの速い市場でチャンスを活かしきれない。

 それでは、どのような組織を是とすべきか。

 組織の基本構造の発展形態からいえば、下図のような模式図で頭を整理すると良い。

・組織の原型として考えるべきものは工場のような軍隊型の生産組織だ。これは図で示すなら櫛型構造になる。機能毎にきっちりとした指揮命令が及ぶような体制を組むのである。定型的な業務が滞り無く進むことを実現したければ、これは明らかに効率が良い組織である。従って、動きが遅い産業では極めて強い競争力が発揮できる。しかし、柔軟性は犠牲になる。

・早い動きへの対応や挑戦的な試行が重要になると、部隊毎の間に壁で硬直的になるこうした組織は避けなければならない。いくら風通しを良くするために階層を減らしても(いわゆる文鎮構造上)、一人が管理できる対象の数(スパン)は限られているから柔軟に動くには限界がある。この櫛型組織の改良版が格子型(マトリックス構造)である。研究開発テーマ毎の組織と機能毎の部隊という2方向からの管理システムで、古くから挑戦されている。しかし、本質的には櫛型組織を温存しており、権限はテーマ毎の組織と機能組織のどちら側が握るのかについても曖昧さを残すので、研究開発プロセスが明確に規定できる産業ならよいが、柔軟な研究開発体制を敷くのには無理がある。

・そうなると、完璧な柔軟性を発揮するためには、ゼロベースで組織構築を目指すことになろう。これが、扇形である。ベンチャー組織の集合体のような、目的毎の組織構造だ。目的毎に新たなプロジェクトが編成される。この組織は、今までの安定した機能毎の組織を崩すのである。当然ながら、今までの組織的な学習方法や知識蓄積システムは機能しなくなる。長期的な熟練を「模倣」から得るということは余り期待できない。というより、プロジェクトに期待しているのは、ニーズの発見とそれに合った製品の提案であり、細かな製品の作りこみではない。ここが肝要だ。二兎を負うことはできない。ただし、知識を蓄積しにくい体制をとれば長期的には極めて脆弱な研究開発体制ともいえる。

・これを避けるには、知識を蓄積すべき専門領域別の組織が別途必要だ。従って、形態としては扇型組織が錯綜する蜘蛛の巣形になっていく。

 この分野で、知恵を組織的に生むための活動を支えるのは、動向調査活動と言ってよいだろう。イノベーティブと見られている企業は例外無く、独自の文化に支えられながら、確固たる目的意識に基づいた活動を進めている。
 逆に、停滞を余儀なくされている企業は、形骸化した活動を熱心に進めていることが多い。

 労力という観点で努力の程度を比較したら、後者の方が注力度は大きい場合もある。筆者は、ここに研究開発活動の変革の鍵があると考えている。下図に成果が出ない企業の典型的な動向調査の活動例を示した。市場で低迷し始めると、多くの場合はシェア低下を止めることが最優先され、インテリジェンス活動の対象は競合の動きやシェア損失原因探索となる。ところが、こうした活動は緻密になればなるほど、本当に重要な動向を知る作業から遠ざかることになる。顧客のニーズやデモグラフィックな変化について、手抜きをすることはないだろうが、シェアアップ策に直接つながらないような調査や分析は軽視されるから、表層的な分析になってしまう。

 本来、一番重要なのは、図表では下に位置する消費者のライフスタイル変化のような新商品開発のタネに結びつく部分である。
 現実には、この領域は調査が一番難しい部分だ。しかし、だからこそ様々なやり方や洞察力を発揮する余地があるとも言える訳だ。要は、消費者の動きをどのように把握し、その意味を製品に反映する方法を確立することができるかどうかという原則に立ち戻り、学ぶ組織を編成することである。

 研究開発システムの目次へ

(C) 1999-2000 RandDManagement.com