今回は、Point Cloudに対するSemantic Segmentationについてサーベイしました。
この分野は論文が多く、ここ1-2年でもたくさんの研究が発表されてます。ただ、その中でどれが重要かというのがイマイチ判断がつかず、いつもよりまとめるのに苦戦しました。
結果として、比較的新しい手法ばかりになっています。
過去このブログで紹介した点群やSemantic Segmentationのサーベイについてはこちらを参考にしてください
先週土曜日(2018/12/15)に開催されたコンピュータビジョン勉強会@関東は、記念すべき第50回でした。
皆さんの支えがあってここまで続けることができました。ありがとうございます。
では、例のごとく資料やリンク関係をまとめたいと思います。
第50回コンピュータビジョン勉強会@関東は、「CVで使えるツールLT大会2」というテーマで、今回ははじめてオムロン株式会社(東京事業所)様から会場をお借りして開催いたしました。
コンピュータビジョン勉強会@関東
http://sites.google.com/site/cvsaisentan/
開催プログラム
第50回 コンピュータビジョン勉強会@関東 - connpass
Tweetまとめ
2018/12/15コンピュータビジョン勉強会@関東「CVで使えるツールLT大会2」 - Togetter
以下で録画を確認できます。
https://www.youtube.com/watch?v=mkcPSdJ1kwE&t=15s
https://www.youtube.com/watch?v=5MgRPfYzu4Y
https://www.youtube.com/watch?v=9vjvlZvl868
取り急ぎ、発表者ごとに資料のリンクをまとめます。(敬称略)
発表者 | 発表内容 | 資料 |
---|---|---|
takmin | Kerasで学習したモデルをOpenCVで使う | |
tomoaki_teshima | Jetson Xavierでasimdhp | |
peisuke | ディープ子を救え!ABEJA Platformの紹介 | |
おさかなさん | chainer-trt: ChainerとTensorRTで超高速推論 | chainer-trt: ChainerとTensorRTで超高速推論 |
tereka114 | 画像コンペティションで使えるPyTorchとそのライブラリの紹介 | 画像コンペティションで使える PyTorchとそのライブラリの紹介 |
a_hashimoto | Be Lazy! Docker rapper 'bonito' | bonito_presentation_2018Dec..pptx - Google ドライブ |
denkiwakame | CVで使えるGPUプロファイリング | GPU profiling for computer vision applications |
yusuke_shinya | ディープラーニングのフレームワークと特許戦争 | ディープラーニングのフレームワークと特許戦争 |
for_tokyo | ImageJの紹介 | CV_Kanto50.pdf - Speaker Deck |
conta | (正式タイトルメモし忘れた:Abeja Platformでサンタコスを判別する話) | |
tomoaki_teshima | 大切なことはすべてOpenCVが教えてくれた |
自分の発表資料についてはこちらにも張り付けておきます。
TensorflowバックエンドのKerasで学習したモデルをOpenCVのdnnモジュールを使って推論する話です。
この記事はフリーランスAdvent Calender 2018の7日目の記事です。
フリーランス Advent Calendar 2018 - Adventar
はじめての方に、自己紹介をしますと、2009年にフリーランスを始めて今年法人成りしたtakminと申します。
お仕事はコンピュータビジョンという人工知能の分野で研究や開発の委託を請けたり、コンサルティングなどを行っています。
フリーランスになった経緯と法人化の経緯については以下のエントリに書きました。
僕のフリーランスとしてのスタイルは、客先常駐はせず、受注前に顧客と作業内容やアウトプット等を合意した上で、作業はこちらの好きな時間、好きな場所で作業させてもらってます。
そのため時間に融通がききやすく、平日に遊びに行ったり、子供が幼稚園入るまでは1日5-6時間は家事育児に費やしてました。その上で、家族を十分養えるくらいには稼ぐことができていたので、フリーランスとしてそれなりにうまくやれていたほうではないかと思います。
ただし僕の場合、たまたまAIブームに乗れたみたいなところもあるのであまり一般化はできないかもしれませんが、この記事で自分なりに身に着けたフリーランスエンジニアでやっていくためのノウハウを列挙したいと思います。その人の性格や職種、景気やマーケットによってここに書いてあることも当てはまったり当てはまらなかったりすると思いますが、この中の1つでも役に立つことを見つけてもらえれば嬉しいです。
目次:
フリーランスは基本的にコネで仕事を取ってくる人がほとんどだと思います。僕も特に営業などはしておらず、昔の仕事仲間だったり、恩師の紹介だったり、自分が主催している勉強会の知り合いだったりとコネで仕事を取ってくることが非常に多いです。
ただそれと並んで、あるいはそれ以上に大きい営業ルートが、自分のブログ記事やSlideshareに上げた技術資料、Githubなどを顧客が検索で見つけて連絡をもらうケースです。
僕が公開している技術資料は、趣味で作ったものだったり、勉強会で発表したものだったり、お客様から許可を得て成果を公開したものだったりしますが、こういう風に情報をオープンにしていくことで、自分が何ができる人なのか明確になりますし、そもそも自分の存在を多くの人に知ってもらうことができます。
もともと情報公開を積極的にやっている動機は、せっかく作った資料やコードなら多くの人に見て役立ててもらいたいというものでしたが、結果として大いに自分の役にも立ってます。
フリーランスに限らず、みんな勿体ぶらずに自分のノウハウをどんどんWebに公開していきましょう!
ちなみに自分のSlideshareはここ、githubはここです。
顧客から具体的な仕事の依頼が来ても、すぐに見積を作成してはいけません。
それよりも顧客が「なぜ」その依頼を出したのか、その背景と目的を知ることがとても大事です。以下のツイートが「目的」とは何かを理解するのに良い例えだと思います。
今朝
— xeno@rappafuki (@xeno_rappafuki) May 8, 2018
上司「だから目的と目標がごっちゃなんだって」
私「すみません分かりません」
上「お前が勇者だとして魔王を倒す事が目的になってんだよ」
私「違うんですか?」
上「違うだろ。目的は魔王を倒す事によって得られる世界平和だろ!」
私「…!!すぐ作り直します」
この後めちゃくちゃ捗った。
ここでいう「目標」が顧客からの依頼内容にあたります。
こちらは一応顧客よりもこの分野の技術に詳しい専門家なので、来た依頼(目標)が目的にとって最適かどうかを再度自分で判断してみます。場合によっては「いや魔王とは停戦協定を結ぶことも可能ですよ。そのほうが全体のコストも安上がりです。」という指摘ができるかもしれません。
もしここで顧客が思いつかなかったより良い提案ができると、顧客からの信頼につながりますし、価格や進め方等の交渉もやりやすくなります。
ただし場合によっては「それなら魔王討伐はやめて、自分たちで和平交渉を進めてみます。」となり、仕事を失うケースもあります。僕は基本無駄な作業が嫌いだし、結果としてお客様の信頼を得られるので、それでも良しとしています。
何よりここでしっかりお客様の背景と目的を抑えておくことで、その後の最適な提案と見積につなげることができ、お客様からただの替えの利く下請けではなく、替えの利かない専門家もしくはパートナーとして見てもらえるようになります。
仕事を請ける時は、事前に作業範囲や前提条件をお客様と合意しておく必要がありますが、僕は仕事のプロセスの中でここを一番重要視しています。僕が過去見聞き(あるいは経験)した炎上案件の多くは、だいたいここの作業の詰めが甘いために起こってました。
この作業範囲や前提条件を合意するために、僕はよほど簡単な案件を除いて、必ず「見積もり提案書」というものを作成しています。見積もり提案書にはだいたい以下のような項目を設けます。
このほかに開発案件だったりすると、納品条件や瑕疵条件などが必要になるケースもあります。
ここでは一つ一つの項目について細かい説明は省きますが、大事なのは何をして、何をやらないかを明確にし、顧客と合意をとることです。また現時点でできるだけ発生しうるリスクを洗い出し、それが回避できるよう前提条件や制約条件に含めておきます。
提案書作成の際は、顧客の目的と状況をしっかり踏まえて、自分が出来る範囲で最善と思われる方法を考えます。仮に依頼されたのは開発であったとしても、顧客がどのフェーズにいるのか、その開発がどういう性質のものかによって、進め方は変わってきます。例えばもっと要件を詰めるためのコンサルティングが必要であったり、技術サーベイする必要があったり、Try&Errorで開発を進める必要がある(機械学習案件など)など、将来顧客がきちんとほしいものを入手するために、今の自分が取るべきと思う手段をこちらから提示します。
見積もり提案書には作業範囲を明確化して炎上を防ぐ以外に、以下のようなメリットがあります。
余談ですが、目的をどういう手段で実現するかを考えるのはまさにエンジニアリングで、提案書執筆は工学系の論文執筆と通じるものがあります。自分が大学の研究室で苦しんだ「論文を書く」というトレーニングが、社会人になってこんなところで役に立ちました。
案件を進めていく過程で、当然トラブルが起きることはあります。それが自分自身が要因(自分が仕込んだバグなど)であれ、外的な要因(3rd Partyの不具合など)であれ、最もやってはいけないのは顧客に対してそれを隠すことです。後々ダメージが顧客に対しても自分に対してもより深刻になります。
僕はトラブルが発生した時は、相手の懐に入り込むくらいの気持ちで、まずは正直に、そして頻度を上げて報告するように心がけています。
面白く思っていない顧客でも、きちんと全力で取り組んでいるところを見せれば、感情としては納得しやすくなります。
ただし、たとえ一所懸命に問題に対応しているところを見せたとしても、原因のあたりもついていなかったり、場当たり的に対応しているように見えると、相手は大きな不安を感じます。
そこで、例えば課題管理表のようなものを作って問題点を列挙し、対応の進捗状況を見えるようにするのは常套手段です。
また、原因のわからない技術的障害のようなケースであれば、その原因を探るためにまずは症状を列挙し、その症状から原因の仮説を立て、その仮説を検証するための今後のアクションを都度報告するようにしています。また、緊急な場合は回避策(別の手段による代替など)を提案します。
障害対応の基本は、症状の観察と列挙、仮説列挙、仮説検証のアクションを繰り返しながら、徐々に原因を絞り込んでいくことです。そういう問題を絞り込んでいく様を顧客に繰り返し報告することで、きちんと考えて問題解決に近づいていることを理解してもらいます。
ここできちんと対応できれば、より顧客からの信頼が増すことがあります。
基本的に顧客から依頼を受けて、作業して、売り上げを立てるというモデルだと、自分が使った時間に比例した売り上げしか上げられません。それでもなんとか売り上げを伸ばそうと自分なりに工夫してきました。
その中の一つとして、仕事の成果を使いまわすことで、昨日10の工数をかけたものを今日は5の工数でこなせるようにというのがあります。
例えば、開発したコードで再利用できるところは、きちんと関数として整理してオレオレライブラリ化したり、論文のサーベイなど公知の事実に関する資料は顧客の情報を削除することで公開させてもらえるように交渉します。
そのためには提案書の段階で、以下のような文言を含めるようにしています。
毎回、開発を行う際は過去の成果を使いまわす可能性があるので、今回開発する部分との切り分けが難しい旨を顧客に説明しています。だいたい現場はこれで納得してもらえてます。
ただし相手が大企業だったりすると、現場の担当者は納得してくれても、法務や調達部門などで揉めることが多いです。
やむを得ない場合は、見積金額を上げることで権利譲渡に対応します(が、そこまで要求されたことはありません)。
本当はうまいこと成果をパッケージ化し、その販売ライセンスや保守費などで儲ける仕組みを作りたかったのですが、残念ながらそこにはまだ至っていません。
サラリーマンは上司を選ぶことができないので、上司ガチャに外れると毎日がとてもストレスフルになります。一方でフリーランスは嫌な顧客とは付き合うのをやめることができます。
むしろ嫌な顧客と関わり続けると、その時間で携われたであろう別のビジネスチャンスを逃すことになります。
案件契約後に相手が問題のあるタイプだとわかるケースもありますが、その場合は一度請けた案件はプロとしてしっかり終わらせ、二度目以降は理由をつけて断るようにしています。相手が嫌な相手だからと携わっている仕事を途中で投げ出したり、クオリティをおろそかにするのは、プロとして決してやりません。
また断るときも、相手が嫌だからということはもちろん言わず、別案件がすでに決まっていることにするなど、波風が立たないように気を付けています。本当にお金に困った時に、それがいつ蜘蛛の糸になるかわからないので。
逆に自分が顧客から嫌われるというケースもありえますが、こういうのはお互い相性なので、深く考えすぎないようにします。(難しいけど)
自分の場合、顧客の下請けではなくパートナーでありたいと思っているので、上から目線で対応してくる顧客は慎重に見極めるようにしています。
だいたいこういうタイプはこちらを下請け扱いして、見積もりに対してなんのかんのと値切ってくるし、要求もコロコロ変わるので、交渉にも時間を取られます。
また金銭面の管理がしっかりしていないようなタイプも地雷原なので近寄らないようにしています。
僕の専門のコンピュータビジョンという分野は、流行りのDeep Learningを使った画像認識だけでなく、LiDARのような距離センサや、SLAMや多視点画像による三次元復元のような幾何学的な知識を必要とするものまで多岐にわたります。またここ最近は技術の進歩も早いため、キャッチアップするだけでも大変です。
個人的には勉強会で発表したり、学会に参加するなどして学習していますが、やはり仕事を通して学習するほうが時間もしっかりとって真剣に取り組める分効率が良いです。
幸いなことに、この分野でフリーランスをしているエンジニアはあまり多くないため、コンピュータビジョンと名のつく様々なタイプの相談が舞い込み、毎回必死に勉強しながら仕事をこなしてきました。
ただそれでも、自分一人で対応するのは不安になるような依頼内容もあります。会社などに所属していればまわりに相談する人もいるかもしれませんが、個人で仕事をしている場合そうもいきません。
僕の場合、そんな時はその分野に詳しい大学の先生などにお金を払って相談に乗ってもらうことにしています。
例えば詳しくない分野を1から自分で調べるよりも、あらかじめ抑えるべきポイントや方向性などを教えてもらったほうが、圧倒的に学習効率は高いです。また、自分で調べたり勉強した結果に抜けや漏れがないかを確認してもらうだけでも十分な価値があります。また一人で悩んだら何時間もかかるような疑問も、すぐに聞けるパスがあるというのは時間だけでなく精神力も節約できます。
僕の場合、だいたい1時間あたりの金額を合意して、実際の打ち合わせにかかった時間分支払うようにしています。そのため、先生との打ち合わせの前にはしっかりと質問内容や資料を事前に作りこみ、余分な時間がかからないように注意を払っています。
(学生さん、大学の先生に教えてもらえるということは実はすごい金銭的価値があるんですよ!)
また僕がSEをしていたころも、システム構築を受託した際、社内に詳しい人がいない技術分野に関しては外注を利用していました。
この時重要なのは、開発を丸投げするのではなく、外注先の開発会社の仕事内容を理解しようと努める、もっと言えば彼らのノウハウを見て盗むことです。そのためには、基本設計書や仕様書などはきちんと自分たちで作る必要がありますが、その際開発会社には技術相談に乗ってもらい、設計書や仕様書の内容確認もお願いします。彼らにしてみればおかしな仕様を押し付けられるよりは、きちんとした仕様書を書いてもらった方が嬉しいでしょうし、もちろんお金を貰うわけですからほとんどの場合協力的です。
開発に当たり、実際に手を動かすのは開発会社ですが、その時も構築手順書等の文書を作成してもらい、その内容のレクチャーの時間も設けてもらうことで、同じような案件が来た時に自分で構築出来るようにしておきます。
この外注を使った学習テクニックは、未経験分野の仕事を請けてもそのリスクを大きく低減できる上、実際の仕事を通して効率的に学習することが可能です。しかもその外注にかかる予算をあらかじめ見積もりに含めておけば、懐も痛みません。
孤独なフリーランスにとっては結構有効なテクニックなのではないかと思います。
見積もりをする際、顧客にはどうしても「工数単価」を聞かれてしまうケースがありますが、僕は「価値」という形で見積金額を決めていると伝えるようにしています。
もちろん、案件ごとにどの程度工数がかかるかは事前に算出しており、赤字プロジェクトにならないように気を付けていますが、「5. 案件の成果を再利用する」にも書いた通り、その工数をいかに削減するかを工夫しているので、単純に工数単価で伝えてしまうとその分安くされてしまう恐れがあります。
以前打ち合わせの場で工数単価とかかるであろう工数を答えてしまったがために、その数字が独り歩きして失敗したことがあるので、それ以降は慎重に対応するようになりました。
もちろん、ある程度パッケージ化できて多売が見込めるようになれば金額を下げることもできるのですが、そこまでにはまだ至っていません。
ただし、どうにもアウトプットの定義が難しいケースなどは工数ベースで対応することもあります。
本来は自分の仕事が顧客にとってどれくらいの金銭的価値になりえるかを、マーケティング等を駆使して算定するのが正しい値付け方法なのでしょうが、それはそれで市場調査やら顧客の情報収集や分析が必要となるため断念しています。(見積もり期間中にそこまでやるスキルがない)
またその仕事が気乗りしないものの場合は、金額を高めに見積もります。この金額は「まあ、それくらい貰えるなら頑張るか。それで高いと断られたなら別に良いや。」と思えるあたりに設定します。
他にも、仕事がしやすそうな担当者かどうか(例えば技術がまるでわからない相手の場合は説明コストが増える)、官僚的な企業で間接部門との交渉や仕事の手続き等で余計な工数がかからないか、権利の譲渡等が含まれるかなども考慮して価格を決定しています。
フリーランスになりたての人が犯しがちな間違いとして、サラリーマン時代の給与をもとに工数単価を設定することがありますが、最低でもその2倍は取ったほうが良いです。フリーランスは常に仕事があるわけではないので、そのリスクも計算に入れておく必要があります。
このエントリでは、自分なりのフリーランスエンジニアとしてやってきた工夫について列挙させてもらいました。
自分の仕事の進め方を人に聞かれることも多かったので、これを機会にまとめることができてよかったです。
見積もり提案書の書き方の詳細、トラブルシューティング報告書作成の具体的テクニック、機械学習を使う案件を受注するときの工夫など、書ききれなかったこともありますが、それは需要があればまたどこかに書きます。
エンジニアは興味関心が技術に向いて、顧客自身に向かない人も多いと思うので、フリーになりたいというエンジニアは「技術力が高いからお金を貰えるわけではない。顧客の期待に応えるからお金が貰えるのだ。」という点は心しておきましょう。
「3.見積もり提案書を作る」でも書きましたが、顧客の目的を達成するための手段を考えるのも立派なエンジニアリングです。しかもそれは専門知識があるからこそできることなのです(でなければ顧客はあなたに相談しません)。
ちなみに、ここで列挙した2-4のテクニックは、自分が新卒で入った会社でSEをしていた頃に身に着けたものです。SEをやっていた当時は、顧客対応や営業サポート、プロジェクト管理ばかりでコーディングの仕事がなく、技術も大して身につかずに腐ってましたが、お陰で今こうして比較的自由に仕事ができています。また大学の研究室で学んだエンジニアリングやサイエンス的な思考方法が、見積もり提案書の作成やトラブルシューティングスキルなどにもつながっています。
人生懸命にやっていたら何がプラスになるかわからないなあ、という月並みな感想で締めたいと思います。
最後までお読みいただきありがとうございました。
前回の記事で、LiDARとカメラ<両方>を使った物体検出について調べましたが、今回はLiDAR<のみ>を用いて道路上の物体検出を行う手法について調査したので、資料をアップしました。
LiDARを用いた物体検出は上記よりもずっと研究の歴史も数も多いので、その中でも
という観点で選びました。
「なんでこの研究がないんだー!」みたいな意見は大歓迎ですので、ぜひご連絡ください。