30歳過ぎから工学 vol.2

http://d.hatena.ne.jp/j130s/ から移行しました.オープンソースロボットソフトウェア技術者兼主夫. 高校・大学学部文系-->何となくソフトウェア開発業-->退職・渡米,テキサス州でシステムズ工学修士取得,しかし実装の方が楽しいと気付き縁があったロボティクス業界で再就職.現在 Texas 州内の産業用オートメーションのスタートアップに Georgia 州から遠隔勤務.

ロボットのハッカソンしてきた

先日職場でハッカソンがありました.機密にうるさい敏感な企業なので一般的な部分だけ少し書きます.まずハッカソンhackathon とは,短期間 (通常 1 日から 1 週間程度) の間に一箇所に集まり,なんらかの目的を設定して集中的にリソースを注ぎ込んで (人,時間,食事w) 開発を行うイベントで,言うまでもなくハッキング *1 + マラソンから来る造語です.有名な成果としては Facebook の Like! ボタンは同社での hackathon から産まれたとされています.
今回は職場のチーム計 13 名が二つに分かれ平日一週間で行いました.1 チームはセンサーと携帯端末のインテグレーションを行い,一方私が入ったチームはヒューマノイドロボットを用い (ヒューマノイド経験者は半数),両チームともある異なる家事をさせました.結果は両チームとも一応予定した機能の実装をほぼ/すべて達成でめでたしめでたし.初めて hackathon に参加したので以下まとまりないですが感想を.

  • かなり個人的な話ですが,ロボット業界に来てまだ数年なので,自分の手持ちのソリューションアイディアが少すぎたため,楽しいはずの機能仕様決めには意見を殆ど出せず,仕様が決まった後の実装屋としてのみの参加になってしまったのは残念 (覚悟してたから OK だが).ロボットの場合,実世界を知覚しないと始まらないので,センサーやマニピュレータ等のハードウェアや,それらに絡むソフトウェアライブラリをうまいこと使って*2目的を達成するわけですが,そのどれもまだ私は経験不足で,かつチームには経験豊富な人が三人いた (アドバイザ一人とロボティクス PhD 学生二人) ので,解決法を考えるプロセスでは彼らにオンブズマンにダッコチャンとなってしまった.ソリューション手段をあれこれ考えるのは既述の通りシステム開発の面白い部分なので,ここは要努力.
  • 実装ではマニピュレータを動かして物を掴んだり離したり移動したりという箇所を,マニピュレータ経験が無いにも関わらず,経験しておきたかったため担当しましたが,慣れるのに時間がかかり過ぎた.マニピュレータを地点 a から b に移動するその間の軌道を計画することを motion planning などと呼びますが,結局動的に計画するのは素人の私には難易度が高すぎ *3,静的に位置を決め打ちさせました.すると今度は自分の担当部分としてはやや時間が余ってしまいイマイチ challenging 感は薄れたのが残念 (チームメイトが担当した画像処理モジュールと結合し,物体の位置を把握して自動で掴むようにしたので,出来上がりは hackathon としてはまあまあのモノではあると思いますが).
  • ていうかマニピュレータ/アームって恐ろしく複雑ですね.予想はしてたけど.
  • 帰宅は毎晩午前様でしたがこれって日本企業や学生だと平時でも珍しくないですよね...とはいえ,普段一緒に密に働かない人同士が一緒くたで集中開発をする hackathon はやはり特別.あまり会話したことのない The Californian な感じのアドバイザがまだ三十前半のくせにベンチャーズなんか聴いてて,そのまんまやん!と同時に古クサ!って思ったり,仲間意識が当然強くなった.月曜早朝に朝食を一緒に食べて始まり,金曜夕方は BBQ で締め (残念ながら Dallas へ週末帰るフライトと重なってしまい BBQ はサラダ抜けでしたが).
  • 帰宅時刻をきにせず短期集中で仕上げる/スキルを身につけるというのは学生が経験を積むにはうってつけのスタイルだなと思う一方,経験豊富な人のヘルプが受けられる状態でないと,どん詰って捗らなくなり,人数を集中してる分失う時間も多くなる.今回はちょうど当日から着任した PhD 卒業目前の学生が大活躍したため捗ったが,彼が居なかったらとんでもないことになっていた.企業でも同じだろうけど特に教育機関で行う場合,スキルフルな人の人数を確保できるかは一つの焦点でしょうね.
  • 企業の業務として Hackathon を行う事に関して (ロボティクスに限りますが).まず一般的な前提として Web 等の純粋なソフトウェアに比べロボットは,ハードウェアが絡むのとタスクが簡単ではないのとで,開発スピードが遅いです.したがっていくら人を集中投下したとはいえ一週間で実現できることは限られ,まして製品直結のものが作られる可能性は低いでしょう.しかしながら,似た理由でそもそもロボットを使っての挑戦がなされてないタスクというのが世の中にはゴロゴロしており (例えば思い付きだけど,人の足の爪を切るロボットとか無いよね多分),短期でそういうった未試行課題に手を付けるのはとても有益でしょう.なぜなら試行してみることで,そのタスクでは何がどのくらい困難なのかが具体的に見えてきたりするから,研究者サイドとしてもマネジメントサイドとしても,今後の方針決めの材料として重要だった様子 (というわけで Hackathon の題材はその企業の商売ドメインから選ばれるのがまずは妥当かと).あと当然ですが成果の再利用が発生する.今回も,昨年夏に同研究所が行った Hackathon で作ったモジュールを利用してうまく動いた,なんてことがあった.
  • (Hackathon に限らないけど) 上述の新任者は,機能の実現方法を決めていく中で,必要なモジュールを外部の知合い/友人が持っている場合ためらいもせずメイルして取り寄せていた.上述の画像処理モジュールも根幹部分は LA の大学院生からファイルを送ってもらって実現.なんというか,そもそも今ロボティクス業界は open source の波がウネリまくっていて,私達のオフィスで開発しているソースコードも半分以上は BSD ライセンスで公開しているわけですが (老舗の部類に入る大企業としては公開するのはまだ珍しい方だと思う),損得なしで成果を共有しあう世界の研究者達 (或いは損得はどうにか精算されてるのか) の積極さに驚く一方,著作権だアイディア漏洩だなどとビジネス的なとこどうなんだろうとも気になった.後で訊いてみよう.

...と,いうように,ヒューマノイドに関して事前スキルが著しく足らなかったため,challenge という側面を楽しみ切れなかったのは残念ですが,それでも短時間で色々学ぶことができたのは収穫でした.今後もっとスキルが身についた時にはもっと楽しめるに違いない.

とあるロボット系企業の無料ランチにあり付いた.さすが California というべきか,かなりヘルシー.

*1:一般社会ではハッキング/ハッカーは悪い言葉として用いられますが,エンジニアの用語としては悪意を持った攻撃行為はクラッキングと呼ぶことが多く,改善の手段として分解/破壊を行うハッキングという行為自体はむしろ歓迎されます.

*2:場合によっては泥臭くても OK.解決法や実装の美しさは Hackathon では優先ではない.機能の実現が優先.

*3:自分の名誉のためというか,一応言っておくと,motion planning はプロにとっても簡単ではない.アドバイザも,今回は静的な planning を使うと最初から決めていた様子.