2009年2月27日

【林衛の業界探求シリーズ（７）】第二回　つらい失敗を糧に技術者は育つ

製品開発志望だったが、システム作りが面白くなる

林
今井さんがデンソーを就職先に選んだのは、どういう理由ですか。

今井
出身が名古屋だったものですから、名古屋に戻ろうかというのが一つありました。

林
それはとても自然な流れですね。

今井
ええ、親もそれを希望していましたしね。専攻が電子工学だったので、電気・電子が生かせる会社に行こうと思っていたのです。トヨタさんは名古屋ですが、機械屋さんの会社だと思いました。

林
そうですね。どちらかと言えば。

今井
電気系の会社は何があるかなと思ったら、デンソーがあったわけです。当時はあまり深く考えてなかったのです。学校の中で募集があったので、先生といろいろ相談したら、「デンソーがあるぞ」と言われ、「じゃあそこを受けてみよう」と、それで入社しました。ですから、就職活動を始めて、「あ、こういう会社があるのか」と（笑）。

林
今や、知らない人はいないですが（笑）。

今井
当時は全く知名度がなかったです。

林
企業規模もだいぶ違うのではないですか。

今井
ええ、それでも私が入ったときには、部品メーカーとしてある程度の位置づけにいました。ただ、知名度という点では、最終ユーザを直接相手にしている会社ではないので、一般の人にはあまり知られていない会社だったのです。

林
そうですね。プロ向けの会社ですね。

今井
当時一般にも知られていたのは、デンソープラグぐらいですね。私も就職するときに、ある東京の同窓生に「なんだ、プラグの会社に行くのか」と言われたくらいです。就職はきちんと自分で考えて選んだというよりは、成り行き的なところが多かったです。

林
でも、熟考して入っても、いきなり意図とは違う配属が決まって、自分で運命を制御はできないところが、特に新入社員のうちにはありますよね。

今井
父親の技術屋として生きてきた姿を見て、「技術屋として生きられる会社ならいいかな」と製造業を選びましたが、「自分の好きな分野で活躍できる場さえあれば、将来いろいろ希望が持てるだろう」と、その辺にはあまりこだわってはいなかったです。

林
IT部門に最初配属になってからは、いかがでしたか。

今井
正直、とまどいました。最初に配属されたのは、当時コンピュータ部と言っていた中の技術システム課で、当時からシミュレーションとかNCデータ作成などのシステムがありました。

林
どちらかというと、エンジニアリング系ですね。

今井
ええ、そうです。いろいろな技術系のシステム開発をやっていて、ICのマスクパターンを設計するシステムや、強度解析などが始まっていました。私はミニコンなら触ったことがありましたが、本格的にIBMマシンで技術計算をやったことはなかったので、そういう意味では面白いと思ったのです。でも製品開発をやりたいという気持ちはずっと消えませんでした。

林
なるほど、頭の中に常にあったのですね。

今井
ええ、ありました。製品開発ができないので、最初はとまどったのですが、実際にコンピュータを扱っていろいろな仕組みを開発しているときには、やはり創造性が発揮されますよね。結果は目に見えて出てくるので、途中からは、「あ、面白いな」と思いました。しかも新しいことにチャレンジさせてくれるし、勉強させてくれる。会社自体も「チャレンジしなさい、研究しなさい」という精神の、技術屋の会社でしたし、とくに私の配属されたところがそういう雰囲気でした。ですからシステムをどんどん作っていくうえで、知識獲得のチャンスはたくさんありました。それは非常に面白かったですね。

独力でのアルゴリズム開発と発表

林
そのエンジニアリング系の仕事の中で、印象的なものは何かおありですか。

今井
デンソーは当時すでに自動車用LSIを作っていました。最初に担当したのが、LSIのマスクパターン、つまり半導体トランジスタを配置配線し回路を組むシステム、即ち自動配置配線システムを開発したのです。アルゴリズムの開発からすべて一人でやりました。当時主流だったアルゴリズムでは、配線がギザギザになるので面白くなかった。人間が配線するときには、あまり折れ曲がらないのです。一本で、スッと線を引く。そういうロジックはないかと、自分なりに考え、線分探索アルゴリズムを開発しました。

林
一種の最適化問題ということですか。

今井
そうですね。一番短距離で折れ曲がりの少ないケースを選ぶということで、数学的アルゴリズムよりもパターン認識に近く「どこが空いているか」を探していくような方式でした。

林
ああ、なるほど。

今井
「どこが空いているか」「こういうケースはこれが一番いい」と判断していくアルゴリズムでＬＳＩのマスクパターンを自動設計できるようにしました。
技術研究や開発したものを、研究成果としてまとめて発表する仕組みがあったので、アルゴリズムの研究で応募しました。実際にはプレゼンテーション結果で優秀な研究が選ばれます。でもアルゴリズムは、やはり難しいじゃないですか。

林
ほんとうにそうです。

今井
良さが分かってもらわないと審査に通らないので、発表する資料を作っていろいろ先輩に見てもらうのですが、なかなか分からないのです。うちの女房に話して分かってもらえば、絶対だれにでも分かるだろうと思って、研究発表のネタを家で練習する傍ら、女房に聞かせていろいろ工夫しました。そうしたら女房は「分からないけども、中抜きアルゴリズムだけは、何かすごいことを開発したのだなと、印象に残った」というのです。

林
キーワード戦略ですね（笑）。

今井
そう。そのキーワードが頭に残って、「あ、何かすごいのをつくって、何か結果が出たのだな」と感じたというので、やったことが何なのかという本質的なことは分からないにしても、そのプロセスや、できた成果、苦労したところは何か感じてもらえるなと思いました。「女房に分かるのだったら、会社でも分かるだろう」（笑）と。

林
奥さまは相当、そのプレゼンテーションに貢献されていますね。

今井
そうですね。われわれのやっているITについて、よくトップからも「君たちは何を言っているのかさっぱり分からない」「分かるように説明していないのじゃないか」と言われます。われわれも一生懸命に分かりやすく説明しているつもりでも、それでもまだギャップがあります。ITの分からない人にもうまく説明できる力が、特にこれからITをやる人に求められます。そういう資質がないと駄目なのだろうと思います。

林
そういう視点で言えば、中抜きアルゴリズムの発表は相当効果があったのではないですか。

今井
「分かってもらえない限りは評価されない」というのは、そのとき実感しました。

林
お一人でアルゴリズムをつくって、プログラミングをして、実装まで全部やるわけですね。

今井
ええ、全部やりました。

林
そういう場合には、先輩とのやり取りはないのですか。

今井
なかったです。教えられる先輩がいないので。

林
全くの独力ですね。

今井
文献や他社でどんなことをやっているかは調査しましたが、基本的に先輩がいて教えてくれるわけではなく、自分でいろいろアイデアを出しながらプログラムをつくって試してみました。そういう時間的余裕を与えてくれたのは、当時の会社の置かれた環境でこそできたことだと思います。今はなかなか、できるかどうか分からないような開発はやれないですね。

林
やれませんね。今では開発にかなりのスピードを求められてしまいますから。

今井
ええ。そういう意味では、私が会社に入ったころはそういうことをやらせていただけたので、研究に対する意欲やチャレンジ精神が大いに養えたと思います。今はそういうふうにはなかなかいかなくて、直ぐに成果を出していくことが求められる。そのあたりを、どうマネジメントしていくかが問われているのかもしれません。

失敗の辛さが工夫につながる

林
今井さんは、IT部門でのエンジニアリング系の仕事は長いのですか。

今井
長いです。2001年まではずっとエンジニアリング系です。

林
徐々に全体の責任を持たれるようなかたちになっていきますよね。私も、今でもエンジニアの端くれのつもりですけど、エンジニアの時代は、仕事としてはわりと大きなものでも、基本的には自分の考えで全部やります。せいぜい小チームです。しかし、今見られている範囲ではそうは行きません。30人、50人いるととんでもないことが起こるし、エンジニアの理屈を超えたマネジメント力が必要になります。エンジニアリング系の仕組みもネットワークでつなげてチームでやらないといけませんし、事務系は特に、いろいろなことが起こる。今井さんはそれをどのように理解し、消化していったのでしょうか。

今井
個人で自動配置配線などをやっていたのは3年ぐらいで、それからチームでCAD開発をやりました。その当時でうちから6人ぐらい、ベンダーさんと共同でやったので全体では10名ぐらいの規模でスタートしました。

林
ちょうどいいサイズですね。

今井
ある程度CADのベースができると、今度はアプリケーション開発をするのに、今で言うビジネスパートナーさんを入れて、もっと大きなチームになっていきました。そういう意味では、大きなシステムを最初からチームを組んでやった経験があります。その中では、やはり失敗もしましたよ。

林
それは、後進のためにぜひ聞かせてください。

今井
いくつか失敗しましたし、大きなトラブルも経験しました。でも、自分で意図せずそういう場面に置かれたときこそ、成長するよい機会です。私は、その最大のものは失敗だと思うのです。失敗しようと思ってやってはいませんから、自分では予想してなかった失敗という事態が起きたとき、勉強になるし経験にもなります。
一度はデータベースが壊れてしまって、修復できないこともありました。そういうときは、もう真っ青ですよ。

林
頭の中が真っ白になりますね。

今井
それでもなんとか先輩の力を借りて、95点くらいまで回復して、あとの5点分はユーザの人に「申し訳ない」と言ってもう一度入れ直してもらいました。
そのときに思ったのは、いかに頑丈なデータベースにするかということです。それは今も自社CADのシステムに反映されています。絶対に壊れないデータベース、あるいは壊れても、壊れた直前まで回復できるようなデータベースのための仕掛けをいろいろ作りました。

林
トレースしたりミラーリング、多重化したり。

今井
ええ。自分でログを取りながら。ログも必ず違うディスクに置くとか。そのためにはバックアップをとらなくてはいけない。CADはオンラインなので、オンラインでもバックアップをとれるシステムとか、いろいろ工夫しました。
そのときの経験が糧になって、「もう二度とあんな目には遭いたくない」「後輩にあんなつらい思いはさせたくない」と必死になってアイデアを出して、頑丈な絶対壊れないデータベースというのを設計しました。おかげで、20何年経っても、いまだにCADのデータベースは何百万という図面を抱えながら動いています。

林
そのつらい経験をしたおかげですね。

今井
それから、日本で開発したシステムを海外に持っていって、動くはずのシステムが動かなかったこともあります。日本で同じマシンを使ってテストして行ったのに、動かなかった。そのときも真っ青だったです。快活でよくしゃべるベンダーのSEさんと一緒でしたが、二人でホテルへ帰って来るまで一言もしゃべらない。「おやすみなさい」もなく二人でそのままそれぞれの部屋に入って、朝起きて「おはようございます」もない（笑）。
日本に調査を頼んでおいたので、翌日わかったのですが、機械は同じだが、マイクロプログラムのパッチがちょっとだけ違っていたのです。それが原因でシステムが動かなかった。それは確認したはずなのですが、サフィックスまではきちんと確認されてなくて、よく見るとサフィックスが1桁余分についていて、そのバージョンだと動かないのですよ。

林
でも、「まさか、そこではないよな」と思っていますよね。

今井
ええ。だから「海外まで来て、何にも仕事しないで帰らなきゃいけないのかな」とすごく不安でした。
そういうことがあったので、海外の仕組みをインストールするときには、いろいろなことをチェック項目として注意するようになりました。そういう痛い目にあうと、「そういうことにならないようにするためには、何をすればいいか」を考えます。それがノウハウになって積み重なっていき、後輩がうまくやれるようになるのだと思います。ですから、そういう絶体絶命の失敗経験は、次の仕事への糧になりますね。

林
動かないと、どうしようもないです。私も全く同じ経験をしています。
あるお客さんのシステムを香港に入れることになったのです。それは自分が担当になったときに、たとえ動いても、ちゃんとしたロジックで組まれていない部分を全部消してつくり直し、徹底的にテストして持って行ったものでした。そのときはパッチの問題ではなく、データベースの書き始まりの位置でした。

今井
ああ、ポジションが違うのですね。

林
そうです。問題は、セクターのポジションが違うことでした。どこから見ても完璧なのに、全く動かない。真っ青ですよね。動かさないと帰れないですから。実際、帰れなくなりました。

今井
ええ（笑）。

林
自信満々で「サッと導入の仕事を済ませ、中華料理でも食べさせてもらって帰ろう」（笑）くらいの感じで行ったのに、それが動かない。2日くらいあれこれやってみて、もう1回データベースを落とし直してみたのです。アプリケーションも全部。そうしたら何の問題もなく動く。悲しかったですね。
パソコンで動かなかったときOSを1回入れ直すのと似たようなものですが、まず思いつかないですよ。

今井
私のときも、絶対に間違いないと言って持って行ったシステムが動かなかったのは同じです。

林
泣けてきますよ。技術力で解決できないですから。もうちょっと、変な画面が出てくるとかであれば対応できるのですが。たぶん今井さんのケースも、手の打ちようがなかったはずです。そういう場合は、当たり前と思っているところを疑わないといけないですね。

今井
そう、ちょっとしたことなのですよね。

林
あとで分かると、がっかりします。

今井
あのときは悲惨だったですね。そういう経験は部下にあまりさせたくないですが、私の経験からいうと、それを経験したことは自分の糧になったと思います。だからあまり会社に迷惑がかからない範囲で“酸っぱい”経験をしてもらう。ヒヤリ・ハットでも、そういう経験があるのは、すごく糧になるのではないでしょうか。

林
そうですね。それは計画できない経験ですが、たくさん仕事をやっていくと、絶対あります。
わたしが少し懸念しているのは、ユーザさん、発注側の方は責任感が強いし、そういうときに真っ青になりやすいと思うのです。でも、昔はもっとベンダー側にも、そういうことに対して責任感が強い人が多かったような気がします。

今井
確かに、そういう部分が希薄になってきていますね。

林
世相が変わってきたのか、「いや、私関係ありませんから」みたいな態度の人もいます。

今井
だから一層、失敗経験は大事です。

林
体験談で若い層の人たちにも伝えていくことで、その中でエッセンスを拾ってくれる人も増えると思います。

今井
体験談もリアリティーと臨場感のある話でないと、なかなか感じてもらえないです。でも、一番のいいのは自分で経験することですよね。真っ青になるぐらいの経験は、やはり財産ですから、いくつか持ってないとね。そうしないと、技術者は強くならないですよ。

林
私はゴルフの神様がいて、「このままうまくいく」と思っているとOBにさせたりする経験をしていますが（笑）、ITにもやっぱり神様がいて、いい人にはちゃんとそういう経験させるのです。ITの神様もその人を育てようとするときにこそ、システムを動かなくしてくれたりするのではないでしょうか。

（次回に続く）

構成：萩谷美也子

| トラックバック[0件]