<   2017年 05月 ( 4 )   > この月の画像一覧

研究開発戦略へのシステムズ・アプローチと、モノづくり大国の貧困

「日本は、ものづくり大国だ」という言い方を、よく耳にする。モノづくり大国とはどういう意味なのか、わたしは正確な定義を知らない。GDPの中で製造業の占める割合が、すでに1割台に落ちている国に、ほんとに適切な形容なのかとも思う。だが、あまり正確に定義できる概念ではないのかもしれない。モノづくりが盛んで秀でているなら、「日本は技術大国だ」という言い方だって、同じくらいしても良さそうだ。しかし、なぜかそちらはあまり聞かない。そういう実感があまりないのだろうか?

むろん日本の技術者のレベルは高い。そのことは、いろいろな国で仕事をしてきたエンジニアリング会社の人間として、証言できる。それでも「技術大国」という気がしないのは、なぜだろうか。技術大国という言葉でふさわしいのは、現在、どこの国だろうか。技術大国という以上は、少なくとも、技術者の待遇がよく社会的にも尊敬されていることが、必要条件だろうが。

1950年代から70年代頃までのアメリカは、世界一の技術大国だと自認していたはずだ。その自信が崩れはじめるのは、’80年代に入って日本の自動車産業や電機産業・半導体産業などに、追い抜かれはじめてからだった。当初彼らは、日本が円安と低賃金に助けられて、アンフェアな低価格攻勢をかけているだけだと、高をくくっていた。

だが、プラザ合意で円高にかわっても、日本の勢いは続いた。そこで、途中から彼らは考えを改めるようになる。技術面でも日本に追い抜かれつつあるのだと感じ、本気で対抗策を講じはじめるのだ。たとえばMITが中心になってまとめた、日本の自動車製造の実態調査と、そこから生まれた『リーン生産システム』という概念は、その一つだ。

リーンは赤身の肉のことで、贅肉のない、つまり余分な在庫を持たない生産方式を意味する。それまでの米国流で中心だった、大ロットの見込生産では大量の中間在庫・製品在庫が生じていた。これではせっかく大量生産で低コストを実現しても、在庫金利を生じて効果が減じるばかりか、需要の変化への対応速度が落ちてしまう弱点に気がついた。そこで、流通業のQR(Quick Response)をさらに拡大したSCM(Supply Chain Management)という概念や、APS(Advanced Planning & Scheduling=革新的生産スケジューリング)のツールが開発されるようになった。

もう一つ、日本ではあまり知られていないものに、技術研究政策の変化がある。米国には「国立科学財団」National Science Foundation = NSFという政府組織があって、大学などに学問研究の助成金を出している。このNSFは’80年代の半ばに、産業界のニーズにあった学際的な工学研究を行うセンターを、全米各地の大学に設置する構想をたてた。これがEngineering Research Center (ERC)プログラムと呼ばれる政策である。ERCは、大学と企業の実務家とが、持続的な提携関係を結ぶことを主眼とした組織だ。工学と言っても幅広いが、4つの柱があり、その最初が”Advanced Manufacturing”(先進的製造技術)であった。当時の米国政府の危機感がうかがえるではないか。

現在、NSFは年間約80億円の支援予算を17箇所のERCに支出している。金額もすごいが、わたしが最近知って驚いたのは、このERCの設立運営が、徹頭徹尾、システムズ・アプローチに従ってなされていることだった。世に出て産業界に役立つ技術成果は、単体ではなく、『システム』でなければならないと、NFS/ERCは考えた。システムとは(いうまでもないが)コンピュータのことではなく、構成を持った仕組みの意味である。この政策を調査した科学技術振興機構のレポートhttps://www.jst.go.jp/crds/pdf/2014/RR/CRDS-FY2014-RR-02.pdf を参考に、どんなやり方なのか紹介しよう。

たとえば、高効率の太陽電池用の素子の開発は、大切だ。だが、それが電力網全体に重大な役割をはたすには、蓄電・変電・送電などの補助的要素の開発が必要になる。単発的な要素技術だけでは、世の中へのインパクトは小さいのだ。だが大学人は、とかく狭い専門分野を深掘りしたがる。それを防ぐために、ERCでは、「三層モデル」と呼ばれる図を各センターが分野ごとに作成し、研究がその中のどこに位置づけられるか、全体の中で生きるためにはどのような要求を満たすべきかを、つねに意識させている。
e0058447_23275758.jpg
上の図は、米国NFSのEngineering Research Centers(エンジニアリング研究センター)のHP
http://erc-assoc.org/content/three-plane-diagram からの引用である。第1層は、「Systems Research システム研究」と書かれている面である。面の外側で、右にある楕円の要素は「Stakeholders ステークホルダ」(外部の利害関係者)で、もっと分かりやすく言うと関係する企業やその潜在顧客達や官庁などだ。ここからセンターに対して、要求がもたらされ、逆にセンターからは「製品とアウトカム」が届けられる。アウトカムという用語は日本でもようやく広まりつつあるが、プロジェクトやプログラムの活動が直接間接に生み出す効果である。

第1層の面の中には、「Testbed テストベッド」が並んでいる。ここで、下の第2層から上がってきた技術要素が、他の技術要素と組み合わされて、システム的に実証される。ここが肝心なところで、いくら米国企業の研究開発能力が高いと言っても、しばしばそれは単機能のベンチャー的なものが多い。それが世に出て真に役立つためには、他と組み合わさったときのパフォーマンスやリスクの検討を経る必要がある。これは単機能の企業だけではできない。そこに、大学や他企業と協働するためのERCセンターという仕組みの必要性が生じるのである。

だが、第1層のテストベッドで実証されたものも、すぐ世に出る訳ではない。面の右側には、「Barriers 障害」の箱が並んでいる。ここを通過してはじめて、デビューできるのだ。したがってシステム層では、テストベッドを作るだけでなく、障害が何かを同定し、対策を講じることが行われる。

真ん中の第2層は「Enabling Technologies イネーブラー技術層」である。Enablerという英語は訳しにくいが、何かを可能にする技術、問題解決技術、とでも言おうか。層の内部構成は上と似ていて、テストベッドが並び、そして右にバリヤー(障害)が書かれている。

一番下の第3層は「Fundamental Knowledge 基礎知識層」である。ここの面の中には、基礎研究とバリヤーが並んでいる。ここで生まれた成果は、「Fundamental Insights 基礎的知識」として、第2層に上がっていく(おい、insightは知識ではなく洞察とか見識だろ、と思われた方もおられるかもしれない。英語辞書的にはそうだ。だがinsightは、lessons learnt=教訓などと並んで、組織の中で共有可能なものとして扱われる。洞察や見識では個人に属してしまう。そこであえて知識と訳しておいた)。そしてこの層にもバリヤーが存在する。第2層と第3層には、第1層から「Systems Requirements システム要求」がおりてくる。

そして、ERC(エンジニアリング研究センター)の仕組みをマネージする立場の人達は、つねに自分たちの開発課題の全体像を、具体的な3層モデルの図として描くことが求められる。その中で、予算や人員を、どのレベルのどの課題に重点配分するかを決めていくのだ。また、全体像の図が描かれないと、ERCにはNFSからの予算が下りてこない。いやがおうでも、研究開発戦略をシステムズ・アプローチの中で捉えざるを得なくなる。

・・と、ここまで読んだ読者は、「アメリカの研究政策の話なんて、自分に関係ないから興味ないや」と思われただろう。いや、もう半分以上の読者が読むのを中断してサイトを離れたかもしれない(^^;)。そこで、ここまで読み進められた少数精鋭(?)の読者のために、一つだけ注記しておく。ゲーム業界の話だ。

研究開発とゲームソフト開発では、まったく別の世界ではないか? だが最近、読んで衝撃を受けた記事があった。

「21世紀に“洋ゲー”でゲームAIが遂げた驚異の進化史。その「敗戦」から日本のゲーム業界が再び立ち上がるには?【AI開発者・三宅陽一郎氏インタビュー】」 http://news.denfaminicogamer.jp/interview/gameai_miyake?utm_content=buffer7f213&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer

という記事である。わたしはゲームを一切やらない人間なので、記事の中の固有名詞はさっぱり分からないし、三宅氏の発言がどこまで正鵠を射ているのかも判断できない。だが、日本人が手元にあるリソースを上手にやりくりする職人芸で勝負をしているウチに、アメリカは集団で科学的に研究開発を進めて、サイエンスの力で一気に逆転していく、という説明には納得感があった。

才能ある個人の職人芸の集合か、それとも組織的で科学的なアプローチか。そこが基本的な問題意識のありかなのだ。

ERCの図の、一番下のレイヤを見ていただきたい。ここは、基礎研究が並んでいる。大学の基礎研究というのは、基本的に研究者が個人個人の興味と能力に従って、進めていく仕事だ。大まかな研究分野はきまっているだろうが、具体的な方向はバラバラ。能力もバラバラ。したがって、普通だったら、その組織からの研究アウトプットは、個人のアウトプットの足し算でしかない。これが普通の大学の組織だ。

この一匹狼の集団に、個人の総和よりも大きな仕事をしてもらうには、どうしたら良いだろうか? 米国NFSが考えたのは、こうした問いなのである。そして彼らは、「仕事のあり方をシステム化する」という方策を思いついた。外界から、システムへの要求事項が入ってくる。それを分析して要件を切り出し、複数のサブシステムに分割する。サブシステムの機能要件はさらに、個人レベルの要素まで落ちてくる。そして、それらは組み合わさって結合テストされ、さらに上位で総合テストにかかる。こうすることで、各個人の仕事のベクトルを、きちんとムダがないように方向付けたのだ。

一人ひとりが個別にターゲットを追いかけている場合は、成果は個人の足し算にしか、ならない。しかし役割分担を的確にして、組織的にダイナミックに動くことで、個人では捕らえられなかった大きな獲物を仕留めることができる。こうして、組織は単なる足し算を超えた能力を発揮する。また、個人個人のムラをなくした、安定した仕事の成果が得られる。ちなみにERCの仕組みは、決してあるスーパー研究者が独裁的リーダーになって、大勢を手足として使うためのものではない。それでは、組織のパフォーマンスは特定の個人の能力と気まぐれに依存してしまう。

最近、日本の大学研究者のアウトプット、とくに国際的なジャーナルに発表する研究論文数が、どんどん減ってきているという問題が指摘されている。多くの論者は、これを、文科省の大学政策(独立法人化や予算削減)に結びつけて論じている。たぶん、そうなのだろう。だが、ひるがえって、成果を個人の足し算以上にするにはどうしたらいいか、積極的な策が提案されているだろうか? 傍からは疑問に思える。

そしてもう一つ、書いておこうか。

組織の仕事のパフォーマンスは、個人の成果の単なる総和。こういう組織、どこかで見たことがないだろうか? ——そう。多くの企業の、営業部門のあり方にそっくりなのである。営業部門の業績は受注額ではかられるのが普通だが、営業マンはたいてい個人プレーで仕事をする。ときには凄腕の営業マンもいるだろう。だが平凡な者も大勢いるし、無能な奴だっているかもしれない。そして戦果は個人プレーの足し算である。

そして大学研究と同じように、日本企業は世界市場で次第に、販売競争力が低下してきている事実がある。円高その他、説明はいろいろあろう。だが、どうやって販売力を、個人の総和以上に高めるかという議論をあまり聞いた記憶がない。優秀な営業マンはいる。だが、有能な営業管理者がいないのだ。セールスの仕組みを、つまりシステムを構想し、作り上げる能力を持つマネージャーが見当たらない。まったく、わたし達の社会はどこを切っても同じ断面が見える。兵士達一人ひとりは勇敢だ。だが、組織を合理的に動かす将軍が、いつも不在なのだ。


by Tomoichi_Sato | 2017-05-23 23:32 | ビジネス | Comments(2)

BOM/部品表に関するセミナー講演のお知らせ(6月20日・東京)

お知らせです。

来る6月20日(火)に、BOM/部品表に関する有償セミナーの講師を務めます。場所は東京・新宿です。

ご承知のとおりBOM/部品表の構築と保守は、製造業にとって古くて新しい問題です。とくに近年は、
 ・新製品開発・投入のサイクルが早くなったことと、
 ・製造のサプライチェーンが国境をまたいで海外に伸びたこと、
 ・企業買収や提携が進んでいること
などの要因が相まって、BOMの維持運用を難しくしています。

この問題は10年ほど前に一度注目を集めた時期があり、わたしも2004年に拙著「BOM/部品表入門」を上梓しました。幸いこの本は未だに現役で、今年も増刷が決まって累計1万部近くになりました。しかしそれは、10数年がたっても、根本の問題が多くの企業で未解決のまま残っている事実を意味しているようです。とはいえ、昨今多少は情報化投資の余裕が出てきたことと、データ・サイエンスやデータ・マネジメントに関心が集まったことで、ふたたび注目されているのかもしれません。

今回はとくに、従来の量産型ではなく、BOMを扱いにくい個別受注生産における知恵などにも光を当てて、「自分で考え身につく」セミナーを目指します。

この問題に関心のある方のご来聴をお待ちしております。

<記>

日時: 2017年6月20日(火) 10:30~17:30

テーマ: 「BOM/部品表の基礎と効果的な活用ノウハウ ~演習付~」

主催: 日本テクノセンター

会場: 〒163-0722 東京都新宿区西新宿二丁目7番1号
     小田急第一生命ビル22F

セミナー詳細: 下記をご参照ください



 よろしくお願いします。
               (佐藤知一)




by Tomoichi_Sato | 2017-05-20 18:36 | ビジネス | Comments(0)

課題展開図からプロジェクトへ

Kさん、追伸です。

長文のメールを差し上げたばかりなのに、すぐに追伸とはお恥ずかしい話ですが、ちょっとだけ補足しておきたいことを思い出しましたので。それは、もう一つの経営戦略の視点、つまり、「What(何を目指すか)」から「How(いかにアプローチするか)」への話です。
(サイト読者への注:前々回「中堅エンジニアのための経営戦略入門」http://brevis.exblog.jp/25732183/ 、および前回「中堅エンジニアのための経営戦略入門(2)」http://brevis.exblog.jp/25754847/ の記事を参照のこと)

経営者の仕事とは、ざっくり言ってしまうと、次のようなステップから成り立っています。

(1) 企業の「ありたい姿」(使命・ビジョン・ゴール)を示す
(2) 「あるがままの姿」(現状)とのギャップ=課題を明らかにする
(3) 課題解決の方途(戦略)を決める
(4) 経営資源を再配置する(組織の変更を含む)
(5) 遂行をウォッチし問題解決を支援する
(6) 結果として新たな経営資源を獲得・蓄積する
(7) 適時(1)に戻る

課題という言葉の意味については、ずいぶん以前にご説明しましたが、覚えていらっしゃるでしょうか(「超入門・問題解決力 - 問題とは何か、課題とはどう違うか」http://brevis.exblog.jp/12188859/ )。課題とは能動的なもので、“あるべき姿”を思い描いて、現実をそこに向かって変えていくためのポイントです。一方、問題とは、(意識的にであれ無意識であれ)“期待していた状況”と、現実の状況のギャップを指します。上記の(2)で言っているのは、まさに課題の方です。能動的な課題設定は、経営者の重要な職務の1つです。

ついでに言うと、マネージャーの仕事も、大なり小なりこれの縮小版である、と考えることができます。ただし、違いは、中間管理職の場合、主たる使命・目標は「上から与えられる」ことでしょう。逆に言うと、自分で目標設定ができない・ビジョンを生み出せない人は、どこまで出世しても、内実は中間管理職であるといっていいかもしれません。こういう人は未来志向ではない訳で、つまり主体的に生きていない事になりますね。じつはよく見かけるタイプですけれども、
・言われたとおりのことをします、という受注型(受け身型)エンジニア
・正解だけを追いかけたがる入試型秀才
・世間から与えられた競争のモノサシでひたすら勝とうとする競走馬型人間
といった人たちで、環境が大きく変わると絶滅していってしまうのです。

さて、(3)のステップで使う道具立ての一つに、『課題展開図』があります。これは最上位の課題を1番上に書き、その課題を解決するための部分的課題をその次にかき、さらに部分課題を解決するための方策を次のレベルにおく、といった形で作られる図です。例をご覧ください。
e0058447_22061180.jpg
この例ではわかりやすいように、最上位の課題として、「会社の競争力再生」をおいています。そしてその次の中間課題として、「販売力の向上」と「コストの削減」をあげました。販売力の向上という課題を解決するために、2つのプロジェクトが生まれます。1つは新製品開発で、もう一つは海外市場の開拓です。さらにコストの削減という課題を解決するためには、生産合理化と物流改革という2つのプロジェクトがあげられています。スペースの関係で非常に単純な図になっていますが、構造はご理解いただけると思います。

ここであげているプロジェクトは、すべて自発型のものです。例えば新製品開発プロジェクトの目的は、販売力の向上であり、その目標としては、6ヶ月以内に新製品を出荷する、性能を3割以上向上する、が挙げられています。プロジェクトの目標は、具体的な数値をもとに、客観的に成否がはかれる形にすることが望ましいのですが、目標設定は当然ながら課題解決の目的に合致したものでなければなりません。ですから、1年以上かけてじっくり開発するとか、外観を変更するだけで性能はちょっぴり変えるとか、あるいは最小の開発予算で出荷するとかいった目標設定は、不適切だということになります。

さて、ここでどうしても『プログラム』という概念について、ご理解いただかなくてはなりません。プログラムとは、プロジェクトの上位概念です。通常はひとつのプログラムの中に、複数のプロジェクトを包含します。ちなみに米国の「アポロ計画」は、英語では"Apollo Program"でした。プログラムは、配下のプロジェクトを有機的に連携させながら進めることによって、目的を達成する活動です。課題展開図をご覧ください。この例では、「販売力の向上」を達成する活動群が、一つのプログラムに該当します。プログラムは、単なるプロジェクトの集合体ではありません。当然ながら、コンピュータのプラグラムとは全く別の概念です(よく混同されるのでこまるのですが^^;)。
プログラムとは、企業組織が新しい能力を得るために行う、時限的な営為です。これはじつは、英国政府が作成した標準書である"Managing Successful Programmes”(通称MSP)の考え方です。英国では、政府自らがこうしたいろいろなマネジメントに関する標準的解説書を制定して、例えばオリンピックや、鉄道網の敷設といった大規模公共事業を成功させるべく、適用しているのです。

プログラムは能力獲得が目的ですから、通常は、経営資源・設備の増強や、その質的向上を伴います。しかし設備を作ったり、人や組織を増強するだけでは、仕事は終わりません。設備や人が新しい「能力」を獲得して、はじめて目的が達成されるのです。そのためには、プロジェクトの結果(アウトプット)を、能力(アウトカム)につなげるチェンジ・マネジメントが重要な仕事になります。MSPではプログラム・マネージャーは、チェンジ・マネジメントの責任者と歩調をとって働くべし、と規定されています。何か大きな成果物や箱物を作って、それで一丁上がりとはならないのです。

プログラム・マネージャーの仕事は、大きく分けると4つあります。
・必要なプロジェクト群の構想・設計
・各プロジェクトの起動・完了(+中止)
・プロジェクト・マネージャーの任命と経営資源の配分
・プロジェクトの成果物を活用した、価値の具現化(課題解決)

なお、図の例では、経営レベルの最上位課題が、いきなりプログラム・レベルの中間課題に展開されていますが、これは企業組織の規模によりけりだと思ってください。大企業ならば中間に複数のレベルがあるでしょうし、中小企業なら経営課題からいきなりプロジェクトにつながるケースもあるでしょう。ともあれ、経営課題を解決するための手段(戦略)として、プログラム/プロジェクトがあるのだ、という点を理解いただきたいのです。

なお、ついでにいいますと、プログラムの上位概念に、『ポートフォリオ』があります。ポートフォリオとは、企業内、あるいは独立したビジネス・ユニット内で、互いに経営資源を取り合う関係にあるプログラム/プロジェクトの集合体です。経営資源(リソース)とは、人・設備・資金などを含みます。

経営者の仕事の(4)にあげたように、限りある経営資源の配分は、とても重要です。ポートフォリオに含まれる様々なプログラムを、適切に優先順位付けを行い、優先度の高いものから配分していきます。優先順の判断には、費用と効果のマトリクスをよく使います。ポートフォリオ・マネジメントの目的は、必要なリソースの配分ですから、企業内でポートフォリオをくくり出す際には、あまり部門単位(研究所・IT部など)の断面だけで集合体をとらえてはならなりません。研究→開発→マーケティング→生産準備という風につながって、はじめてビジネスの成果を生み出すのが普通だからです。

課題展開図に話を戻しますと、よくある間違いを二つだけあげておきます。一つめは、最上位の経営課題を次のレベルに展開する際、その設定を間違えることです。しばしば、そこに既存組織の単位をおいてしまうのです。たとえば「競争力の再生」なら、「営業部門の課題」「製造部門の課題」という風に分解してしまう。こうしたやり方がなぜ間違いかと言うと、現組織がカバーしていない問題が抜け落ちてしまうからです。また、組織間にまたがる問題が見えなくなりがちです。

もう一つのありがちな間違いは、重複や漏れがあるような改題展開をしてしまうことです。MECEな課題展開をしなければなりません。MECEとは、Mutually Exclusive and Completely Exhaustiveの略で、「漏れもなく、落ちもない」状態を表す略語です(もともとはロジカルシンキングで使われていた用語です)。日本全国の地図を、47都道府県にわけた場合、そこには漏れも重複もありませんよね。あるいは製品を部品表(BOM)に展開する際は、上位の親品目を下位の子部品が漏れも重複もないようにカバーする訳です。これがMECEです。

だから課題展開図とは、企業の経営課題のBOMだといっていいかもしれません。BOMの作り方によって、製造のしやすさや効率性は大きくかわります。上手な課題展開こそ、経営戦略の腕の見せ所なのです。Kさんも、ぜひこういった視点を持ちながら、製品開発の仕事を進めていかれることをおすすめします。ああ、すみません、また長くなってしまいました。最初に「ちょっとだけ補足します」なんて書いたのに(-_-;)。今度ぜひまた、会ってお話できる機会が持てるといいですね。


<関連エントリ>
 →「超入門・問題解決力 - 問題とは何か、課題とはどう違うか」http://brevis.exblog.jp/12188859/ (2010-02-21)
 →「中堅エンジニアのための経営戦略入門」http://brevis.exblog.jp/25732183/ (2017-04-28)
 →「中堅エンジニアのための経営戦略入門(2)」http://brevis.exblog.jp/25754847/ (2017-05-07)

by Tomoichi_Sato | 2017-05-14 22:06 | プロジェクト・マネジメント | Comments(0)

中堅エンジニアのための経営戦略入門(2)

長くなってきたのでここまでのところを少しまとめます。

製品やサービスの開発という視点からビジネスを考えるときには、4つの大きな要素があります。市場、競争、組織体制、技術の4つです。この4つは、企業の持つ能力の4つの面を表している、とも言えますね。つまり、販売能力、競争力、供給能力、技術開発力の4つです。

製品やサービスを開発するときには、これら4つの要素を独立にバラバラに検討するのではなく、合わせ技として、スパイラルを形成するような仕組みを考えることがポイントです。

ところでこの4つの要素は、最初の2つが企業にとっての外部環境を表し、残る2つが内部環境を表すと言い換えることもできます。ここで似たようなものとして想起されるのが、SWOT分析でしょう。よく経営コンサルタントは、最初に訪問したクライアントに対し、SWOT分析という道具立てを導入に使います。SWOTとは、strength, weakness, opportunities, threatsの略で、すなわち、強み・弱み・機会・脅威の4つを表しています。

これらを、<内部環境—外部環境>と、<プラスの面—マイナスの面>の縦横4つのマス目に書いて、具体的なポイントを列挙し、そこからラフな戦略の方向性を立てていくのです。このSWOT分析の「機会」は市場を、また「脅威」は競争を表していると見ることもできます。ただし「強み」と「弱み」は、組織体制と技術に直接対応している訳ではありません。が、わたしの経験では、企業人が自社の強み・弱みを客観的に把握するのは結構難しいものです。ですから、むしろ供給能力と技術開発力の視点で課題を列挙する方がブレずに議論できると思うのです。

さて、もう一つ、米国のポーターという経営学者がまとめた、競争優位のための3つの戦略があります。コストリーダーシップ・差別化・集中の3戦略です。

この3つの戦略と、先ほどの4つの要素の関係について、わたしの理解を簡単に整理しておきます。図をご覧ください。テーマは競争戦略ですから、「いかに勝つか」が問題です。それに対して、供給能力(組織体制の力)によって、安く・早く・大量に生産して、市場を席巻するのがコストリーダーシップ戦略です。いいかえると、薄利多売ですね。そして、これができるのは、市場の大半を牛耳られるような王者(リーダー)企業です。

これに対し、チャレンジャー企業はどうするか。コスト競争に打って出たら、体力の差で討ち死にです。そこで技術開発力を発揮して、リーダー企業とは異なる特色と優位性を持つ製品・サービスをつくって、挑戦する訳です。これが差別化戦略です。たとえていえば、コストリーダーシップ戦略の正面攻撃に対して、差別化戦略は側面攻撃ないし奇襲攻撃に相当します。

ではもっと規模の小さなベンチャー企業や中小企業はどうするか。彼らは、特定の顧客との密接な関係の継続、そして既存顧客の満足・実績を元にした新規顧客の開拓という道を選ぶしかありません。これが集中戦略です。小さな市場を選び、そこだけに集中して錐のように穴を開け、大手を破って打ち勝つのです。大規模な広告宣伝は難しいでしょうから、口(くち)コミやネットなどで顧客を広げていく。まあゲリラ戦ですね。
e0058447_23214285.jpg
余談ですが、この三つの戦略、国レベルの行動にも当てはまりそうな気がします。太平洋戦争で、圧倒的な優位性を持っていた米国に対し、チャレンジャーの日本がとったのは奇襲攻撃でした。そしてベトナム戦争で解放戦線がとったのは、まさにゲリラ攻撃でした。

話を戻すと、もしもKさんが、従来とは全く異なるジャンルの新規商品を企画されるなら、たぶん集中戦略ではじめるしかないでしょう。これはという顧客に狙いを定め、顧客が今まで気づいていなかった問題・ペインを掘り起こして意識の上にのぼらせます。そして、それを解決できるのはわが社のこの製品しかない、と信じ込ませることができれば成功です。あとは徹底してサービスを集中する。もし顧客の満足を得られれば、その実績を唯一最大の広告メディアとして、さらに次なる顧客を掘り当てていく訳です。

逆に、市場を席巻できるような供給体制もないまま、低価格でコストリーダーシップ戦略に打って出たり、大した技術力もなくすぐ真似されるような差別化戦略をとったりするのは、愚の骨頂だということです。自分の置かれている状況を冷静に判断しながら、一番良い競争戦略を決めていかなければなりません。

ただ、こうしたポーターの競争優位戦略論に対し、その後いくつかの批判も現れました。その一つとして、ミンツバーグの戦略類型論を取り上げましょう。カナダの経営学者ミンツバーグは実証的な学風で知られていますが、彼は戦略には二つの類型があることを調査から見いだし、ポーターらの戦略論があまりにも計画立案に偏重していることを批判しました。1987年のことです。

ミンツバーグによると、二つの類型とは、熟考型と創発型と呼ばれます。「熟考型戦略」Deliberative strategyとは、当初から意図した戦略で、それがちゃんと実現したもののことです。つまり、考えてから走り出す、上にあげたポーターの戦略のようなタイプですね。これに対し、ミンツバーグが「創発型戦略」Emergent strategyと呼ぶ種類のものがあります。これは、長期にわたり繰り返しとった行動パターンが成功に結びつき、結果としてそのパターンを組織の基本方針としたものです。これは歩きながら考えるようなやり方ですね。この両者がある、と。

ポーターらの好む熟考型戦略は、うまく当たれば成功しますが、外部環境の大きな変化に対して弱いという面があります。逆に創発型戦略は地味ですが、まあ合議制の文化の強い日本企業では好まれるかもしれません(これは逆に言うと、参謀機能が弱いということにもなりますが・・)。

さて、ここであらためて、Kさんの最初の問いに戻りましょう。経営者でもない、重役でも部長ですらないリーダークラスのエンジニアが、戦略という仕事にどう関わるべきか、本当にそんな必要があるのか、という問いです。答えから言ってしまうと、必要あり、です。なぜかというと、技術者はプロフェッショナル・エンジニアとしての自立を目指すべきであり、そのために戦略の基本を学ぶことが大切だと思うからです。

もしもKさんが、経営企画部などの参謀機能の部署におられるなら、話はもちろん簡単です。戦略立案と遂行のモニタリングが、部署の本来業務だからです。まあ、戦略立案部門と言っても、自分が決める訳ではなく、可能ないくつかの選択肢(オプション)と評価を示し、経営層に決断してもらうことが基本的なスタンスとなります。ただし、このような部署の仕事は、エンジニアとしての仕事ではないですね。

では技術者としてはどうなのか。ここで大切になるのが、以前書いたように、「上司の上司として考える、顧客の顧客を考える」スタンスです。仕事に期待される要件を洞察するためには、それが必要です。言われたこと、要求されたことだけをするのではなく、本当に期待されることを先回りして考える能力。これが、プロフェッショナル・エンジニアとして求められる能力です。

米国やカナダにはプロフェッショナル・エンジニアという制度があることはご存じでしょう。彼らは会社勤めのこともありますが、プロとして独立している場合もあります。聞いたところによるとカナダでは、エンジニアは労働組合にも参加できないのだそうです。なぜならエンジニアは弁護士や会計士などと同様に、Professional(独立性のある知的職業)だから、という社会的概念があるためだとか。

単に言われたことだけやるのは兵卒、あるいは労働者の仕事です。主体性を持つ者が、プロフェッショナルと呼ばれるにふさわしい。主体性を持つとは、未来を創造しようとすることに他なりません。未来の創造とは、未来商品・未来技術を創造することもその一つですが、仕事のやり方を新たしくするのも含みます。Kさんがこれまで工場でやられてきたことは、まさに主体性を持った未来の創造ではありませんか。

技術者や会社員にとって、「主体性」の反対とは、何でしょうか? それは、雇用義務や社会の義務だけ果たせば、あとは自分の自由だろ、と思う態度ではないでしょうか。かなり多くの人がそういった態度をとっているのは事実ですし、まあ、それも一つの生き方だと言えば言えます。じつは大学を出るかでないかの若い人の中にも、就職したらとにかく会社の要求する義務だけ果たして、あとは家族や趣味に生きたい、と考える人達が案外います。ちっとも未来志向ではありませんね。

ただ、そうした態度は、雇用や社会のあり方を新しくしようという希望を持たないこと、でもあります。極論すれば、それは自分が会社にとって交換可能な部品か、ロボットとなることを意味します。ロボットは、希望を持たない存在ですから。本来は未来を設計し創造するはずのエンジニアという種族の中にも、そういう物言わぬ大多数が占めていく現実を、わたしはいささか居心地わるく感じます。

わたしは別に、技術者は皆、独立して技術士事務所を開くべきだ、などと主張している訳ではありません。ただ、このような社会環境のとき、エンジニアはただ会社に従属するだけでなく、主体性を持って仕事の未来を考えるべきではないかと思う次第です。そのために、いわば「個人事業主になったつもりで、頭のトレーニングとして」経営戦略についても思いをめぐらすべきだと考えるのです。それは技術リーダーを目指す人にとって、必須のトレーニングの一部だと考えます。わたしは最近、研究部会の仲間と共に、そうした技術リーダーのための相互研修とコミュニティの場を作りたいと構想しています。遠いのでKさんにお声がけするチャンスがありませんが、そのうちご披露できればと思っています

そしていつか、Kさんが非常にユニークな製品を開発されたおかげで、それを売ってほしいと求める顧客が長蛇の列をなし、自分で好む顧客のみをピックアップして仕事を受けることができたら、そして営業に頭を下げたり無茶なコストダウンを命じられたりする悩みから解放されたら、素晴らしいと思いませんか? そのためには、どの市場に対し、何を売って、いかに供給し、どうやって競争を闘うか(あるいは闘わずして勝つか)を、懸命に考える必要があるのです。それをできるのが、エンジニアとしての仕事の醍醐味ではないでしょうか?


<関連エントリ>
 →「中堅エンジニアのための経営戦略入門」http://brevis.exblog.jp/25732183/ (2017-04-28)
 →「職人的であること、エンジニアであること」http://brevis.exblog.jp/24607574/ (2016-08-21)



by Tomoichi_Sato | 2017-05-07 23:22 | ビジネス | Comments(0)