2017 年技術的な振り返り

2017 年は特に目標を立てずにやってきた。ほぼほぼ Erlang/OTP と WebRTC な 1 年だったと思う。

自社製品の開発は内部コードを整理しつつ、機能追加は控えつつ、品質と安定をテーマに改善していった。

次の自社製品や、既存自社製品の新機能の開発も手を付け始めた。

社外のお手伝いはコンサルティングがメイン。組織づくりしたり、プロジェクトをうまくすすめるようにしたり、新規事業のビジネス考えたり、社員の教育方針考えたり、評価制度考えたり。何が専門かよくわからないが、色々なお手伝いしてる。

コンサルティングの話は別に書くとして、技術的な振り返りをしていく。

GPGPU と映像コーデック

自社製品であるネットワーク・サーバの開発が主な仕事だが、2017 年後半から動画変換というのに手を出し始めることにした。

理由は完全に興味があるからの一択。

動画の変換は残念ながら Erlang は一番苦手な分野なので、使うことはできない。だからといって C/C++ で Erlang と繋ぐのは現実的だが、他社との差別化が難しい。小さな会社は差別化がとても重要。

ということで手を出したのが GPGPU だった。

GPGPU といっても色々なのに手を出しているのではなく NVIDIA 一択、つまり CUDA 一択。理由はシンプルでサーバ再度で GPU を乗せているクラウドは全て NVIDIA だから。さらに NVIDIA の GPU には NVENC/NVDEC という専用命令が積んで有り、動画の変換が拘束に行える仕組みが用意されている。このあたりは NVIDIA VIDEO CODEC SDK というので情報が公開されている。

昔と比べて色々道具は揃っているなと感じたのも手を出した理由の一つ。

第一目標

この NVENC/NVDEC を Erlang から呼ぶことでうまいこと Erlang が受けとった映像データを高速に変換したい。

ハード依存なので、Erlang/OTP / Erlang NIF / C++ / NVIDIA VIDEO CODEC SDK でなんとかなるだろうと見ている。ここまでは来年の夏頃には成果を出せたらと思っている。

NVENC は H.264 しか使わない、H.265 はまぁおいておく。

NVDEC は VP8/VP9/H.264 が使えるのでその辺を、といっても引き渡す設定を色々いじるだけで大丈夫そう。

第二目標

NVENC/NVDEC が非対応なコーデック VP8/VP9/AV1 のエンコード (AV1 はデコードも) を GPGPU を利用して高速化したい。

そのためにはそもそも VP8/VP9/AV1 がどんな仕組みでどうやって変換されているのかを理解する必要がある。ということで libvpx と aom のコードを読んだりしている。この辺は知識もほとんどないのでこれから頑張る所。

ハードに頼れるところは頼りつつソフトもがんばるという方針。

これらの方針を決めてから、勉強する言語が増えた。今まではまったり Erlang だけ書いていればよかったが、そうはいかなくなった。

libvpx や aom は C で、NVENC/NVDEC は C++ で書かれているので、このあたりを勉強しつつ、まずはサンプルコードなどを読み漁っている状況。

さらに CUDA というか GPGPU の理解をするために、色々写経したりしてる。C/C++/CUDA でコードを読みつつ、書きつつ動画変換の知識を学んでいる。

技術でご飯を食べるのを諦めた

今年の結論はこれ。コンサルティングの仕事が増えてきて、自分の需要はここにあるんだな、なんて実感することが多かった。

もともと凄腕の技術者というわけでもないし、色々なことができるタイプでもなかったので、技術でご飯を食べるのは難しいなと実感していたが、現実は厳しかった。

ただ、やはり憧れはある。であれば技術でご飯を食べるのはあきらめて、興味があって続けられそうな技術を仕事にしていこう、自社製品という形でアウトプットすれば仕事だ。それでご飯が食べられるかどうかは気にしないことにしよう、そうしよう。という判断をした。

諦めた技術

ということで、技術でご飯を食べていかないと判断したので、ウェブのフロントエンドとバックエンド、スマートフォンアプリ、デスクトップアプリ、クラウドこの辺の技術は仕事で使っていくのは諦めた。もともと書いたことなかったが、未練を断ち切る事にした。技術の選定は詳しい人に相談しながら決めるが、実際に手を動かすことを止めた。

• フロントエンドは React やら Babel やら Flow やら Webpack
• スマートフォンは Swift やら Kotlin やら React Native
• ネイティブアプリは Electron
• クラウドは AWS と GCP
• ウェブアプリは Django
• 解析系は Elastic Cloud

これらの技術は全て自社で使っている技術だが、全て手を動かしていない。全て社員やお手伝いしてくれている @tnamao にまる丸投げしている。

サポートは向いているのかもしれないと思い始めた

自社製品のプリセールスは、基本的には社員に任せっきり。

ただ、つまりテクニカルサポートは向いているのかもしれない。メールの対応がめんどくさいな、嫌だななんて思わなく、楽しいし、直接お客様からフィードバックが貰えるのは良い。

ただ、これ自分が自社製品の開発も兼任しているからというのはあると思う。開発者なのでなぜこうなってるか、どんな仕組みなのか、何ができないのかは把握しているため、的確に拘束なレスポンスを返しやすい。

自社製品を買って頂く殆どの理由が「評価中のサポートが良かったから」というのがある。お客様にとって最低限の機能要件を満たしていれば、後はサポートが購入条件となるということがなんとなくわかってきた。

サポート力、継続的に上げていこうと思う。

まとめ

より狭い技術、より狭い興味、より狭い世界で、市場が求めているかわからない自社製品を好き勝手に作り続けて行こうと思う。

作りたいもの作って、売れたらラッキーくらいが自分にはちょうどいい。