第5回:リサーチエンジニアは楽しいお仕事

ソフトウェアアーキテクト四方山話

みなさんこんにちは。システムエグゼの相田です。

さて、ここ数回「技術」から若干離れた話が続いたので、今回は少し技術よりの話をしようと思います。

第五回目は、のびのびと楽しいお話です。個人的に。

あ、AI とか量子コンピューティングとかコンシューマ系のフロントエンドとか、そういうオシャレでモダンな話はしません。別の部門が担当(※)しているので。
(※ 昨年は面白がってイベントで AI 系のアテンドしましたが、私の主担当領域は エンタープライズ系なのです)

その手の話も楽しいのですが・・・エンタープライズ系にも楽しい話がいっぱいあります。

関数型プログラミングを待ちながら

私が初めて触ったプログラミング言語は、子供の頃の BASIC 言語です。懐かしい。
大学で C 言語や FORTRAN に触れ、社会人になって最初に担当したのはVisual Basic/VBA でした。「4GL」なんて言葉が流行った時代ですね・・・
その後 Web が流行し始め、当時の社長(現会長です)に、

「Sun とか言う会社のイベントに参加しろ。Java とか調べて来い」

と言われ今で言う Meetup に参加し、そこで Java に出会いました。Java 2 の頃ですね。Java は今でも好きです。私に「オブジェクト指向」を教えてくれたプログラミング言語です。
その後 Microsoft さんが .NET Framework の提供を開始したので C#.NET に触れ、現在まで約20年くらいオブジェクト指向言語を扱う仕事をしています。

とは言えこの手の技術は市場のニーズに応じて流行り廃りするもので。

「次にエンタープライズで流行する言語は何かな」と考え始めたのが2009年頃。
この頃から研究を続けているのが、いわゆる関数型プログラミングと関数型言語です。
とりあえず Scala というのが流行っているらしいと本を買って研究。関数型界隈の話題を見るといやいや純粋関数型言語でしょ Haskell でしょというのでやはり本を買って研究。Haskell 美しい、と感動しつつもエンタープライズ向けだといかがなものかと迷い。

Haskell が JVM 上で動くの? Frege?さらに関数型リアクティブプログラミングで Elm か。へえ。Clojure(LISP の方)なんてのも。
ああいやいや趣味じゃなくてエンタープライズで流行りそうなヤツ、と軌道修正。
なるほど OCaml ね。おっと Microsoft は F# 出したか。R とか Erlang、Elixir はやや文脈違うな。お!Swift いいね。でも Apple 系だけか・・・。
・・・などと楽しんでいた所、2016年頃に Kotlin に出会い。

一目惚れでした。Kotlin 良いですね!

なんというか「好み」なんですよね。JVM 言語でもありますし、これは Java 勢なら気にいるんじゃないかなあ、と思っていたら案の定大人気となりました。
Spring Framework なんかもいち早く Kotlin 対応してくれましたし、2017年にはGoogle さんが Android 向けの開発言語に正式採用というニュースも。

10年待って、やっと本命が登場した印象です。

弊社でも Android 系開発では Kotlin の事例も増えて来ました。
エンタープライズ向け/サーバサイドで採用するのはもう少し先になるかもしれませんが、個人的に大変楽しみにしております。

ネイティブ VS WebAssembly

さて、プログラミング言語の世界も大変楽しいのですが、一方で凄まじい勢いで進化を続けているのがプラットフォームの世界です。

2009年に情報処理学会のフォーラムに参加して「クラウドって何?」みたいな話をしていたのも今は昔で、クラウドコンピューティングはエンタープライズ系でもすっかりコモディティ化しました。クラウドのコモディティ化に並行し、2014年頃にはコンテナ型仮想化の世界が本格的に進化を始め、Docker コンテナやそのオーケストレータである Kubernetes、そしてその先にあるサービスメッシュの世界へと向かいつつあります。

その流れで、最近のトレンドは「小さくて高速なアプリケーションをたくさん束ねる」方向なんですよね。
より小さなメモリフットプリントで、より高速な動作に。
色々な技術がそちらの方向を向いていて。

仮想マシン言語をネイティブへ

Java だと Oracle さんが新しく発表した GraalVM がそれですね。Java コードからOS ネイティブイメージを生成出来たりします。ネイティブなので非常に高速に動作します。

先の Kotlin だと Kotlin/Native というプロジェクトがあって、こちらも同様に各 OS 向けのネイティブイメージを生成します。
(Windows OS 向けだと Win32 API 使ったコードが生成されてました・・・!)

これらネイティブイメージを Docker コンテナ上で動かそう、という方向のようです。
なんやかんや言って、やっぱり仮想マシン上で動作するものよりもネイティブイメージが最も高速なのは間違いありません。

「Web」にバイナリの力を ─ WebAssembly

もう一方の動きが JavaScript の世界から生まれた WebAssembly です。
こちらはブラウザにバイナリっぽい(※)「アセンブリ」をホストさせちゃおう、というプロジェクトです。個人的にはこの WebAssembly に非常に注目しています。
(※ バイトコードスタックではないので OS ネイティブではありません)

さらに現在 WebAssembly System Interface(WASI)という動きが活発化しており、ブラウザ以外の場所でも WebAssembly が動作するようになりつつあります。

実装としては Cloudflare Workers とか Fastly Lucet、あと Wasmer なんかがあります。
これが実用化に向かうと、WebAssembly はフロントエンド、サーバサイド、そしてエッジ(今だと CDN とか)で動作するようになります。

そしてさらに様々なプログラム言語で、プログラムコードを WebAssembly 向け実行形式である wasm に翻訳するプロジェクトが進行中です。
LLVM 系の動きが最も活発な様子で、C 言語や Rust で書かれたコードであれば概ね wasm 翻訳出来る状況になりつつあるようです。

個人的に注目しているのは 2020年に公開される(予定の)Microsoft の「.NET 5」に含まれる Blazor です。
Blazor は C# で書かれた ASP.NET MVC 風のコードを WebAssembly 化するもので、フロントエンド向けの SPA やサーバアプリケーションの両方を C# 及び同じフレームワークで開発出来るようになる「可能性」があります。

・・・JavaScript でなら今現在でも出来ますが、エンタープライズ系だと即時採用は難しいんですよね。既存資源の問題や、人材確保の課題があるので・・・

リサーチエンジニアは楽しいお仕事です

なんだか楽しくなってきました。こんな話なら無限に書いていられますね。

ここまで挙げた技術は、エンタープライズ系で実際に採用されるまでまだ数年はかかるだろう、と思われる技術です。エンタープライズ系とは、主に企業内における基幹業務向けシステムの領域で、IT ガバナンス的にどうしても安定した技術基盤の採用が求められます。いわゆる「枯れた技術」というヤツですね。

技術というものは世の中に生まれ出て、まずはコンシューマ系で採用され様々な試行錯誤に晒されます。その結果「枯れた」技術が、遅れてエンタープライズ系で採用されるわけです。このような現象をコンシューマライゼーション(consumerization)と呼ぶ事もあります。エンタープライズ系で採用されるまでの期間は様々ですが、例えば「クラウド」の場合、日本市場では概ね10年程かかりました。

さて、今回挙げた例では私が初期観測したのが、

・ 関数型プログラミング:2009年 ─ 今年10年目
・ WebAssembly:2015年 ─ 今年4年目
・ GraalVM:2018年 ─ 今年2年目

です。さて、実際にエンタープライズ系で採用されるタイミングは ──

このように「今は仕事では使わないけれど将来必要になる技術を研究する」エンジニアを「リサーチエンジニア」と呼びます。私はアーキテクトであると同時に弊社におけるリサーチエンジニアを長年務めています。
やはり我々はプロのエンジニアですので、実際のニーズが発生した時には既にその技術のスペシャリストでなければなりません。ですので、実際に使う事になるかどうか不明な技術でも、日々情報収集と研究に明け暮れ・・・

・・・という建前を示しつつ、本音で言えば、単にこういう技術の話題が大好きなのですね。趣味と実益を兼ねておりまして。

さて、それではまた海外の技術ニュースサイト見てみますか・・・

というわけで。

今回は SI/エンタープライズ系に関係する話題だけでしたが、弊社にはコンシューマ系にも対応するもっと「尖った」部門もあり、ビジネスチャットのアーキテクトグループではさらに多様・多彩な技術の話題で日々盛り上がっています。

今はエンタープライズ系にもデジタルトランスフォーメーション(DX)の波が押し 寄せていますので、コンシューマライゼーションまでの期間も短くなる傾向にありますし、弊社でももっとリサーチエンジニアの人数を増やしたい所です。
現代の技術の世界はあまりにも広大で、一人のアーキテクトの手に余るので・・・

いや本当に、こんな話なら無限に書いていられます。

さて、ちょっと今回は読む方を選ぶ記事だったので、次回はもう少し日本語比率の 高い記事にしたいと思います・・・

それでは、また第六回(あれば)でお会いしましょう。