EdgeX Foundryを推すNECの担当者に訊いた「忍者」的なシステムとは？

The Linux Foundation（LF）が推進するLF Edgeに属するエッジ向けソフトウェアプラットフォームのEdgeX Foundryを推進するNECの谷口暢夫氏にインタビューを行った。これは2020年2月に行われたEdgeX Foundry Meetupのフォローアップとしてインタビューしたものだが、EdgeX Foundryの話に留まらず、コミュニティのあり方やGoogleとの関わり方など多方面に渡る内容となった。

自己紹介をお願いします。

NECでEdgeX Foundryを推進する谷口氏

私は今、NECのデジタルプラットフォーム事業部というところで働いています。その部門はデジタルトランスフォーメーションを推進するのが役目なんですが、実際にはNECの各事業部と協力して顧客向けのSystem of Engagement、つまりSoEと呼ばれるシステムをやっています。その中でIoTのエッジの部分にEdgeX Foundryを推しているという立ち位置です。

NECには新卒で入社しまして、最初は中南米の局内交換機のビジネスをやっていました。父親の海外勤務が長く、スペイン語圏で仕事をしていた関係でスペイン語が話せたので、大学時代には1年間休んで南米で教師をやっていたこともあります。中南米のビジネスをしていた当時は徐々にオープン系のシステムが交換機にも入ってきていて、市場が入れ替わっていく時代だったと思います。

それでVoIPのシステムを海外のベンダーから仕入れて販売しようみたいな流れにのって、さまざまなベンダーのシステムを検討していた時にLinuxベースのシステムと出会いました。「おぉ、こういうのがあるのか！」っていうようにオープンソースソフトウェアに接しましたね。

その後、社内公募でOSS推進センターに異動して、その流れで今はデジタルプラットフォーム事業部にいるといったところです。オープンソースソフトウェアという意味ではDockerが出てくる前にcgroupとかnamespaceとかの議論がOSS系のカンファレンスで盛んに話されていて、その当時は何が何だかわからなかったんですが、Dockerが出てきて「あ！そういうことだったのか！」と腑に落ちたっていう記憶がありますね。

その後に参加したカンファレンスにはSamsungのエンジニアがいっぱい来ていて、「これはホビイストのソフトウェアじゃなくて本格的にビジネスで使うソフトウェアになってきた」というのを実感しました。

EdgeX Foundryとの接点は？

EdgeX Foundryはかなり初期の頃から注目していまして、社内での利用推進を行いながらPoCなどを実際の顧客と進めているという状況ですね。EdgeX Foundry自体は今、5番目にあたるFのリリース^※1、つまりFujiというのが2019年の11月に出たところです。IoTを実装するという時にエッジの重要性というのをずっと言い続けているんですが、EdgeX Foundryはニュートラルでベンダーの政治力みたいなものが少ないと個人的には思っています。

注：EdgeX FoundryのコードネームはB（Barcelona）から始まっているため、F（Fuji）が5番のリリースとなる。

参考：EdgeX Foundry Project Wiki:Roadmap

特定のベンダーが大きなコントリビューションを行うオープンソースソフトウェアだと、どうしてもそのベンダーのやりたいことや方向性に偏ってしまう傾向はありますね。実際にEdgeX Foundryを作っているのはどんなベンダーなんですか？

実際に大きなコントリビューションをしているのはDellやIOTech、Intel、Canonicalなどです。The Linux Foundationの傘下のプロジェクトとして活動していますが、LFが作ったIoTのエッジ関連プロジェクトを集めたLF Edgeにもメンバーとして入っていますが、同じエッジのAkraino（正式名は「Akraino Edge Stack」IntelとAT＆Tが寄贈したコードから構成されたオープンソースプロジェクト）と比べると、あまりキチッとしていなくてちょっとゆるい感じですね。

参考：IntelとAT＆Tが推進するEdgeプラットフォームAkrainoとは？

谷口さんが感じるEdgeXの「ゆるい」点をもう少し具体的に教えて下さい。

LFのプロジェクトですから、ガバナンスの面や組織自体はかなりキッチリできています。ゆるいと感じる点は、コードを書くことに注力していることと、あまり政治的なやり取りがないという部分ですかね。例を挙げましょう。これはあるカンファレンスで出た「LF AI Foundation」というプロジェクトに関する質問にLFの人間が答えていて気が付いたことです。その質問は「どうしてLF AIにはGoogleもTensorFlowも入っていないんですか？」というものでした。私もそれは疑問だったので、その答えに興味がありました。

そこでの答えは「GoogleはKubernetesをCNCFに寄贈したのを後悔している。だからTensorFlowもそうなって欲しくないと思っているからではないか」というものだったのです。KubernetesはLinuxに次いで成功しているオープンソースプロジェクトだと思っていたので、この答えには正直びっくりしました。Googleはもっと自分達だけでコントロールしたいと思っているということなんですね。

しかしオープンソースプロジェクトがニュートラルであることでKubernetesはあれだけ成功しましたし、すべてのパブリッククラウドプロバイダーも参入してきて互換性も高く維持されています。そう考えるとこれは難しい問題だなとは思います。

その話はちょくちょく聞きますね。私も海外のベンダーのエグゼクティブにインタビューした際に何度か言われました。GoogleはKubernetesをCNCFに差し出したことを後悔していると。

しかしオープンソースソフトウェアってLFの（Executive Directorである）Jim Zemlinさんがよく言いますけど、「ProductがProjectになってProfitを産むというサイクルが上手く回ることが絶対に必要」なのです。

これはよく誤解されていると思うんですけど、オープンソースソフトウェアってソフトウェアそのものも重要ですが、それを支えるコミュニティなどのコード以外の部分も非常に重要なんですよね。私の見解では、それはマーケティングに属する領域です。だからKubernetesがエコシステムとして成長しているのは良いことのはずなんです。そういうエコシステムがないとイノベーションが起こらない。例えばエッジとビルマネジメントのシステムと連携することで、単に管理がスマートにできるだけじゃなくて、複数のビルを連携させてプロジェクションマッピング使って街の見え方を変えてしまう。そういうこともできるわけです。

実際上海の街はそんな感じになっていますよね。あとドローンを使って花火の代わりに夜空を演出するとか。

そうです。でもそれを実現するために技術やソフトウェアの占める割合というのは小さくて、街の規制や法律と調整をすることなどのコード以外の部分がとても重要なんですよ。そしてこのような突拍子もないことって、一つのベンダーだけではできないわけですし、そういうことを発想するアイデア自身も産まれないのです。だからそういう部分がオープンソースソフトウェアになっていることには大きな意味があると思います。

ソフトウェアだけではなくてそれを取り巻く環境を変えることが重要っていう指摘ですね。それはDevOpsにも通じる話ですね。日本では開発と運用が別会社だったり、開発は外注、運用は社内という組織構造になったりしているのに、外資系のDevOpsのツールベンダーが「ツールを入れれば御社もDevOpsが実現できます！」と安請け合いをするのを見てると「あー、何もわかってないんだな」って思います。

そうですよね。あとこれはSystem of Record（SoR）をやっている会社がSystem of Engagement（SoE）をやろうとする時に顕著になるのですが、SoRは現場から業務改善の提案で何かをシステム化するものであるのに対して、SoEはそもそもこれまでやっていなかったことをやろうとするわけです。

ホワイトボードを使って説明する谷口氏

つまり自動車メーカーが、モノではなくてクラウドと連携して今までやったこともないようなサービスを提供するようなものですか？

はい、そうなると現場の改善では難しいです。それをビジネスとして発想する人も、現場にはいない人、つまり外部から引っ張ってきたほうが良いみたいなことが起こるんですよ。

そうするとシステムだけの話ではなくなっちゃいますよね。

あと「今後12ヶ月でこうやって計画して、コストはこれだけ、売り上げはこれだけ」みたいなプランニングをキッチリやってからビジネスを始めるみたいな発想でもダメなんですよね。

SoRとSoEの違いで私がよく例に出すのは、「SoRは侍、SoEは忍者」だなと。つまり侍は何かをやるにしても、まず殿様にお伺いを立ててOKをもらってから敵の首を取りに行く。でも忍者はとりあえず素早く動いて敵の首を取ってきちゃう。そういった忍者の素早さ、とにかく慎重に計画してというのではなく、まずは動いてから考える、真っ暗で向こう側に何があるのかわからないけど、とにかくジャンプする。このように、常にあらゆる可能性を考えつつ、その場その場で最適な動きをするみたいなことが必要なんだなと思います。

Red HatのCEOのJim Whitehurstがちょっと前のRed Hat Summitで「Planning is Dead」つまり「計画を立てること自体に意味がない」と語っていましたが、それにも通じる考え方ですね。

納得できますよね。あとSoEの場合、カスタマーエクスペリエンス（CX）というのも重要になるんですけど、それって体験なのですべての要件を考えてシステム化するというのではなくて、かなり偶発的なことが起きます。そして、それに対応するという姿勢が大事かなと思っています。たまたま作ってみたらおもしろかった、ではそれをスケールさせるためには何が必要か？　みたいな発想ですね。

最後になりますが、EdgeX Foundryが次にやるべきことはなんでしょう？　個人的な意見で構いませんので教えて下さい。

コアな部分はもうできています。ですが、例えばビルマネジメントのシステムのプロトコルでBACnetというのがありますが、これへの対応が完了しているわけではなくてポイントで対応するのに留まっているなんていうことがあります。そういうのを、ちゃんとどのバージョンでも対応していくというのが必要でしょうね。デバイスの下のほうのプロトコルなどは、別のモジュールとして対応していくというのは正しいと思います。

あとこれは社内的な話ですが、確実に導入例を積み上げていって、「IoTのエッジといえばEdgeX Foundry」というようになることですね。実際には私も個人として参加していて、NECという企業はEdgeX Foundryには参加していないんです。そこで、「成功例を積み上げてNECとしてコミュニティに参加する」というのをやりたいと思います。

2月に東京で行われたEdgeX Foundry Meetupにも参加して、EdgeX Foundryの啓発にも力を入れる谷口氏だが、まずは成功例が重要というのはLPI-JAPANの理事の鈴木敦夫氏も語っていた社内説得のためのマイルストーンと言ったところだろう。

NECはエンタープライズとパーソナルコンピュータやAtermに代表されるコンシューマー機器の両端を実践できているベンダーとして、IoTエッジには大きなビジネスチャンスがあると谷口氏は語る。エッジデバイスのキーとなるプラットフォームとしてEdgeX Foundryがメインストリームになれるか？　これについては、引き続き注目していきたい。