製造業エンジニアの道

自分を伸ばし、会社を伸ばす自己革命

グローバルで浮いてる日本企業

グローバルEMS企業(アメリカを本拠とするグローバル企業)の日本支社で開発部門の責任者をやっていたころの話。

 

まだフォックスコンが台頭する前、ソレクトロンとかフレクトロニクスといったメガEMSが日本に進出してきて、ソニーNECなどから日本の工場を買収して、日本でのEMS事業の拡大を狙っていたころ、私はジェイビルという世界ではあまり目立たないけど、EMS事業では世界で4位の会社で働き始めました。

 

当時、多くの欧米企業が、製造での付加価値よりも、製品企画や開発にこそメーカー企業が勝負するチャンスがあると、製造のアウトソーシングが進んでいました。

Apple、シスコ、HPなど、経営資源を企画や開発にシフトして成功している会社が多数出てきていました。

 

ところが、日本企業は、1970年から80年代にかけて、TQCで品質の日本として、製造業では押しも押されぬ存在となり、Japan As No.1 という本が大流行しました。

 

この成功体験が染みついていたせいか、日本でのEMS企業の進出はほぼ失敗に終わります。

部分的に、EMSを利用しているケースは多数あるものの、フォックスコン以外のEMSは、2018年現在、ほとんどが撤退しています。

 

この件に対しては、まだたくさん言いたいことがありますが、このときのひとつの経験談をお話ししたいと思います。

 

当時、EMS企業で日本での開発責任者をしておりましたが、人件費の問題などで、開発リソースは中国を活用そようと、開発拠点の本部を上海に置いていました。

私も、上海で多くの時間を過ごしましたが、特に日本企業の開発マネージャの方たちを上海にお招きして、ビジネスチャンスを伺っていました。

 

そのときの私の上司は、ドイツ人で、でもとても仲良くしていて信頼関係も厚かったのですが、ある日本企業の開発部長を上海に招待してミーティングを行ったのですが、この部長さん、日本人同士の会話では饒舌なのですが、海外の人たちとのミーティングでは口をつぐみます。

 

英語が苦手ということなので、私が通訳を務めますが、それでもあまり口を開きません。こちらのプレゼンにも無表情で、私が日本語で本音を引き出そうとしても、眉につばを付けるような感じで、終始しかめっ面をします。

まあ、打ち合わせとしては失敗だったのですが、会議が終わって、ドイツ人の上司が私のところに来て、

「お前は良く我慢できるな。ずいぶんといやな思いをいただろう。」

と言いました。

「根っからの日本人ですね。」

と私が言うと、

「日本人は、いつも自分たちが特別だと思ってないか?」

と言いました。

 

ちょっとドキっとしましたね。

自分たちがいつも特別。。。

知らず知らずのうちにそんな思いが日本人の中に生まれていないか。。。

 

そしてトドメの一言。

「彼らを二度と俺の前に連れてこないでくれ。」

 

お互いの違いを理解し、受け入れ、そしてグローバルでビジネスをする、という世界で、日本企業はいつまでも大量生産時代の成功を忘れられずに、自分たちの成功の上で立ち止まっている。

 

もう、そういうのをやめたいなと、強く感じています。

 

 

マインドマップで右脳を刺激

f:id:kamonk:20180621180413j:plain

マインドマップは、会社勤めのころ、アイデア検討の場で使っていたのですが、どちらかというと他人が使っているのを見よう見真似で使っていたというのが正直なところでした。

本来の意味や成り立ちなどを知らないまま、発言内容を関連付けながら整理していくツールなのだと思っていたわけです。

 

10日ほど前に、知り合いがマインドマップの講師をしていて、奨められるままに一日コースの講習会に参加してきました。

講師の方は、マインドマップを作ったというTony Buzan氏に直接教わったということで、最初に、世の中で使われているマインドマップは、亜流も多くて本来の意味を誤解しているものも少なくない、という話がありました。

 

マインドマップの活用方法は4つで、

  • 思考整理
  • イデア発想
  • 記憶
  • コミュニケーション

なのだそうです。

マインドマップの作り方として大事なことは、

  • キーワードをつなげていく(文章を書かない)
  • 色をたくさん使う
  • イメージ(画像、イラスト)を使う

ということで、特に私が使っていたものは、文章を書いていたように思います。

人々の発言の主旨を簡潔に書いていくようなイメージを持っていましたが、実は本家のマインドマップでは、文章は入れないのだそうです。

 

また、色やイメージも意外でしたが、実はマインドマップは脳の構造と同期するように考えられていて、右脳と左脳を効果的に使うようにするものだとの説明でした。

 

確かに、右脳を動かすというのはイメージを使うというのを聞いたことがあります。また、色も脳を刺激したり、記憶に残すためには重要なのだそうです。

 

右脳といえば、七田式というのが有名ですね。

幼少時から右脳教育をすると絶大な効果があるなどと言われ、七田式は子供の教育として広く知られています。

 

自分の右脳が動いているのか、以前、七田式の本を何冊か読んで試してみたことがあります。オレンジチャートというのがあって、オレンジ色の下地に、真ん中に紺色の丸が書かれているシンプルな画像です。

これを30秒ほどじっくりと眺めて、目を閉じると残像が残るのですが、元の色(オレンジの下地に紺色の丸)が残像として残っていれば右脳が動いているということらしいのです。

私は、何度か試してみたのですが、何度やっても残像は色がひっくり返ったもの(紺の下地にオレンジの丸)しか見えず、これはつまり右脳が動いていないのだそうです。

 

繰り返し訓練すると、少しずつ残像が元の色になり、しかも、その残像が残る時間がどんどん長くなるということで、右脳が活発に動くと、残像の色を自分で変えたり、形まで思ったように変えられるようになると、その本には書いてありました。

結局、当時は右脳があまり動いていないらしい、という事実を突きつけられて、あきらめて引き下がったのですが、ここでまた、右脳を使うという場面に出くわして、少しばかり腰が引けたのですが、反対に今度こそ、右脳の活性化に成功してやる、という想いも芽生えて講習を受けました。

 

話をマインドマップに戻します。

多くの人が経験があるように、文字や文章を記憶するのはなかなか難しいものがあります。でも、イメージや色は記憶に残りやすいですよね。

そのイメージや色と、キーワードが、書いた位置や周辺の他のキーワードと関連づけられると、キーワード同士がつながっていきます。

これは講習の中でも体験しました。

 

また、キーワードとイメージが並ぶことで、実はそこに書かれていない、他のキーワードやイメージ(どちらか一方でいい)が浮かんでくるのです。

これは、プレインストーミングにも似てるかもしれません。

イデアが他のアイデアを呼ぶというものです。

 

製品開発の中で、私が実践してきたアイデア発想は、課題に対して抽象度を高くしながら、近視眼的な見方を、様々なこと、様々な技術領域やビジネス領域に視点を広げて、他の領域からアイデアを借りてくる、ということをやって成果を出してきました。

 

もしかすると、マインドマップは、その考え方にプラスして、さらにアイデア発想を促進するものになるかもしれません。

 

マインドマップは、組織の中での強力なコミュニケーション・ツールになりえるものかもしれません。

講師は、マインドマップ以外でも先生業をしているとのことですが、生徒さんたちの悩みを聞くときに、マインドマップを使うのだそうです。

生徒が悩みについて話すことを、色で分けて、時々絵のようなものも書いて板書するのだそうですが、生徒さんは、それを見ているうちに、勝手に自分で解決策を見つけて納得して帰っていくことが、時々あるそうです。

絶対に解決できるとは言えないでしょうが、面白いエピソードですね。

 

さて、右脳が動くかどうかは別として、マインドマップを自分の仕事に活用したいと思うようになりました。

さて、どうすればいいか?

 

とにかくたくさん書いてみることと教わりました。

書き続けることで、自分で気付いていくことなのでしょう。

 

ということで、毎日、朝にその日のやるべきこと、つまりスケジュールをマインドマップで書くことにしました。

 

本来、カラーペンと画用紙を使って、手書きで書くのがいいのだそうです。

 

そういえば、パソコン文化になって、文字すら自分では書かなくなった現代人にとって、自分で鉛筆やカラーペンを使った”手書き”というのは、大いに脳を刺激するものかもしれません。

 

私も、講習が終わって10日間、毎朝起きると、画用ににカラーペンを使ってその日の為すべきこと(ToDo)をマインドマップに書き出します。

 

たった20分程度で、今日一日やるべきことをイメージとキーワードを使って表現します。これ、意外と気持ちいいです。

朝、まっすぐに画用紙に向かって、その日を創造し、それを自分なりに表現して自分に対して約束をする。

朝から、とても気持ちがシャキっとして、気持ちが昂ります。

 

ほんの小さなアクションですが、これは癖になりそうです。

 

冒頭の画像は、iPad用アプリ(Buzan公認アプリ)で作成しましたが、普段は手書きで書いてます。よそ行きにアプリを使ってます。

 

毎日、忙しい。

でも、忙しい中で、何か小さな、でも前に進んでいることを探している人!!

 

参考にしてください。

 

 

 

「知らないことを知ることから」が開発の本質

「自分が何を知らないかを知る」ということは、易しいようでなかなか難しいのかもしれない。

開発現場は忙しすぎて、また、技術の進歩も早くて、わからないこと、知らないことをキャッチアップしていたら、求められる仕事のスピードについて行けないのかもしれない。

 

でも、開発の本質、技術者の本領って、知らないことに大きな興味を持って、それを追求して、アイデアを出すことだと思う。

 

製品全体のシステムが肥大化して、XXの専門家がたくさん現れて、組織はマトリクスされて、隣の部署が何をやっているかなんて、わからないし、わからなくっても全然かまわない、ということが随分と長い間続いてしまったように見える。

 

いろいろなメーカー企業のマネージャーに話を聞いてみると、製品全体をわかっている人間はもういない。製品をゼロから設計できるやつは、もう10年も前にいなくなってる。という答えが返ってくる。

 

「知ってることを知っている」

「知らないことを知っている」(知識ギャップ)

「知っていることを知らない」(暗黙知

「知らないことを知らない」(愚者の天国)

 

下の2つは、まさに「無知は罪」というところだろうか。

上の2つの世界で、知識ギャップをみんなが同じレベルで理解していて、それを会社全体で追い求める、というのが本来の姿だと思う。

 

きっと、20年前は、多くの世界がそうだったように思う。

 

「何にでも強い興味を持つ」

 

5歳児のように、何度も何度も「なんで?なんで?」と聞く。

 

エンジニアは、こうでありたい。

 

アメリカボストン郊外にあるテラダイン・べンソスという会社は、トヨタの開発手法(リーン製品開発)を学び、そこから、独自の開発プロセス"Knowledge Based Product Design”(知識ベース設計)を編み出し、大成功している。

 

新入社員の研修プログラムに、小さなソーラーカーモデルを設計する実習があるのだが、まず、自分たちが何を知らないかを徹底的に出すところから始めさせるのだそうだ。

 

基本に帰りたい!

 

 

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

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

 

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

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

 

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

 

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

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

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

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

 

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

 

 

 

開発現場の実態

f:id:kamonk:20180607053929j:plain

 

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

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

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

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

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

 

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

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

そうなのです。

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

 

はじめまして!

はじめまして!

 

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

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

 

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

 

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

 

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

 

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