初めに
ものごとを成功させるためには、成功させるための仕組みが必要だ。
ビジネスとして開発を成功させようと思うのなら、成功させるためのしくみを意識しないわけにいかない。
ソフトウェア開発をしていると、自分たちの作った実装が意味を持つものとして生き続けるためには、とてつもない労力が必要なことを感じている
- ライブラリを実装する対象のCPU・ボード
- ライブラリが必要とする各種依存ライブラリ
- 部品はEOLになる。
- ライブラリは、OS,言語のバージョン、依存ライブラリのバージョンの変化が常に待ち受けている。
一つの実装が価値をもって生き続けるためには、全力で走り続けることが必要だ。
そのようななかで、「実装が生き続けるためには、標準になることが必要だ。」と感じたので、以下の駄文を書いた。
Linux の場合
今でこそLinuxがUnix系の標準的なOSとして各種デバイスで使われている。Linux は 1991に個人がIntel 80386 CPU を搭載した32ビットPC/AT互換パーソナルコンピュータを使ってUnix互換の機能を持つOSを動作させてみたいという動機で開発が開始したものにすぎなかった。各種商業のUnix、HP-UX, SunOS/Solaris, AIX,IRIXなどが存在していた時代のことだ。
GCC（GNU C コンパイラ）の場合
- Sunの初期のWSにはSunのCコンパイラが付属していた。
- しかしある時点からCのコンパイラが付属しなくなった。
- GNUのCコンパイラが標準となっていった。
Cコンパイラを開発・メンテナンスするコスト
Cコンパイラを開発・メンテナンスするコストはとても大きい。それぞれの会社がそれぞれにCコンパイラを開発すると、それぞれの会社がその費用を負担しなければならなくなる。コンパイラによる微妙な違いがあると、その違いのために損なわれる開発コストは膨大になる。
それが、GCCという共通のコンパイラによって、開発コストが大幅に抑制されている。
最近の言語は、標準の実装をもって普及している。
- Fortranの時代には、Fortranの言語仕様という標準だけが存在して、Fortranのコンパイラは個別に存在していた。そのため、「◯◯のコンパイラよりは、△△のコンパイラの方がいいですよ」ということがある。
- しかし、Java, Python, Ruby, Go言語などは、言語の普及の際には標準の実装の処理系があって、その処理系が標準として普及をになっている。
- 標準があることが、普及を容易にしている。
OpenCV の場合
OpenCVも2000年のリリース直後の数年は、数多くの画像認識のライブラリの実装の１つにすぎなかった。それが今では、OpenCVは、シングルCPU、マルチコアのCPU、GPUなど多様なデバイス上で動作し、多様なOS上で動作する一番の重要な画像処理・画像認識のライブラリとなった。
新規のアルゴリズムを実装し公開するのに別のライブラリにしない理由
- 標準となっているライブラリに追加して公開する方が、利用してもらえる可能性が高まる。
- 同じ目的のための似たような開発プロジェクトが乱立するよりは、同じ開発プロジェクトにした方が開発者のリソースを有効活用しやすい。
- 画像認識のように、実装先のプラットフォームが多様なことが必須なライブラリで同じアルゴリズムが、同じように使える利点は大きい。
- 比較：特定のプラットフォームに特化し類似ライブラリ。
- あるタイミングでは、互換性を残ってでも演算のパフォーマンスがOpenCVを上回ることはあった。OpenCVがほぼほぼIntelのCPU用のものであって、ArmのCPUに使えなかった時点では、OpenCV類似の商用ライブラリの価値は高かった。
- しかし、現在の時点では、Arm用の画像ライブラリの価値は以前より低下しているだろう。もちろん、十分な最適化がされているライブラリは、価値を持ち続けている。
Numpy の場合
Numpy の前身であるNumeric モジュールも2001年の時点では、一部の挑戦的な人が使っているものにすぎなかった。MATLABの良さを知っている人が、pythonでMATLABっぽく使ってみたいという想いのために使いだしているものにすぎなかった。
これがnumpyとなって、python APIを使って機械学習ものの重要な構成要素にまで成長するにいたっている。さらには、matplotlib との組み合わせで、MATLAB並みの簡潔な数値計算と高性能なグラフィックライブラリを持つようになった。scikit-learnという機械学習のライブラリ、OpenCVのpythonバインディング、こういったそろっていったことで、深層学習をC++以外から利用する際に標準的な言語にPythonを押し上げていくことになる。さらには Pandasというライブラリ、jupyter notebook という環境によって、S言語やR言語に類似した対話的な統計解析環境を手に入れている。
かたや、統計分野での歴史ある商用ライブラリS言語は、S-plus として継続はしているが、「2014年をもって S-PLUSのリリースは終了しております。今後、OS追従なども含め、メンテナンスの予定はございません。」という状況に達してしまっている。
Blenderの場合
3DCGのソフトウェアであるBlenderは、オープンソースの3DCGのソフトウェアとして確固たる地位を獲得している。しかし、その歴史は、商用のソフトウェアとして始まっている。
「しかし開発途上にあったBlenderを手放すことができなかったトン・ローセンダールはBlender Foundationを設立するため、"ソースコード解放"を合言葉に大々的な募金キャンペーンを行い半年で10万ユーロを世界中から集結させ、ソースコードを再びその手に取り戻した。」とある。
これは、なぜだろうか？
ここであげた例は、商用ソフトウェアとオープンソースのソフトウェアの場合の比較である。
しかし、オープンソースだからといって成功が約束されているわけではない。
オープンソースの大半は、見向きもされないようなソースコードが大半だろう。
Linuxと同様に商用Unixの置き換えとしての可能性があり、使われ続けているものFreeBSDなどのBSD系OSがある。でも、何かの違いのためにBSD系のOSではなく、Linuxの方が普及している。
MATLAB風の簡潔な行列演算、高機能のグラフィックスという点では、Octaveという選択枝もある。
しかし、機械学習の分野で使われる言語としては、Python（NumpyやMatplotlibを含む）が普及しており、Octaveではない。Octaveの初版は1988年とあり、numpyよりもはるかに古株だ。C/C++言語で記述された関数をOctaveで利用する枠組みも用意されているなどの点があり、拡張性がないわけじゃない。
これらの例では、何か成功につながる仕組みが何かあるはずだ。
私がMATLABからpython に移行した理由
- 社内のプロジェクトを移動した時に、MATLABのライセンスを引き継ぐことができなかった。
- MATLAB上で開発した成果は、社内の開発者自身でも利用不可能なものになってしまう。
- 自分が開発した結果を社内でデモンストレーションしようとすると、MATLABのライセンスが紐づけられたPCを持ち歩くしかない。
- 成果物を、社内の別の人に動作を可能にしようとするには、MATLABのライセンスを購入してもらおうしかない。（あるいはデモ版のライセンスを業者から入手してもらう）
- MATLABの年間ライセンスを更新し続けることのハードルが高い。
- Octaveに移行しなかった理由
- Octaveは、拡張性を使いこなすには至らなかった。
- OctaveをMATLABと互換性のあるコードとして書こうとするのはおっくうだった。
- Octaveのむかしのグラフィックは制限が多かった。
- 行列計算言語でしかないOctaveでは、pythonのカバーしている機能を満たせなかった。
- MATLAB よりの Python, numpy, Matplotlib, OpenCVの 方が魅力で上回るようになっていた。
- OpenCVで実装される機能を早く使うには、C++かPythonに限られる状況になった。
開発者のコミュニティの重要性
- 開発者のコミュニティのないシステムは不安が多い。
- 商用ライブラリであっても、開発者のコミュニティのないシステムは不安が多い。
- ソフトウェアが動作する環境の構築
Google ドキュメント、スライドが普及した要因の１つ
- Microsoft のWord, PowerPoint などの問題点（Office 360以前）
- 互換性を損なうバージョンのアップ
- UIの変化によって、操作性の低下を引き起こす。
- １つのドキュメントを複数のメンバーで読もうとすると、複数のメンバーのPCのディスクを浪費する。
- 各人が同一のドキュメントを読んでいるのかがメール添付・ネットワークドライブからのコピーなどによって、確認できない。
- 組織内でバージョンをそろえることができても、組織を越えてバージョンをそろえることはできない。
- もっとも普及したソフトウェアであるのにもかかわらず、標準であることの利点を維持できなかった。
標準に寄せよう。標準にしよう。新しい標準を作ろう。
- ライブラリを活用する側のコードも、ライブラリを構成しているコードも、貴重な開発の成果である。
- その成果の価値を維持し続けることが、ライブラリの利用者・ライブラリの開発者にとって共通の利害である。
- 1人がって用語の使い方をしない。
- 標準に寄せることで、メンテナンスコストを減らすことができる。
- 互換性の断念は、それに見合う価値があるときだけにする。
- 例：OpenCVがバージョンアップする際に後方互換性を捨てるときがあった。
- C言語のサポートの廃止、C++だけへのサポートへの移行
- 事実上の標準であることに、オープンソースであることは必ずしも必須ではない。
- 例： Cuda
- 例: 自動車産業におけるSimulinkの活用
- 標準であることによる利点が複数の組織にまたがって共有される場合には、商用ライブラリであっても、それが事実上の標準として価値を持つ。
自作ライブラリへのこだわりよりも、標準によせることが大事なときがある。
- 自作ライブラリである機能を実現してきたときに、ある時点でオープンソースなどの実装が自社内の自作ライブラリを上回ってきたときには、自作を放棄して外部の実装の利用に置き換えることも必要だろう。自分たちのビジネスとして利益を出す源泉の部分への開発にリソースを割り振るべきだろう。
メンテナンスが終了されたライブラリに依存しないこと。
- ソフトウェアは、多くの他のライブラリに依存している。
- 利用しているライブラリのバージョンがサポート期間が終了することに、あなたの関わっている実装も対応し続けなくちゃいけない。
- OSのサポート期間が終了する。
- 利用している言語の処理系のそのバージョンのサポート期間が終了する。
- 利用しているライブラリのサポート期間が終了する。
- 新規に利用したいライブラリでは、共通に利用するライブラリに対して最新の版を要求する。
- こういった状況になるから、実装を生き残らせようとする限り変化し続けることだ。
ほとんどの画像認識の実装はいずれ死滅する。その時期が早いか遅いかだ。
- 画像認識・機械学習の開発にかかわっていると、まさにそう思う。
古いアルゴリズムが価値をもたなくなっていく。
- 今どき HaarCasecade とか HoG SVM とか使わないよね。
- 新しいアルゴリズムの方が優秀な学習結果を示している。
機械学習のフレームワークも絞り込まれていく。
- 例: chainer のメンテナンスの終了
- 例: 2018年3月、Caffe2はPyTorchにマージされた
- 例: Yolo darknetの実装から pytorch を使ったyoloの後継アルゴリズムへ
依存ライブラリのバージョン問題
- python のバージョン
- numpyのバージョン
- opencv のバージョン
- onnx のバージョン
これらのバージョンの組み合わせで、実装がサポートしきれなくなることを生じる。
ターゲットデバイスの供給問題
- ターゲットとするデバイス、センサ・CPU、GPUの供給問題はある。
- 例：kinectの供給停止
- ターゲットとするボードが供給されなければ、意味がない。
- ターゲットのボードのEOL
- 世代の古すぎるGPUボードを差し込んだPCでCudaを使って開発することは意味をもたない。
- 古すぎるGPUボードは、最新のライブラリの対象外
いずれ死滅する独自実装のために
- 入出力、APIを明示化しておこう。
- 抽象クラスの下に個別の実装を開発しよう。
- 代替可能性があるライブラリを意識しておこう。
- 代替可能性を低下させる独自機能は考えもの。
- 独自実装を、上手に置き換えていこう。
追記
日本の大手会社が技術を陳腐化させてしまう理由
在来型日本企業の状況
- ライブラリを国内でだけの提供にしてしまう。
- 生き残るためには、海外の市場をライバルにただでくれてやってはならない。
- 海外という巨大なマーケットをものにしたライバルが、いずれ、国内も含めて殲滅させてくれる。
- ドキュメンテーションの不足（特に英文）
- これだけ機械翻訳の品質があがっているのだから、英文のドキュメントをつくるのがめんどうだってことはないよね。
- ライブラリの仕様を確認するにも営業を必要としてしまう。
- ライブラリが、どのデバイス・どのOSで動作するのか、webサービスのAPIとして提供しているのかどうか、たったそれだけを調べるために、営業を必要としてしまうのには、うんざりしてる。
- 営業にコンタクトしてくださいが、どれだけ、ユーザーを失っているのかを気にしてください
- 対案： webサイトにアクセスして、メールアドレスと、アンケートに答えれば、確認用のメールがとどき、それをクリックすれば、登録済みユーザーが十分な情報にアクセスさせてください。
- （誤解のないように言っておくが、営業は必要だ。一つのソフトウェアのソリューションを１つの顧客にしか売らないというのは、生産性が悪すぎる。極力、使い回しの効くライブラリにしておいて、同一の内容を、別の会社に売れるようにしておくことが大事だ。販売済みのライブラリの利用者から上がってくる要望はなんであるのか、把握するのに、ユーザーの声を聞く営業は重要だろう。）
- 数年前の優位を今の優位と勘違いしている。
- 画像認識・機械学習・そしてそれらを利用する分野は、半年でがらっと状況が変わってしまう。
- 数年前の有意は、簡単に入れ替わってしまう。
- 残差がある程度以下に少なくなってしまえば、それ以上の性能の向上は、たいがいの人にとっては意味がなくなってしまう。
- 海外を含めた技術サポートの不足
- 開発エンジニアに技術サポートをさせるのは間違い。
- 技術サポートチームを開発チームとは別に作らなきゃならないのはわかっているよね。
- 技術サポートのノウハウの共有化。web上で、ユーザーが質問し、それを技術サポートが返答し、それを検索で見つけることができる。
- そのようにすることでだけ、利用できるようになる。
海外の企業の状況
- web上で技術情報の仕様が得られる。
- web上のAPIでライブラリのスペックを確かめられる。
- 比較的簡単に、評価版のライセンスを提供を受けられる。
- 世界的な展開をすることで、普及を加速させる。
身近な人が作ったものが優れたものであっても、その価値が理解できない。
- 一律の評価基準で評価しようとすればするほど、評価に失敗する。
- 新しい技術分野は、 一律の評価基準に反映できない。
- 先進的な一歩を作るときに、それが必ず成功することを、事前に証明することはできない。
− だれが見ても自明になるのは、開発が成功した後だけだ。 - そういった理由のため、身近な人が作ったものが優れたものであっても、その価値が理解できない。
このような状況がもたらすこと
- 海外の企業にとって、在来型日本企業は何の競争相手にもなっていない。
- そのため、ある時点で世界的に技術がトップにあったとしても、すぐにその状況が低下してしまっている。