新しい価値を実現するには協力することだ

ある分野のエンジニアとして長年働いている。
20年前とも10年前とも、ソフトウェアをめぐる状況は大いに変わった。
そこで感じたことは、「協力することによってしか新しい価値を実現できない」ということだ。
そのことを述べようと思う。

## 着目する論文の著者が2人以下ということはほとんどない。
- ある着想をもって、それを実装し、論文として発表する。その作業はとてつもない労力を要する。
- タスクの明確化
- タスクに対する改善方法
- そのことを実証するためのデータ・セット
だから、最近の論文では、著者の数が2名以下などということはほとんど無い。
論文になりうるアイディアをちゃんと実装して、検証して、github にリポジトリを公開し、データセットを明らかにして、第三者が検証できる状況で論文を投稿する。
十分にその時点での先行例を調査して、自分たちの実装に新規性があって、有意な改善になっていることを示さなくちゃならない。
時間をかけすぎたら、「すでに〇〇の論文で発表になっているよ」となる。
だから、少なすぎる人数で開発している暇はない。



## ノウハウの秘匿が意味を持つことが少なくなった。（なくなったわけではないが）
理由：
- アルゴリズムの寿命が短くなった。
- そのため、５年もたてば、たいがいの実装上の工夫はなにも意味を持たなくなった。
- HaarCascade の例
    - 実用性を優先する限り、cv.CascadeClassifier()の検出器を2024年のいま利用する意味はない。
マスクをした顔を検出できないし、顔の検出の性能も今の主力のCNNベースの顔検出の方が精度・実行速度の両方で性能がでるでしょう。
    - HaarCascade の検出器では、１つのカテゴリーしか検出できません。そのため、新たに検出器を作る際にHaarCascade を使う理由を使う理由はありません。
    - また、HaarCasCadeの検出器はGPUを使う高速化にも適さないものです。
    - すべては、それが発明された時代と、今の時代のバックグラウンドとなる技術の違いです。
- ノウハウを秘匿すると、自分でメンテナンスし続ける必要を生じてしまう。
これが大きい。ノウハウを社内で他のエンジニアに引き継いであっても、本家に反映されない限り、
何回もその「ノウハウ」の出番となってしまう。
うれしいのは、そのようなノウハウを必要とせずに、すんなり使えることだ。
（それがモジュールであろうが、学習済みのモデルでもだ。）

#### 技術ブログを公開する企業も増えてきた
- Zen [Tech Bolg - Turing](https://zenn.dev/p/turing_motors)

## ARM専用の画像処理ライブラリよりもOpenCVを使う流れ
- 2010 年代だったら、まだARM用の商用汎用画像処理ライブラリが存在していた。
- 2024年の現在、ARM用の商用汎用画像処理ライブラリほとんどは見かけなくなった。
- 理由：
	- 組み込み系もARM64のアーキテクチャが普及したこと
	- OpenCVでのARM64がふつうに使えるようになったこと。(pip でもインストールできる)
- そのため、ARM用の汎用の画像処理ライブラリはほとんど見かけなくなった。
- 標準のライブラリが充実していくことで、個別のライブラリはどんどん不要になっていく。

## 個別のFPGA実装が不要になる汎用デバイスでの実装が継続して進展中である。
- 画像認識処理を個別のFPGA実装で対応していることがある。
- FPGA実装の利点：
	- 用いているCPUでの処理能力ではできないことを専用設計で効率よく実現できる（ことがある）。
	- 処理をCPUから外だしできるので、その分負荷を軽くできる。
- FPGA実装のその後：
	- 利用できる標準的なデバイスの処理能力が向上してくると、FPGAに外だしする魅力が薄れてくる。
	- GPU, DLAなどのメーカーが提供する標準的なデバイスの方が、学習結果の差し替えがしやすい、アルゴリズムの入れ替えがしやすい。
	- そういう状況のなかで、FPGAを使わない選択をすることがある。
## 商用ライブラリも特定のバージョンの有効期限が短くなった。
状況：
- そのバージョンのOS の寿命
- そのバージョンの言語の寿命(例: pythonの特定バージョンの寿命)
- そのバージョンの依存ライブラリの寿命
### その結果
- 商用ライブラリの特定のバージョンの寿命が上記の寿命に影響を受ける。
- 商用ライブラリを用いても、その有効期限の問題は残る。
## ライブラリの特定のバージョンのEOLになるまでにしなくてはならないこと
- そのライブラリの評価
- そのライブラリを利用した製品の開発
- そのライブラリを利用した製品の販売・サポート
- 次のバージョンに移行するための準備
- 次のバージョンに移行する枠組みの実装
- 次のバージョンへの移行の完了

## 自分たちで開発するライブラリも、ライブラリの寿命の問題を避けて通れない。
- 依存ライブラリのそのバージョンのEOLに対して、対応し続けることが大事。
- 特定のタスクに対する推奨アルゴリズムが変わっていく。
- 例：yolov3 
- -yolov4、yolov5, yoloR, yolox, yolov6, yolov7, yolov8 など

## 特定のデバイスを想定するライブラリの場合
- 特定のデバイスがいつまで存在するのかがわからない。
- いずれは、EOLになる。それが早いか遅いかの問題である。
- 先進的な技術をつぎ込んでいるデバイスであればあるほど、次の世代に入れ替わりやすい。
- そのデバイスが、生産され続ける範囲の中で、製品を売って利益をあげなくてはならない。

## 一定以上の速度で行動しないとなにも結果を出せなくなる。開発にもカットオフ周波数が存在する。
- 時間応答のシステムは、どの高周波成分まで追随できるかという限界の周波数（＝カットオフ周波数）が存在する。
- その周波数未満の長い時定数の現象（＝ゆっくりとした現象）に対しては、うまく応答できる。
- しかし、あるカットオフ周波数を超えると、まったく応答できなくなる。
- それと同じことが、起きている例が多いんじゃないかと疑っている。
- 画像認識・機械学習などの分野の進展の速度が速いために、従来の時定数でのマネジメントでは、研究と開発をマネジメントできなくなっているんじゃなかろうか。
- 研究の実務を担当する人よりも上の階層で、状況を把握が追いつかず、実務の担当者の自主性が許されてなければ、時定数はとても長くなってしまう。
- その結果は、開発の着手にGOを出した時点で、その他大勢の開発者の誰かによる成果で、その着手は無意味な状況になってしまっている。


こういったことをしなくてはならないので、それらが円滑にいくように環境を作り上げていくことをしなくちゃならない。		
## 自分たちは何を開発するのか
- 現状をどう分析するのか？
- 解決するタスクとして何を選ぶのか？
- そのタスクをどう解くのか？
- どのように開発を加速するのか？
- そういったことを協力して考えていくことだ。

## よいタスクの定式化はそれだけで価値がある。
- 機械学習で解決するタスクは、その時代ごとに変わる。
- よいタスクの定式化とは：
	- 問題を明確にしている。
	- 解くべき範囲を上手に切り出して巨大すぎる課題にしていない。
	- その課題の解決方法は、転用されうる一般性がある。
	- そのタイミングで着目する価値がある。
	- うまくっているのかどうか判断しやすい。
	- 開発の方向性をのぞましい方向に導く。
- よいタスクの定式化はそれだけで価値がある。
- よいタスクの定式化にそったデータセットは、新たな技術を開発する場所を提供する。
    - 公開されたデータセット
    - 公開されたデータセットを作り出した手順
    - アノテーションをする際の判断基準
    - 同等なデータセットを作るための情報が含まれていること。
    - データセットを作ることは、それ自体で論文にする価値がある



## １人エンジニア、１つのチームだけでできることは限られる。
- 新しいタスク(あるいは既存のタスク）に対するSotA(State-of-the-Art)となるアルゴリズムを開発するとしよう。
- アイディアを思いついて実装する価値のあるものだということの意識を共有する。
- アルゴリズムを実装する。
- そのタスクを学習・評価するのに必要なデータを用意する。

## 僕たちの目指すゴールはいつまでに何をすることか
- チームとして成立するには、協力する関係を作り出せるかどうかだ。
- 協力できるものだけが残ってチームを作るのもあるだろう。
- 死屍累々の先行の取り組みを見てもなお、自分たちに作り出せる何かがあって、それに僕たちの数年の努力を集中できるか。

### ケチをつけるのは簡単すぎる。
- どんな優れた内容の提案だってケチをつけるのは簡単すぎる。
- 難しすぎる課題を、「すべて解決してくれる万能な手法」なんてのは存在しない。
- 力技で大量のデータと大量の計算リソースを使って解決できるチームなんて、数箇所しかないだろう。
- 自分たちで扱いきれるアプローチの範囲を広げていきながら、最低限解き切る課題を明らかにする。
- その最低限解き切った内容を利用することで、開発が加速するようなものを選べ。

## 協力関係を創り出す時定数が大事だ
- 何度でも言う。「一定以上の速度で行動しないとなにも結果を出せなくなる。」
- 技術開発の方向性を、「万人が納得してから」を前提にしたら、なにも意味のある結果を出せない。
- 判断する責任のある人**だけ**が判断すればいいのである。
- ケチをつける暇があったら、有益な情報を提供しよう。
- ケチをつける内容は、得てして、ケチを付けられる人は承知のうえでやっている。
- 間違ったアプローチに対するアドバイスは「間違っている」ということじゃない。
- ある目的に対して、十分な結果を得られないことを本人が納得できる指標に気づきえるヒントを与えることだ。
- 花が美しいことを伝えるためには、美しいと感じさせた部分を表現することであって、「美しい」と述べることではない。

## 価値があるうちに収益をあげよう(会社の場合)
- 今の時代は技術の陳腐化が激しい。さっさと価値があるうちに、会社の場合だったら収益をあげよう。
- 価値があるものを価値があると認めよう。
- 価値があるものを、自社の事業戦略の中で強みとなるようにしていこう。
- 足りない部分は絶対ある。それを補って価値を高めていこう。

## 新しい技術・新しいサービスでは協力することが大事だ
- 新しい技術を導入する際には、双方の協力が大事だ。
- 機械学習を含むタスクの場合、十分な学習用・評価用のデータを提供できない限り、製品を納入してくれる業者が性能を確保することは難しい。
- いい要求仕様の場合には、そこで開発された技術が他の場面でも活用させる可能性が出てくる。


# 使われる理由のあるデバイスを使おう
- ある目的のためのデバイスを選択する場合でも、使われるだけの理由のあるデバイスを使おう。
- そのなにかを選択した時点で、そのデバイスのユーザーは、協力するのが得策だ。
- そのデバイスの効果的な使い方を共有するという選択肢がある。

### ほんの少しの安さを理由に、実績の少ないデバイスを選ぶことの欠点
抱え込む困難：
- 供給停止が早まる心配
- サポートの不足
- 解決を必要とするさまざまなこと
これらは、見かけのほんの少しの安さなんて、簡単に吹き飛ばしてくれる。


## ユーザーもライブラリを一緒になって育てるしかない。
- 開発速度の目まぐるしい時代、ドキュメンテーションが追いつかないことが生じうる。
- その環境を選んだという時点で、利害をともにする仲間になっている。
- 不具合を見つけて、その不具合を回避するノウハウなどを、自社の内部に溜め込んでも何の価値もない。
- その不具合が解消したときに、そのノウハウは、むしろ害をなす。
- さっさと不具合のレポートをあげて、そのライブラリの開発者に対応してもらうしかない。

## Bug Reportを書くこと
- 開発され続けているライブラリで、何らかのbugが残ることはありがちなこと。
- documentation と実装との乖離は残りがち。
- だから、ユーザーとしてできることはbug report を書くこと。
- Githubに公開しているライブラリの場合には、[Issues][New issue] でレポートを書くこと。
- 明解な日本語を書けば、機械翻訳で英文にできる。
- だから、英語が書けなくても気にする必要はない。