はじめに

大規模言語モデルとか深層学習を使ったうえで、自社の製品・サービスの開発にぴったしのエンジニアを採用したいと思うだろう。
しかし、そういうぴったしのエンジニアが見つかりにくい理由を述べようと思う。

機械学習のタスクは、とても広い。

例として画像認識タスクを示す。

物体検出
顔照合
セグメンテーション
トラッキング（＝追跡）
３D計測
ポーズ推定
属性の推定
Visual Question Answering
caption生成
画像生成
動画生成

拡大中の機械学習タスク

生き物の認識機能が行動との関連付けの中で発達してきたことを考えると、機械学習自体も
なんらかの行動とひもづいていくのは自然なことだ。
だからEnd-to-endの行動までを含めた機械学習の分野が拡大している。
単純なグリッパーであっても、カメラと視覚言語モデルとの組合せによって、多くのチャレンジがなされるようになってきている。

どの分野のタスクにも、苦手な条件が存在する。

苦手な条件を克服するためのアプローチはタスクによって異なる。
データの増強なしに、エレガントに解決できるのには限界がある。
人々の期待とのギャップは残り続けている。

どの分野にも、応用上の課題が存在する

想定している用途でのデータを増やして、必要な精度を達成させる。
十分な実行速度がほしい
組み込み可能なデバイスで動作させたい
計算量を削減したい。
精度が十分に出ない時の利用上の対策を考案し、実施する。

これらの理由のため、何をしなくても十分ということは、ほとんどの場合ありません。

当社の事業の中での成果物とのつながりが見えない

「機械学習の成果を、当社でどう利益に結びつけていくのかは、機械学習エンジニアのあなたの見解は見当はずれし、考察が足らない。」
「あなたはなにも事業がわかっていない。」

「いろいろ結果を出してきたようにいうけど、最新技術の移植じゃないか」

「最新技術の移植で、独自のアルゴリズムなんて作ってないじゃないか」
「最新のフレームワークで、学習しなおしただけじゃないか」
「最新の商用ライブラリをもってきて、追加の実装をしただけじゃないか」
このような点も応募者の能力が不十分なんじゃないかという気がしてくる。

このように応募者の能力は不十分に見える

あなたは、画像認識を含む機械学習タスクを製品・サービスに組み込むために、エンジニアを募集します。
しかし、現時点でのそのタスクの分野に対して、応募者の能力は不十分に見えます。

状況

「最新のOSSでの実装を超えるような実装をいま持ち合わせていないじゃない」
「最新の大規模言語モデルの枠組みで学習をしたことがないんじゃない」
「最新の動画生成AIでphoto realistic な路上動画を生成したことないんじゃない」
「End-to-endのロボットアームの動作生成なんてしたことないんじゃない」
「異なる視点の数枚の画像から、対象物のモデルをリアルタイムに創り出すなんてやったことがないんじゃない」
「Cudaデバイス以外のデバイスで、最新の組み込み用のアクセラレータ使ったことないんじゃない」

状況その２

「エンジニアしているけど、論文全然書いていないね」
「特許も出してないんだ」
　所属した会社・部署の方針により、自利用している技術の詳細を語れないことが多い。
特にアルゴリズムの場合には、特許の侵害を証明しにくいという理由のために、特許出願をしないことが多いです。
そのため、回路規模を1/10にしたようなアイディアでさえ、特許出願されることはありませんでした。
そのため、有用な結果を出したエンジニアであることの証拠を示しにくくなってしまうことがあります。

だれだって、自分をすごいように言うよ

ある会社が、そういう技術を作って利用しているのは知っている。しかし、それがあなた一人の力じゃないでしょ。

このように、応募者の能力は、常に不十分に見えます。
ではどうしたらいいのでしょうか。

ピンポイントでこちらから探しに行く

その分野のその技術をまさ今に開発している場所にコンタクトをとる。その人を引きづりこむ。
ピンポイントの分野での求人をしようとするならば、これしかありません。
その人が応じてくれるだけの開発環境・待遇を用意することです。
そうすれば、キャッチアップの時間も短縮できますし、すぐに、世界の最前線に立つことも可能になります。

優秀な開発者は、自分が結果を出すためには、ちゃんと物事が判断できる人がいて、必要な開発のための投資ができること、
同僚の開発者も優秀である環境が重要なことを知っています。
あなたの会社が、そのような会社であることを発信していれば、入社してもらえる可能性が高くなります。

その分野を今まさに開発している人を引きづりこむことができれば、開発成功の可能性は高くなります。

この文章での主題

この文章では、ぴったしのエンジニアが見つかりにくい理由を述べます。

ぴったしのエンジニアが見つかりにくい理由

個々のタスクに対する進展がとても速い

そのため、過去の業績はすごい速さで陳腐化して見える。
過去の実装を作り上げたということは、「いまさら〇〇の経験言われたって」と逆評価さえ引き起こす。

国際学会で発表しているレベルの研究者でさえ、世界的には数万人以上いると見られる。

機械学習の分野の進展は、１０年前の速度よりも速くなっています。しかも、他の分野でこれほどの速度で進展している分野がないというくらいに、大規模言語モデルの機械学習の分野は競争が激しく、急速に変わっています。
そのため、一人のエンジニアの寄与できる比率は、とても小さくなります。顔照合の実用研究をしている会社が１０社程度だった時代とは違うのです。

ちょうどその分野を開発してきているエンジニアでないかぎり、ぴったしにはならない。

期待する開発内容は、その時々に変わる

先進のテーマを開発できるのは、その状況にいる人だけ。
- ぴったしのテーマを開発している人は中途採用の転職市場に出てこない。
- その分野でいまの時点での最良の実装を実現できていると客観的な証拠をだせる人なんて、ほぼいない。
データもなく、開発資源もない人物は、勝負にのぞめない。

業務利用を前提としたとき、優秀なエンジニアはいきなり独自実装を始めない。

業務利用では、確実に結果を出すことを優先します。
そのため、既存の実装で利用できるものがあればそれを利用します。
独自実装は、実装に時間もかかります。期待した性能がでるかもわかりません。
独自実装ができる能力のエンジニアでも、まずは既存の実装の評価・利用から始めます。

ほしい分野の技術経歴をもつ人がいない

視覚言語モデルという枠組みが出てきたのは最近ですね。その分野で学習やtransformerのネットワーク構造を使いこなしている人がいない。

暗記していることだけを利用したコーディング試験は、能力を過小評価する。

実現したい内容をコーディングする際には、ライブラリの理解が必要
常にライブラリの仕様を確認しながら実装する。
web上のコーディング試験は、環境の悪さのために、過小評価する要因となる。
アルゴリズム重視とシステム開発重視では、必要な能力が違う。
このため、webテストでのコーディングを実施しても、期待する水準のエンジニアは見つからないということが生じます。

このように職務経歴やwebテストで目的の人材は見つからない

期日までに目的の開発を成功させたいのに、目的の人材を見つけることが苦慮していることでしょう。

人がいないと嘆くのは正解か

エンジニアは変わっていける。適切な誘導があれば、変わっていける人も多い。OSSによる実装から、自分たちの目的にそったものを見つけ出して活用する人も多い。
データを分析する力、機械学習の結果を適切に疑って改良できる力、そういう資質を持っている人はいます。
もちろん期待はずれの人もいるでしょう。期待はずれの人を採用してしまうリスクは減らしたいですよね。

学び続けられるエンジニアならばついていけること

目的が明解な範囲でのライブラリ・言語の習得
タスクを明示したうえでの最新の実装の調査

採用側企業の事業の中での価値について

これは、機械学習にとりくんでいくんだという会社側の姿勢に依存します。
担当の機械学習エンジニアだけで決められる問題ではありません。
事業の状況を知らない応募者が、申し分のない提案ができるなどと期待できるのは、期待のしすぎです。

ドメイン知識があるというのは貴重なこと

機械学習は、学習させる内容、学習させた結果の利用のしかたなどの詳しい方が、そうでないより圧倒的に有利になる。
もちろん、まっさらな前提知識でデータサイエンスの視点で学習を作り上げていくというのもある。
しかし、学習させるデータの品質の問題や、現象の解明に不可欠なデータがあるのに、欠落しているという問題に対しては、データサイエンスの側から補うのは大変だろう。例：ある画像が病気を示しているのか、そうでないのかという真値を与えるのは、その分野のドメインの知識のある医療関係者だ。

それ以外の分野でも、外観検査には今までの外観検査の蓄積がある。
どこまではOKでどこからNGとなるのかは、素人には判断がつかない。

言語Aから言語Bへの機械翻訳が正しい内容になっているかを判断するには、言語Aと言語Bのドメイン知識が必要だ。
ドメイン知識を学ばないままに、その分野の機械学習で成果を上がられるとは考えにくい。

画像認識タスクの多くでは、なぜドメイン知識に着目されないのか

人は、画像に写っているものが人であるとか、自動車であるとかたやすく判断する。
人は、写真に写っている内容が空間としては、どう広がっているのだろうかをたやすく判断する。
そのために、画像認識タスクの多くでは、機械学習のエンジニアが、等しく、ヒトによる画像認識という分野のドメイン知識を持っているという前提に立っている。
そのことが、ドメイン知識に着目されていない理由である。

画像認識タスクの多くでも、レンズ・イメージセンサというドメイン知識を活用しよう

実は、画像認識分野の機械学習では、レンズやイメージセンサの知識はドメイン知識の一種である。
レンズやイメージセンサの内容によって性能が格段に違ってしまうからだ。
レンズやイメージセンサの選び方は、それなりの知見がいる。
イメージセンサは、なにも考えなくてもいい絵がとれる魔法のセンサではない。
iPhoneなどのカメラアプリがとても優秀にできているから、
自分たちが用意しているレンズ・イメージセンサでも、簡単に同等の水準にいくとは思わないことだ。
適切な露光条件にしないと、白飛びしたり、暗かったりする。
露光時間の長さによっては、モーションブレを生じる。
そういった知見を、画像の撮影に反映させることができる。
そういった知見は、機械学習の分野にも効いてくる。

レンズ・イメージセンサの知識を持つエンジニアは、カメラとボードとの接続・タイムスタンプ問題・カメラ姿勢問題を気にする。

カメラとCPUボードとの接続方式を気にします。
そしてその方式で販売されているカメラを調査します。
画像の解像度・フレームレート・帯域を気にします。
何台のカメラを接続できるのか気にします。

画像認識の推論用のデバイスというエッジな世界の経験

Cuda デバイス
Jetson Deep Learning Accelerator (DLA)
Google TPU
Intel Movidius
OpenCV AI Kit
HAILO
画像認識のFPGA実装

機械学習を加速するのはCudaのGPUだけではない。さまざまなターゲットデバイスが存在する。
それらで、推論をさせるのは、かなりニッチな技術だ。
そのようなドキュメントも不足しがちな状況で移植していくのは、才能が求められるだろう。

新天地は経験者が少ない

ロボットハンドの触覚の機械学習には、ビジョン系の機械学習の技術と同じものが使われている。
ロボットハンドの触覚を用いた学習は始まったばかりなので、経験者がいるわけがないし、
市場にそういう人がでてくるわけもない。
だから、「ロボットハンドも学習できる」と自己主張するビジョン系のエンジニアを採用するしかない。

新天地で挑戦し続けられる素質はあるのか

新天地の分野で機械学習を成功させるのは簡単ではない。
あきらめやすい人は、結果のたとどりつけない。
自分たちの強みを理解していること
不足している内容を補うための行動がとれること
経験したことのない分野の論文を読むのをひるまない。
見通しをたてるための実験が計画できること
採用されやすくするために根拠のない「できます。やります。」を言う人を鵜呑みにしないこと。
そういったことのできる人かどうかの見立てが重要になります。

いま担当していない部分については、その時点ではできることが限られる。しかし、担当すればできる人も多い。

C++ 2014 以降の規格を漠然と理解していても、その規格にそったコーディングを日常的にしていなければ、すぐには書けない。
しかし、素性のよいソフトウェアエンジニアであれば、そのスタイルでのコーディングに慣れ親しんでいけるだろう。
あなたの会社には、既にC++ 2014以降を使いこなしている人たちがいるのだから、そのコードを学んでいける。

たくさんのOSSの実装が出てくる時代に必要な能力

自分たちの用途に必要な実装は何であるのかを、明示的に示せる能力

　何を入力とし何を出力とするアルゴリズムで、どのような性能が出ているかを示せれば、自分たちの用途では十分であるかを示せる能力
足りない部分があれば、それを明示的に示して、その開発が進められるように促すこと。

よい実装を見つけて利用する能力

　ある目的のための定式化したタスクに対して、どの実装を利用するのがいいのかを選び出せる能力
　産業上利用する目的では、ライセンスがOSSでありかつ品質が十分であれば、それを用いて、独自開発をしないという選択肢もあります。
　よい実装を見つけて利用する能力が、従来よりも重要になるでしょう。
　既存の実装を利用しつつ、使いやすくするため、コーディング能力が不要になることもないでしょう。

よい実装をよい実装として広めていくこと

よい実装は、使われていってこそ価値が高まります。よい実装を見つけたら、それをいいねしましょう。その分野での実装の調査の出発点にできる状況にしましょう。
よい実装は、ライブラリとして標準化されていき、コミュニティとしてメンテナンスされるようになっていくことがのぞましい。
そのようなコミュニティのメンバーにあなたはなれるはずです。

データに対する洞察力をその人が持っているか気づけるか。

適切なデータセットを作ることこそが、機械学習の要点。
しかし、アルゴリズムの方だけがすごいと勘違いする。
現実的なエンジニアは、まったくの新規のアルゴリズムの開発よりは、既存モデルの改良を優先する。
新規アルゴリズムを作れる力量を持っていてもだ。
このため、新規アルゴリズムを作れる力量を持っているエンジニアまでも、「データの改良をしかできない人」と勘違いする。

スキルでなく素質のある人を加えよう

これは「プロジェクト・マネジャーが知るべき97のこと」にあるエッセイの１つだ。
変化が激しい分野では、ある時点でのある能力なんてどんどん陳腐化していく。
学び続けることができるか、結果をきちんとまとめ上げることができるか。
数学を使って世界をモデル化する能力も、深層学習や大規模言語モデルのアルゴリズムの理解に必要な素質になっていないか。

その人物は新しい分野を学び続けられる人物か

新しい分野での機械学習であれば、その分野を学んで適切な判断をできるようにしていく必要がある。
分野によっては日本語の文献が存在しない。
それでも文献を読んで理解して、次の行動を起こせる人物かどうか。
機械学習は、機械が学習する以上に人が学習しなければならない。
あなたが、その人物にさせたい内容をその人物は理解できるだろうか。
そういった内容を面接を通じて確認するのがいい。

マネジャー経験は本当に必須なのか

先進的なアルゴリズムの分野の場合には、そのアルゴリズムを実現してものにするために、組織の中でのチームワークが必須です。
そのなかで、チームのメンバーの協力を得るために、必要なことをわかりやすい言葉で述べることになります。
お互いの事情を理解して、どう歩み寄ることができるのか必要になります。
それを実現できていれば、採用先のチームの中でもできる可能性があります。
先進的なアルゴリズムの開発の分野では、自分自身がコードが開発できることのほうが重要であって、自分でできることを仕様書を書いて、外注することは少ないはずです。
ですから、マネージャ経験の比率よりも、問題を自分で解決するコードを書けることの比率の方が重要性が高いということはないでしょうか。
マネジャー経験を必須にしてしまうと、せっかくの人を候補から見逃してしまっていないでしょうか。

簡単に教えられるpythonのパッケージ化の手法

画像認識や機械学習のアルゴリズムに注力している人は、ときとして自作ライブラリのパッケージ化の手法に詳しくないことがあります。
でも心配いりません。これらは簡単に習得可能なことです。
Python プログラマのスキル標準化のための項目を参考にしてください。

既にいるメンバーで足りていることがあれば、要求を減らすこともできる。

MLOpsをこれから作り上げていかなくちゃならない状況だと
MLOps を作り上げられているくらいのソフトウェア管理・データ管理のノウハウが必要だ。
しかし、既にできる人がいれば、追加のメンバーはその人に学べばいい。
学べるだけ人物であれば、いいと採用の条件を緩めることができる。
webアプリケーション開発も同様。

一人が加わるだけで物事が解決することは少ない

加わったエンジニアと前からのエンジニアが一緒になって取り組むことが、解決につながる。

データが不足しているときにできることは限られる

期待した結果を出してもらおうとエンジニアを雇い入れても,
データが不足しているときは、できることが限られる。
データエンジニアを寿司職人との共通性をあげている記事をどこかで読んだ。
元のネタがよくなければ、いい結果はだせないということだ。
「ぴったしの機械学習エンジニアじゃなかったな」と判断する前に、取り組みの中で必要なデータを提供できているかを確認してみてください。

解くべき課題の定式化は、それでいいのか

解くべき課題の定式化は、その実現可能性という部分に関係しています。
解くべき課題が、その時代の実現可能な範囲に入っていなければ、どんなにきれいな定式化であっても、実現できません。
人検出のタスクがある程度実現できないうちは、人の姿勢検出は意味を持つタスクになりようがありませんでした。
言葉の類似性や文脈依存の解釈ができる言語モデルができる前は、自由なキーワードでの物体検出など、定式化が意味を持ち得なかったでしょう。
今の技術の中で実現可能な範囲に、解くべき問題の定式化が入っていますか。

解くべき課題のビジネスとしての定式化は、それでいいのか

見逃しも誤検出もない検出技術は理想です。
しかし、現実の問題としては、何らかの見逃しが発生するか、何らかの誤検出が生じます。（あるいは両方生じます。）　そのような中で、どのように運用するのがよいのかをビジネスの問題として考えなくてはなりません。

見逃しと誤検出では、どちらの方が深刻な間違いになるのか？
それぞれの間違いの結果は何が生じるのか？
これらの情報の提示がないまま、見逃しも0%、誤検出も0%を求めることは有効ではありません。
誤検出を減らすためのデータセットの追加のしかた、
見逃しをへらすためのデータセットの追加のしかたが
あります。
それらのためにも、ビジネスとしての定式化の中身をエンジニアに伝えることが大切です。

Ubuntuどっぷりのエンジニアはパソコンも使えない人に見える。

Ubuntuどっぷりで作業しているエンジニアは、Windowsを使うことがありません。
そのためwindows のExcelのマクロなんて使うこともありません。
利用しているパソコンにはUbuntuしかなくて、windowsのアプリケーションなんて使うことがないのです。
そのため、windowsで作業されているあなたは、「自分でさえ知っていることをなぜ知らないんだろう」と思うでしょう。

何を解決してほしいのかを明確に伝えられているか

何を解決してほしいのかを明確に伝えられていれば、ミスマッチは減るだろう。
採用担当の人には、必須の項目とそうじゃないものを明確に伝えること。
必須としている条件を満たしているのに、それ以外の条件を元にお見送りにしてしまうことを防ごう。

web面接であれば、エンジニアとの打ち合わせもしやすいものです。

解決したい課題に近い分野のエンジニアを交えて、web会議をしてはどうでしょうか。
web会議で、面接の手間は格段に少なくなりました。
力量のある社内のエンジニアは、その候補者が妥当なものかどうかを適切に質問で見極められるはずです。

期待倒れになる場合

　応募者が十分な資質を持ち合わせていない場合、あなたの会社の期待にそえない場合があります。
　このような場合には、あなたの会社の期待に添えないことがありえます。
　

機械学習分野での適切な直感を持たない場合
最新の実装を論文やコードで調査する力量を持たない場合
タスクの実現に対して執着心がない場合
期待する内容が、並のエンジニアの水準をはるかに上回る場合
既にいるエンジニアとの相性が悪い場合
機械学習分野を理解するための数学の理解がない場合
開発のベースとなるソースコードを読解する力がない場合
開発の要求を出している側が、開発の要求仕様を伝えることができない場合
- 期待している内容がころころ変わる場合には、それを満たすことができません。
- 期待している内容が、現時点での技術の水準よりもはるかに上回っている場合
機械学習で必要なデータをそのエンジニアがアクセスできない場合
　これはどのようなエンジニアでも対処できません。

あなたの前にいるのは、エンジニア一般ではなく、個別のエンジニアです。

一般論をかざして判断するのではなく、個別のエンジニアで判断してください。
その応募者が期待できるエンジニアかどうかか分かるのは、将来の同僚です。
その応募者とうまくやっていけそうかどうかが分かるのも、将来の同僚です。
採用予定の部署のメンバーと討論させてみて、使えそうな人物かどうかを判断してみてはどうでしょうか。

いま採用できなくても

どういう状況であれば採用の可能性が高まることを告げることはありかもしれません。
あなたの会社に興味を持ってきている方です。必要とされている技術が△△とわかれば、その分野の能力を高めてから再応募してくれるかもしれません。

ぴったしの機械学習エンジニアが見つからない理由を述べてみました。
それに対してどういう選択肢があるのか。
また期待はずれの人を避けるためにはどういう点に気をつかたら良いのか、思いつくまま書いてみました。
何かの参考になれば幸いです。

関連記事

画像AIエンジニアの雇い方
 機械学習をするうえで簡単に身につかないこと
 Python プログラマのスキル標準化のための項目