| 全体トップへ戻る |
エンジニアについて
私自身は日本企業のエンジニアとして長年働いた。日本企業のエンジニアと米国企業のエンジニアとの差
研究所のエンジニアと事業部のエンジニアとの差、日本企業におけるピュアエンジニアの処遇
発展途上国の新人エンジニアなど、エンジニアに関していろいろ観察してきた
２０１６．０３．２９ 追加
１． ｢個｣ の確立と ｢個性｣米国駐在から帰任した後、 ｢米国のエンジニア達の『個』を活かした働きぶりの良い所を取り入て、独創的な開発エンジニアを輩出させる環境作り｣ に励みたいと思った。個性を生かしたとも言えるが、 ｢個性｣ という日本語には ｢他とはちがって｣ という ニュアンスが強い。私がここで言いたい ｢個｣ というのは、｢一人一人が自発と自律の出来る｣｢自分がやっている事に“自分なりに” 完結した論理を持っている｣ということであって、「他と違っているか否か」ではない。 そういう個の集合の中で個と個が切磋琢磨した結果として ｢他とはちがってきわだったもの」が出てくる。そういう環境に変えたい。 先ずは個としての｢自発｣と自分なりの論理と、それに沿って自分を動かす｢自律｣が備わっている人の数を増やすことが重要だと思う 設計の実験室や工場のデバッグ現場を歩き、スコープをのぞいているエンジニアと話してみて一番先に感ずる ｢日米格差｣ は、 ｢自分が今何をやっていて、そこに現れている波形が何を意味するか｣ を、観測している当人が理解しているかどうかだ。 ｢何を測定しているの？ どうなると何が問題なの？｣ という私の質問に対する彼らの答えに端的にそれが現れる。 「さあ・・・測れと言われたので・・・」という答えは圧倒的に日本へ帰ってきてからが多い。 アメリカ人のエンジニアがそういう答えをするのには出会った事がない。 エンジニアから測定を依頼されているテクニシャンでも、 ｢ここが狭くなると問題だと聞いている。それを捕らえるのには このプログラムが必要なので作っている｣ といった答えをして、自分の測定方法がいかに便利かを力説したりする。 彼らは日本と違って、エンジニアの卵でも見習いでもない。諸々の測定を請け負うプロとして働いているからだろう。 だから、テクニシャンに、 ｢そこが狭いとなぜ問題なの？｣という更に踏み込んだ質問はお門違いということになる。 一方日本では、エンジニアの卵達が先輩エンジニアの指示でいろんな測定をやっている場合が多い。 ｢測定のプロではないが、見習いエンジニアとして問題の全体像を描きつつ測定をしている｣という点がアメリカより有利だった筈だ。 ところが、測定の技術はプロと程遠くて、しかも採っているデータの意味を問われて｢さあ・・・測れと言われたので・・・｣では どうにもならない。 測定を依頼する方は、｢どんなデータになるとどんな問題がなぜ起こるか｣を説明して依頼するべきだし、 依頼される方は、もし自分がそれを知らないなら測定にとりかかる前に、きちんと質問して理解しておくべきだ。 他人から ｢べきだ｣ 等と言われるまでもなく自分からそうして ｢自分なりの論理｣ を構築してから仕事にかかるのが ｢自発と自律｣ を備えた一人前のエンジニアへの道だろう。言われるままに自分で理解もしないで従っているだけでは、何年たっても 自発と自律を備えたエンジニア (自発と自律を備えていないでエンジニアと呼べるかどうか怪しいが) にはなれない。 そういう多くの｢自発と自律を備えたエンジニア｣たちが切磋琢磨する中から、｢他とは違って際立った｣独創が生まれる。 一人一人の｢自発と自律｣の度合いを仮に｢自立度｣とし、自立度80%以上の人の存在確率を｢自立率｣とするなら、 アメリカ人のエンジニアの自立率が95%、わが方のエンジニアの自立率は30%程ではあるまいか。 |
２．エンジニアと学習ディスクのアクチュエーターの動きを表す程度の数式記述は、エンジニアなら全員学校で学んでいる。だが、それが意味する物理的な性質を理解している人は非常に少ない。現実に物にさわった事がない学生時代に、 いきなりsin/cos, jωだと言われても、すんなり物の動きと数式の関係を理解できる方が不思議というものだ。 私のように、現に物を設計しようとして、微分方程式が解けず、つまり現実の切実なニーズを持ってから、会社を辞めてまで sin/cosや､ jωを習いに学校へ行った人はごく僅かだろう。 ニーズがあるとないとでは、理解の度合いと速度が違う。 日本人エンジニアの多くは、学校を卒業した後に、そのニーズに 初めて直面しているはずだ。直面しながらも、『むかし学校で習ったが、あの訳の判らんことをまたやる気はしない』と、 アレルギーをおこしている者もいることだろう。そういう人に言いたい。『ニーズを持った今なら、はるかに簡単に理解出来る』と。 私のように出直したケースは日本では稀だが、アメリカでは、いや、日本以外では普通だ。技術的課題に直面して、理論を学ぶ必要 を感じたら、その講座だけを夜間の大学で学んだり、一定期間会社を休んで関連の単位をとるのは当然のことなのだ。 彼らはニーズを持って学んでいるから、理解は早く、深い。大学で、ニーズを持たぬ内に単位を取って、何年も経ってからニーズに 直面する日本人エンジニアの多くは、実用的な理解度で彼らに劣っている。 私の場合でさえ、ニーズを持ったとはいえ、ニーズを持っていた時期と学んだ時期とには2−3年のズレがあった。 今ほどではなかったが、レジャーランド的要素の多い学生生活を送る内に、当初は切実だったニーズも鈍り勝ちであった。 ニーズに直面した時の切実さを保ったままで学んでおれば、もっと深い理解が出来ていたろう。 夜学で学ぶアメリカ人達は、 皆そういった鮮烈なニーズに駆られて学んでいる。昼間に解決すべき現実と直面し、夜はそれを解明するための理論を学ぶ。 現実を見て、それをどう数式で記述するか、数式を見て、それはどう言う現実の動きを記述しているのかを、直感的に頭に描ける人が 物を設計し、デバッグするのと、そうでない人がやるのとでは、速度、精度ともに格段の差があることは誰でもわかる。 日本では、そういう人が増える環境が乏しいが、アメリカではエンジニアと呼ばれる全員がそうしていると思ってまちがいない。 そうやって自分のスキルを上げる以外に給料を増やす手段がないのだから。 ボケッとしていても、一つ会社にへばりついておりさえすれば、そこそこに給料が上がる国など日本以外にはほとんどないのだ。 公務員は事情が違って日本と似た面もあるらしいが、我々は公務員を相手に競争するわけではないのだから、気休めにもなるまい。 日本でもそういう事に気づいている会社では、社内でそういう環境を作っていて、いつも技術者全員の技術的スキルをチェックし、 不足している者の昇給は抑えて勉強させるプレッシャーを与え、勉強したい者にはその機会を与え、スキルが上がれば給料を上げる 仕組みを持っている。 だがしかし、そういう仕組みを持った会社が少ないのは、その必要がないほどエンジニアの技術力が高いと 思っているせいか、それともそうせずとも自発的に皆が自分でそういう機会を探して勉強すると思っているかのどちらかだが、 そのどちらもが当たっていないことは、エンジニア自身が一番よく知っている。 知らないのは出身学校名でのし上がった現在の経営幹部だけだ。 実務技術者がとっつきやすく、自分自身で学習環境を作るのに都合の良い、シミュレーションソフトがパソコンに搭載できるサイズで 売り出されるようになった。『MATLAB』の中の『SIMULINK』というアプリケーションが役に立つ。このシミュレーションソフトは、 伝達関数で記述した単位機能ブロックをブロック図上でつなぎ、入力に任意の波形を与えれば、出力波形が表示される。 私のようなロートルが、モタモタとマウスを机から取り落としながらでも、ディスクのアクチュエーター制御（連続アナログ系、 離散ディジタル系とも）、ヘッドからの出力信号処理回路、書き込みヘッドからの発生磁界などのシミュレーションができるほど 使いやすい。若い諸君ならすぐに使い慣れて、ブロック図と演算プログラムをループにして、私などが使っているより、 はるかに高度なシミュレーションが出来るだろう。回答は数式ではなく、ボード線図と波形で周波数特性と時間応答の双方を即座に 表示してくれるから、大学教授から数式を教えてもらうより、直観的でわかりやすい。 シミュレーションは、単に設計のために使う道具である他に、『実経験の代わりに、実経験よりはるかに早いサイクルで、 はるかに明瞭な理論と現実のつながりを示しながら、バーチャル経験を積ませる道具』として、『学習』にも役に立つ。 おおいに活用してもらいたい。 |
３．研究所のエンジニアと事業部のエンジニアわれわれは何のために微分方程式を解く必要にせまられるのか。『物の動きの時間的変化を把握したいから』に他ならない。その動きがどんな数式で表現されるかを知りたい訳ではない。ただ、時間的動きを『前もって』把握するためには、 数式で記述して計算する必要があるからである。そして、数式で記述するためには周波数ドメインで議論することが必要になり、 物の「時間的動きの直接的表現」からやや離れた数式にならざるを得ない。 数式表現は最終目標ではなく、物の動きを解明するのに必要な途中経過に過ぎない。 研究所のエンジニアと事業部のエンジニアについて、日頃私が感じるのは、研究所のエンジニアは、『数式で記述する』部分ばかりに 偏り、それが『物のどんな動きを記述しているか』を知らない。逆に、事業部のエンジニアは『こういう風に動いているものは、 数式でどう記述されるのか』を知らない。知らないというのが言いすぎなら、一歩譲って関心が薄いといっておこう。 もう一つの違いは、『省略とモデル化』についてである。 一般に、現実のものの動きを漏らさず記述するためには、膨大な数式が必要だ。はじめからそんな膨大なことを数式で記述すると 『主要な動き』が『枝葉末節』にうずもれて判りにくくなるばかりなので、枝葉末節をひとまず省略してして考えるのが普通だ。 そうすることで物事の本質が把握しやすくなるから、大きくジャンプするような技術革新を考えるのには都合がよい。 ところが、事業部のエンジニアが日頃格闘している相手は、『主要な数式記述から省略されている部分』である場合が多い。 主要な部分が間違っているような物が実際に試作機として作られることなどありはしない。 だが、主要な部分さえ理屈どおり動けば売り物になる機械などこれまたありはしない。 日頃そういう現物と格闘している事業部のエンジニア達は、『どうせ数式で記述出来るようなことは動ているに決まっている』と 決め込んで数式で記述することを考えようとしなくなる。 一方、研究所のエンジニアは、自分がたくさんな事を『枝葉末節』として省略していることを忘れ、というより、ずっと先輩たちの 代からそうなので、省略していることを認識すらしていない場合が多い。 こんなところに、双方の『どうせあいつらは計算出来ることしか判らない』『どうせあいつらは計算などできはしない』という 相互不信が醸成されやすい原因がある。多かれ少なかれ、そういう傾向が存在するのは、当然のことだ。 それをどう少ない状態に維持できるかが、研究所と事業部双方ののマネージメントの永遠の課題なのだ。 『枝葉末節を省略したのは、技術革新を生みやすくするためであって、いったん生まれた革新技術は、省略した部分を復活させて検証 しなければならない』という当然の事を研究者が認識し、『枝葉末節の部分と言えども、個別に分解さえすれば、数式記述が出来て、 解析しやすくなるのだ』というこれまた当然のことを事業部のエンジニアが認識して実行することが唯一の解決策なのだ。 |
４．企業におけるピュアエンジニアのキャリアパス私が在籍した当時のＦ社は、いわゆる技術のウデ一本に賭ける『ピュアエンジニア』ともいえる存在に対して最上位に達するための整備されたキャリアパスが存在しなかった。最上位として、技師長というものがあるにはあったが、これはラインの 課長→部長→事業部長（または事業部長代理）と登っていったあとにのみ到達できる地位であった。 ラインの長は、技術だけでなく、部下の人事管理、顧客対応、ビジネス利益の管理といった”純粋技術”とは無縁の雑用を こなさなければならない。 『ピュアエンジニア』は、往々にしてそのような管理能力に乏しい場合が多い。結果として上昇パスを絶たれる場合が少なくない。 そのような問題について、当時勤労（人事）部長だったＹ氏に提言書を出した。ちょうど本社の人事部でも、かつての年功序列に 代わる人事制度を模索中であったらしい。本社人事部長のＯ氏からＹ氏を経て、『一席設けるから、話を聞かせて欲しい』という 申し入れを受けたことがある。このときＯ氏が構想していたのが『目標管理制度』であった。 それまでは、各事業部の課長・部長が集まって部下の年間実績を評価・査定し次年度の昇格・昇給を決めるという方式であった。 『それでは、査定される当人が全く関与できず、どんな議論を経て決定をくだされたのか、不透明だ。』という問題への対策として 各年度の初めに各自の目標を 書面で提出させ、年度末にその達成度を当任と上司が面談して判定し、次年度の昇格・昇給を決める 『目標管理制度』への移行である。目的は、従来方式の“部下と上司間の不透明性、評価基準の不明確性”を改善することだった。 初めて聞いた私の第一の疑問は、 その“目標の価値”をどう決めるのか？ 複数年度にわたる目標をどう表現するのか？ であった。 “目標に達成の難易度に応じた値札を付けなければ意味がない”というのが私の意見であり、Ｏ氏の質問は“正当な値段を決めきれる 部課長がどれくらい居るか”であった。『うーん、５％〜１０％ですかねえ、値段を付けきれる部課長は』と私は答えた。 結果として、値札なき目標管理が始まったわけである。 『目標管理』、『成果主義』は、年功序列、学歴＝学校名主義の欠点を除くべく導入されたが、私はかつて在籍した事がある 同業他社の老舗的大企業に比べて、Ｆ社は、学歴＝学校名主義の色合いがもともと薄いと感じていた。 私は、値札無しの目標管理が実施されたあとでは、『以前に行われていた事業部全体の部下の序列をその事業部の部課長全員が一堂に 会して合議の上決め、事業部長が承認して年度成績を決定し次年度の昇格・昇給を決める』という方式は、個々の部下との間の 透明性は低かったにせよ、『全体としての公平性を保ちながら各人の能力を評価する』のに適した方式であると思うようになった。 Ｆ社が真っ先に取り組んだ目標管理制度は結果として失敗に終わった。そのうえ、人事部から退職した人間によって書かれた、 『内側から見たＦ社「成果主義」の崩壊』という本がベストセラーになったりして世間から叩かれた。 以下は私がアマゾンのサイトに書いたこの本へのレビューである。 『目標管理』、『成果主義』は、年功序列、学歴＝学校名主義の欠点を除くべく導入されたものである。 著者がＦ社の人事部門に所属していたのは、まさにその導入、実験段階にあった時期である。いわば、試作機が完璧に動かないから といって、その設計の末端であったとはいえ一員であった者が、修正の努力をすることなく現場から逃げ、外から批判するという、 男の風上にも置けぬ者の著書である。 私は技術屋として定年までＦ社で働いた者だが、技術屋としてあれほど面白く働ける会社はなかった。 たしかに、『目標管理はうまく機能しなかった』とは思うが、それは各目標に”値札”が付けられていなかったことに起因している。 従来の年功序列、学歴＝学校名主義で上がってきた当時の管理職には残念ながら、それを付ける事のできる管理職が、少なかった。 そのため、やむなく値札なしで見切り発車せざるを得なかったのだろうと思う。当時の人事部長は、私のような技術者までを交えて 真剣な議論をかさねていたのだ。それらをを知らずにたった３年ほど現場放棄した社員の手になるこの本が、ベストセラーになり、 翌年から技術系までも就職希望者が激減し、Ｆ社は大きな迷惑を受けた。その事自体、日本の社会と若者の劣化を物語っている』、と 私は思っている。』 話が少しそれたが、本題の『ピュアエンジニアのキャリアパス』の方は、あれから２０年経った２０１６年現在でも依然として 日本の大企業の問題点であり続けている。むしろ、ピュアエンジニアに限らず、『突出した者を潰してしまう』日本社会の同調圧力 の高さに起因する問題の方が、日本社会全般の問題点として浮上してきている。 |
５．フィリピーノ達 １９９５年半分偶然にフィリピンの新人採用の面接官として出張したのが4 カ月前。行く直前のNHK スペシャルか何かでピストルの密造工場から日本へ密輸されている状況を見たりしていて、悪い先入観を持っていた。 それが逆に幸いしたのかどうか、行ってみるとショッピング街はアメリカのモールと大差ないし、果物はうまい。スーパーの店員も 私よりはるかに流暢な英語をしゃべる。学生に面接してみると、全部ではないが、『俺がこの国をこれから作り上げるのだ』みたいな 大言壮語をはくのが一人や二人ではない。自分の若いころの仲間に出会ったような気がして親しみを覚えた。 日頃わたしはこのシリーズ『開発の現場から』で若い人達にいろんな文句を言っている。我々が入った頃と現在の事業部の状況 (製品の単純さ、規模の小ささ、先輩の少なさ) などの違いはある程度判っていたつもりだが、その他に国全体の時代背景の違いも 大きいのだな、と実感した。 これからはい上がろうとする国の若者と、既に成長をとげ、成熟するかしないかの内に早くもやや欄熟傾向になった国の若者。 だが、国はともかく、事業部は這い上がるかさもなくば消滅というのが我々の時代背景なのだ。 若い人に『事業部の運命は俺の双肩にかかっている』くらいの大言壮語をはくようになってもらいたい。 そんな事を思っていたからか、つい口を滑らせて、『あんな連中なら教育のし甲斐があるだろう。なんなら俺も一役買ってもいいよ』 となって、3 日間の導入教育『Theory of Operation of HDD 』を引き受けることになってしまった。 それから教育資料のネタさがしを始めたのだが、ろくな資料がみつからない。MRヘッドだけとか、高記録密度の開発計画だとか、 ロードマップだとか、ないわけではないが、そんな話をいくら聞いても只今現在のHDD がどう動くのかわかりはすまい。 これから工場を動かそうかという彼らにはほとんど役にたたない。日本人の新人なら立派な(?) 先輩達がたくさんいて指導してくれる 中で、2 〜3 年かけて育てば良いのだろうが、フィリピーノ達はそんな悠長なことは言っておれない。 ドロ縄だが、慌てて自分で作ることにした。英語で書く余裕はないので、日本語で書いて翻訳を頼んだ。 頼んだ日には5 ページほどしかなかったものを、追加、追加で結局は文章だけで20ページになった。 しぶる翻訳屋をなだめたりすかしたり、結局は脅してどうにか納期を承知させ、翻訳に出ているあいだに、図を自分で作った。 ワープロで絵を作るほどの使い手ではなし、お絵描きソフトなど夢の又夢。幸いシミュレーションソフトを少しばかり使えたので、 作った資料に出てくる波形はいままでのどんな資料にあるものよりリアルだ。最終的には20枚ほどの図をつけることが出来た。 幸い、翻訳屋さんも技術の判る人だったので、大した手直しもなく使えた。翻訳するのにえらく骨がおれたとこぼしてはいたが。 さて当日、先ずは、『君達はこんなに良く組織された教育を受けることのできる最初の新入社員だ。日本人はこんな教育は受けない。 なぜならみんなベテランの間で2 〜3 年かけて覚えればよい。だが、君達は半年後には自分で工場を動かさねばならない。 もちろんベテランも応援に行くが、人数が少ない。だから私が基礎知識だけを3 日で教える。 この知識は全ての基礎だが、それを知っているだけでは工場は動かない。この基礎の上には、部門ごとのたくさんの木が生えている。 その木にたくさんの枝があって、その先端に実がなっている。工場を動かすために必要なのはその実だ。 半年かけて木によじのぼり、その実を食べて工場を動かせるように育ってほしい。一人一人が別の実を食べることになろう。』 とぶちあげてから、『今から15分与える。第一章を読め』といって教室を出た。 一種のかけだと思ったが、15分後に教室にもどるなり、『何か質問は？』とやってみた。彼らもびっくりしたらしい。 ザワザワはするが手を上げる者がいない。『質問をする必要がないほど理解できたのか？それとも何を質問してよいか判らないほど 理解出来なかったのか？』とあおってみた。 一人が立ちあがって、やや抗議する調子で、『何の定義もされない専門用語が たくさん並んでいる』というと、一斉にみなが同調する。こう書いてくるとひどく緊張した固い雰囲気のようになってしまったが、 そういうわではない。雰囲気は陽気になごやかにやっているのだが、書くとこうなってしまう。 そこで、『だから質問は？と聞いている。どの言葉が判らないの？』といったら、続々と質問が出始めた。 あとはその質問に一つずつ答えて、他には？と繰り返している間に第一章は全部話し終えた。 全部質問に答えるばかりではなく、始めから話すつもりでいた筋のことを途中でまとめて話したのはもちろんだが。 大体話してしまったなという感じになったところで、『質問がなければ次へ進む』と言った途端、あわてて何人かが手を上げる。 かなり初歩的なことが判っていない連中が、このまま先へ行かれてはかなわないと思って、質問するのだ。 そうすると、すでに判っている者が、勝手に答えてくれる。 私は『そのとおり』とかちょっと違うな、本当はこうだ。とコメントするだけで済む。 私のかけは当たったようだ。何しろ、3 日間もずーっと英語をしゃべり続けることなど出来はしないのだから。 頑張って教科書を作っておいてよかった。後はずっとこの調子で最後まで通すことができた。 でも、彼らのものごとを吸収しようとする熱意は大したものだ。理解できない、納得出来ないことには、なかなか引き下がらない。 彼らが指摘した教科書の誤りが3 箇所あった。もちろんばらつきはあるが、あんな程度の記述しかない教科書でよくぞあそこまで 理解するなぁと内心舌を巻く場面も何度かあった。かなり高度の理解力の者が何人かいるのは確かだ。 しかし、大した理解力ではなくとも、とにかく自分が納得するまで食い下がってくる者の数が多いのが気に入った。 日本人の新人を相手にしてあのやりかたをとれば、『シーン』と静まり返って、だからといってこっちも『ではおしまい』と言って 打ち切るわけにもいかず、進退きわまったのではあるまいか。 そんな具合だから、私も非常に楽しい3 日間を過ごすことが出来た。来週には彼らが各職場に配属される。 明るい連中だから楽しく迎えてやってほしい。彼らを直接指導する立場になる人は、少なくとも教科書は手に入れておいて欲しい。 英語版も日本語版も、各工場とも、責任者の手元に原紙を配っておく。彼らはよく質問をする。もちろん配属先で教えるべき細かい 事までは教科書には書かれていない。だが、自分で答えられない時は、知っている人に尋ねて答えてやってほしい。 君だってその答えを知っておく方が良いに決まっているのだから。 だが、そうするのにあまりに忙しくて、長く (2 〜3 日も) 待たせてしまいそうな場合は、少なくとも○○さんが知っているはず だからその人に聞け、と教えてやってほしい。では、フィリピーノ達をよろしく。 あれから２０年経った。日本の会社を含め、世界の先進国のの製造現場は殆どかつての途上国に移ってしまった。 さらには開発機能までが移転しそうな勢いだ。さてどうするか。若いエンジニア諸君の双肩にかかっている。 結構力を入れて育てたつもりだが、何年も経つうちに、ある者はアメリカ企業に引き抜かれ、当のＦ社もＴ社に身売り、そのＴ社が オカシクなって、今ではどこに散らばったか知る由もないが、あの国のどこかで、『この国は今俺たちが背負っているのだ』と たくましい働き盛りを過ごしているのだろう。そう思いたい。 |