KK's Room

    私の、仕事・趣味・興味・思考を記録しておく場所にしています。2010年2月27日から開設しました。初回だけ、「0:初めまして」シリーズをお読いただけるとありがたいです。

    カレンダー
    10 | 2017/11 | 12
    - - - 1 2 3 4
    5 6 7 8 9 10 11
    12 13 14 15 16 17 18
    19 20 21 22 23 24 25
    26 27 28 29 30 - -
    最新記事
    カテゴリ
    キーワード
    月別アーカイブ
    全記事表示リンク

    スポンサーサイト

    --.--.--

    category : スポンサー広告

    上記の広告は1ヶ月以上更新のないブログに表示されています。
    新しい記事を書く事で広告が消せます。

    自動化する/しないの線引きが大切

    2010.03.16

    category : 2.1 シミュレーションと最適化

    自動化という言葉もまた、よく使われる一方で解釈の広い使いにくい言葉だ。ここまでは自動化するけどこれ以降はしない/できないという境界線を明確に共有してしまえばいいのだが、得てしてこの境界線が曖昧だったり、共有しないままで話をしてしまうから、問題が起こる。”最適化”という言葉と同様、安易に使うとやけどしかねない危険語。

    自動化には、まず良悪両方の意味があることが問題。人間を楽にしてくれる、といういい意味もあるが、意図せず、勝手にやってしまうという悪いニュアンスもあるわけだ。両方の意味がある理由は、境界線が曖昧なまま自動化を行ったことから来る経験が生んだものだろう。たとえば、ロボットが登場し始めたころの一番の危惧は、自動化が行き過ぎて暴走するのではないか、ということであったりした。

    ソフトウエア・ロボットの概念での自動化には、明確な線引きがある。”コンピュータの操作作業を自動化する”ということだ。作業だから、人間が行う必要は全くない。ここまでは、誰でも納得するだろう。

    次に、シミュレーションの実行作業を自動で行った結果として、最適解探索したのちの設計パラメータや出力も”自動的に”出力される。大量の生データとともに、条件を満たした満足解や、一番よさそうな最適解も出力される。

    しっかりと分析できるデータを短時間で得られるわけだ。本来、この結果を、分析・検討するのは、人間である設計者の仕事であるはずなのだが、それを行わず出てくる結果を、”何も検討せず自動的に”使ってしまう利用者が、まま出てくる危惧も指摘されてきた。

    問題なのは、その危惧を”自動化”のせいにし、さらに自動化を行うソフトウエアを使うと設計者の質が落ちるという、ネガティブ論に発展させてしまう人が、少なからずいることである。これは、明らかに問題把握の誤りである。

    自動化ということを正しく常識的に理解して、使い方と教育しだいだということがわかれば、むしろ、何十倍の効果を発揮するのである。間違った理解でせっかくの道具のよさを生かせないのは、つくづくもったいないと思う。

    さもわかったような口ぶりで、「自動化が悪い”」という人は、同時に、「設計者は考えるのが仕事だ」と、当たり前のことを言う。まさに、考える時間をたっぷり与えるために、”無駄な作業を自動化”してくれる道具だというのに、「その本質を理解しない、あなたの頭の方が悪いのでは?」とブログだから、少々きつい言葉で言わせてください。

    今の言葉、今まで当人たちの前では言えなかったから、あーすっきりした!

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                              今日の1枚 、じゃなくて、2枚

    2010/3/16
    昨年はじめてインドに、バンガロール。富豪と貧困、最新建築とゴミが雑然と同居していながら、不思議な魅力。もう一度行きたい。カメラを向けたら、集まってきた無邪気たっぷりの男の子たちと、素直にポーズを取ってくれたかわいいこの姉妹がとても印象に残っている。
    - Lumix LX3 -
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    人-1-2010.3.16:P_LX3_1040493 

    人-2-2010.3.16:P_LX3_1040579 

     

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                              今日の1曲
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    キャノンボール・アダレイ・クインテット・イン・シカゴキャノンボール・アダレイ・クインテット・イン・シカゴ
    (2003/04/23)
    キャノンボール・アダレイ

    商品詳細を見る
    [Stars Fell On Alabama]
    実は、Cannonball Adderley & John Coltraneとなっていて、Coltraneを聞くにもいいのだけれど、やはり、このアルバムは、Cannonball。特に、日本語曲名「アラバマに星落ちて」のCannonball(アルトサックス)とWinton Kelly(ピアノ)のアドリブは、ジャズを聞いたことのない人でもたぶんすーっと入ってくるぐらい、メロディック。まるで楽譜があるんではないかと思うほど。こんなに心地よいアドリブはめったにない。ジャケットも、遊び心があってとても気に入っている。


    スポンサーサイト

    tags : 自動化 シミュレーション LX3 

    comment(0)  trackback(0)

    Software Robotでコンピュータ作業を自動化

    2010.03.09

    category : 2.1 シミュレーションと最適化

    3/3の記事で、Software Robotという概念に基づいて、GEにて革新的なツールが開発された逸話を紹介した。この技術で何が新たに実現されて、何が変わったのだろうか。

     

    実現されたことは、設計者の業務時間の大半を占めていたコンピュータ上での対話型作業の大半が自動化ということだ。たったそれだけのことで、実は、下記に示すように設計業務が根本的に変わることが分かる。

     

    1)作業時間の激減(1/5-1/20)と人為ミスゼロ
    2)思考と判断という業務へ集中できる
    3)人の経験や技術に依存しない
    4) より多くの設計方案を効率よく検討できる

     

    まず、1)は定量的な成果として、上司や経営層にもわかりやすい。時間激減効果は、このツールを使えばだれでもすぐに実証できる。人為ミスゼロの波及効果は広い。なぜなら、人間が行う作業には人為ミスが潜在的につきものであるから、ミスがないかをチェックする人や作業が発生する。自動化すれば、それらの作業は一切不要になる。

     

    最も重要なのは、2)だ。マニュアル作業で行っているときは、作業の方に忙殺され、別の案を考えるのは、作業の合間に行うといった方がいいだろう。ところが手順を自動化してしまえば、本来設計者が行うべき業務である思考と判断に集中した時間が確保できる。1)のように定量的には見えないが、確実に業務レベルが向上するもっとも重要な効果だ。

     

    3)は、作業手順を標準化できると言い換えた方が分かりやすいだろう。熟練者しかできなかった複雑な手順も標準化されてしまえば、経験の浅い人でも作業が可能になる。熟練者は、煩わしい作業から解放され、さらに高度な業務に従事できる。組織能力が向上するということである。

     

    4)の意味するところは、コンピュータ上でパラメータを変えて繰返しシミュレーションを行うことができるので、手作業で例えば2日で10ケースしか検討できなかたものが、同じ2日で数百~数千ケースの組み合わせのパラメータスタディを極めて効率的に行うことができる、ということである。これだけ増えるならば、量が変じて質の転換となる。このポイントは、別の大きなテーマになる。

     

    繰り返すが、作業を標準化し、手順を自動してコンピュータで行わせるというだけで、これだけの効果が出るのだ。このことは、もっと世の中に知られていいことだ。単純な原理こそが、世の中を大きく変える。Dr. Siu Tongは、Software Robotの概念を想起した時、産業革命を思い出しながらこれらのことを一瞬で見抜いたのであろう。GEは、1980年代にすでにその恩恵をたっぷり受けていた。

     

    しかし、日本はソフトウエアの産業革命ともいえる、この技術の恩恵を十分に受けているとはいえない。産業革命前のままである。往々にして、手順を自動化する効果というと、1)の定量的な直接効果だけに着目しがちだが、それだけでは本質を見ていないことになる。2)から4)までの効果も十分に理解してきっちりと抑える必要がある。

     

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                 今日の1枚
    2010/3/9
    横浜にしばし出かける。いい被写体が至る所にあるので。でも気に入った写真は、たいてい偶然の出会いの時に撮れてしまう。実は、偶然をおびき寄せるために出かけるのだ、ということに気付いた。  -  Lumix FZ20 -
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     

    街-1-2010.3.9:P1070109_edited 

    tags : シミュレーション 最適化 つなぐ技術 FZ20 

    comment(0)  trackback(0)

    サンプリングから学ぶ=攻撃の要は偵察にあり

    2010.03.07

    category : 2.1 シミュレーションと最適化

    「最適設計支援ソフト」という標語でソフトウエアを紹介し始めて、すぐに気付いたのは、聞く人に二つのタイプがあるということだ。

    一つは、最適化アルゴリズムを自分で書いたり、試したりしたことのある人で、たいがいはあまりいい経験をしていない。したがって反応は、そんなに簡単に最適解は探せない、初期値によって最適解が異なる、計算回数が増えて困る、などそれぞれの意見はある意味で正しいのだが、それを回避する対策や別の方法を持たないために、最適化探索とはこういうものだという、固定観念を持ってしまっていることが多かった。

    最適化技術に関する初心者に共通するもうひとつのタイプは、いままでの設計よりもいい解が必ず見つかるのか、最適解ということを保証してくれないと困る、これまでと同じ解しか出なかったら意味がない、など。これらの意見は、最適化に対する過度な期待から、“最適解”自体にのみ注目していることから来る、偏った見方である。

    この見方は、結果ではなく探索プロセスに主眼を置くことを説明すると修正できる。すなわち、いきなり最適解の探索を実施するのではなく、実験計画法などのようなサンプリング手法を適用して、設計空間を分析して、理解するというステップを踏めばよい。

    次のステップとして最適解の探索を行うことで、その解の意味、位置づけ、最適である理由、代替案なども把握できるのである。過去に最適化にいい経験をしていない人たちの大半は、はやり、サンプリングのステップを経ていない場合が多かった。

    これは特別に習得しなければならないノウハウというほどのものではなく、自分が解探索をするとしたら何をしないといけないかを、素直に考えることで自然と出てくる手順である。例えば、熟練設計者は過去の設計経験から十分なサンプリングを(それと知らず)行っていて、それを踏まえて新たな問題に対する最適解を”勘と経験“で導いているわけである。

    シミュレーションで設計し最適解を探索するということになったとたんに、サンプリングのプロセスを省略してしまい、答えがストンと出て来ると思いこんでしまうのが間違いのもとなのだ。前に「最適解は失敗の学習結果」で書いたように、失敗(サンプリング)をせずに、成功(最適解)を得ることはあり得ないし、得たとしてもどうして最適なのか理解できない。

    こういうことは、教科書には書いていないが、実務上はものすごく重要な手順なのである。アルゴリズムは学ばなくてもいいが、こういう手順は体にしみこませておく必要がある。新しいツールが登場しても、変えるべき部分とやり方を変えてはいけない部分は必ずある。ツールをうまく使いこなせるかどうかの条件の一つであろう。お客様に説明するとき、必ずこの点を徹底的に説明する。「アルゴリズムを学ぶのは難しいかもしれないが、手順を理解するのは常識で十分。」

    唐突かもしれないが、軍隊でいう偵察行動は、サンプリング的なアクションだ。偵察(サンプリング)なしに、いきなり攻撃(最適化)しないのと同じである。攻撃の確度を高めたいと思ったら、理屈ではなく本能として事前偵察を徹底的にすべしなのである。

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                 今日の1枚
    無性にシャッターを押したくなり、ユリを撮っていたら、ユリが鏡を覗いているような気配がしてきた。
    @自宅 - Lumix FZ30 -
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    花-2-2010.3.7:p_fz30_1010298bw_edited 

    tags : シミュレーション FZ30 最適化 

    comment(0)  trackback(0)

    便利だが誤解を招く言葉「最適化」

    2010.03.06

    category : 2.1 シミュレーションと最適化

    「最適化」という言葉は分野を問わずよく使われるので、あたかも世の中の人々が同じ意味を共有しているかの錯覚に陥る。この機能は「最適化」されています、と言われればなんだか、分かったような気になって安心してしまうとことがあるが、実はたいへん危ない曖昧言葉であるのだ。例を挙げよう。

    部屋は最適な温度に保たれています。=>誰にとっての?お風呂の前と後では?

    最適な製品を選ぶ=>値段?性能?スタイル?

    最適な環境のマンション=>騒音?広さ?駅からの時間?

    なぜ曖昧か、理由はもう明らかだ。
    “最も適する“の適するというのは、条件が定義されて初めて成り立つことばである。条件が明確に共有されている場合は誤解なく使えるが、条件の解釈が人によって異なったり、定義なしで使うのは大きな誤解のもとになる。

    “最適解”は、目的関数を与えられた条件のもとで最大化あるいは最小化する設計変数の組み合わせを表す数学用語である。したがって、条件が変わると、最適解も変わるのは当然である。また、最大と最小の両方の意味を含ませても使っている。

    なぜ私が、最適化という言葉に敏感になったか、一つの経験をお伝えしたい。あるセミナーでタグチメソッドに詳しい方と話をしていて、最適化は重要だという話になり、当然うなずいて会話をしていたわけであるが、途中からどうも話が噛み合わないことに気がついた。その当時の私が解釈していた最適化は“性能指標の最大化もしくは最小化”を意味していた。

    一方、タグチメソッドの二段階設計の最初の手順として示される最適化は、“性能が安定(ロバスト)であること”なのであった。こちらの意味を私は、ロバスト性という別の言葉で表現していたので、まさか、“最適化”が、ロバストの意味で使われているとは思いもよらなかったのである。

    (かつ、混乱に輪をかけたのは、私が意図していた“性能指標の最大化もしくは最小化”は、二段階設計の②段階目の、チューニングという手順なのであった。二つの日本語が相互に、別の意味で使われていた会話がいかに混乱していたか想像してみて欲しい。)

    “性能が安定であること”が、最も適していると考えるのはそれはそれとして納得できる定義なのである。一方、私の定義する最適化もまた、いいのだ。悪いことにたまたま同じ言葉を使って違う内容を表現していたということである。左様に、最適化という言葉は、人によって解釈によって異なるということが身に沁みたのであった。

    私は、最適という言葉を目にすると、「自分で選べる余地が十分にある解集合」と自動的に解釈する癖がついた。要は、 “適する条件”が変わったときに答えが用意されているのが最適ということなので。

    ちなみに、中国では、最適化ではなく“優化”という言葉を使うそうだ。最適化ほど意味が解釈依存ではなく、最大/最小ほど強くなく、程よく表現しているいい言葉だと思うのだが、残念なことに日本語に劣化をいう言葉があるのに、“優化”がないのは不思議。“優化設計のすすめ”をいう見出しでプロモーションをしたことがあったが、広めることができなかったのが心残り。


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                 今日の1枚
    三寒四温の時期に降る雨は特に冷たく感じられる。雨にぬれた梅を撮るのは寒いが、撮影中の一時はそれを忘れて夢中になる。
    @日向薬師 - Nikon D70 -
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



    花-1-2010.3.6:d70_04774_edited

    tags : シミュレーション ロバスト性 D70 最適化 

    comment(2)  trackback(0)

    最適解は失敗の学習結果

    2010.03.05

    category : 2.1 シミュレーションと最適化

    「最適解」というとどこかにすでに存在していて、それを見つければいいというイメージがないだろうか。理論解がある場合にはそれで正しいが、ほとんどの世の中の問題に理論解はないので、たいがいは、探索していく方法が必要になる。

    これを人がやると試行錯誤やモグラ叩きとも言われる泥臭い探索方法になり、甚だ効率がわるい。その探索をソフトウエア・アルゴリズムで自動的に行うのが、最適化アルゴリズムである。世の中には数多くのアルゴリズム(手法)があるが、他の解と比べて今回の解はよいのか悪いのかという比較をして、その時点の一番いい解を最適解としている基本原理は同じである。

    平たく言えば、悪い解(失敗)とより良い解(成功)の繰返しを数値的に行っているわけなので、失敗の学習をした結果として最適解を探索したのだという見方ができる。言うまでもないが、人間世界であっても、経験のない設計者がいきなり優れた製品を設計することはできない(理論解はない)ように、優秀な設計者とは失敗の経験から学んでよい設計のコツを知っている人なわけである。

    「失敗を学ぶことから、成功集合を抽出するのが、最適化である」を、さらに言い換えると、最終的に選択する最適解(成功)が1つであったとしても、その裏(過去)には数百回あるいは数千回の最適ではない解(失敗)があって初めて、最適解(成功)を選択できる、ということ。失敗を学ぶ方法を確立すれば、成功に導く方法が分かるという当たり前の方法論は、最適解探索の原理でもあるわけなのだ。

    また、条件が変わると、今の最適解は別の解が最適解となり、失敗だと思われていた解が新たな最適解になりうる。すなわち、失敗データベースというのは、過去の無価値遺産ではなく、“成功例を導くための膨大な知的資産”であるということができる。

    最適解を探索するのに、数千回も計算して、最後に一つしか選ばないのは膨大な無駄ではないかという疑問もいただくが、実は、数千回の失敗から学んだ結果としての最適解の価値に着目すべきである。繰り返すが、探索の条件を変えれば、残りの数千個のどれが新たな最適解になるかわからないのだから。

    この見方を敷衍すると、単純な探索のためだけではなく、ある種の分析を施すことによって、Best Practice Rule(熟練者のノウハウ)を定量的に抽出することが可能になると期待できるのである。「失敗に学ぶ」というと、二度と失敗をしないための対策を立てるためという後ろ向きのニュアンスが強いが、言い換えて「成功ノウハウがわかる=ベスト・ソリューションを導く」という前向きな意味で使われていいのである。

    この意味で、昨今Simulation Data Managementという技術分野に注目が集まりつつあるが、まだまだその戦略的な威力が十分に理解されているとはいえないし、関連要素技術もこれからの発展を待たなければならない。このテーマについては、仕事としてもライフワーク的にも興味を持っているので、さらに掘り下げて書く機会を持とう。


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                
                                 今日の1枚
    気持ちのいい青。海岸で、コントラストを引き出せる被写体を探していたら、思わず目の前に。

    唯一の所有ライカ。40mmという焦点が気に入っている。コンパクトカメラとしての大きさもちょうどよい。
    @大磯 - Leica CM -
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    海-1-2010.3.5:CM-01-35_edited 


    tags : シミュレーション 失敗 Leica 最適化 

    comment(0)  trackback(0)

    人生を変えた言葉「設計とは最適化」

    2010.03.04

    category : 2.1 シミュレーションと最適化

    スーパーコンピュータ会社に勤務していた頃、社長と元N自動車専務のM氏との会食の場に同席する機会があった。当時私は、N自動車担当のSEというだけで現場代表的に末席にいただけであるが、その場の誰かが、話題が途切れたところで”設計とは何ですか?”という恐ろしい質問をしたのをはっきりと覚えている。

    M氏といえば自動車業界で尊敬を集めておられる自動車設計の第一人者の方であったから、M氏の専門的な回答へ対等にフォローする会話を誰もできるはずもなく、後先かんがえないその不用意な質問に、全員の食事の手が止まってしまった。(人は都合のいいことを忘れるから、もしかするとその質問をしたのは、私だったかもしれないという恐ろしい思いもよぎるのだが、だれかは本当に忘れてしまった。)

    さらに、M氏も質問後、食事の手を止めただけでなく1分間近く黙ってしまったものだから、皆”M氏の機嫌を損ねてしまった”と内心思い、益々場が凍りついてしまい、どうしたものか、と皆がハラハラしているうちに、おもむろにM氏が語った一言が、「設計とは最適化」であった。

    彼は、機嫌を損ねたわけではなく、我々自動車設計のしろうとを前にして分かりやすい言葉を探そうと、1分間真剣にその回答を熟考していたのであった。

    私は2つの意味でこのときの情景が忘れ難い。一つには、どのような場であろうと真摯な回答をするというM氏の技術者としての誠実さである。こういう人間的に深い方だから部下にも誰にでも尊敬される第一級の技術者なのだと、理解した。二つ目は、本質的でかつ含蓄に富むそのシンプルな回答そのものである。

    設計を議論する際の最適化ということばは、ともすれば、数学的な意味での”唯一絶対の最適解“という狭い意味での最適と解釈される場合も多く、甚だ誤解を招く用語ではあるが、本来、最適の定義は、条件により多様であり、唯一絶対を意味しない。

    まさに、それゆえに、「設計とは最適化」という一言は、複雑・多様な設計条件のもとで”可能な限り適正な設計解“を見つけたいという、設計者の夢を示しているといえよう。さらには、重量最小、性能最大といった単目的問題だけではなく、トレードオフ性を持つ多目的問題、ロバスト性や信頼性、コストや製造性、デザイン、感性的魅力なども含めた総合的な最適性を、設計者は目指しているということを、M氏は一言で表したかったのだと理解する。私は、このときに「最適化」という言葉にM氏が思いを込めた意味以上の、思いや解釈を経験したことがない。それほどに、M氏の設計人生を表するかのような深い言葉に感じられた、素晴らしい一言だったのだ。

    その場での私の理解は上に書いたようにきれいに整理されてはいなかったけれども、直観的に「設計とは最適化」という言葉は自分にとって本質的に重要だと感じられ、強烈に私の頭に残った。以後何かにつけこの言葉がよぎり、「設計最適化」を実現するためのしくみやソフトへと関心が傾いていき、情報収集しているうちに、Isightという製品を紹介してくれたのが、NASAの著名な最適設計研究者であったDr. Hiro Mであった。奇しくも同じ名字の二人目のMさんである。

    同じ言葉を別な場で別な人から聞いていたとしたら、さも当たり前すぎて右から左に聞き流していたかもしれないが、先のような状況でのM氏の言葉であったから、私にとって仕事人生のターニングポイントになった言葉になったのだった。

    M氏は、その場にいた1技術者に多大な影響を与えたということは全く意識もされなかっただろうし、すでにお亡くなりになっているので、感謝のメッセージをお伝えする機会は永遠になくなったわけだが、私には一言で人に影響を与えうる人物に会えたというだけでも忘れ難い思い出である。優秀な技術者はいい製品を作るが、超優秀な技術者は人を作るというようなことを、どこかで読んだ覚えがある。実感である。

    (筆者注:N自動車のM氏と書かざるを得ないのが残念。ブログであるからどのように解釈引用されるかわからないので、本名の開示は控えさせていただいた。)


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                
                                 今日の1枚
    「ネムネム」はとても活動的なリスだったけれども、たまに、ふっと、”憂い”のある表情を見せた。こういうときは、触ってもじーっとしていて、人間よりもよっぽど人生(リス生)のことを真剣に考えてでもいるかのようだった。

    - Nikon D100 -
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



    シマリス-2-2010.3.4:D100-07531 

    tags : D100 シミュレーション 最適化 

    comment(0)  trackback(0)

    ソフトウエアロボット - Software Robot

    2010.03.03

    category : 2.1 シミュレーションと最適化

    以下は、私がいた会社の創業者Dr. Siu Tongが、”Software Robot”というアイデアを思いついたときの経緯を書いたもの。この業界では有名な逸話だったが、最近は広められる機会も少なくなってしまった。なので、日本語訳付きでぜひ紹介しておきたい。新しい技術が生まれる時は、なんらかのドラマチックな出来事があるのだということを示す、実例でもある。産業革命を引き合いに出しているところは、いかに彼が新しい思いつきに興奮していたかが、想像できる。実際そのぐらいすごい技術だったのだ。彼が開発したEngineousというツールは、GEの多くの事業部で使われ、80年代-90年代前半GEの技術向上力とビジネス成長に大きく貢献した。
    --------------------------------------------------------------------------------------------------------------

    以下原文
    -----------
    I was at MIT late 70's. went to GE Aircraft Engines at Lynn, Massachusetts in 1979 for a summer job interview. I asked the GE manager what would I be doing if I came to work there. He said I would be taking one of their software for turbine disk analysis and try different shape, materials, and flow conditions, and then plot the results at the end of the summer so he could make a decision on the final design.
    I told him that seems very boring and asked could I write a program to automate the task. He said "it couldn't be done, otherwise, they won't be a few thousands of their engineer doing that kind of work everyday, not just a summer". I said ok and on the way back I recalled the lecture on Industrial revolution where people invented machine to automate tedious factory jobs and obtained significant productivity gain. Here in the 20th century where white collar workers are doing similar repetitive motion on the computer key board except no one can tell that walking by.
    I thought I will come to show them how to do it right. The next day, GE mailed out a rejection letter. Not having much rejection previous to that, my ego was hurt. At that time, I had finished my Ph.D research on an experimental project, past my qualify exam, and was about to start my thesis. I decided to quit that work and started a new thesis with a different department to prove that "it can't be done".
    4 years later, I showed sufficient promise of this approach GE Corporate R&D hired me. I spent 11 years and got $12M funding to development Engineous, the commercial version of my idea at MIT. The software that was said "it can't be done".
    ----------------------------------------------------------------------------------------------------------
    以下訳文
    -----------
    1970年代の後半、私はMITの学生であった。1979年の夏休みのインターンシップの面接を受けるために私はGEエクラフトエンジンへ出かけた。私はGEのマネージャーと面接し、もし採用されたらどんな仕事をすることになるだろうかと尋ねた。彼は「タービンディスクの解析をするソフトウェアを使い、異なる形状、材質、流量条件を試してもらおう。夏の終わりにその結果をプロットしておいてほしい。私がその中から最終デザインを決める」と言った。私にはその仕事はとても退屈に思えたので、プログラムを書いて、タスクの処理を自動化してはどうか、と提案してみた。彼は「そんなことできっこない。もしできるなら、ひと夏だけでなく、毎日そんな仕事をしているエンジニアが数千人もいるわけがないだろう」と言った。
    「分かりました」と私は答え、家路につくその道すがら、私は産業革命の授業のことを思い出していた。産業革命では退屈な工場の仕事を自動化する機械が発明され、生産性は劇的に改善した。20世紀の今日、ホワイトカラーの労働者たちはコンピュータのキーボードに向かって同じような繰り返しの仕事をしている。ただそれが目に見えないだけなのだ。私は自動化を実現する方法を彼らに示そうと思った。しかし、翌日、私はGEから不採用の通知を受け取った。それまで私は拒否された経験はほとんど持っていなかったので、私の自尊心は大いに傷ついた。当時私は(航空宇宙関連の)Ph.Dを取得するための研究を終えており、試験にも通っていて、後は論文を仕上げるだけだった。しかし、私は決心した。いまやっている研究はやめて、「できっこない」と言われたことができることを示すために別の学科で新しい博士論文を書くことを。
    4年後、私は十分な成果を上げ、GE中央研究所は私を雇い入れた。私はそこで11年過ごし、GEは私のプロジェクトのために1200万ドル投資してくれた。私のプロジェクトは「エンジニアス」と名づけられ、これこそがかつて「できっこない」と言われたソフトウェアなのだ。
    -------------------------------------------------------------------------------------------------------------- 

     

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                
                                 今日の1枚
    草木が凍ると美しくなる。家のそばの道端や畑の何でもない枯れた葉、木の根、花、ゴミまでもが、霜が降りて凍ると、魅力ある被写体に変身する。冬の早朝の誰も知らない楽しみ。    @厚木近辺 - Nikon D70 - 
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     

    凍-3-2010.3.3:d70_04566_edited 

    tags : シミュレーション D70 つなぐ技術 

    comment(0)  trackback(0)

    私の仕事

    2010.03.03

    category : 2.1 シミュレーションと最適化

    改まってこういうタイトルで書こうとするとなかなか難しい。とはいえブログの中で書く話題は、私の仕事に関連していることが多いので、最初のテーマとして書いておかなくては。
     
    産業構造の中の位置づけでいうと、「IT産業→ソフトウエア販売業→製造業向け→設計開発・生産用途ソフトウエア販売」。主なお客様は、自動車・航空・宇宙・電機・精密・機械・化学・材料といった製造業のCAD/CAE/PDM製品を利用している部門、それと大学や研究機関。ちなみに3文字熟語は、CAD : Computer-Aided Design, CAE : Computer-Aided Engineering(いわゆるシミュレーションと同じ意味), PDM : Product Data Management。さらに、私が専門としている技術は、CAO : Computer-Aided Optimizationとか、PIDO : Process Integration & Design Optimizationとか、SLM : Simulation Lifecycle Managementなどと、呼ばれている分野になる。IT業界は略語が多すぎるのが、困りものだ。
    製造業界向けIT産業の世界では、製品設計において”ものを作らず、実験を行わず、試行錯誤せず”というのが共通の標語になっている。何を言っているのか思われるだろう。実は“(CADで)ものを作り、(シミュレーションで)実験を行い、(パラメータ設計で)多数の評価を行う“というように、ITを駆使することでバーチャルな世界で設計開発を行うということなのだ。実物ですべて設計することに比べ、格段に期間が短縮され、コストが減り、品質も高まるではないか、という世界である。
    バーチャル化が進んだとしても、まだ課題が残る。コンピュータで設計やシミュレーションをしている人たち(設計者、解析者、研究者)は、日夜繰返し計算をして、もっとよい設計をしたいというニーズを持っている。試行錯誤を減らして、効率よく結果が欲しいのだが、その作業手順は専門的でかつ複雑なので、時間と手間がかかることが多い。例えば、シミュレーション用のモデル作成、データ変更、計算機間のデータ転送、計算実行、結果評価、データベースへの保存というような一連の作業手順を想像してみてほしい。このような作業を人間の手を経ずに自動化して、効率よく仕事を行えるようにする技術は、この10年来日本でも幅広く活用され、大きな効果を上げてきた。根幹になっているSoftware Robotという概念を次のトピックとして紹介しよう。

    私は、「つなぐ技術」と称されるこの分野にそれなりの貢献してきたと自負している。普段は3文字熟語やいろいろな専門用語でいっぱいの世界だけれども、やっていることは実は常識で理解できることがほとんどである。技術の中身を知らなくても、何をやっていて、何が問題で、どんな効果が出るかは、普通の言葉で十分に説明できる。まだまだこの分野と技術は十分に認知されているとは言えず、もっと活用されている世界があるはずである。これまでお客様に説明したり、仲間と議論したり、学会で話をしたり、自分の頭の中で考えていただけだったりしてきたいろいろ話題を、このブログに記していこう。

     

     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                
                                 今日の1枚
    冬晴れの早朝、湖面に波はない。凍てついた桟橋が早朝の静けさを引き立たせる。 

    @箱根芦ノ湖畔 - Nikon D100
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     

    凍-2-2010.3.3:d100-12945_edited 

    tags : シミュレーション D100 つなぐ技術 

    comment(0)  trackback(0)

    プロフィール

    シママロ

    Author:シママロ
    名前 K.K.
    生年 1959年早生まれ
    職業 製造業向けIT産業
    業務 技術マーケティング・営業支援
    専門 Simulation, 最適設計支援,「つなぐ技術」の啓蒙
    趣味 写真, カメラ, シマリス, 科学読物, 一部の絵画, JAZZ, iPhone
    興味 ITの持続的社会への貢献, 情報価値と抽出, 芸術美&自然美&機能美
    出身 青森県八戸市
    住所 神奈川県厚木市

    検索フォーム
    RSSリンクの表示
    最新コメント
    最新トラックバック
    リンク
    ブロとも申請フォーム
    QRコード
    QR
    訪問回数

    Copyright ©KK's Room. Powered by FC2 Blog. Template by eriraha. Photo by sozai-free 2000px.

    FC2Ad

    上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。