※注意
　当記事、意外と反応があってうれしいのですが、
　基本的に駄文が並んでいる否定的な内容ですので、
　期間限定での公開とさせていただきます。(~11/10辺りまで)

本当、「こんな甘い考えでよく仕事を貰えるな」と今の会社を見ていて思うので、その状況をつらづらと書こうと思う。
（内心、かなりムカついている）

でも、分かる部分もあるのでどう折り合いをつけたらいいか、自分自身がわからない。
世間にも自社にも否定的な意見なので、ある意味酷いメモかもしれないが・・・。

背景(仕事)

• 工場用に産業用カメラを設定し、各種試作品・量産品のインライン検査を行うための受託開発を行なっています。
• 受託開発前に、事前検討(なんちゃってPoC)を行い、規格書通りの合否判定ができるかを決めて、見積もりを提示します。最終的に、認められれば仕事として着手します。
  • なんちゃってPoCと言った理由は後述。闇深い理由があるため。
• メカ設計や回路設計も行いま
  • ・・・せん。実際は、他社から部品を買い上げて組み立てるだけで、複雑な開発はしないし、全体的な評価もしません。
  • 実際に装置を作るのは事前検討では出来ないので、受注前に色々話をするものの、顧客との技術レビューは一切しません。
  • そのせいで、「なんでそんな複雑なものを使わなくてはいけないのか」という疑問を払拭できていない状況です。
  • また、例えば機械自体の評価をすることもしないし、構造計算のスキルを持っていないので、装置が揺れていて画像がまともに撮れないみたいなことが起きても、物理的な方法で問題を先送りにします。
• 画像処理のアルゴリズム評価は事前検討の中で行いま
  • ・・・せん。顧客から「数値を出してくれ」と言われた時のみ、何らかのアルゴリズムを使って自分たちの都合よくロジックを捏造して提示します。
  • あえて捏造と誇大していますが、それは事実です。なぜならば、そのロジックは「仮」で、実際は案件が着手してから全く別のものを検討し始めるからです。
  • 当然、不良率、認識率なんて提示しません。口を揃えてお客さんにこう伝えます。「認識率は規格に合えばシステム全体を通じて100%である必要がある」「認識率どころか、自動化をしている間の動作異常も全く発生しないのが当然である」と。
• 受注後の客先フォロー？なんで俺らそんなことやる必要あるの？
  • 実際に運用して不良が起きたら「不良を作ったのは俺らのせいじゃないから知らない」とトンズラこきます。合理的な根拠はあるのですが、その点に対する説明責任は果たさず、最終的には客先との関係が破綻します。
  • 私はソフトウエア設計担当で不具合だけではなく、検査状況もモニタリングが出来るのである程度顧客との説明をし、簡単に解決できそうな部分であれば仕様追加とテストも行います。
  • ですが、メカ周りの議論になるとメカ設計者が指摘を聞かなくなるので半ば諦めています。金くれないと対処しないと。技術レビューを自分から率先してやってないところに大きな問題があるのですがそれは・・・。

なんちゃってPoC

• PoCでは光学系の検討を行います(まあこれは大切です)
  • カメラ、レンズ、照明などの情報を使って、空間分解能や被写体深度を推定します。
  • 改善する時に、偏光素子やレーザなどの光学系変更、視野角を狭くする代わりにより高精度に検出するなどの方法を提案します。
  • これ自体は大切なことでして、この時点で合否判定における特徴が画像表現でコントラストが十分に取れなければ、仕事として成立しないのはよく分かりますし、同意できます。
  • この仕事は一般のデータサイエンティストにはない専門性のあるスキルかも。この本質を理解出来ている人は意外といないので
• １番の問題は、「インライン検査装置を導入したらどの程度効果が現れるかが見えないこと」です
  • なんちゃってPoCなので、規格に合った母集団の認識率100%、不良率0%を前提にするわけです
  • ところが、そんなことは絶対あり得ません。仮にアルゴリズム単体での認識率が100%だったとしても、ゴミが入った、途中で動作を止めてしまった、静電気が入った、配電系統が突然おかしくなった、インライン検査で流してはいけないものを流してしまった、実は検査時のサンプルを壊してしまった、色々理由が考えられるので、仮に10万個の製造物を毎日検査していても、１個くらいはそういうのを見逃せないのです。
  • また、アルゴリズム単体の認識率100%というのもあり得ません。
  • 例えばアライメント処理を考えてみましょう。こういうインライン装置の場合、どう搬送させても位置ずれが発生しますが、その位置ずれが想定外の移動量だったり、回転がおかしかったり、変なおかれ方をしたり、なんだかんだ変なデータが必ず混入します。その時点で、認識率100%を保証することは絶対できません。
  • 100%ではないので、本来はフールプルーフ設計をある程度しておく必要があるのですが、そう言う認識がないですね。
• 出来るとすれば、用意された標本データが一定の条件で100%検出出来ていることを検証するのみです。
  • 統計検定の話は勉強している人なら分かると思いますが、n個の標本を定めても、母集団が常に不良を保証するための有意水準α、検出能βの存在があります。したがって、どう頑張っても、α、βの範囲外では、正常データは誤判別するし、異常データは正常データとして混入される可能性があるかもしれません。
  • その場合の性能保証ですが、α、βが十分性能として認められる範囲で保証するのが基本になります。したがって、必ず「そうではない場合どうするか」のプランを考えておく必要があります。
  • そして、こうした話は、現業の既存事業との計画と紐づけられている必要があります。検査装置で言えば、年間の営業クレームが100件／年から10件／年になったら嬉しいじゃないですか、とか言いようはあるわけでして、事業に対しての直接的な効果を提示できなければ、工場の経営陣は検査装置に投資しようとは思わないでしょう。

機械学習を使うことはうちらの仕事じゃないんだ

• 言い分は確かに分かる部分はあります(ここは私もちょっと共感できる)
  • 機械学習に不慣れな人にありがちな思考なのですが（私も含む）、機械学習を使えばどのような問題もデータさえあれば解決できますよって意見は非常に怖いです。具体的な事象、評価したい対象、特徴をまず決める必要があります。
  • それから、それが統計的な手段で解決が望めそうで、情報量の抽出や分類、回帰などの手段が有効であると判断できれば機械学習の使用を検討するべきだと思います。
  • したがって、次の案件で機械学習を使おうと意気込んでいる人をみたら気をつけましょう。まず、どんなことを実現したいのか、どんな事象、評価をしたいのかを丁寧に聞き取りするところがスタートです
• ・・・ところが、機械学習を「魔法の杖じゃない」などと言い訳して嫌う人が画像処理の仕事をすると、それもすっっごく悲惨な目にあります
  • まず、彼らには「学習データと評価データを用意する」という思考がありません。（そういや私が前職の新人の頃はペーペーだったからそんな感じだったのよく覚えている）
  • いや、それどころか、「実機なしで動かせるようなローカルデータを残すこと自体意味がない」という思考に陥っています。したがって、評価データを使ってアルゴリズムが変わってもきちんと認識できることを評価できないわけです
  • そう言うことがなぜ起きるか？と言うと、極端に言えば、機械学習嫌いはもれなくビッグデータやローカルテストなどのデータを使った評価方法について価値を感じないからと私は考えます。深層学習はビッグデータの恩恵を受けやすい領域の一つだと思うのですがね。ビッグデータを嫌う＝評価データベースを作ることを嫌うみたいなもんです。つまり、実機で動いている動作が全てってことです。
  • つまりその画像処理によるアルゴリズムが何が正しいのかを定義できないのです。「アルゴリズムに問題が起きているんですけど」っていう顧客クレームに対して、「それは仕様の範囲外で検査対象じゃないから」と軽く受け流しやがります。そして、検収条件には決して「検査対象外になった場合の対処法」を書いたりしないので、仕様の範囲外かどうかすら顧客は判断できなくなるのです。
  • じゃあそれをやって欲しかったら顧客はどうするかというとお願いするわけですが、開発受託側である方は仕様変更になりますので金を取りますよと言うんです。一見正しいように見えますよね？
  • でも、パラメータ一つ書き換えて検証して全データが受け入れられることを確認する作業が仕様変更のための検討になるとしたらどうですか？　評価データがないので、それが出来ているかを確認するには実機がないと無理って言うんです。
  • そんな非効率な仕事、顧客が望みますか？今までOKだったデータと、ちょっとNGそうなデータが混ざった時に、両方の性能保証が必要そうなことくらいすぐ分かると思うんです。それを試しに評価してくれと言うのは、当然必要になってくると思うんですが、実機ベースで仕事するとなると、アップデートしたアルゴリズムが妥当かどうか評価できなくなるわけですよ・・・。
• ちなみに判定基準ですが、今の会社の場合「２値化した画像を基準にして粒子解析する」が８割で、「２値化した画像から長さや平行度などの幾何学的な特性を求める」が２割って感じですかね
  • キーエンスがやってることとほとんど同じやんけ。しかもキーエンスの画像処理ソフトの方がもっと高機能なこと出来てるって言うのにww
  • ２値化基準ですら、今の世の中、大津の２値化やエントロピー使う方法など方式は多様にあるのに、「固定の閾値で」っていつも言ってますね。
  • 光学系ひとつとっても、迷光やクリアランス、寸法公差による影響があるのに、固定の閾値を決めて面積取れるようなケースなんぞ、よほど光学像が２段階でコントラストが明瞭なもの以外そもそも同一精度で測れないんじゃないの？って思ってます。これもなんちゃってPoCと呼ばれる所以かな
  • しかも光学像って、被写体深度の範囲に、センサの垂線と物体面が同一の位置関係に入らなければ正常に画像として取り込まれないんですよ。角度揺らぎなども当然あるのに、考慮されていないって言う
  • これと認識率100%の件が本当に辻妻合うんですよ。【「仕様から決めたアルゴリズムは、正しければ合格とし間違っていなければ不合格とする」モジュールが実行される確率が100%起きる】のは反対しないし。まあ、「モジュールが正常に実行される確率」とか「自分たちが思っていた認識率」と「現実のアルゴリズムの認識率」は全然違うものだけどね！！！

尚、「認識率の定義がおかしい」ことに対する指摘はここでは話していません（私自身もそこまで明確に向き合って案件に取り組めてません）。
　と言うか、そんな話をする以前の問題なので・・・。
　繰り返しますが、そもそもアルゴリズムが正しく動く状態が定義されてないことが問題です。

どうしようかな

統計の勉強はある程度やってきましたが、機械学習に関しては結構弱い部分もあるので、
まずは私だけでもその中で得意分野を作ってみて、実務に応用出来るようになってから考えたいね、と思っています。

光学系の話が多く、画像処理を使った基材画像面のノイズキャンセリングとか、独立成分分析などを使った方法、あるいは一般センサの議論でもMUSIC法や圧縮センシングなどに関心があるので、その辺りの分野を中心に勉強してから、将来考えようかなって思ってます