**********************************************************************
セッションS2-a 分科会
テーマ： Academic Engineerの開発技術
コーディネータ : 安積卓也 (立命館大学)
講師: 本田 晋也 (名古屋大学)
      笹田 耕一 (Heroku Inc．)
      三好 健文 (イーツリーズ・ジャパン)
      大澤 博隆 (慶應義塾大学) 
日時：2012/8/31 9:00 ~ 10:30
参加人数： １５人程度 最後２０人程度
**********************************************************************

（議事録本文）

安積さん:
     アカデミックエンジニアという題目で４人の講師を呼んでいます．
     アカデミックエンジニアというのは大学であったり学会で活動しながらも実用的な開発をしている方
     
     講師の方は，本田先生，笹田さん，三好さん，大澤先生
     本田先生と笹田さんは未踏のスーパークリエイター
     三好さんはインターフェースなどで多数の執筆活動
     大澤先生はさきがけという研究費を獲得されている．

     時間は１人１０分程度，最大１２分で終了
     大学での開発の難しさとかを話してもらいます 

本田さん：
     学生さんの方どれくらいいます？半分くらい
     経歴
          熊本電波高等専門学校 卒業
          豊橋技術科学大学 博士後期課程 終了
          名古屋大学 組込みシステム研究センター
     
     センター
          企業からお金を頂いて，さらに企業から出向していただいた研究員の方たちと研究を行なっている．
          そのため，普通の大学よりはソフトウェア開発の頻度が高い．
     これまでの開発の軸，ソフトウェアとしては
          TOPPERS/FMPカーネル (マルチプロセッサ向けRTOS)
          SafeG(組込みシステム向けデュアルOSモニタ)
          SystemBuilder(システムレベル設計ツール)
          TLV(トレースログ可視化ツール)
          SkyEye for TOPPERS (RTOS向けシミュレーション環境)
     SystemBuilder以外は全てオープンソースで公開している．
     どのようなものか
          ・FMPカーネル          
               マルチプロセッサ向けのRTOS．
               マルチプロセッサで，linuxよりももう少し低レベルの組込み向けのOSをやっている．
               なぜ開発したかというと，IPAの未踏ソフトウェアをやらせていただいて
               作ったものがベースになっている．これそのものは未踏ソフトではない．
          ・SafeG
               最近色々デモンストレーションしていますが，仮想マシンの一種．
               リアルタイムOSとアンドロイドを一緒に動かす．
               他にもVMはいろいろありますが，違う点はリアルタイム性があること
               簡単にデモをお見せしたい
                    RTOSとリナックスがそれぞれ独立に動いている．
                    中で通信もできる．
                    リナックスがどうなろうがRTOSはちゃんと動く
                    デモ動画
                         評価ボードとPCとipodと倒立振子．
                         評価ボードはシングルコア，PCはRTOSのコンソール，ipodはカメラ
                         評価ボードとipodはCANでつながっている．
                              電源を入れるとRTOSがすぐに起動．ナビのガイドカメラ
                              その後ろでlinuxが動く，
                              倒立振子自体の制御はRTOSでやっていて，
                              linuxはまだ立ち上がっているものの，仮想マシンなのでうまくRTOSが制御している．
                              androidはbootに時間が掛かる
                              androidはほとんど手を入れていない．
                                   OpenGLとかも動く
                              RTOSとアンドロイドとの間もリアルタイム通信ができて，
                              データはRTOSが持ってきて，画面はandroidのような使い方
                              Linuxが止まってもRTOSがちゃんと動いている．
                              自動車メーカにだいぶ前にお金を頂いて開発したものをベースに開発，
                              オープンソースとして公開
          ・SystemBuilder
               唯一オープンソースとしていない
               IPA未踏ソフトウェアの成果がベース
               C言語での処理の一部をハード化できる．
               ハード化したものとの通信もつくりましょうという．
               C言語でシステムを書くと，あとは自動的にシステムが作れるというもの
     
          ・TLV(TraceLogVisualizer)
               可視化ツール
               OSの動きとか，システムの動きとかを可視化出来る．
               特徴とするとどう可視化したいというのをスクリプトに書ける，
               自由に可視化できる(自由と言ってしまうといろいろ見解がありますが・・・)．
     
     いろいろソフトウェアを開発していますが，やはり大学にいるので研究者でなければならない．
          一つは作ったものを道具として使って共同研究をやっている．
          マルチプロセッサのOSが最たるもので，作ること自体は研究性はないけれども，
          これを使って，例えばトヨタさんだとエンジンとかにだとかで，そういった道具として使っている．
          オープンソースにして，最近見なくなったガラケーとかにも載った．
          他のものも共同研究のお話も頂いたりしている，SafeGなんかも一生懸命営業している．
          可視化ツールとかは共同研究とかでつかっている．

     
     大学におけるソフトウェア開発の意義
          先行開発的な位置づけ
               マルチプロセッサのOSとか企業でつくるとリスクが高いものを大学で作れたらいいかなと
               最終的に完成度を挙げるとかは出来れば自分たちでやりたいけど，難しいので企業の方にやっていただけたら．
               もっとお金をかけて企業のほうでテストをしてもらってて，そういうのがいいのかな？
     
          作ってもお金にならないけど，重要なソフトウェア
               これもマルチプロセッサOSとか仮想マシンとか．
               要は作っても，それが製品にならないもの．お金儲けにならないけどいるよねというソフトウェアを大学で作る意義はある．
               我々としてもそういったものを作っていくというのが必要だと感じている．
          オープンソース化
               多くの者はオープンソース化しています．          
               オープンソース化ということで社会に還元するという事もありますし，
               品質を保つモチベーションになれる．
               大学で自分たちで使うものだと作りっぱなしになる．
               でもオープンソースだと他の人にも見られるので，変なものは見せられないということで品質を保つモチベーションとしてはいいのかなと思います．
               また，興味を持った会社からコンタクトあるかもしれない．
               あまり企業も論文読んでという習慣がない感じがありまして，
               オープンソースで置いといて，使ってもらって，一緒にやりましょうとなることもある．
               
          共同研究は重要
               組込みの開発はお金がかかる
                    例えば先程のデモ動画のSafeGの評価ボード+ICE合わせて１５０万円
               社会からの要求の獲得
               
          ソフトウェア書いて共同研究をすれば充分か？っていうと
               論文発表は必要
               私の場合ずーっと任期でやってますので，今回はあと１年半
               次のポストを考えると論文発表しなければ
               ですけれども，投稿する学会は選択したほうが良いと考えています．
               今回紹介したソフトウェアの半分くらいは投稿したけど落ちてるというのがあります．               
               
          相性の悪い学会ということであまり言いたくはないですが，情報処理学会．
               やはり新規性が非常に求められる．
               ソフトウェアの作り込みとかは評価するけど新規性がないからだめだといわれることが多い．
               酷いのになりますと，車載向けソフトだから自動車に搭載した評価がないと意味ないと言われることも．
               ページ数が足りない．
               リジェクトが多くて情報処理学会への投稿は避けている．

          で最近どうしているかと言いますと，システム開発論文のほうに．
               時間がないのであれなんですけれども，
               ソフトウェア論文の趣旨とかを見てもらうといいかと思います．
               少しだけ紹介しますと
                    非常に
                    しかし，ページ数がかかってしまうので嫌がられるという噂も
     
     まとめ
          大学では自分の名前で比較的自由にソフトウェアが作れる．
          特にオープンソースにすると大学が権利を主張しないのでいい．
          論文は必要
          たまに相性の悪い査読者に当たって落とされる時もありますけれども，
          何回もトライできますので最終的に通れば勝ちかなと．

笹田さん：
     ４月に東大から転職いたしましてHerokuというcloudの外資系の会社に行きまして，
     まつもとゆきひろさんの元でrubyの開発をするというジョブについています．
     このパソコンは大学時代から使っているもので，大学の頃からストレスフルな環境にあったこともあって
     壁紙が幸せな，綺麗な感じになっているんですけど，まぁそれは置いといて発表させていただきたいと思います．

     私自身は学生時代からプログラミング言語rubyの処理系の開発をしてきた．
     実際にrubyを使われている方も多いかと思われるのですが，その最新版のruby1．9から入ったVMをずっと開発してきた．
     どっちかって言うと学術研究と言うよりは，オープンソース・ソフトウェアとして社会に貢献するというのがこれまでやってきた仕事なのかなとおもいます．
     その仕事を学生時代，教員になってから，企業に移ってから，開発環境はどういうふうに変わってきたのかなと紹介したいと思います．
     やはりいいところ悪いところいっぱいあるんですね，
     大学だから良いとか，大学だから悪いとか，企業だから良いとか，企業だから悪いとか．
     まぁ一番いい所は学生なんですけれども，ずっと学生でいるのも大変なので・・・

     今回はどんなプランかっていうのを紹介できれば
     まずは成果がどんなものかを紹介
          Ruby用仮想マシンYARV:Yet Another RubyVM
               YARVという名前で仮想マシンを作りました．
               オペレーティングシステムを仮想化する仮想マシンではなくて，
               言語処理系を活かすためのテクニックの一つとして，仮想マシン（スタックマシン）を作りました．
               
          我々の業界は世間にアピールする必要がある．税金をもらってプロジェクト研究をするっていうと
          私がやっていることは素晴らしいことだと言っていかなければいけない．
          世界で広く利用されている．日本初というのがキーワード

          学術的な知見は少ない，そんな中でいままで知られていない知見をどうするかっていうのを
          私が論文などを書いていく上で考えていったことです．

     具体的にどういうことかというと，
          Ruby1．8っていうまだ使ってらっしゃる方もいるかもしれないんですけれども，
          これはちょっと古い処理系．構文解析をして構文木を作ると，構文木をそのまま実行するというものだったのを，
          コンパイラをさらにそこに挟みまして，仮想マシンの命令文に変換して，その仮想マシンの命令を実行する．
     
          それに対して利口な最適化をかけてやるんですね，いろいろ早く動かすという話をしてきました．
          私自身このあたりの最適化技術がどのくらい効いたかということで博士論文が通ったのですが，
          今回時間の都合上，このへんの細かいところは省略させて頂きます．
          もしインタプリタとかで高速なものが作りたいという方がいらっしゃいましたら，
          お声かけていただければアドバイスできると思いますので．

          細かい話の補足をしておきますと，
          先ほどスタックマシンと申しましたけれども，レジスタマシンという計算機アーキテクチャの問題があって，
          まつもとゆきひろさんの主張するmrubyはレジスタマシン型になっている．
          2005年のこの研究("Virtual machine shutdown: stack versus registers")でいろいろと研究されてまして，
          我々としては自動最適化すればレジスタマシン型に近づけるし，
          現にmrubyよりはrubyのほうが高速にできているのもありますので，
          ギリギリまでいくとこうなんだけれども，実際にはこうだというのが知見になる．
          このへん興味があるかたはお声をかけてください

     今の仕事
          Herokuっていう会社で何をしているかって言うとクラウドの仕事をしているわけではなくて，
          Rubyの処理系の開発をしている．
          昨日にまつもとゆきひろさんがRuby20周年というお話をしましたが，CRubyを出すという話，Ruby2.0を出すという話をしてなくて良いのかと思ったりはしたんですけれども（笑）
          私自身のミッションは2013年2月24日で20周年を迎えるのでそこでリリースするために活動しています．
          あまり時間がないので，大きな改良はせず，とにかく出すということを考えている．
          あまり大きな見直しはないのですが，いろいろやってます．例えばIEEE754のdoubleの形式をハックしてプロットの計算を高速にするなど．

      これからが本題です
          OSS(オープンソースソフトウェア)コミュニティでの開発
          大学での開発(学生時代)
          大学での開発(教員時代)
          企業での開発
          
     それぞれの開発がどんなふうに違うのか
          まずRuby自身がOSSで育まれていたものなのでこちらを紹介します
               多くのボランティアに支えられている．
                    いろんな人がいます．例えば，最近だとこんな風にしたらバグが起きるというのを動画で出してきたりして
                    そんなの見てられるかということになってしまうように，いろんな人がいる．
               重要なのがReputationの文化があって
                    こいつはすごいというの人が発言力がある．
                    これがアカデミックと違うのが論文の数とか，この学会，この先生の下とかそういう話ではなくて，
                    ほんとにその人がすごい人，例えばイベントやブログで有名な人だとか，
                    そういう人がReputationを得られる．
                    そういう人達が，声を大きく使って，その人を中心になっていくんじゃないか
               性能よりも品質というのがある．
                    研究っていうのはバグがあっても速くなればいい．とにかく，評価さえ取れればバグがあってもよい世界
                    OSSの世界ではバグがあったら速くても駄目
                    そういう使う側としては当然だけれども，そのへんが違うところ．
               
     
          学生時代：
               和田栄一先生が「寝ても覚めても電車で立っていても考え続ける」のがハッカーだというふうに仰っていて，
               私もそのとおりかなと思っています．私自身，ほんとにそんな感じで電車に乗っている時でもスタックをどうするかを
               ずっと考えていた．
               実はRubyは趣味でやっていて，研究は別でやっていました．
               そっちをやらずにこっちばかりやっていたんですね．
               本業さぼってずっとこれやってたらこれが本業になってしまった．
               IPA見とうソフトウェア創造事業の支援があって，３回も支援いただいた．
               25歳以下いますか？数名
                    ぜひ，未踏に出すということやってもらったらいいと思います．
          大学の教員時代:
               寝ても覚めても・・・
               学生に任せるときには，完成度よりも新規性を求めて，外に出すプロダクトができていなかった
               バグ修正を行う勇気
                    バグ修正は論文にならない．
                    でもバグ修正をしないと使い物にならない．
                    大事そうなところは論文になる．
          企業での開発
               重要なこととして，HerokuはRubyやJavaなどを簡単にdeployできるプログラマの生産性を最大化させるクラウド・プラットフォームである．
               世界で最も実績のあるPaaSである．と言えと言われているのでこれだけは覚えて帰ってください．
               
               学生時代に戻ってRubyの開発をしているんですけれども，     
               いま危機感を持っているのが学生の輪講などが無いので，知識が入らないこと．
               ブログに書いてある知識は興味のある知識，それしか入ってこない．
               こういう学会とかに出さしてもらうと自分の知らない知識が入ってきて嬉しい．

     メッセージになるんですけれども
          とにかくいろいろ考え続けて，寝ても覚めても考え続けると，使えるプロダクトになるっていう風に，
          とにかく石にかじりついてやっていけば難しい技術，新規性が無くてもオープンソースとしてやっていけると信じている．
          できれば競争相手のいないほうがポッとでやすいんじゃないか

三好さん：
     株式会社イーツリーズジャパンの三好です．よろしくお願いします．
     アカデミックエンジニアということで話を頂いたんですけれども
     私自身まだ就職して半年たらずで見習いということでお話させて頂きます．
     自己紹介
          東工大でドクターまでとったあと，東大で笹田さんと一緒に働かせていただいて，
          東工大で働いて，電通大で働いて，今の会社というふうに転々としている．
          興味としては
               コンパイラとかハードウェア協調設計
               他に何か一貫して何かについて興味があるわけではないんですが，
               研究としては
                    細粒度自動並列化コンパイラの開発
                    メニーコアアーキテクチャのコンパイラ
               趣味
                    メニーコアアーキテクチャのプラットフォームを作ったり
                    
               コンパイラやっていたらまぁ作れるよねということでCUDAとか，NVIのコンパイラを作ってみたり，
               ストリーム処理専用アーキテクチャを作ったり，
               JavaからFPGAの開発が行えるJavaRockというコンパイラ．
     
               自分の中ではコンパイラとハードウェア協調設計ということで一貫してやっているが
               ふらふらといろんなことをやっていた．

     イーツリーズジャパン
          社員4人，小さいものの設立１０年を迎えてて，
          ベンチャーと言うよりはスモールカンパニーという会社．
          HW，MW，SW，SIの４人で１人いなくなると会社がやばい．
          FPGAがいっぱい入っている専用サーバを作っている．

     本題
     アカデミックエンジニアというのは響きが良くてカッコいいので気に入ったんですけれども結局何？
          ただ私がそうであるとしたら，とりあえず楽しそうです．
          アカデミックとエンジニアは相反するようでも共通項がある
          それをうまく両立させているのか
     何を話していいのかわからないので自分語りをしたいと思う．
          アカデミックとして論文を書くというよりは，ものを作る経験が大学生活の半分以上を占めている．
          その後に論文をかくというふうにしてきた．

          元々は大学1年生のときにケイツー電子という会社でアルバイトをしていた．
              ここでは高周波のアンプとかの設計をしたり強化をしていた．
              すると隣の席で組込みプログラミングをしていて，楽しそうだなぁと思ってみていた．
               
              この関連でFPGAで無線機を作るみたいな話があって，FPGAでいろいろという話に発展していった．
              この機会FPGAがいろいろ使えるようになっていった．
              
              実はじゃんけんに負けて希望した研究室ではない研究室に入ってしまった．
                    実際に作っていたものは簡単化した世界でのグラフの話をしていた．
                    私としては実装するほうが楽しいのになと，簡単な世界でこねくり回してるのは面白くないなと思っていた．
     
              今思えばグラフ理論難しいなと，逃げかもしれないが，実装のほうが楽しいと思っていた．
              このときは，大学ではなくてアルバイトの方でFPGAとWEBサーバをやっていた．HBFAなどを書いていてすごく楽しい                
    
         大学４年生なので論文を書かなければならない
         アルバイトの知見をわりときれいな日本語でなんとか論文にできないか．
              落としどころとして，例えばプログラムの中のコントロールプログラムとデータプログラムを上手くミックスしてあげられないかとか
              コンパイラの延長として書いたものを簡単にできないか
     結局アルバイトというのはお金もらってやっていたものなので，
          FPGAやWEBサーバを触っていたのは現在でも効いているのである意味成功ではあったものの，
          邪な発想でなんとか論文にできないかなというのはあまりうまくいかなかった．
     ドクターはなんだかんだ取れたものの，自分としては不本意，もっとちゃんとした研究とか開発とかしていかなければならないと思って，大学を出たあといろんな大学を点々としていた．
          その中ではcell向けの細粒度自動並列化コンパイラ
          メニーコアアーキテクチャプロセッサという言葉に飛びついてテストベッドの開発
          メニーコアプロセッサの中でのスケジューリング手法の検討
     こんな中で，もっとちゃんとしたいと思っていたので研究のやり方を学ばせてもらった．
     ちょうどLLVMをつくられたころだったので，LLVMを使ってメニーコアプロセッサのコンパイラを作るにはどうしたらいいのかという研究をしたりとか
     実際にプロトタイプとしてFPGAを100個並べてメニーコアのシミュレータを作るためのHDLのコードを書いたりした．
     正直論文はあまりかけなかった
     
     前職電通大
          やっぱり論文書かなければ，大学にいるのだから論文を書くのが使命だと言われた．
          戦略をたてて論文を書く，とにかく論文をかくための研究をやっていた．
          このときやっていたのが
               ストリーム処理プロセッサ　
               CUDA/MPIの処理系
          論文を書くためのプロジェクトで，
               論文を書くためにはどういうテーマが求められていて，
               どういう結果がでたら良くて，
               そのためにはどういう実装をしたらいいのか
          ということを自分の中で決めてそれにそってやっていく．
          結果的に国際学会にも論文通った，ジャーナルにもなり，論文は成功
          でも実際に使えたか？は微妙
     
          そのときに今のイーツリーズジャパンの社長とお話ししているときにJavaでHW開発したいよねという雑談をしていて，
               これは論文と関係なく作った

          今メインでやっているJavaRock
               Javaをベースにしたシステムモデル設計
               Threadやwait-notifyとか何か他のものを起こすっていうのはハードウェアとの親能性が高い
               Javaで書くとハードウェアロジックとして出来る．
     
     振り返ってみると短い人生の中で，研究とエンジニアを両立できていたのか
          博士取る前
               大学で論文はかけたが使えるものはなかった
          メニーコアアーキテクチャ
               論文はあまり，ただし今後の学生さんとかの研究に使えるものは出来た
          論文を書くってことに集中した部分ストリーム処理プロセッサ : 研究・発
               論文は書けた
          Javarrock：開発・発
               使えるものを目指している
     
     論文書いているとなんだかんだ新規性とか優位性をこねくり回しているので意外とえるんじゃないかと
     あるいはJavarockは使えるものであれば，論文になるんじゃないかとも思った．
     論文とエンジニアリングはやっぱり違う．
     
     割り切ることが重要！
          欲を出して，エンジニアリングの中で論文書こう，
          論文書いてる中で実際物作ろうっていうのは駄目なんじゃないかなとは思いました．
          
     アカデミックエンジニア（笑）にならないようにしましょう．


大澤さん：
    慶応義塾大学から来ました大澤です．
    学問の分野で開発を行なっているものとしていろいろとまとめていきたいと思います．
    自己紹介．
     私自身の研究がロボットを使ったヒューマンインタフェース
    専門の研究分野     
          擬人化した物体からの情報提供ということで
               ヒューマンエージェントインタラクション
               ヒューマンインタラクション
               ヒューマンインタフェース     
     経歴
          大学にいて，研究院，大学にいるので，あまり企業にいたことはない．
     どうしてこういう研究しているのか
          もともと人工知能に興味
          Bitという雑誌を読んでこれからは人工知能，ロボットだということで手を出し始めた．
          
     人工知能どこでやればいいのか：コンピュータ分野
          私がやった研究の一つ
               動画：
                    目と腕をつけるとロボットになる
               普通のロボットと違ってパーツごとに普通の家電製品に取り付けて，マッチング化してヒューマンインタフェースを作りました．
               例えばセンサーデバイスをつけて皮膚感覚を再現してあげたり，対応したコンテンツを再生してあげたりということで，
               センサとかロボットカメラとかを使ったものを開発してきている．

     なぜこういう研究をしているのか
         擬人化というものの可能性を広げたい
         例えば今までの研究で言うと，人間のインタフェースとしてロボットとかバーチャルエージェントを置いてというものはいっぱいあった
         コンピュータは人間ではないので，もっと人間よりも良いインタフェースが作れるのではないか
               そういうときに擬人化のどういう要素がどういう時に必要なのかということを細かく調べて発展させていきたい．
               こういう要素の重要な部分を見つけると人工知能という分野においてどのようなものが重要なのかというところで貢献できるのではないかと考えています．
     
     アカデミックエンジニアなのかという事も含めて考えると
          私はロボットとかインタフェースの分野で研究．
          広義の開発という意味では，開発をしていきながら作ってきた．
          
          こういうロボットとかインタフェースの研究・開発には大きく二つに分けられる．
               大きく知見の発見（実験系）
                    これはサイエンスに近い領域．
                    こういうインタフェースにすると人間はどういう反応をするか
                         ある要素を入れたときに人間に対してどういう影響を与えられるか調べる．
                    これは昨日のポスターでアンケートを取りながらやった結果をまとめたものですが
                         眼と手みたいなものがあって，それが切り替わるとどれぐらい存在感が変わるのかというものをグラフにしたもの
                         データからいろいろなものが見えてきて，そういうものを調べていくのが研究になっていく．
               新しいインタフェースの提案（システム系）
                    こちらはどちらかというとエンジニアリングに近い領域になる．
                    例えば新しいシステムを作って，それがどれくらい上手くいくかっていうことをシステムの提案込みでやっていく．
                    実装開発した成果は評価される傾向はある．
                    ロボットインタフェース分野，所謂CS系分野との違いは，開発にコストがかかる．
                    ものがあるし，上手く動かないというのがあり，ロボットなんて作るのに数年かかるとかあるので，
                    作ったなりに努力は認めようっていう傾向はある．特にロボット研究はそういう傾向がよく見られる．
         個人的に開発と論文がどうちがってくるのかというものを，自分の考えを言うと，      
               製品開発
                    便利な道具を作ることだろうと自分では思っています．
                    今人を助けるというもの
               論文は何のために書くのか
                    便利な道具を作り続けるための方法論を提案
                    今人を助けるというよりもこれから数十年経って人を助けるかも知れないような知見を提案していくこと．
                    実際最近の論文で参照した一番古いもので1860年のdarwinの研究，顔と表情に関するものを参照した．
                    論文を出すと自分がやったことが100年後にある研究者に使われたりすることも考えられる．
                         自分がやったことが100年後に見られるというのは魅力
                    今助けられない，将来人を助けられないゴミみたいなものになる可能性もある．
                    どっちが向いているかっていうのは人によって違うかと思います． 
                         開発が出来ないのかっていうと細かい改良を行ったとして評価されるかというと評価されないこともある．．
                         １００年後も救い続ける貢献が求められる．

                    ただしアイディアを伝えるためにはきちんとした実装が必要なのは確か
                         そのためのブラッシュアップは必要

          比較として関わった研究: 芽が出なかった研究・ヒットした研究
               芽が出なかった研究
                    小さな小型のロボットがあってそれをどう使うかという提案
                    このロボットの中に携帯をいれて，携帯とロボットを連携させて新しいことができないか．
                    こういう携帯がついたロボットを手に持って，その位置にあるブログを読むロボット，ブログロボット．
                    結果として，国際会議のHRIというヒューマンロボットインタラクションではそこそこの分野なんですが，そこのポスターとかビデオ発表止まり

               ヒットした研究
                    この研究を続けてきて，手じゃなくて肩に載せるロボット
                    今年までやってきた研究
                    国際会議のCHIで採択，かつ上位５％に入り受賞．
                    日本の大学組織で初めて

               実際どういう違いがあったのか
                    動画:芽が出なかった方
                         ブログを表示
                         ロボット登場
                         GPSが途切れたら
                         BLOGを読む
                         記事の評価を聞くまで行う

                    動画：受賞した研究
                         肩に乗っているロボット
                         人に動きに合わせた動きをする．
     
                         遠隔地から操作ができ， 慶応と秋葉原で繋いでいる．
                         遠隔地から買い物の指示．
                         目線を共有している．
                         店員との会話もできる．
                         アイコンタクトができる．
                         ロボットの方をみて店員さんがコンタクトをとっている．
                         店員さんお辞儀もする
                         どの商品化をカメラでみながらうまく指示ができる
                         商品への視線を共有
                    とまぁこんな感じで，実際の研究としては，秋葉原で実験をして，実験結果を論文にして提出して賞を頂いた．
                    何が違っていたのか
                          ロボットの実装はあまり変わっていない．デザインも出来ていた．
                    じゃあなにが違ったのか，
                          ソフトウェア，ハードウェアの改良を細かくおこなっていって，自分たちの相手が実現できるくらい実装をちゃんとしたというところが評価されたんだと思います．
                          それから提案を考えなおしたのもあって，
                              他人が実際にそこにいてデートできるというわかりやすくまとめること
                          学会でウケそうな評価を検討した
                              CHIという学会ではトレンドとして，意見評価ではなくて，実際に外に持ち出して，実際に使ってもらって，それから新しい事を発見していく形の
                              フィールド調査が多いので，そういったものを実際におこないまして，これまでの性能評価でなくて実地での検証で，新しい事が見つかったというのを述べてみました．
                             
               開発は非常に重要だと思っていて，こうやって改良していく事で自分たちの方法論がうまく使える
                    インタフェース系の研究だと実際に実装して動かないと意味が無いので，実装する事は大事．

               開発だけしていればいいのかというと，そうではなくて
                    自分たちのアイディアの新規性とそのアイディアで成長できるものを選ぼう

               まとめ
                    学問的な評価を受けながら開発するにはどうしたらいいか
                         長期的な視点に立つ事．
                              商品の開発は今役に立つ事が含まれるが，論文書こうというと１００年後も役に立つのかというのが重要になってくる．
                         ターゲットにそっていること
                              受けいられそうな目標，評価を狙うということもあり
                              どの分野から受け入れられるのか，その分野に対してどんな貢献があるのかっていうことを意識すると良い      
                         あきらめない
                              2008年から５年以上やってきてやっと芽が開くということもある．
                              ただその間なにも考えていないわけでなくて，考えてというのが大事で，
                              自分の持っている武器がどこで通用するかということを考えるべきじゃないかと思います．

<質問・意見>
安積さん：
     会場から質問，意見あれば

Tさん：
     京都大学のTです．
     聞いていいのか微妙な質問なんですけれども，特に笹田さん，三好さんにお伺いしたいんですけれども，
     オープンソースで作って公開しているもので，いかに利益をあげるかっていうのはどういう風にお考えでしょうか．
               
笹田さん：
     オープンソースをビジネスにのっけるかっていう話ですよね，非常に良い質問だと思います．
     私のやっている仕事はビジネスにならないんですね．ビジネスとオープンソースの開発は違うものじゃないかなとは思っていまして，
     その辺りはビジネスセンスがある方に任せたいというのが本音．
     例えば弊社がオープンソースの活動に対してうまくできているのは，
     他のビジネスモデルによって得られた利益を使った，社会貢献的なところもある．
     私みたいな，まさに世界中の人に使われるような開発をやっている．

     逆に言いますと，言語処理系で金を儲けているところは殆ど無い．
     今回私がHerokuっていう会社から雇っていただけたのはかなり珍しい例とは思います．
          
     例えばRedHatさんがエンタープライズ向けにサポートで儲けるという話もありますし
     開発とは別の観点からそういうやり方があるんじゃないかと思います．

三好さん：
     私はJavaでハードウェア開発するものをオープンソースで公開しているんですが，
     そもそもFPGAを使ってる人がそんなにいないので，まずはそれを広げるのが仕事なのかなとも思います．
     バイナリをオープンにすればいいだけかと思われるかもしれないが，ソースをオープンにすることで宣伝効果を期待している．

Kさん：
     アカデミックエンジニアの定義わかってないのであれなんですが，
          
     新規性がどうとかいう話がありましたけれども，学生にも大事な話かもしれないのですが，
     論文に新規性はいらなくて，論文っていうのは新しい物を発表するところではなくて，開発でも理論でもなんでも良いんですけれども，得られた知見を発表する場だと僕は思っていまして，
     ほんとに良い論文をみると新しいものもあるし，古いものもありますが，よんであぁなるほどというのがちゃんとまとめられている．
     
     論文出して，新規性が無くて落とされるというのは，それは単に論文の査読者とかクオリティに依存していて，
     ほんとに良いところに出したら，新規性がなくても得られる知見があれば論文は通ると思うんですね．

     ということは開発をしていて，何の新規性がなくても，例えば笹田さんが今1．4倍になるっていう話がありましたが，
     それはすごい結果なので，良いところの学会に出せば通ると思う，逆に余り良いところに出さないと新規性がないと落とされるかもしれない．
     
     必ずしも新規性にこだわってしまって，開発が出来ないというとかそういうのがあると悲しいところかもしれないのですが，
     今までの論文とかで新規性がないから不再録っていうコメントとかが実際にあったんでしょうか？
          
本田さん：
     私の場合，新規性が無いために落とされるパターンは結構ありました．
     ただ全くないと，何を新規性として持つかっていうのは価値観の違いで変わる．
     新しい設計が新規性だと思っていても，そうではないと思う査読者もいる．
     これくらいやっていればいいんじゃないかというのが見えてくるといい

Kさん:
     僕も開発が好きで，理論もまぁ好きですが
     新規性で蹴られると，アカデミックエンジニアっていうのカテゴリ無くなりそう，それは悲しい
     どうすればいいかっていうと，査読者やっている方って分かると思うんですけれども，論文の新規性って単なるいち項目にすぎない
     他にも評価する部分はあるので，格好良く脚本をかければ，脚本家になれれば，単なる開発の成果でも論文になっていくかなと，これは書いていく側のアプローチで．
          
     査読者とかコミュニティとしてこういうのを取っていこうというのもあります，まぁこれは大きくなってしまって大変ではありますが．
     僕が言うと，論文上手く書くと，新規性無くても全然アカデミックで行けるのではないかと思っているのですが．

大澤さん：
     新規性って言葉にはいろいろ定義があるとは思うのですが，
     新規性がなくて落とされることは，そのコミュニティでやられている既存の方法で，そのままのモチベーションで，
     やっていて全然新しくなくて落とされるんだと思います．
     コミュニティによってまったく発想が出てこなかったと認められるものであれば新規性があると認められると思うので，
     認められるところを探していくというのも一つ我々のやり方であると思います．
     ある分野ではすぐに出来そうに思えても，例えば応用の分野とかアプリケーションの分野に行くと，その発想は無かったとかその技術でそんなことが出来るんだと認めてもらえることもある．
     
     学会というのはいろんな分野もありますので，違った分野を狙っていくと新規性という面は十分クリアになるんじゃないかなと．

安積さん：
     笹田さんにお聞きしたいんですけれども，
     教員のときに新規性を重視した開発が余り出来なかったと仰っていたんですが，
     どういう利点を新規性に持っていたか

笹田さん：
     学生さんに論文を書いてもらって卒業してもらわなければいけない．
     新規性っていうとなんですけど，誰もやっていないパターンをやる．
     できるかどうかわからないものを攻めてもらいたい．
     できるかどうかわからないから研究するわけなんですけれども，
     実際に修論は１年くらいしかない
          その中で使って貰うまで完成度を高めるってところまでは難しい
          githubとかに挙げてもらってみんなが使うようになるまでがんばれって言う風に言い換えたりするんですけれども
          いやぁもう評価が取れたんでと終わっちゃう人が多かったかなと

     これに関してはとりあえず自分の中で完成がありまして，
          先生に言われたテーマだしといってなかなか情熱がいかない，例えば修論が終わったら，もう終わったからとなるのは
               いいものをある程度作ってることも終わったから良いですとなるのはもうちょっと正解のやり方があったのかなと反省はしています．
     
本田さん：
     結構同じで，やってもらって修論やって終わったらもういいやと，終わった後にどっかいくことが多い．
     その辺りうまくいくやり方あれば     

笹田さん：
     ただ自分の中でがーとやりたいと思っていた事が学生もそうだと思っていたから，学生さんはそうではなかった事が多い
     その辺の開発を，プロダクトとしてまとめられればいいなとは，
     学生がやったことは自分でやり直すということも大事かなと．

Kさん：
     2個だけ，言い方がストレートなんであれなんですけれども
     学生のせいにしたらだめ，学生が出来なかっという事は多分教員側に問題があったと教員側はそう思うべき．
     ただ，それは置いておいて，アカデミックエンジニアということなんで，
     大学でどこまでやったらエンジニアリングとしていいのか，僕はプロダクションクオリティは大学には出せない物と思っていて，
     それをやりたければチームを作ることが大事と思っています．
     大学でどこまでやったらエンジニアリングとしていいのかということをお聞きしたい．          
            
本田さん：
     我々今マルチプロセッサをやっていて，基本的には我々はプロトタイプを作って，そのあとはブラッシュアップ企業で．
     ブラッシュアップさえできなくなっている企業っていうのが多くなってきているかなと．
     シングルプロセッサのOSときは大体わかるので，いいものの．
         マルチプロセッサになるとそもそもマルチプロセッサに対してはどうすんだという話から始まって
         解決ということで各社コンソーシアム型の共同研究
               一社がボンと我々が使うからというのはなかなか無いので
               ちょこちょこお金をもらってフラッシュビジョンをあげて使っていこうっていうのはやっている．
          多くの人が興味を持っていただけたら使えるけれども，まだそんなに使いたい人がいないというときはどうしようかなという感じですね


Kさん：
     結構プロジェクトによって違う．
     バグバグだけど面白いから企業から求められることもあれば，
     企業からクオリティ求められるっていう幅があるんですかね？

本田さん:
     企業内の製品に使うときは完成度の高いもの
     プロトタイプは面白いもの
          
     最近思っているのはいきなり高い壁は難しいので，低い，企業内でプロトタイプ作りたいというお客さんを見つけて，
     まず使ってもらってちょっとずつレベルを上げていくのがいいのかなと．

笹田さん：
     私自身はどこまでやったらいいかという答えはもっていない．
     プロダクション，クオリティを上げるために大学を出た人間なので，
     大学にいてどうこうっていうのは答えを持たない．
     みんながソフトを作ったら大学の教授になれるかっていうと，そういう文化にはなっていない．

     それをタイトルの一部として持っていて，研究なり，教育なりを進めている先生方は尊敬できる．
     端的に言えば言語処理系だとMMとかそういう研究者コミュニティとか，あの辺は良い文化もあるのかなと．
   
三好さん：
     そもそも工学の人が入ると思うんで自分がやりたいところまで作ればいいとは思います．
     自分がやって胸を張って論文がかけるところまでやれればいい
     のめり込めばのめり込むほど外から見れば論文書けなくて無駄だなと思える時間の中でも，
     作り方とか新しい発見はあるので，ちゃんと評価が出来れば論文になるかもしれないし，
     胸を張って言えればその人の開発したものだと言える．
          
     答えになっているかわからないですが，好きなところまでやればいいと思います．

     もう一つ言うとすると，世の中のソフトウェアハウスってすごいので，どんどん外注すればいい

大澤さん：
     個人的は，大学の役割っていうのは企業ができないことをやるべき
     まずビジョンを示すべき，
     採算がとれるなら，あらかじめビジョンがあるならば企業がやればいい
     大学として企業が出来ない成功できないものをやるべき．
     失敗したなら失敗したなりの知見を発表すべき．

     開発のどこまでやればいいのか，
          大学はビジョンを示すべきだと考えて，限られたリソースをどうつぎ込むか．
          汎用的に何でも解決できるようなものでなくて一つのコンセプトに対してちゃんと動くものというのにリソースをつぎ込むべきという風に考えています．

Kさん
     もし学生さんが，なんとなくこの子ビジョンはないけどめちゃくちゃ実装はすごいなという子がいたらどうします？
     
大沢さん：
     その場合はこちらの方でビジョンを描いて与える．
     それは私自身の基準としては，修士までの子であれば社会に出たときにいかに武器を持っているかというのが大事なので，
     ビジョン自体は与えて，そのビジョンに対してもうやってもらう．

     博士までいくなら，ビジョンを考えるところまでをサポートしてあげるべき．

Tさん：
     自分の面白いと思っている物を作ってる人がすごいいいなと，
     それで論文も通しているし，成果を出している．
     それでアカデミックエンジニアと言う造語を思いつきました．
     こういう生き方に憧れるので自分もなりたいなと思ってます．
            

■まとめ
アカデミックエンジニアとして開発されているか，されてきた方々を講師にチュートリアルを行い，議論をした．
大学にいる以上は論文を出さなければならず，その中で開発という事であれば，いろいろと問題があがってくる．
しかし，論文を上手く書く，コミュニティについて吟味するなどそれをクリアする方法はあり，実際に論文を通してこられた方々がいる．
自分が面白いと思える物を作り，それで論文を出す，アカデミックエンジニアという生き方には憧れである．

以上