KubeConで富士通のエキスパート江藤氏に訊いたOSSの勘所

KubeConがクラウドネイティブなシステムのためのカンファレンスであり、多くの新興ベンチャー、オープンソースプロジェクトに関わるエンジニアが集う場所であることは疑問の余地はない。また同時に、システムインテグレーターなどの旧来のプレイヤーにとっては、クラウドネイティブなマーケットに対して「どこにフォーカスしたら良いのか？」「ツールは何を選択すべきか？」などの答えを見つけるための場所でもある。

富士通は、Linuxの初期の段階からオープンソースソフトウェアにコミットをしているシステムインテグレーターだ。その中で中心的な存在であり、今もThe Linux Foundationのボードに名を連ねる江藤圭也氏（富士通株式会社 プラットフォームソフトウェア事業本部Linux開発統括部統括部長）にKubeConの会場でインタビューを行った。

富士通のオープンソースソフトウェアのキーパーソン江藤圭也氏

富士通のオープンソースソフトウェアへの関わりについては、江藤氏がインタビューに応えた以下の富士通のブログ記事を参照されたい。

参考：OSSの地平へ 富士通の取り組み なぜ富士通はOSSにおいて中心的な役割を果たし続けるのか?

江藤さんは富士通でオープンソースをやっているわけですが、プロプライエタリなソフトウェアにも精通していると思います。プロプライエタリなソフトウェアに携わっているエンジニアと比べてオープンソースのエンジニアはどこが違いますか？

当然ながら富士通には、プロプライエタリなソフトウェアやお客様から発注していただいたソフトウェアを開発しているエンジニアがいます。実は、定期的に担当する分野のシャッフルはしているんですよね。私自身はプロプライエタリなソフトウェアというか、従来のウォーターフォール型の開発で進められているプロジェクトが悪いとはまったく思っていません。ちゃんと教育を受けて基本からソフトウェアを開発するというやり方は、悪いわけではないのです。ただ私の立場から言えば、今やオープンソースソフトウェアで開発をしないと相手にしてもらえないという状況はあると思いますね。

ただ現在のニーズにはマッチしていない、と。今はいかに素早く機能を実装できるか？の戦いですからね。

それは言えるかもしれませんね。対外的に見ればオープンソースプロジェクトに関わっているエンジニアってちょっとチャラチャラしているし、軽いと思われるかもしれませんが、エンジニアとしては真っ当な人ばかりです。

この機会に江藤さんにお訊きしたいことがあります。クラウドネイティブやアジャイル開発、そしてDevOpsと盛んに言われていますが、日本の事業会社ではそれを実施するのは難しいと感じています。ひとつには開発者が社内におらず外注化されていて、運用は社内という構造的な問題があると思います。でももっと会社の中に開発を行うエンジニアを入れようという流れができているとは思います。ではそういう事業会社がクラウドネイティブになっていくためには、どの辺から何をしたら良いのでしょう？

そんなことがわかっていたら苦労はしませんよ（笑）。私の経験からお話をします。Linuxという狭い領域に関して言えば、今やLinuxはHPCから組み込みまで幅広く応用が広がっているわけです。これを車で例えると、ダムを作る時に使うような数十トン積みのトラックと、街を流しているタクシーの両方に使えるような車を作れということを、ソフトウェアでやっているのが、Linuxだと思うんですよね。

私がLinuxを始めた当初は、HPCにLinuxが使えるようになるなんて思ってもいませんでした。でもすでにHPCのプラットフォームの大部分はLinuxになっています。で、その無理な要求を実現するためには非常に基本的な技術を積み上げていくしかないわけです。それをちゃんと積み上げていくことで、スケールアウトするようなプラットフォームが実現できる。

しかしだからといって現場からの要求をすべて実現できるわけではないし、そもそも業務の現場からの要求を完全に理解しているソフトウェアエンジニアがいるのか？　という話にもなるんですよ。そもそも理解できるものなのでしょうか？　

エンジニアが「分かった！」っていう時に、理解したつもりだとか誤解だとか妄想だとかいろいろ世間からは言われると思います。でもそういうエンジニアの思いこそが重要ですし、世の中を動かしていると考えています。そういう熱い思いを伝えていく、コミュニケーションしていくことが重要ですよ。

コミュニケーションが重要という部分から発展させますが、オープンソースソフトウェアって会社の中だけじゃなくて、世界中の国も組織も違うエンジニアとコミュニケーションしながら進めていくじゃないですか。そういう時にどうやってコミュニケーションすれば良いのか？　こういうことは誰も教えてくれないと思うんですよ。その部分をもう少しわかりやすく伝えられたらと思うんです。

その部分で言えば、富士通の経験を紹介しますね。Linuxの開発の時に社内のエンジニアが機能拡張についていろいろと提案して説明したりしても一向に採用されない、マージされない、というのが2年ほど続いたことがありました。その時にある人が、他のコミュニティのメンバーがどういうコミュニケーションをしてるのか？　これを調べたことがあるんですよ。そうすると上手く新しいコードをマージしている人達っていうのは、クリーンアップと称してソースコードになにかしてるんです。で、自分たちが入れたい機能が入りやすくなる環境を作っている。そういうことをしながらキーパーソンにちゃんとアプローチして、最終的に入れたい機能をマージしている。単に機能の説明をするだけじゃダメっていうことがわかったんです。

それはいわゆる根回しとは違うものですか？

根回しとは違いますね。ちゃんとコードに対して仕事をしているわけです。もちろん、さっき言ったように誰がこのプロジェクトのキーパーソンなのか？　これを知る必要はありますよ。でもそれってプロジェクトによって違うし、一般解ではないんです。

そういう意味ではコミュニケーションの中でも、ハイコンテキストとローコンテキストというものがありますよね。つまりハイコンテキストは日本人がよく言う「行間を読む」みたいに全部言わなくてもわかるだろう？　みたいなモノです。そういうのをちゃんと理解しないといけない。

ローコンテキストは「すべて文字で説明しないと伝わらない」みたいなものですか？

そうです。ローコンテキストの典型的な例を挙げると、私が以前読んだ本には「世界で最もローコンテキストな人間はドイツ系スイス人である」と書かれていました。かつて打ち合わせをしたRed HatのVPでサポートの責任者の方が、そのドイツ系スイス人なんですよ。で、その打ち合わせはRed HatのLinuxのあるリリースの修正を依頼しに行ったんですが、「ここの部分にはバグが多い。だから直してくれ」みたいなことを訴えたんですが、それが全然通じないんです。つまり、抽象化した言い方で「何％こっちが多いからこうしてくれ」みたいな言い方では伝わらないんですよ。その人は「そのバグは具体的にどういうものだ？　全部オレに見せて説明しろ」みたいな形で数百個あるバグの全部を説明しないと理解してくれないんです。その時は、Excelで整理した細かい内容を全部見せて説明しました。そういうローコンテキストな場合もあるわけです。

それって私がMicrosoftにいた時に、ビル・ゲイツにプレゼンテーションをする時はパワーポイントやExcelのグラフじゃなくて生のデータを持っていかないと上手く行かないというのと同じですね。ビルはグラフじゃなくて全部具体的な数字で把握しようとしてましたから。

でもやっぱり人間ですから浪花節みたいな感情も大事な場面も多いんですよね。

江藤さんにぜひ伺いたい質問があります。あるビジネスマンが江藤さんに「新しいビジネスをやるためにソフトウェア開発をしたい。そのためのチームを自由に作ってくれ！」って依頼されたらどんな組織を作りますか？　それってこれから起業しようとする人達に参考になると思うんですよ。

良い質問しますね（笑）。そうだなぁ、ひとつだけ言うとしたら開発とサポート、営業は混ぜちゃダメなんですけど、遠くに離し過ぎてもダメっていうことかなぁ。組織としては分かれていても近くにいないと、コミュニケーションが取りづらくなって貴重な意見が聞けなくなる。そういうことは大事だと思いますね。

あと組織という意味ではCNCFもそうですが、例えばHelmのチームのUpdateとか聞いてても凄くちゃんとしてるんですよね。オープンソースプロジェクトなのに、ガバナンスとか意思決定のプロセスが。

それはそうですね。CNCFについては、多分にCTOのChris Aniszczykが頑張ってると思いますね。Twitterでの彼の経験が凄く活かされていると思います。そういう意味では、オープンソースプロジェクトだからといっていい加減というわけではなく、逆に相手がどこの誰だかわからない分、ちゃんとした組織やプロセスを作らないと運営が難しくなるというのは経験として活かされていると思います。

今回は聞けませんでしたが、次回はぜひ、The Linux FoundationやCNCFとの上手い付き合い方みたいな話も聞かせて下さい。お忙しい中、ありがとうございました。

実際にはここで記したよりも多くのトピックについて語ってくれた江藤氏であった。オープンソースプロジェクトの運営の経験やCNCF、The Linux Foundationとの付き合い方など、これからオープンソースプロジェクトに参加していこうというエンジニアには参考になるヒントをいくつも共有してくれることを期待したい。