2007-05-26

カイゼンを実現できる多能工を目指そう!

R30氏のブログ R30::マーケティング社会時評 の記事『ポリバレント=多能工って言えばいいんじゃね?』を読んで、トヨタ生産方式の強みについてどんな人材がカイゼンに向いているのかイメージが沸いた。

「Polyvalent:ポリバレント」とは本来は科学用語で、日本語の意味では「多能工」ということだそうで、「サッカーの日本代表にはポリバレントな選手を登用すべきだ」といった感じで使うらしい。この例では、ひとつのポジション(役割)だけでなく、いろいろなポジション(役割)をこなせるような人材が必要という意味だ。

さて、R30氏はポリバレント=多能工について次のように書いている。

【R30 マーケティング社会時評 「ポリバレント=多能工って言えばいいんじゃね?」より】

 ものづくりの世界での「多能工」の意味には、まず作業負荷の平準化がある。つまり、ある工程の作業ができる人というのがライン内に複数いることで、その工程の作業負荷が一次的に増えてもそれを前後の工程の人が分担できる、だから生産ライン全体で見るとボトルネックが生じにくい、というのがそれだ。

 ただ、多能工のメリットはそれだけでなくて、複数の工程をこなせるため仕事に飽きが来ない、複数工程にまたがる「カイゼン」の提案ができる、そして熟練すれば単工程の作業をこなせる人よりも多くの人から尊敬を集められる、といったこともある。言うなれば作業者のモチベーションそのものを高めることができまっせ、というのが多能工化の本質的な価値である、とトヨタ生産方式の中では言われているわけだ。

【引用終わり】

多能工の特長としてまとめると次の4つになる。
  1. 工程の作業負荷が一次的に増えてもその前後の工程の人が分担できる。
  2. 複数の工程をこなせるため仕事に飽きが来ない。
  3. 複数工程にまたがる「カイゼン」の提案ができる。
  4. 熟練すれば単工程の作業をこなせる人よりも多くの人から尊敬を集められる。
今、大規模・複雑化した組込みソフトの世界では複数工程にまたがる「カイゼン」の提案ができるエンジニアが少なくなっている。

もともと小規模なプロジェクトで組込みソフトの開発を行っていたころは、上記の4つは誰が指示するでもなく組織の文化として浸透していた。だから、TQC活動(カイゼン活動)も特に違和感なく現場に受け入れられていた。

ところが、作らなければいけない組込みソフトが大規模・複雑化し、設計・開発工程も長く、複雑になってくると、技術者の目標として多能工になるという意識がだんだん薄れてきた。

開発日程の縛りからくる締め付けが組込みソフト技術者から余裕を奪ったことが、多能工になりたいと思う気持ちを萎えさせる最大の要因だと感じる。

余裕がないから、自分の役割だけをこなせばいいやという感覚がプロジェクト内に広がってしまう。このブログサイトで再三書いているように、日本人の技術者は責任と権限が曖昧なまま作業を進める。そのため、責任が明確になっていない状態で自分の殻にこもられると、セクション間のインタフェースの認識違いなどが生じる。そうするとインタフェース仕様の調整などを誰かがボランティアでやらないといけない。

多能工を目指すでもなく、(人に指導できるくらいの)専門性があるわけでもない非常に中途半端な技術者が増えてくると当然「カイゼン」は進まない。

組込みソフトにおける多能工とは組込みアーキテクトのことだと思う。組込みアーキテクトは、要求と制約のトレードオフをしてアーキテクチャの最適化を図る必要があるため、要素技術の知識も必要だし、市場要求についても分析できないといけない。

組込みソフトの世界で多能工(=組込みアーキテクト)になれればカイゼンの糸口が見えるようになるし、自分自身のモチベーションにつながる。

以前、このブログで日本のソフトウェアエンジニアも責任と権限を明確化して仕事をしないといけないと書いたが、だからといって何かの技術の専門家に留まれとは言うつもりはない。責任と権限は意識しつつも、自分の周りの技術にも興味を持ち、「それは自分の領域ではない」とった壁を作らずに多能工を目指すべきなのだ。

それを実現するためには、エンジニアの中に心の余裕がないといけない。しかし、現実的には仕事に追われる日々を過ごしている技術者が多いだろう。でも若いうちに苦労して多能工的な幅広い知識とスキルを身につけておくと、徐々にその知識・スキルが生きてきて工程やアーキテクチャのカイゼン点が見えてきて、カイゼンを実行することによって作業効率を高めることが可能になり、さらにカイゼンを進めることができるという好循環のステージに入る。プロジェクト規模は小さかったけれど、自分はこの好循環のステージを経験したことがある。今では、どうしたら悪循環に陥っているプロジェクトを好循環に変えることができるのか試行錯誤しているところだ。まだ、結論はでていないが、実感としてプロジェクトメンバの中で多能工を目指す姿勢を持ったエンジニアがいることが条件であると感じている。

ところで、R30氏は『ポリバレント=多能工って言えばいいんじゃね?』の記事のなかで、多能工を嫌う人種として専門家ホワイトカラーのことをぼろかすに言っている。(R30氏のいつもの語り口なので、特にぼろかすではないのかもしれないが・・・)

【R30 マーケティング社会時評 「ポリバレント=多能工って言えばいいんじゃね?」より】

・・・いわゆる「専門家ホワイトカラー」系の世界の住人である。この方々は1つの領域に深く深くはまっている人にこそ最高の価値があると思っていて、複数の領域を股にかけて何の専門家なのかよく分からないぐらいいろいろな領域に足を突っ込んでいる人を、ことさら卑下するさげすむ傾向がある。

 「専門性」という名の下に隠蔽されたこれら「専門家」の視野狭窄、柔軟性のなさ、そしてもっとぶっちゃけて言うと「使えなさ」みたいなものは、最近とみに深刻だと思う場面が増えているのだけど、当の専門家の間にはそういう世間の評価に対する反省というのがまったくないというのがさらに深刻ですな。
要するに、知的退廃というヤツでしょうか。

【引用おわり】 (この後のくだりは過激すぎてちょっと書けません)

R30氏は、複数領域の専門性を併せ持っている「多能工」が高い価値を生み出すことができ、純粋学問と社会の間の「実務系学問」の領域くらい、多能工専門家の評価をもっと高くする仕組みがあっていいのではないかと書いているが、自分もまったくそのとおりだとおもう。

専門領域を横断して、要求と制約を最適化する多能工は価値の高い商品やサービスを生み出すことができる。しかしながら、そのような多能工はアカデミアの世界では評価されないし、多能工が解決する領域を研究する学会(たとえば失敗学など)は、専門領域の学会よりも下に見られているように思う。

ちょっと話がずれるが、学会やシンポジウムに論文を投稿する際のしくみをご存じだろうか。投稿論文はすべてが採用されるわけではなく、論文の査読者が投稿論文を査読しふるいにかけ、査読に通ったものだけが採録される。

通常、査読はその道の専門家数名が行う。大抵はアカデミアが行う。そして、投稿論文は採録される場合もされない場合も、査読者が“匿名”の状態でコメントが付けられ、投稿者に通知される。

ここで自分が引っかかるのは、なぜ査読者の名前を伏せるのか? という点だ。自分が投稿するときは多くの場合、多能工的なアプローチが解決する方法論なのだが、それに対する特定領域の専門家のコメントがしっくりこないこともある。このようなときは、コメントの真意を聞きたいこともあるし、場合によってはディスカッションしたいときもある。そもそも、ほめるにせよ、批判するにせよ、匿名でコメントをするというところに釈然としない何かがある。

専門家としてのプライドや誇りがあるのなら名前を隠す必要はないし、その後の意見交換で双方ともに有益な情報を得ることができるかもしれない。もしかして、「投稿者は査読者よりも下だからコメントに反論するなどもってのほか」、だけど、「専門以外の領域横断的なことを聞かれても答えられないから名前を出したくない」のでは、と勘ぐりたくなる。

ともあれ、価値の高い商品やサービスを生み出さなければいけない組込み製品の開発組織では、多能工を目指すでもなく、専門性もないような技術者を作らないようにしなければいけないし、専門領域に閉じこもっている技術者はカイゼン力が弱いということを認識しつつ、多能工でありながら自分の役割もキッチリ果たせるような技術者の育成に努めなければいけない。
 

2007-05-21

組込み機器におけるギャランティとベストエフォート

2007年5月20日付けの毎日新聞朝刊に「時代の風」というコラムがあり、東大の坂村健先生の写真が載っていた。

坂村先生の写真は ESECとかETのパンフレットやWEBサイトではよく見掛けるが、新聞のコラムで見たのは初めてだった。

コラムのタイトルは『デジタル・デバイドと自己責任』で、坂村先生は自宅のインターネットがうまくつながらなくなり、その復旧でえらく手間取ったという先生の知人のエピソードを通して、インターネットの世界におけるベストエフォート(最大努力)型とギャランティー(性能保証)型との違いについて解説している。

このコラムを読んだときに頭に思い浮かんだのは、『組込みソフトエンジニアを極める』で書いたリアルタイム要求とスループット要求のことだ。

リアルタイムシステムにおけるリアルタイム要求にはハードリアルタイムとソフトリアルタイムがあって、ハードリアルタイムは応答時間を保証しているのでギャランティー型と言える。それに対して、単位時間あたりの処理能力が高いことが要求となっている場合はスループット要求となり、応答時間という観点から見るとそれはベストエフォート型となる。

リアルタイムOSは応答時間を保証(ギャランティ)することができ、昔のUNIXやWindowsなど、CPUの処理時間を各スレッドに均等にしか割り振れないOSの場合は応答時間で考えればベストエフォートだ。

ベストエフォートだから、CPUの性能が非常に高かったり、平行に動いているスレッドの数が少ない場合は全く問題ない応答をするのだが、Windowを10も20も開いていくと徐々にレスポンスが悪くなる。これがベストエフォートのベストエフォートたるゆえんだ。

リアルタイムOSを使っても、パフォーマンスが100%を超えることはあるが、優先度の高いタスクに対するCPU時間を保証することはできる。これがギャランティ型のギャランティ型たるゆえんだ。

さて、坂村先生はこのコラムの中で専門のリアルタイムOSのことについては一言も触れておらず、インターネットがつながらない原因をたらい回しに合いながら突き止めても「ルーターの相性が悪いようです」と言われてしまうのは、インターネットはユーザーの責任の上に成り立っているベストエフォート型のシステムであり、今の世の中どんどんベストエフォート型のシステムが増えていて、身を任せていればいいというシステムはほとんど存在しないからだと書いている。

【デジタル・デバイドと自己責任より引用】

 インターネットはその「自由化」のもっとも進んだものだ。あるサイト中のデータを見るまでには実はたくさんの関係者がいて、それぞれが独立している。だから「インターネットの責任者を呼べ」と言っても、誰なのか分からない。
 しかし、だからこそ会社や国の枠を超えられる。たとえアフリカとでも、簡単にしかも無料でメールのやりとりができるのはそのおかげだ。

 :

 鉄道と道路、電話とインターネット・・・これらの違いを考えればわかるように、自由度を求めれば求めるほどシステムはベストエフォート型になる。そういう時代の情報システムでは、技術設計と同程度かそれ以上に制度設計が重視される。技術ではカバーできない部分は制度でカバーする。こうした発想が必要なのだ。

【引用終わり】

ギャランティ型とベストエフォート型のたとえとして、坂村先生は鉄道と道路、電話とインターネットを対比させた。でも、ここでは組込み機器における、ギャランティ型とベストエフォート型について考えてみたい。

そもそも、組込み機器のユーザーは製品に対してメーカーが機能や性能をギャラインティするものだと考えていると思う。インターネットのように、自由度が求められることによってベストエフォートに変化し、ユーザーが自分自身で責任を負担しなければいけないと考えるようになるのだろうか?

インターネットだってギャランティしてくれる誰かがいれば、その対価を払うユーザーはいる。組込み機器は機能や性能をギャランティしてくれるからこそ、ちょっと高くても買ってくれるお客さんがいるのだと思う。

もしも、組込み機器に自由度が求められたとしても、それは組込み機器全体がベストエフォート型にするのではなく、ギャランティの部分とベストエフォートの部分を切り分けることで解決しなければいけないのだと思う。

これを勘違いして、組込み機器は自由度が求められるようになったのだから、ベストエフォート型にすればよいと考えるとユーザーからそっぽを向かれる危険性が高い。

ハードディスク内蔵のDVDレコーダで立ち上がり時間が長くなったのは、メーカーが組込み機器をベストエフォート型にしてしまった典型的な例のように思える。

ちょっと観点が変わるが Linux などのオープンソースソフトウェアを組込み機器に採用した際に、オープンソースソフトウェアの信頼性をギャランティするのはLinuxを供給するベンダーではなく採用した組織側であるということを忘れている人がいるように思う。

Linux を供給するベンダーと問題があったときには速やかに原因の究明やサポートをする契約を結ぶことはできるが、オープンソースソフトウェアそのものの信頼性をギャランティしてくれるベンダーはほとんどいない。オープンソースの自由度がもともとベストエフォートに流れるようになっているからそうなるのだが、日本人は対価を払って買ったものは、その製品の機能や性能が当然ギャランティされているものだと思い込んでいるから勘違いするのだと思う。ベストエフォート型の商品や、ユーザーが一部自己責任をともなう商品などが(説明書にそう書いてあったとしても)実際には存在するなどと考えていないのだ。

メーカーも自己責任の部分は販売するときに声を大にして言わない、説明書の隅に小さく書く。でも、ベストエフォートの部分でユーザークレームが発見され社会問題にまで発展してしまうと、結局はメーカーがやり玉に上げられる。メーカーも「ベストエフォートですから、責任はユーザーにあるのですよ」とは主張しない。日本人特有の責任と権限を明確にせず、問題は発生したときに考えればいいやという曖昧な対応の結果だ。

自由度の高いインターネットのシステムを使っているユーザーでも坂村先生が言うように、システムがギャランティ型ではなくベストエフォート型になっているので、自己責任は発生しており、その分システムを安価に使えていると認識してくれるようには思えない。

日本のメーカーは商品の購入時にユーザーの自己責任は前面に出したがらないし、多くのユーザーはトラブルが発生して自己責任の部分が明確になっても「そんなことは聞いていない」と反論せず、泣き寝入りしてしまうので、わざわざマイナスイメージを最初に言う必要がないのだ。

しかし、組込み機器の中でも、特に安全性や信頼性が求められる機能や性能については、メーカーはそれらの機能や性能について保証しなければいけないということを忘れてはいけないと思う。

そこを自由度の高さを実現するためにベストエフォートでよいのだと考えた組織は、市場の中で競争優位を保つことはできなし、ユーザーは文句を言わずにそのメーカーの商品を買わなくなり、そのメーカーは知らず知らずに市場でのシェアを落としていくように思う。

2007-05-12

日本人はリスクを表に出すのが嫌い?

プロジェクトの会議に参加していると、ソフトウェアエンジニアはリスクがあるにもかかわらず上にリスクを言いたがらない傾向があるような気がする。日程が遅れるというリスクを言いたがらないのは心情的に分かるが、技術的なリスクやプロジェクトのリスクは抱え込んでいて後で報告するよりもできるだけ早いうちに上に報告してしまった方が得だと思っていたのだが、どうもそうでもないようだ。

後でリスクが現実のものとなってしまったら責任は自分自分が全部負うことになるが、早いうちにリスクの可能性を表明してしまえば上司にも責任を一端を負ってもらえる。この考え方が成り立つのは、責任と権限が明確な組織の場合だ。

でも、日本の組織では責任と権限は曖昧なことが多い。だから、問題はそんなに簡単ではない。リスクを早い段階で明らかにして誰も助け船を出してくれなかった場合、危惧していた問題が現実のものになってしまったら、失敗の実績プラスリスクを知っていたのに未然に回避できなかったという負の実績も背負うことになってしまう。日本の組織では評価も曖昧なので給料が下がることはあまりないが、印象が悪くなる。曖昧な社会において「あいつは役に立たない」というレッテルを貼られるのはイヤだという者がおおいだろう。

だから、リスクを知りながらリスクが具現化してしまうと、リスクを隠しておいたときよりも自分の評価が下がってしまう。リスクは言わないでおいて、何かの拍子にうまく解決できてしまえば自分に対するマイナスポイントを減らすことができる。

逆に,早期にリスクの可能性をポンポン会議で発言できる技術者は、裏返せばリスクを回避できる自信があるからだ。

早期にリスクを表に出し、そのリスクを解決することができれば、その技術者の実績として周りに認知してもらえる可能性が高いが、リスクを報告せずに解決してしまうと、誰もその実績に気がつかない。

そう考えると、技術力に自信のないエンジニアはリスクを隠す方向に動き、技術力に自信のあるエンジニアはリスクを表に出す方向に動くと言えないだろうか?

もちろん、このロジックの前提は、リスクを上司に報告しても責任を負担してもらえない、リスクを回避できる能力が上にありそうにないという組織の場合だ。

部品に調達や内部・外部との交渉など技術的な要因が伴わない手助けはよろこんで動いてくれるハードウェア出身の上司も、ことソフトウェアの技術的な問題や、ソフトウェアプロジェクトに特化したマネージメントの問題となると相談しても、「大変だね」という同情のことばをかけてくれるだけだ。

そうなると、ハードソフト混在のプロジェクトの場合、ソフトウェアプロジェクトの問題解決能力が低ければ低いほど、リスクが表に現れず製品開発の最後になって、先にも進めない後戻りもできないという状況に陥ってしまうことがある。

最後の手段としてあらかじめ計画していた機能の一部をが削られたりする。このような日本のソフトウェアプロジェクトに特有のシチュエーションはソフトウェア開発における悪循環を生みやすい。

プロダクトマネージャや組織上位層は、悪循環を回避するために自分自身がソフトウェアに関する問題の解決の手段を持っていなくても、ソフトウェアエンジニアから何とかリスクを聞き出す(引き出す)努力をすべきである。

そして、そのリスクが技術的な問題なら、その問題を解決できそうな技術者を組織の内部、外部から見つけ出してサジェスチョンしてもらえるような手配をすべきだ。組織内部に問題解決の知恵がないのなら、コンサルタントに相談するものいいだろう。

問題は、プロダクトマネージャや組織上位層が日頃ソフトウェアの問題解決に役立ちそうなコネクションを広げようという努力をしていない点にあると思う。

だから、ソフトウェア技術者から相談を受けても何も助け船を出してやることができないので、下には「相談しても無駄だ」と思われ、積極的にリスクを伝えておこうという気が起きないのだ。

悪循環から抜け出すには、まずはリスクを早め早めに表に出すという習慣をつける必要がありそうだ。
 

2007-05-07

スキルの伝承は8割以上の企業が不十分な状況

日経ものづくり 2007年4月号の “数字で見る現場” という連載で「スキルの伝承は8割以上の企業が不十分な状況」という記事があった。

Q1 【技術者が必要となる知識やノウハウ、技能などのスキルがベテランから若手へと十分に受け継がれているか】という問いに対して
  • 以前と比べて、急激に不十分な状況へと変化してきている(18.0%)
  • 状況は悪化(43.2%)
  • 以前も今も、十分に受け継がれていない(22.9%)
  • 一時期は不十分だったが、徐々に状況が好転してきている(7.8%)
  • 以前よりも十分に受け継がれるようになった(1.9%)
  • 以前と同様に十分に受け継がれている(2.8%)
  • 分からない(3.2%)
  • 無回答(0.2%)
といった回答になっている。日経ものづくりは、どちらかといえばメカ屋さんや製品開発を全体から見る技術者・管理者向けの雑誌で、ソフトウェアに特化しているわけではないが、スキルの伝承というテーマについては、メカもエレキもソフトもあんまり関係はなさそうだ。

例えば、Q2 【受け継ぐスキルは変わってきていると感じるか】という質問に対しては、受け継ぐスキルの幅が広がった上に、奥深くなっていると回答した人が 60.4% いる。

この数字は過去にこのブログで書いた「新人技術者へのハードルは確実に高くなっている」 の記事の主張を裏付けている。

また、 Q4 【契約社員や派遣社員などの割合が増加することで人材育成に対する考え方はどう変わるか】に対しては以下のような感じだ。
  • 短期的に効果が出るような育成に重視する(38.9%)
  • 長期的に雇用する可能性が低いため、積極的に育成できない(38.3%)
  • 正社員が現場から遠ざかってしまうので、それを補うための育成が正社員に必要となる(30.8%)
  • 契約社員、派遣社員、正社員で育成方法は変わらない(18.1%)
  • その他(5.0%)
  • 分からない(6.2%)
  • 無回答(0.9%)
2番目の「長期的に雇用する可能性が低いため、積極的に育成できない」はノウハウの組織外流出の悪循環を加速させる。

ついに来たプロジェクトマネジメントを外部発注する時代」の記事で取り上げた、日経ビジネス 2007年4月2日号の特集記事 “抜け殻”正社員-派遣・請負依存経営のツケ-がこの悪循環の結果だ。

正社員から非正社員への転換を進め、人件費圧縮に伴う相対的な利益増加のうまみがやめられなくなってしまい、ふと気がつくと長年伝承してきたスキルの多くが組織外へ流出してしまう。

受け継ぐスキルの幅が広がって奥深くなっているのに、長期的な教育ができず短期的に効果ができるような教育ばかりをあさっていると、表面的な技術やツールに頼りがちになり、腰の据わったスキルの伝承ができない。

Q5 「ベテラン社員や会社組織といった教える側の課題は何か」については
  • 教育に時間を割けない(68.4%)
  • 教える人材が不足している(62.4%)
  • 長期的な競争力の向上という視点がない(47%)
  • 積極的に自分のスキルを伝えようとしない(40.5%)
  • その他(6.4%)
  • 分からない(1.0%)
という状況だ。

Q6 【教わる側の課題は何か(複数回答)】については次のような結果
  • 自分自身で考え抜くことに慣れていない(69.3%)
  • 直近の業務を優先しすぎる(52.8%)
  • 新しいことを学ぼうという姿勢が足りない(49.6%)
  • 現時点の業務以外への興味が薄い(47.2%)
  • 工学的な基礎知識が不足している(44.1%)
  • 身につけたスキルが自分の財産になると考えていない(30.6)
  • 短期的な評価を気にしすぎる(29.2%)
  • その他(5.4%)
  • 分からない(1.1%)
ものづくりで競争に勝たなければいけないのなら「自分自身で考え抜くことに慣れていない」は致命的な欠陥だし、直近の業務を優先し、新しいことを学ぶ姿勢がなく、現時点の業務以外への興味が薄く、工学的な基礎知識が不足し、身につけたスキルが自分の財産になると考えていないとなると、もうとりつく島がない。

このような人たちを生み出してしまった原因はテストの点数で子供を評価するという学校教育システムのせいではないかと常々考えていた。

欧米では、モンテッソーリ教育を実践する「子どもの家」という教育施設がある。(日本にもそれなりにある

モンテッソーリ教育についてはいずれ詳しく書くとして、モンテッソーリ教育の基本的な考え方はこうだ。
  • 子どもは環境を征服しながら自立していく。(子どもはどのような環境をも征服する力を持っている)
  • すべての子どもが持つ「自己開発力」を信じて待つ。(焦らずに子ども自らの気づきを待つ)
  • 環境を作る教育を考える。(子育ては粘土をこねるのではなく、草花に水をあげるようなもの)
  • 子どもは動きながら学ぶ。(子どもが動きながら学べる環境を考える)
ここに一環して流れているのは「依存から自立への離陸を手助けしてあげよう!」という精神であり、具体的には
  1. 自己選択(作業する場を明確にし、環境を整える)
  2. 作業に関わる(提示は子どもが理解できる速度で)
  3. 集中現象-繰り返しの活動-(姿を隠す、じょまをしない、口出しをしない)
  4. 達成感・満足感(共感しともに楽しむ)
という4つのサイクルを回すことを提唱している。

このサイクルを回す中で、すべての場面で、謙虚に子どもを観察することが必要であるとモンテッソーリは主張している。

この考え方を一枚の絵にしたものがこちらにあるので参照していただきたい。また、このモンテッソーリ教育の考え方を組込みエンジニアに適用するときの絵として提案したものがこちらだ。

欧米では、子どもをモンテッソーリ教育を行う「子どもの家」に入れることがエリート教育であると考える親がたくさんいる。自立して自分でものごとを考え抜く子どもは組織の中でリーダになり組織を引っ張っていくことができると考えているからではないだろうか。

欧米では自立した子どもにすることがエリート教育で、日本では子どもを塾に通わせ知識を詰め込むことがエリート教育なのだろうか。

ちなみに、子どもの頃に、自分で選択し、集中し、達成感・満足感をたくさん得る経験をしたエンジニアは、自分自身で考え抜くことに慣れており、新しいことを学ぶことに喜びを感じ、工学的な基礎が問題の解決に結びつくということを肌で感じることができ、身につけたスキルが自分の財産になると考えるように思う。

では、大人になってしまったらもう遅いのかという疑問に対しては、「教材がいいと受講者の食いつきが違うね」を読んでいただきたい。上記の4つのサイクルを5日間で体験する研修もある。

最後に、日経ものづくりの記事に戻って、残りふたつの質問と多数回答を紹介したい。

Q7 【すでに自動化(ブラックボックス化)されたスキルを技術者自身も見つける必要もあると思いますか】
  • 全員が覚える必要はないが、一部の技術者は身につけて伝えていくべき(53.6%)
  • 自動化されてしまったスキルであっても、基本的にすべての技術者が身につけるべき(40.8%)
Q8 【臨機応変な対応力を身につけるには、理論的な知識と経験のどちらが重要だと思うか】
  • 理論的な知識と経験のどちらが欠けても、臨機応変な対応力は身に付かない(73.8%)
技術者教育を計画して実施しようとするとき、予算化する際に組織の中には必ず費用対効果のことを持ち出す人がいる。まあ、教育費用が一人あたり数十万円にもなる場合は「貴重な利益を効果が出るかどうか分からないものに使っていいのか?」「昔は技術は教わるものではなく、先輩から盗んでいた者だ」と言いたくもなるだろう。

そんな人には、この日経ものづくりの記事で具体的な数字で、製造業の人材育成の現状を解説してやって欲しいと思う。