画像AIエンジニアの雇い方

Last updated at 2024-08-21Posted at 2023-07-13

画像AI関係の求人は多い。また、画像AIの利用経験者は日増しに増えている。
そのようななかで、画像AIのエンジニアを雇い入れる企業の側の採用担当者に向けてアドバイスを書く。

あなたの企業で、雇い入れたい画像AIのエンジニアにさせたい業務は何ですか？

「図１：この図の中央の小さな黒い箱部分に示すように、現実世界の機械学習のうちほんのわずかな部分だけが、機械学習のコードでなっている。必要とされる周辺の土台は広くかつ複雑である。」

自分たちのチームに何があって何が足りていないのかを確認しよう

新規に人員を増やすのは、組織にとって簡単ではない。
既に業務が収益が上がるようになっていて、人を投入すればもっと収益につながる、そういう状況の組織ばかりじゃないはずだ。
画像AIエンジニアを雇い入れたいと思った理由には、画像AIの分野が既存のOSSをgithub からgit clone するだけじゃ、足りないと感じたからだろう。
画像AIの分野はここ20年以上にわたって、進歩を続けていて、利用できる状況が確実に拡大している。
自分たちのビジネスの分野で、画像AIが利用できそうだという直感に対して裏付けを与えていって、ビジネスの分野で成果をあげて、収益につながるようにもっていくことだ。
何をどうさせたいのか、ビジネスとしてのストーリーを描く。
その中で、どういう画像AIがあれば価値を持つのかを明確にしていく。
ぼやけた全体像でいいから、全体像を描いてみる。
何がボトルネックになりそうか、推測してみる。
そのボトルネックを解消するためには、どういう選択肢が必要なのかをリストアップする。
その１つとして画像AIエンジニアを雇うことが入ってくるだろう。

画像AIエンジニアの持つ周辺技術

深層学習
- 深層学習のアルゴリズム自体への寄与
- 自分たちの用途のためデータ・セットの準備と学習の推進
- 深層学習を含む技術の自社製品・サービスへの取り込み
- 特定のターゲットに向けたデプロイ
機械学習（例：SVM、クラスタリング）
画像の加工
画像信号処理
- ノイズ除去
- ボケの除去
イメージセンサ・レンズの組み合わせの選択
- 光学系の評価
- 画像認識技術との組み合わせでの評価
顔検出・顔照合ライブラリの評価技術・利用技術
物体追跡
大規模データの管理技術
バージョン管理
cloud storage の利用
python の自作ライブラリのパッケージ化(whl)と配布
画像計測
- ステレオ計測
ToFデバイスの利用
SLAM
Computer Graphics
イメージセンサのAF技術
イメージセンサの絵作り
- High Dynamic Range

場合０：画像AIを含む業務の全体像がわかる人物がほしい。

選択肢：

社内の人員の養成。
コンサルティングの利用。
画像AIを含む業務の全体像がわかる人員の採用。
自分たちのビジネスの状況に応じて、取り組み方は変わるはずです。早く動き出せる状況にたどりつく時間を買うために、画像AIの開発に関わった人物を雇れることは価値があります。ベテランエンジニアは、その分野の初心者がおかしがちな失敗と対策を知っています。

場合１：既存の画像AIシステム・モジュールを使ったシステムを組み上げたい。

例：顔照合ライブラリの利用
例：物体検出の既存学習済みモデルの利用

アドバイス：　実は、画像AIのエンジニアでなくても、素性のよいソフトウェアエンジニアならば、お役に立てる可能性があります。

もちろん、画像AIエンジニアの方が既存の画像AIシステムの利用上の注意点を知っているので、問題になりそうな部分を、評価し、課題を明確にし、問題点を回避する方法を知っている場合があります。
複数の候補となるソフトウェア(OSSや商用ソフトウェア)に対して、どのように評価するのがいいのかを考え、評価を実行することができます。その際に、必要なデータセットをwebから見つけ出すことや、自分たちでデータセットを作り上げることができます。

場合１ａ：　既存の画像AIシステム・モジュールを使ったシステムをメンテナンスしたい。

− 既存の画像AIを使ったシステムを運用し続けるうえで問題になるのが、依存ライブラリの問題です。

画像Ai・画像認識の分野で使用しているライブラリが複数になっているシステムがあるはずです。これらの分野ではpythonを使っていることが多い。しかもpythonのバージョンはあがってきていて、運用中のバージョンがEOLが近づいてきます。そのため、それらのシステムのバージョン問題を解決するためのメンテナンスが必要になります。機械学習では、onnx-runtimeやnumpy, sckit-learn, opencvなどを同時に使っていることがあります。そのことが原因で、複数の画像AI/画像認識のモジュールで依存ライブラリのバージョンでコンフリクトを生じることがあります。
これらの問題に対して、画像AIエンジニアが、特別有利な立場にありません。
商用ライブラリの場合には、ベンダーに対応を依頼する。
OSSのライブラリの場合には、依存ライブラリのバージョンを指定してして、自分でビルドし直す。

場合２：既存の画像AIシステム・モジュールで学習済みのモデルがあるので、それをターゲット環境に移植して、高速化を図りたい。

アドバイス：　対象デバイスへの移植になれていれば、素性のよいソフトウェアエンジニアならば、お役に立てる可能性があります。

PCでのある形式の学習済みモデル->ターゲットデバイスでのデータ形式の部分について、それぞれのライブラリについて調べることだけが必要な作業です。
もちろん、移植元のソフトウェアのバージョンと、移植先のソフトウェアのバージョンによって、移植関係の変換用のスクリプトの動作状況は変わります。
ターゲットデバイスでの高速化にはint16やint6への変換作業も含まれます。これは、ツールのサポート状況によってできることできないこととがあります。

この作業を行う際には、画像AIのエンジニアと含めて作業することを強く推奨します。
理由：

高速化によって、性能が劣化していないかどうかの検証が必要です。
検出されやすい場合に検出されることは簡単ですが、
検出されにくい場合の性能劣化に気づくには、画像AIのエンジニアが必要です。

場合２ａ：　GPUやDLA(Deep Learning Acceralator),マルチコアやSIMD命令やFPGAなどを、独自の手法で高速化をしたい。

この分野は、通常のSWエンジニアにも、通常の画像AIのエンジニアにとって、手強い分野です。
この分野のエンジニアに対して、学習データのデータの品質についても問題やデータのマネジメントを頼んではいけません。
今まさに、その作業をしているのでなければ、さっさと、すぐに高速化をしてくれることはできない可能性が高いです。
最適化しようとするアルゴリズム、ターゲットデバイスの特徴によって、最適化のしかたが変わってきます。
コンパイルオプションに -O2, -O3を付けるだけみたいな世界ではありません。
データの処理の流れの中で、いま一番のボトルネックになっている部分から解決していく必要があります。

場合３：既存のOSSの画像AIシステムのうち、カスタムモデルに置き換えて利用したい。

アドバイス：　素性のよいソフトウェアエンジニアの方でも、画像の機械学習についての知見がないと成功はのぞめません。　画像認識関連のgithub をgit clone して動作させているユーザーの方でも、カスタムモデルで学習を実行するには簡単ではありません。

学習用データが用意されている範囲をトレースする。
その例と同じアノテーション形式でアノテーションを学習用・評価用に追加してみる。
追加した評価用データでの性能を評価してみる。

これらができるようになったら、以下の作業です。

ユースケースにそった学習用・評価用データを収集・撮影する。
アノテーションを付ける。
学習を実行し、評価を行います。

画像AIエンジニアの場合、このような学習を行うときに、初心者の学習者では、どのような部分で性能の不足が生じやすいのかについて感が働く傾向があります。機械学習の汎化性能を確保しようとするのは、既存の機械学習のアルゴリズムにどのような弱点があるのかを知っている必要があります。また既存のデータセットにはどのような弱点があって、ビジネス上のユースケースにとって弱点となりうるかを知っている必要があります。経験の豊富な画像AIのエンジニアはそれらの役に立てるでしょう。

場合４：　カスタムモデルでの機械学習を構築できるようになっているが、大量のデータで学習・評価をできるようにMLOpsをたてつけたい。

MLOpsでは、必要な処理の定型化・自動化を行うことになります。その意味ではDevOpsのエンジニアと共通する部分があります。MLOPsという枠組みが成立して年数が少ないので、MLOpsのエンジニアは多くないはずです。しかもMLOpsはどのフレームワーク上で行うかによって、実作業は違ってきます。おおまかな考え方が同じフレームワークならば、その考え方をもとに別のフレームワークのMLOpsをたてつけることになるでしょう。

MLOpsは、画像AIエンジニアとDevOpsエンジニアとの共同作業になるはずです。

場合５：知られている画像認識のタスクに対して、既存のアルゴリズム上の課題を解決して、実運用の可能性を拡大させたい。

このような作業は画像AIのエンジニア冥利に尽きるものです。
ほとんどのSWエンジニアの場合、このような作業は難しい作業です。画像AIのエンジニアになりきることが必要です。
このような作業を実現するには、課題を分析して、何をどう実現すれば成功できるかを考える必要があります。
着想を明確化するエンジニア、それを実装するエンジニアの双方がいるチームが妥当でしょう。
最新のアルゴリズムのコードが１名のエンジニアで書かれていることは、まれで複数のメンバーで書かれているのが多いです。
このような場合、学習・評価用のデータの収集・アノテーション作業に、アルゴリズムチームの工数をうばってはいけません。
このようなアルゴリズムチームに対しては、論文を執筆する許可や、場合によっては、OSSでコードを公開する許可を与えてください。
このような開発を継続できるようなメンバーには年収1000万円でも安すぎると私は思います。
問題は、このような作業に対して意気込む候補者が、それを実現できることを客観的に事前に示す方法はないということです。
画像認識AIのエンジニアに対して、採用する側の見極め能力が必要です。
また、せっかく獲得した有能な画像認識AIのエンジニアを、全社一律のリストラで手放さないことです。
理不尽な扱いをしないでください。
このような方を、MLOpsの立ち上げに使ってはいけません。

場合６：今ある事業上の課題のなかで、何が画像AIで解決可能になっているのか、何をどう取り組むべきなのか？

この問題設定の場合ですと、その事業のなかでの課題に対する適切な優先付けが必要です。
画像AIエンジニアができるのは、この事業場の課題を熟知している方との共同作業です。
画像AIエンジニアは、魔法使いではありません。
事業上の課題解決のため、いっしょに考えることです。
そのために画像AIエンジニアを社内に取り込むのも良いですし、コンサルタントの画像AIエンジニアと取り組む、あるいは、外部の開発者と組むのもよいです。

場合７：　画像AIを含む製品・サービスの仕様の策定への参画

これの段階で画像AIエンジニアを含めることを推奨します。
どういう仕様ならばビジネス上価値があるのかという視点と、画像AIの可能なこと、可能にしていくこととをすり合わせるためです。
例：ADASのための歩行者検出の場合
- 何m先の人まで検出しなければならないのか
- ハンドリングの状況の中で、どの視野の範囲で検出しなければならないのか
- 許容できる遅延(レイテンシ）はいくらなのか
- フレームレートはいくらなのか
- 人の位置の距離の精度はどれくらい必要なのか
- 足元が隠れている人の距離の精度はどうなのか
こういったさまざまな問題をプロダクトオーナーと一緒に考えていく必要があります。

場合８：レンズ・イメージセンサ・照明・撮影条件を含めた画像として評価

画像AIは、撮影した画像によって性能が決まってきます。
画像AIシステムの性能を見極め、仕様を作成するには、レンズ・イメージセンサ・照明・撮影条件なども重要な要素です。
製品の満たすべき内容を、これらのパーツの仕様に落とし込む必要があります。
レンズ・イメージセンサを含めた評価のために、どのような実験をして仕様を確定できるかどうかは、担当者の力量と経験に依存します。
画像AIエンジニアの中には、このような経験を積んでいる人もいます。
画像AIを含むシステム設計では次のような作業が必要になります。
- カメラの視野角・解像度・画像AIに入力させる画像範囲の選択
- 画像AIでの入力解像度の選択
- 画像AIに入れるfps
暗がりでの特性・極端な照明変化を考慮する必要があるかどうか
- そのような状況でも性能を出そうとすると、次のような考慮が必要になります。
- レンズ・イメージセンサ・蓄積時間の選択が十分なSN比を可能にするか、どうかです。
- 低照度条件でのノイズの部分については、イメージセンサを含む基板の開発メーカーとの交渉が必要になります。

場合９：空間の認識と時間の認識とを満たす画像AIのエンジニアを求めている

この場合、センサの時刻情報の管理とセンサの空間配置が重要になります。
回路設計・ファームウェアのエンジニアの協力が必須です。
その部分なしに、空間の認識と時間の認識とを満たす画像AIを作ることは不可能です。
画像AIのエンジニアは、画像のファームウェアの開発者ではありません。
画像取得の時点で、レイテンシが大きくなってしまったシステムでは、できることが限られます。
バッファリングされた画像を入力とすることは、空間の認識と時間の認識とを満たす画像AIでは推奨されません。
このような分野の場合、単独の画像AIのエンジニアで解決できる範囲を超えています。
このような分野に詳しいエンジニアとその他のエンジニアが協力して取り組むことが必要です。
空間の認識には、ステレオ計測・ToF画像の利用・単眼カメラからの空間把握などがあります。
空間の把握・点群の理解などは、独自の経験が必要になります。
その分野のエンジニアを雇い入れたい場合には、任せたい内容を十分に明確にして求人を出すことです。
自律移動ロボットの市場が拡大しているので、この分野のエンジニアへの需要は多いと思われます。
− 必要な経験を明確にして、十分な待遇を明らかにして、業務の魅力を伝えて、採用をかけるのがいいと思います。

場合１０：新しいタスクを設定して新しい価値を生み出す画像AIを開発する。

本質的な部分で画像AIを開発することこそが、大きな進展を作っていきます。
そしてそれを社会で共有することこそが、画像AIや機械学習の未来を作っていきます。
この部分を実現することが競争力の源泉になります。
こういう分野の開発をするためには、開発者を信頼することが重要になります。
信頼できる開発者・研究者を選んでチームを作ったあとは、過度な干渉をしないことです。
開発の目標を、組織の目標に沿うようにすること。
開発の成果を、組織の利益にそぐうようにすること。

場合：　学習を実現するデータそのものの品質を確保して、学習と評価の性能を達成させる。

重要なことを忘れていた。
学習を実現するデータそのものの話だ。
− 最新の機械学習のOSSをgit clone し、インストールして、学習を実行することは、手順をたどっていけばできる。
学習させるデータの品質の確保だ。
機械学習が失敗するさまざまな要因を理解したうえで、適切な学習・評価データを確保するための作業だ。
この分野は、重要性が高い割に、詳細に語られることが少ない。
機械学習の経験者の知見を入れることが大事だ。
- AIモデル作成は簡単ではなかった

画像AIエンジニアの見極め方

どういう種類の画像AIのエンジニアがいるのか

機械学習、画像認識分野の研究室の出身者

2010 年以降は増えてきている。
深層学習・SVMなどのアルゴリズムを大学で学んで、研究室の教育水準によっては、そのレベルも高い。
github, pythonなどが研究に着手した頃には、この分野で使われている。

深層学習以前からの画像認識の開発者

顔検出が普及したころの時期のエンジニア
物理や情報工学などの分野の出身者が多く、企業内で画像認識に取り組んできた人々。
HaarCascede　の顔検出, HOG-SVN　の人検出などを参考に独自の改良を積み上げてきている。
OpenCVはC言語から利用している世代。
機械学習の前に、どのように画像を事前に処理しておくかで、性能がどれほど変わるのかを経験している。
画像処理の分野も詳しいことが多い。

マシンビジョン系のエンジニア

マシンビジョンは、制御された条件において高速に、外観検査を行うことで独自の進化を遂げてきた。
そのため、使用するライブラリが独自の商用ライブラリの比率が高い。
マシンビジョン系とそれ以外の分野での交流が意外と少ない。

画像AIのエンジニアは利用言語がPythonに偏っています。

C++は、業務としてのコーディングスタイル・使用してOKなライブラリ・マルチスレッドのライブラリなど、どのみち再学習してからでないと実用プログラムになりません。

C/C++ については、OpenCVとの組み合わせでしか使ったことがない。
そういった偏った経験になりがちです。
限られた組み込み経験も、メモリ領域を確保を静的に確保するスタイルのコーディングだったりします。
C/C++は、安全ではない推奨されない機能がいたるところに存在します。
そのため、ふだんの作業がPython上、MATLAB上などになっています。
ですから、C/C++のコーディングテストで、画像AIエンジニアの能力を見極めるのには適しません。
しかし、経験をつんだエンジニアの場合ならば、次のようなステップでC/C++のコードを開発できるはずです。
- PythonやMATLABでアルゴリズムを構築する。
- テストを所定の動作をすることを確認する。
- それぞれの言語の範囲で高速化を実現する。
- 検証された手順をC/C++で実現させるための対応のライブラリを調べる。
- それをC/C++で実装する。
- 動作の期待値が、Python MATLABバージョンと同じことを検証する。
- C/C++の範囲でプロファイリングを行い、ボトルネックを見極めて高速化する。
- 単体テストの自動化を行う。
- その製品が満たすべきコーディングのガイドラインがあれば、それに適合させる。
C++はスマートポインタ以降のバージョンを使い、Boost C++ ライブラリを使うことでしょう。

画像AIを含むタスクの多くは、後処理に別の機械学習を必要とし、画像AIエンジニアは、それらを習得している。

画像AIのエンジニアの多数は、scki-learnにある機械学習の各種の手法を習得しています。
それらは、画像に限らない技術です。
分類・回帰分析・クラスタリングなどです。
それらを画像認識の後処理や、画像とまったく関係のない機械学習にも習得していることが多いです。
主成分分析・SVMなども使いこなせる人が多いです。

画像AIエンジニアも学び続けている。

Python 言語にtype hintを付けることで、可読性の向上
pytest を用いた単体テストで、実装の劣化を防止する。
CircleCI などの利用
データの管理、git lfs, DVC(Data Version Control)

あなたの会社のチームとは、別のクラウドサービスしか知らないといって、採用を断念しないでください。

クラウドサービス環境は１つに熟達していれば、他のサービスも同様に使えるようになるはずと思ってください。
最近は、クラウドサービスを利用しながら開発することが増えています。
しかし、AWS, Azure, Google Cloud Platformなどについて同時に習得している画像AIエンジニアなんて、まずいません。
そのエンジニアが利用してきた種類と、あなたの会社のチームが使っているサービスが違うからといって、採用を断念しないでください。
あなたが雇い入れたいのは画像AIのエンジニアなんです。

直近の担当業務だけで、能力を見極めてはならない。

開発している製品のなかで必須（MUST）な項目とあったほうがいい（should better）項目では、必須の項目を優先させなければなりません。
そのため、アルゴリズムの開発ができるエンジニアでも、タイミングによっては、学習・評価データの収集に集中していることがあります。
ですから、学習・評価データの収集しかできない人と間違えないでください。

プロジェクトマネジメントとアルゴリズムの開発能力

Q: 画像認識・機械学習を知らない通常プロジェクトのマネジメント経験者と画像認識・機械学習を多数解決してきたエキスパートで、たまたまマネジメントをしてきていない人とどちらに仕事を任せたいのか？

アルゴリズムの開発能力を求める場合の画像AIエンジニアに、その時点でのプロジェクトマネジメント能力を求めてはいけません。
画像AIエンジニアは、多くの場合エンジニアチームに所属して切磋琢磨しています。
新しいアルゴリズムを考案する、新しい工夫をなしとげるそういう部分に特化しています。
その時点でマネジメント経験が蓄積していることはありません。
しかし、それはマネジメントをできないことを意味しません。
解決すべき課題には、どこにどのような注意点があって、それをどのように、解決していけばよいという筋道が見えていたりします。
課題が画像AIに強く関わっている問題ならば、画像AIを知っているマネジメント初心者の方が、画像AIを全く知らないマネジメントのベテランを上回る可能性があります。

製品開発マネジメントと研究開発マネジメント

これらは別物です。

開発の現場だけを経験してきたエンジニアをどう評価するか

雇用側であるあなたは、マネジャーに対して何を期待するのか？
- 提供するサービス・製品の全体像が、ユーザーに対して適切なものを提供させること。
- 依頼元と受託側での内容の取り決めを適切なものにして、責任を明確化して、費用についての取り決めを行うこと。
- 提供するサービス・製品の開発に対して、社内の開発チームなどのリソースの確保、社内の開発チームのチーム内の開発のマネジメント
- 提供するサービス・製品の開発に対して、何をどのような技術を使って実装するのか、開発チーム内の知見を利用して、開発方針を定め、実装していくのか？
- 開発スケジュールの中で開発を実現するために、どのような開発スタイルをするのか、それをチーム及び、社内で合意形成をしていくこと。

画像AIエンジニアの過去の成果を評価するには、当時の技術水準の中で評価してください。

深層学習以前の画像認識（例：顔検出・顔照合、人検出・人追跡など）は、深層学習によって置き換えられました。
今はよく知られた改良手法も、当時は知られていなかったのです。
新しいことを作り出せるエンジニアであることを確認してください。

画像認識・画像AIエンジニアの側の技術的な方向性

応用志向
応用志向の中での課題解決としての技術要素の開発
技術トレンドの中での技術開発

画像AIエンジニアが応募してきているときに、何を期待しているのかを確認しよう。

どの段階の仕事をしたいのかで、相性が大きく異なる。

いま何をどう取り組ませたいのか？

いま何をどう取り組ませたいのかに対しては、確実にできること、たぶんできることなどがあります。
たぶんできることに対して明確な証拠を出すことはできません。
アルゴリズム開発者が、「こう改良すれば従来を上回るんじゃないかな」と考える時点で、確実に上回ることを示すことはできません。
もし、証拠を開発前に出せるという人がいたら教えてください。

自分たちの開発スタイルを示そう

開発で成功するためには、開発スタイルが重要である。
開発がうまくいくように改善してきた開発スタイルを示すことで、共感してくれるエンジニアが集まりやすくなります。

採用予定者の足りない能力は、既にいるエンジニアから学び取らせよう。

StackOverflow などで問題の解決方法を探り当てているエンジニアは、新しい環境の中で新しいライブラリ・フレームワークを学び取ることができます。
そのため、不足している経験があっても、チームのメンバーが教えることができれば、問題はないでしょう。

画像AIエンジニアを雇い入れたいあなたの状況は、１つとして同じじゃない。

画像AIエンジニアを雇い入れたいあなたの組織の事情や業務は、何一つ同じものが、あなたの組織の過去の事例の中にありません。
いま必要なことに対して、重要性を占める素養はなんですか。
いま必要なことに対して、重要な素養をもった人を選ぶべきです。

画像認識の分野は広く、しかもそれぞれの分野が2~3年で技術が大きく変革を生じている。

そのため、画像認識の全ての分野で最新の技術をすぐ活用できる画像AIエンジニアは存在しません。
あなたの職場で必要としている画像認識技術はどういう分野であるのか、そしてどのプロセスに対してエンジニアを求めているのかを明確にすることです。
そして明確な職務内容と、そのポジションに対する魅力を十分明確にすることです。
もし合致するのであれば、新卒の学卒・院卒に対しても十分な待遇を与えることです。
「安く値切れればそれに越したことはない」という発想では、たとえ採用に成功しても、彼ら・彼女らの知見が開発チームで受け入れられずに終わってしまうことでしょう。
「動画像コーデック技術開発、国際標準化、システム開発をグローバルな環境で行える能動的な人材を募集します。」に対して「＜賃金内訳＞　月額（基本給）：250,000円〜」というのは、世の中なめてませんか。

コーディングテストの限界

コーディングテストはアルゴリズムの知識を測るもの
ジニアは不慣れな環境で試験を受けなければいけない
ディングテストの内容が実際の業務内容とかけ離れていることが多い
引用元

そのような注意をもって、コーディングテストを利用してください。
求める能力を持っている人が、コーディングテストで不十分な得点になりやすいのです。

参考文献

プロジェクト・マネジャーが知るべき97のこと/スキルでなく素質のある人を加えよう

プロジェクト・マネジャーが知るべき97のこと/私たちはスーパーヒーローではありません

プロジェクト・マネジャーが知るべき97のこと/すぐれた開発者を見つけるには