儲かるアイデアをどう出すか？

新規事業のためのアイデアを集めようとすると、アイデアはたくさん出るけれども、どうも儲かりそうもないとか、事業としては成功しそうもない、ということになりがちではないでしょうか？

事業アイデアを考えるときに、事業を創るということを、いい製品を作ることだと思っていないでしょうか？

先端技術を使って顧客の興味を引く、いい製品を作ればお金は後からついてくると考えている人、特に技術者は多いのではないでしょうか？

もちろん、いい製品を生み出すことはとても重要ですが、それと事業を創り出すこととは別だと思っています。

事業を創り出す、ということは、”お金を動かす仕組み”を創り出すことだと私は思っています。

いい製品を利用して”お金を動かす”ということです。

そして、”お金を動かす仕組み”とは、まさにビジネスモデルということです。

しかし、ビジネスモデルなんて、簡単にできるものでしょうか？

すでに言われていることかもしれませんが、ビジネスモデルは、他の領域から借りてくればいいのです。

他の事業領域でうまく行ってるビジネスモデルを、徹底的にパクる（TTP)ことを、組織的にやることが重要だと思っています。

でも、パクるのも実はやり方があると思っています。

まず、パクるためには、他の領域のビジネスモデル、成功パターンや失敗パターンを深く理解している必要があります。社内に世の中のビジネスモデルを研究して蓄積し、すぐにそれらの情報を活用できる体制などが必要かもしれません。

簡単に言えば、ビジネスモデルの専門家です。

次に、そのビジネスモデルの知識を使って、実際に自社領域で一工夫してうまく活用して、付加価値の高い儲かる事業を創り出すということですが、ここにも仕掛けが必要です。

それは、「抽象化力」と「アナロジー力」です。

多くの人、特に技術者は、物事を近視眼的にしかみれない傾向があります。時に近視眼的に、時に全体を俯瞰して物事をみる、抽象度を自在に変化させながら物事を見る訓練がされていません。

そうすると、考え方が凝り固まって、アイデアが広がらないのです。

抽象度を変化させる力は、訓練できます。私はコンサルの仕事の中で、この方法も教えています。

抽象度を高くした状態で、自社製品と世の中のビジネスモデルを広く眺め、さらに「アナロジー力（類似力）」で、類似性を発見しながら、自社領域で新たなビジネスモデルを造って行く能力を、個人だけでなく、組織的につけていくと、新規事業の成功確率は大幅に上がる、ということになります。

開発現場の実態

いくつかの企業の開発部門で、このスライドを見せると、多くのエンジニアが大きくうなづきます。

「思い当ることありますか？」と聞くと、

「たぶん全部当てはまるかもしれません。」と返ってきます。

「どれが一番重要な問題ですか？」と聞くと、

う～んと唸って、でも皆の答えは必ずしも一致しません。

これらは、現場で実際に出ている”症状”ですよね。

このひとつひとつの原因を考えて対処しようとする、なんてことをあなたの職場ではやってないでしょうか？

”熱がある”から解熱剤を飲む、”咳が出る”から咳止め、”下痢気味”だから下痢止め、”背中が痛む”からマッサージ、そして”寒気がする”から厚着をする。

実は、すべての症状の根本の原因が”肺炎”だったとしたら、”肺炎”に手をうたなければ解決にはならない、ということです。

ひとつひとつの症状を明らかにすることはとても大事なことなのですが、それぞれに対処療法をとってしまうことが問題なのです。

開発現場の症状も、元をただしてみると、実は根本的な原因があるはずなのです。

2002年ころに日本でもベストセラーになった「ザ・ゴール」という本はご存知でしょうか？いわゆるTOC（制約の理論）の考え方を小説風に教えてくれる本です。

組織の中で起こる問題は、全体を見ずに「部分最適」に終始してしまうことで、解決できないということを教えてくれるのですが、もっと基本的なところは、問題を起こすのはすべて人々の「行動」であって、その行動は、組織の「評価基準」によってもたらされ、評価基準は、組織の「方針」で決まってくるということを理解することが重要なのです。

わかりやすく言うと、誰かが悪いことをして、その結果問題が起きてるのではなく、すべての人がいいと思って（会社の方針や行動基準に従って）行動していて、その結果で問題が起きているので、問題解決は、その方針や行動基準の矛盾（対立構造）を理解しないとできないということです。

たとえば、いい製品を早く市場に出すというのは、どんな企業でも目指すところ（方針）になります。しかし、その大方針の達成度を評価する基準はいくつかあります。

QCD（品質、コスト、納期）必達！なんて言葉を開発現場では良く耳にします。しかし、３つの基準を本当に平等に扱っているかというと、かなり怪しいと言わざるを得ません。

開発マネージャさんたちが評価されるのは、実は納期の優先順位が一番高いのです。それが一番目に入りやすいからです。

”内容を理解していない設計者にサブユニット設計を任せる”ということが、例えば、設計の後戻りを発生させるひとつの「行動」だとすると、その行動をとる優先度の高い目的は、納期を守る、ということになります。

それに対して、品質を最重要とする、という評価基準を第一優先にすると、本来は、”内容を知らない設計者にサブユニット設計を任せない”ということにならなければなりません。

つまり、ここに組織の対立構造（ジレンマ）があって、しかも、このこと自体を簡単には責められない、ということがわかってきます。

そうなのです。

この組織内の対立構造をすべて明らかにして、全体をみて、部分最適でない対応をするために、トップダウンで実態に当たらなければ、いつまでも同じようなところを行ったり来たりという状態になってしまうのです。

はじめまして！

はじめまして！

60才で大手企業を定年退職したのをきっかけに、シニア起業して製品開発のコンサルティング事業を始めて約1年になります。

幸運にも何社かのクライアントに恵まれて、とても有意義な1年となりました。

2期目に入って、もっともっと日本の製造業が元気になるべく、また、エンジニアの皆さんが、喜びに満ちた会社と家庭での生活を送ることが出来て、さらに企業が発展していけるような世界を創っていくことに貢献していきたいと考えています。

私自身は、大手精密器メーカーで開発部門を長くやっていた一方、外資系半導体企業や、海外EMS企業などで開発部門の責任者や、受託開発の中小企業で経営者としての経験なども持っています。特にアメリカ企業に所属して、その目線で日本企業を見てきた経験もあり、日本の製造業全般にたくさん言いたいことがあります。

経験談のようなこと、何かのヒントになるような記事を書いていきたいと思っています。

多くの将来の企業幹部候補となるエンジニアの方にお付き合いいただければ幸いです。