タイトル:「行列のできる組み込みセミナー&ディスカッション
     〜最強のエンジニア&コンサルタント軍団〜 パネル編」
コーディネーター:杉浦 英樹(富士ゼロックス)
パネリスト:工藤 浩志(IBM)
      楠部 集(横河ディジタルコンピュータ)
      佐藤 啓太(デンソー)
      西 康晴(電気通信大学)
      橋本 隆成(SONY)

議論の内容:
S氏:本日はパネリストのIBMの方に来ていただいている。簡単に自己紹介をどうぞ

K氏:オートおよび携帯の方をやっている

司会:本題に入ります。たくさんの質問をいただいているので、それについて議論してい
く。まず、最初に、新人教育をどのようにやっていくか?について。福田さんからの質問「教える内容、時期は?」

N氏:本質的原因は大学。現状の大学:C言語、アルゴリズム、など教えている。一般的なことを教えていない。学生はできる気になっているだけ。たとえば、構造体を使えないのにC言語をマスターした気になっている。大学で全部教えてほしい。教育の側面で大事なこと:知識、モチベーション。

S氏:まず、やはり、何を学ばなくてはいけないのか。マーケット計画的なことでは、専門以外なところ、社会のニーズ。お手本になる人を早く見つけて、その人についていく。
視野を広げた内容を。専門知識を学ぶとともに、それ以外のまわりの教養も学ぶ。

D氏:計画的にやるべき。数年後にどういうふうにやりたいのか。コンセプトを作れる人が必要。それぞれ何人必要なのか?将来のことにたいして考える。新しく身につけないといけない。新人のうちに学ばせた人のほうが使いやすい。1からやるよりも、新人に
これからのことも教えないといけない。効率的に考えないといけない。センスがある人とない人では全然違う。たくさんはいらない。1人とか2人とかいればいい。選抜しないといけない。芽のある人を教育しないといけない。

観客1:入れるときに戦略にのっとった人をとればいいのでは?

D氏:そうですが。そういう人を見つけるのはなかなか難しい。

観客1:カテゴリは?

D氏:大きなカテゴリはある。よいモデルを書ける人は少ない。

観客1:伸びる人を選別できるのでは?

D氏:そうです。問題は時期です。

観客1:???

D氏:???

N氏:たとえば、ある一部の企業では学生の間テストに行ったり、共同研究をしたり、ソフトの品質に詳しい先生を紹介してもらうとか。よくないことですが。自頭のよさが重要。
テストをして論理能力を図るとか。

観客1:テストのやりかたは?

N氏:技術的にエキスパートな人がほしい。

S氏:では、現場での教え方は?

G氏:新人教育だと、絶対的な答えはない。やりかたはいろいろ。企業のビジネスのやりかた、時代背景とかも違う。人権費が沸騰。プログラミングなどはインドや中国など安い人を雇ったほうがいい。
技術の空洞化を考えるべき。学問として教えることは可能だが、本当に価値を理解することは難しい。最低減の基礎を学ぶべきなのか?

X氏:うちは放任教育。非常に珍しいですが。業務の多様性に対応できないから。集合教育は基礎的なとこに特化して、あとは、各事業体に任せる。会社の方向性を最初はしめさない。個別教育に関する懸念としては、楽な方向にいってしまう。現状として、どう新人のやる気を保たせ続けるか?


Y氏:人的ネットワークは早くから教えてほしい

S氏:観客の方も意見をどうそ

観客2:刺激を与えないと。日本のメーカ、大学の方もアメリカのように企業にいってから大学に行くような人に何らかの補助をしてあげるとか。

S氏:次の質問にいきます。
   木本さんからの質問:「会社では、デバッグを使用しない。使用すると生産性があがりますか?」

D氏:デバッグはテスト以前の問題。動かない問題をどう解決するのかという問題なので、
間違いなくお勧めできるかなと

観客3:デバッグを使わないとわからないようなバグを書くなと言われた。
だから、なるべくデバッグを使わなかった。ハードは別として。だから、この質問者の気持ちはよくわかる。

D氏:自分のプログラムだけの話だとそれでいい。が、周辺の環境がからんでくるとそうはいかない。バランスを考えないといけない。

観客3:デバッグを使うことを前提にするなとは言われる。

D氏:それは間違いないかと

N氏:自動的にテストケースをはいてくれるものがある。頼りきれないっていうのが重要。にっちもさっちもいかないやつがでてきているので、その辺は重要。

S氏:次の質問に行きます。
   分散オブジェクト指向として 何が必要か?

G氏:意図がよくわかりませんが、組み込み車を扱っていた時期があるのですが。今後も強調して動作させるとか。具体的にどうこうとういうのは、メーカによる。提案していただくのがいいのかなと。

S氏:次の質問に行きます。
   業務に追われ続け、改善にむかう時間がない。そういう人たちを救う手段?

Z氏:経営層 金額で示す必要がある。教科書道理にやってうまくいくものではない
最後の場面で結果を出すまで待っていると無理。動くのが早い。プロセス改善も金額に表すことが重要

G氏:異論はない。ビジネスは趣味ではない

K氏:2モデル→6モデル。いかに生産的にするか?危機意識を持っている。
今まで、市場に出せば売れる。しかし、今は違う。どうするか?

Y氏:自分たちのあいてる時間でやらないといけない。
改善がパターン化されているといい。その分下駄が履ける。コスト短縮できる。
小さなところにも芽をむける。

N氏:2つのパターンがある。今困っている場合と課題を達成する場いい。
今困ってないんだったらまだいいかなと。そうでないところは、改善に力を
どういうリスクが発生してきたのか?情報交換すればいい。困っている場合は、振り返り作業をする。みんなで確認しあう。立ち止まって振り返るのは大変重要

S氏:次の質問に行きます。大学でどこまで教えるべきか?

N氏:ある程度は可能。具体例としては、ライントレースができればいいかなと。ハードだけできてもソフトだけでもだめ。2人でハードとソフトに役割分担してやる場合には、お互いのことを考えないといけない。
カリキュラムを使う。日本はすごく遅れている。日本の大学では、ソフトウェア工学はせいぜい1から2単位程度。アメリカはたくさんある。
実践的な教育をするべき。

Y氏:もっと、マクロ的に教育を見せてほしい。いろんな広い世界を見せてほしい。
その後で、学生に進路を決めてほしい。全体を伝えてほしい。

観客4:インド、中国のことを考えたときに、プログラミングはそういった人を使えばいい。リーダーとしてまとめていく人がほしいはず。日本には、プログラマがやりたい人はほとんどいないはず

N氏:大学で教える教授の価値観によって学生のなりたいものが決まってしまう。
企業の人には、大学に教えに来てほしい。企業と人と学生が交流する場面をつくってほしい。学生は企業の人の話のほうに関心がもてるはず。実際に現場で働いているわけだから。

Y氏:学生は若いうちに、いろんなとこに武者修行に行ってほしい。
恥をかるのは今のうちだけ。年を取ると、恥をかけなくなる。知らないことを聞けなくなる。

観客5が自社の宣伝を行う。

S氏:次の質問に行きます。開発現場では。マネージャからの指示も少ない
新しいチャレンジを行うための動機付け、余裕のつくりかた。うまくいかない場合にはどうするか?

Y氏:オブジェクト指向だけあげてもだめ。
組み込み教育はアメリカが熱心。アメリカの大学は、この分野はどこと決まっている
日本だと偏差値で大学を決めてしまっている。大学教育と切らない。
アメリカの大学では、事前に課題がでて、授業はディスカッション形式。

K氏:いろんな考え方がある、自分にあったものを見つける必要がある
自分の武器になるようなものをみにつけることがまず大事。
なぜうまくいかないのか?を考える。なぜ?をつきつめ問題を共有することが大事。
自分が対処できる問題とできない問題を分ける必要がある。
できない問題は上にやる。根本原因をシェアすることが大事。
うまくできないものをうまく回避することが大事。

観客6:自分たちがどれくらいできないのかを把握する。

N氏:手戻りはどのくらいあるのか?(会場の人に挙手によるアンケートを実施)
組み込み業界では、4から5割が多い。見栄を張って、3〜4割という人が多いが。
このプロジェクトマネージャーは無能。同じ製品を同じように作ってはだめ。同じ製品は売れない。コストダウンなど改善をしていかないといけない。
工夫するということ自体を評価基準にするなどして、やる気を持たせる。
お金であがるモチベーションは長続きしない。直接ほめてやることなどが重要。

質問者:現場から上に声が聞こえてこない。現場で働いていたときには、楽にする方法を考えていた。で、立場が変わっときに、現場の人にどう言えばいいのか?が悩み。モチベーションをあげさせるためにはどうすれば?

S氏:先頭するキーマンが必要。ちょっと変わったことをやっているような人が必要。刺激になるような人をマーク。その人の動向を見てみる。

観客7:5から10年の教育でぜんぜん違う。その間にどう教育するか?が重要

S氏:キーワードは教育

N氏:企業の責任。現場の人はきっちり声をあげることが重要。難しい場合は外部の力を借りる。たとえば、今回のSWESTなどの場で出版社を使う。出版社に記事にしてもらう。
そうすれば、上も考える。

S氏:次の質問にいきます。モデルの最適化、検証に向いているモデルの作成をしたい

Y氏:分析レベルの段階で。それ以外はUMLを使って。
サンプルをとらないでできるツールはある

N氏:ツール屋さんは付属の機能の説明はしても、この機能がないとは言わない。
ちゃんと状況を聞いてくれる人なのか?開発に親身になってくれるツール屋を選ぶ。

S氏:ツール自体の特性がある。自分たちの設計にあったツールがあるのかどうか?
まず、目的をはっきりさせる。その後で、当てはまるツールを探す。

観客8:では、課題解決のときのツールの選び方は?

Y氏:ツールには作業の手順がある。人件費の問題もある
ツールをやってるかやってないかで格付けをする。

N氏:ツールは縁みたいなもの。相性のいいっていうのがある。信頼できる人を探すことが大事。

S氏:時間がきてしまったので、この辺で終わります。ほかにも質問がありましたが、全体の数からして、多くの質問について議論できたと思います。