日本でOSSのコントリビュータを増やすには何が必要か？ 座談会形式で語り合う（前編）

オープンソースソフトウェアをITシステムの基盤やミドルウェア、Webフロントエンド、IoTデバイスなどの開発などに使うことは、もはや避けて通れない。アプリケーション開発においてもプログラミング言語はオープンソースが当たり前だ。オープンソースソフトウェアの開発をコミュニティに委ねる場合、多くのコントリビューターが必要となるが、現実的にはRed Hat、Google、Microsoftなどの巨大企業に雇用されたエンジニアが仕事としてコードを書き、バグの修正を行っているケースと、そのソフトウェアを最初に開発し始めたベンチャーのエンジニアがコアとなって開発するケースとの2つが主な形態だろう。そこにそのソフトウェアを利用するエンドユーザー側のエンジニアが参加し、エンドユーザー側が欲する機能やバグ修正をコミュニティのメンバーとして続けていくという状況が欧米での実態だろう。

日本においてもNTTデータやNEC、富士通、日立などの大手IT企業が業務の一環としてオープンソースソフトウェアの開発に参加するというのが一般的な姿だろう。オープンソースソフトウェアを開発するコミュニティが建前として「コミュニティが主体」と言ったとしても、実態は大手企業のエンジニアやベンチャーのエンジニアがコアとなっているという状況は変わらない。しかし、日本における状況は欧米のそれとは異なる。

なぜなら日本ではソフトウェアエンジニア（特にデベロッパー）がエンドユーザーに所属している例が少なく、多くのソフトウェアエンジニアは大手ITベンダーおよびシステムインテグレーターに所属し、エンドユーザーからの開発案件を受託して開発、納品するという形式が一般的だからだ。

システムインテグレーターも多くの開発において開発プロセスは子会社や外部のソフトウェア開発会社に発注し、その進捗管理を行うというのが常識だろう。運用はエンドユーザーのIT部門が行うにしても、この構造ではエンドユーザーがオープンソースソフトウェアのコミュニティに参加する可能性は極端に低くなる。そんな状況から、オープンソースソフトウェアのコミュニティに参加して貢献を行うエンジニアを増やすためには何が必要か？ これについて、業界の識者に座談会方式でインタビューを行った。

前置きが長くなったが、今回は草の根のオープンソースコミュニティの支援活動を続けてきた日本仮想化技術株式会社の宮原 徹氏、同じく玉置伸行氏、ニュートラルな視点で俯瞰できる立ち位置にいるThe Linux Foundationの江藤 圭也氏、企業からの貢献を続けているNTTの水野 伸太郎氏、同じくNECの元木 顕弘氏に集まっていただき、座談会方式で意見を出してもらった。

座談会参加者、左から水野氏、玉置氏、江藤氏、宮原氏、元木氏

最初にこの会をやりたかった背景をぶっちゃけてお話しますと、オープンソースソフトウェアが当たり前になってきている中でそのコミュニティへの貢献を企業に属しているエンジニアが仕事と両立しながら行うということを上司に納得させるには何が必要なのか？ を探りたいんです。まずは日本のOSSコミュニティへの貢献が今どうなっていると認識しているのかを江藤さんに伺いたいです。

江藤：そうですね。良い話からしますと日本の証券取引所を運営しているJPXという企業があって、そのグループ企業で決済の清算を行う会社のJSCCという企業があります。JPXグループはarrowhead（金融商品取引システム）を開発した2010年より前から、海外の同業を直接訪問・勉強されていて、海外では先行してオープンソースを使う、特に清算処理はオープンソースのHyperLedgerでやるのが普通だということをよくご存知です。それを上位幹部の方もよく理解されていると。これはHyperLedger Meetup、今はLFの中ではDecentralized Trustと言う名称になっていますが、そのイベントの中で言ってました。なのでコンサルティングやシステムインテグレータも入ったそうですが、コアな業務部分を、オープンソースを使って自社エンジニアがビルドするというのが、トップまで含めて海外の事例を理解して実行した例になりますね。

でもそれっていわゆる黒船がやってきて急に方向転換をせざるを得なかったという稀な例ですよね（笑）。HyperLedgerで開発なんて普通のシステムインテグレーターじゃ請けてもらえないっていう。

江藤：そうですね。それを黒船方式ではなく普通の企業が自主的にやるっていう例は、ないことはないですが、どっちかというと会社の中の上のほうにいる私のような威勢の良いおじさんが「俺がこのオープンソースでやると決めたからやるんだ！ 予算も通してくる！」みたいな横暴なやり方でオープンソースを用いて開発するっていう例が昔はありましたね（笑）。

NTTの水野さんとしてはどんな認識ですか？

水野：企業がオープンソースソフトウェアを使うという時にいくつかのレベルがあると思うんですよね。最初はエンドユーザーとして使うレベル、それからバグを見つけてその修正をコミュニティに還元するというレベル、そして最後は、機能が足らないのでそれを実装してコミュニティに還元するというレベルです。最初のレベルであっても「誰が書いてるのかわからないコードを使うのか？」とか「バグが出たら誰が直すんだ？」というのに応えなきゃいけないというハードルがあって「そこはレッドハットさんにお任せします」みたいな言い方で乗り越えたとしても、その次に行くのは相当難しいですね。

元木：これはシステムインテグレーターの立場でも同じですね。コミュニティへの貢献という観点で見ると、お客さんから案件が来てそれにオープンソースを使って開発したとして、足らない機能の部分を独自に開発して提供するのか、それとも元のオープンソースソフトウェアの機能追加として戻して取り込んでもらうのか、という判断をしなきゃいけない段階というのが来ると思います。独自に開発すると、元になったオープンソースが更新された時に合わせてテストもしなきゃいけないし修正も必要になるかもしれない。なのでそういうのは元のオープンソースに還元したほうが良いという話も出てきます。

水野：NTTが、独自に開発するのではなくオープンソースソフトウェアに還元するっていう発想になったのは、OpenStackをやっている時ですね。OpenStackに足らない機能やバグ修正を研究所のエンジニアが作って社内に閉じた形、内部パッチみたいな形で持っていたんですけど、それが150件くらいに積み上がった時に「これは毎回、新しいバージョンに併せて確認したりするのが大変だ」ということになってそこから「Upstream First」っていう方針に変わったんです。

NTTは研究所っていうパッチを作れる組織があったからできたのかもしれませんが、それでも150件も積み上がるまで、還元しようという発想にはならなかったのですか？

水野：それはですね、作っちゃったからそれは終わったこととして次に行っちゃうわけですよ。気が付いたら貯まっていました。その時に考えたのは、内部パッチとしてバグ修正とか機能を追加している資産なのにも関わらず、この形式だとずっと面倒を見ないといけない負債になっちゃうんですよね。なのでそれは止めようと。ただし社内にはそれは自社の資産、知財なんだから持っておくべきだと言う意見があったのも確かです。でもお金を儲けるにしてもここじゃないよね、もっと別の部分でやるべきだよねというように意識が変わり、それでUpstream Firstの考え方に変えて全部コミュニティに戻しました。

元木：実際にやろうとすると、バグを修正してコミュニティに還元という2番目以降のレベルをマネージメント層に理解してもらうのはすごくハードルが高いと思いますね。プロジェクトの中でバグを見つけたとしてそれを還元することを「なんでお前がやるんだ」とか「そういうのは他の人にやってもらえ」みたいな言い方に対して有効な回答がないのです。長い目で見ると、コミュニティに還元することで認めてもらえて何かあった時に解決が早くなるみたいなことはあるかもしれませんが、それもコミュニティによって違いますし。バグ修正のパッチをプルリクで送ったとしてもそれがマージされるかどうかもわからないし、「責任者は誰だ？」みたいなことを管理職に聞かれても明確には答えられないこともあるでしょうし。

玉置：企業の案件でオープンソースを使ってその中でバグを直してUpstreamに戻すなんていうのは、そのユーザー企業と開発を行うシステムインテグレーターがどれだけちゃんと握れているのか、つまりオープンソースに対する認識を合わせておけるか、という話なんですよね。そこがちゃんと合っていると、コミュニティに還元する時に問題はあまり発生しないと思います。

水野：パッチを出したは良いけど、それがいつ適用されるのかはわからないし、下手すると年単位で待つ必要があるかもしれない。そういうところも含めて待てるか？ というのは重要ですよね。

「俺たちはお前らにこんなに金を払っているのにどうしてこれが直らないんだ、責任者呼んで来い！」みたいな商用ソフトウェアのようなケースがまったく通じないのがOSSっていうことですよね。

水野：企業からオープンソースソフトウェアに貢献しようとすると、発生する問題点として良く挙げられるのはライセンスに含まれる関連条項なんですよね。これをちゃんとやろうとするとすごくコストがかかる。つまり開発を行ったのが自社なのか関連会社なのか、このライセンスが及ぶ範囲はどこまでか、そういうことをちゃんと知財とか法務と確認しなきゃいけない。まじめな企業になればなるほどコストがかかるんですよ。

宮原：そういう意味ではその辺をグレイにできるいい加減な企業のほうがやりやすいかもしれませんね。

知財の話もそうですし、エンジニアが仕事中にコミュニティ関連のことをしていることもある程度、なぁなぁで行けるかもという意味ではそうでしょうね（笑）。

後編（3月4日公開予定）は草の根オープンソースの変化と、エンジニアの取るべき選択肢に関する内容が続く予定だ。