オープンソースに「実績は？」と聞く虚しさ

実績は世に出てこない

永遠のテーマかもしれません。

何かオープンソースのプロダクトを現場に導入しようとしたとき、

「えっ、実績は？」

という質問が発生することがありますが、実はこれほど虚しいことはありません。

システムで何のツール使われているのか？

これは機密情報に当たりやすいので、当然なんの許可もなく社外に言いふらせるものではありません。言いふらそうと思うきっかけもないかもしれません。

当然、利用されたツールの実績は、世の中に出て来ません。

オープンソースのジレンマ

有償のツールだと、買い手がわかる (可能性がある) ため、ビジネス的にも実績情報を活用したいですから、買い手に依頼をして実績会社として紹介させてもらうというような線もあるかもしれません。

ですが、オープンソースのプロダクトだと、多くはダウンロードされておしまい。(有償ではないオープンソースを前提にしています)

誰がダウンロードしたのかもわからない

ちょうど、こないだの JJUG CCC 2016 Fall にて、オープンソースの Mixer2 の作者の方が、まさにこのジレンマを発表されていました。
俺のコードがどこでつかわれているのかわからない問題あるいはマイナーOSSの生存戦略 | Slideshare

ダウンロード数くらいはわかりますが、昨今は「誰か一人がダウンロードしてプロジェクトで共有」という形ではなく、Maven や Gradle などのビルドツールで、各自のPCでダウンロードさせたりしますから、ダウンロード数と現場の数というのが、いまいち比例しません。
(いずれにせよ、プライベートで試してみた、というダウンロードもあるでしょうし)

オープンソースの作者からすれば、どの会社で使ってもらっているのか？という情報は、喉から手が出るほど欲しいものです。それは、有償のツールだろうが、オープンソースプロダクトだろうが、広めたいわけですから、その欲求は同じです。

でも、オープンソースプロダクトだと、その情報を手に入れるのは困難です。営業するにしても、どの会社に当たって良いのかもわからない。だいたいお金もらってないから、営業するコストがもろにポケットマネー。普段別の仕事している人が大抵ですから、そういう活動に時間は割けません。

無意味な質問

これを踏まえると、「実績は？」という質問自体に虚しさがあることがわかります。

わからない

としか言いようがなく、非常に無意味な質問に聞こえるからです。

これは、そのツールを提案した人に限らず、オープンソースの作者だって同じ状況です。

もしかしたら全く実績ないかもしれないし、逆にめちゃくちゃ実績あるのかもしれない。

頼るのは名声!?

そこでみんなが頼るところは「知ってるかどうか？」です。

"実績は？"質問のパターンで、

「聞いたことないツールだけど実績は？」

というのが圧倒的に多いです。

実際には、その人がたまたま知らないだけ、縁遠いだけ、というケースも多いのですが、人間「知らないことは不安」という性質を持っていますので、当然と言えば当然です。

逆に言うと、聞いたことのあるツールに関しては、あまり実績を問わない傾向にあります。

要は、先の通り世に実績情報がないので、ネット上や雑誌などで話題になっているか？そういったところに頼るしかないわけです。話題になっていれば耳に入ってくる、話題になっていなければ耳に入ってこない、耳に入ってこないということは使われてない。

ちなみに、"実績は？" と問われる方が、そもそもそういう技術情報に敏感かどうか、というのも気にするところです。実は話題になってるんだけど、その話題をキャッチしてないだけとか。

いずれいせよ、実績という言葉が、わりとふわふわした論理で成り立っている、というのがポイントです。

メジャーとマイナー

どれだけ頑張って議論しても、あまり情報量は変わりませんから、

有名なオープンソースなら大丈夫だろう

という結論に陥りやすいです。

当初、実績を細かく気にしていたのに、結局、有名でメジャーだから実績ある、という論理で落ち着くことが多いです。

ゆえに、マイナーなオープンソースプロダクトは、メジャーなオープンソースプロダクトよりも、しっかりと説得力のあるセオリーを組み立てないといけません。

メジャーなオープンソースプロダクトは、有名というだけで、その義務が免除されやすいです。

実績を気にして実績ないコード

でも、jfluteはそこに危険な匂いを感じています。

「メジャーだから実績ある」というセオリーは、「システムは千差万別」という前提を押し隠す

ものになりやすいからです。

...

本来議論しないといけないことは、

この現場にフィットするのか？

ということなので、メジャーなツールを選んだとしても、それが、この現場にフィットするのか？フィットさせるためにどういうことをしたらいいのか？この議論が必要だからです。

つまり、有償ツールだろうがメジャーOSSだろうが、マイナーOSSだろうが、この工程は必要なのです。

でも、

1. メジャーだから実績ある
2. 選定終了
3. さあ作り始めよう

この流れをよく見かけます。

行き着く先で見かけるものは...そのメジャーなオープンソースプロダクトが「可哀想だなぁ」という光景。

うまく使いこなされないメジャーなオープンソースプロダクト、本当はこうすればいいのになぜか自分たちでガリガリ書いてる。そのメジャーなオープンソースプロダクトの上に、自分たちで作った独自の仕組みが積み重なっている。ある程度は仕方ないけど、随分多いような...

「そのコードって、実績ないよね？」

実績をすごく気にしていたのに、実績のないコードがそのシステムの中核を担っている

そんな現場たくさんあります。

まあ、そのコードが一概に悪いわけではなく、メジャーなオープンソースプロダクトではすんなり解決できない特殊な要件が、その現場あるならしょうがないわけで。そういうことは往往にしてよくあります。
　=> なにを社内フレームワークと呼ぶか？

ただ、単純に使いこなしきれてないだけだと、"おいおい" 感じになるわけです。それは現場のプログラマーの実力もありますが、選定の時に議論していないことも大きな要因です。フィットするかどうか？どうやってフィットさせるか？

...

いつも jflute は...あの一年前、二年前の「実績」にこだわった議論って、いったんなんだったんだろう？って感じるわけです。

「実績関係なくない？」

とまで言わなくても、

「実績あるから(有名だから)って、何も気にしないじゃダメじゃない？」

と言いたくなるわけです。

現場フィットレイヤのプログラムは、できるだけ少なくしようと努力はしますが、多かれ少なかれ必要だったりもするので、そこまで視野に入れた議論しないと。

もし、そこまで実績を気にしてるのであれば、そもそも実績のないコードがシステム内に蔓延することを防ぐ施策を考えないと！

質問と行動の矛盾

そして...

オープンソースに「実績は？」と聞くのであれば、いざその現場で使うことになった時には、その実績を世の中に公開するでしょうか？

例えば、jfluteは色々な現場に行く都合上、色々と知っていることはあります。

「それ教えてくれ！」

そう言われても、

「御社の実績も他社に伝えてよろしいでしょうか？」

と言わざるを得ないのです。

もし、その行動と覚悟がないのであれば、いたって矛盾した姿勢であるとも言えます。

自分は情報を出さないのに、人から情報は引き出したい

これはオープンソースの話に限らず、一般にあまり褒められる行為ではないですよね。

もちろん気にするけどね

とはいえ、もちろんjfluteも気にします。仕事においては、ギャンブルするわけにはいかないですから、その現場へのフィット感を探るために。

ただ、実績という言葉を、「利用してる人が多いかどうか？」という単純な解釈だけではなく、適用しようとしている現場に似た現場で実績があるのか？という風にも考えます。

なぜなら、たくさんの実績があっても、この現場のマニアックな状況と同じ状況で、実績があるとは限らないからです。システムというのは千差万別。よそでうまくいってるから、ここでうまくいくとは限らないし、よそで失敗してるからってここで成功しないとは限らない。

なので実績の内訳を気にしますし、一方で実績といってもその程度の判断材料でしかない、という感覚も忘れません。

そして、気にするからには、できるだけ情報を公開できるよう努めます。情報公開することによる会社のメリットを確立させつつ(ブランド力のアップなど)、ツール側もメリットが得られるように。それで win-win のきっかけになるはずで。情報公開をビジネスにしないと。

# 最近で言うと、U-NEXTさんが JJUG CCC で、
# LastaFluteやDBFluteの実績を発表 (Slideshare)
# してくれました。
# 会社にもメリットがあることを提案し理解をして頂けました。

プログラマーもそういう提案や行動していかないと、この問題はなかなか解決しないと思います。

ちゃんとオープンソースを知ろう

この手の話は尽きません。いたる現場でいたる人から、似たようなジレンマ話を聞きます。

とはいえ「実績は？」と聞く人が悪いわけではありません。気にするのは当然のことなので。ただ、オープンソースというものを知らないだけ。

jfluteは、今後同じような話になったら...

「このブログをまず読みましょう！」

と提案します。そのために書きました。

あまりに色々な現場で、同じ話をし続けて来たからです。しっかり話をすれば、多くの人に理解してもらっています。

もし、そのオープンソースの特性を受容できないのであれば「その現場ではオープンソースを使うべきではない」という話に落ち着くだけです。そういうビジネス判断も悪くはないでしょう。

オープンソースたちも、ちゃんとわかって使ってもらいたいはずです。