Elasticsearch普及のカギは「365日グッドリスナーであること」生みの親Shay Banon氏の開発哲学
全文検索エンジンElasticsearchは、ビッグデータ分析や可視化の分野で世界的に利用されているプロダクトだ。このほど、オープンソースプロジェクトとしてこのElasticsearchを開発した技術者であり、運営するElastic社(本社オランダ)のCTOであるShay Banon氏が来日を果たした。
Elastic社の製品は、ElasticseachやkibanaといったOSSから有償サービスまでを含めると、全世界で3000万件以上のダウンロード数を誇るという(2015年7月時点)。これらの製品群を支えている技術者約130人、社員約250人は世界各地に散らばり、リモートでプロジェクトにあたっている。
また、開発トップであるBanon氏は、世界中のユーザーから四六時中寄せられる問い合わせほぼ全てに自ら目を通すなど、桁外れのハードワーカーとしても知られる。
弊誌は今回、このBanon氏に単独インタビューする機会を得た。オープンソースプロジェクトの世界的な成功者の仕事哲学に、イノベーションのヒントを探った。
OSSは魔法ではない。成功のためには努力と投資が不可欠だ
―― 今回はShayさんの仕事の流儀、仕事哲学について伺いたいと思っています。はじめに、どのような経緯でオープンソースのプロジェクトに関わるようになったかをお聞きしたいのですが?
15年前に移住した先のロンドンで、シェフになるための勉強をしていた妻のためにアプリケーションを作ろうとしたのが始まりです。
レシピなどの料理の知識を簡単に検索できるようにするために、Apache Luceneという全文検索ソフトウエアのプロジェクトに携わったことがきっかけで、その後、Luceneに基づいたCompassというプロジェクトを立ち上げることになりました。
OSSにはその前からユーザーとして関わっていて、その運動には関心がありました。その後のキャリアはオープンソースありきのものと言っていいと思います。
Compassのプロジェクトを通じて、OSSを普及するために必要な2つのことを学びました。一つは、非常にシンプルなものでなければならないということ。もう一つは、それなりの投資をしなければならないということです。OSSは、放っておいても勝手に広まるような魔法ではありません。
夜も寝ずにメールに回答したり、週末にもIRCで話したりしました。Compassでの7年を通じて、OSSのプロジェクトを成功させるのにはどれだけの努力が必要かを知っていたので、Elasticsearchをゼロから作り始めるのはとても勇気がいることでした。
ただ、ユーザーやコミュニティ、インフラは自分の想像を超えて広がっていったので、続けていくという決断はすぐにできました。
―― Elasticsearchはどこから着想を得て開発したのですか?また、それを会社化することにしたのはなぜでしょうか?
Compassは1台のサーバで完結する世界であって、あるプロジェクトで使われ、終わると使われなくなるという類のものでした。
しかし、世の中で扱われるデータ量は日に日に増え、クラウド技術も進展した。そうした環境の変化もあり、もっと良い検索エンジンが作れるばずという思いを強くしていったんです。
Compassでの経験があったから、成功するにはかなりの努力と投資を要することは分かっていましたし、多くの人が自分の提案を受け入れてくれるだろうという自信もありました。それで、勤めていた会社を辞め、100%このプロジェクトにコミットすることにしたんです。
幸いにもヨーロッパやシリコンバレーのスタートアップの人たちなどが使ってくれたため、次第に24時間365日来る問い合わせに対応しなければならなくなりました。このタイミングでしっかり対応しなければMiss outするという思いがあり、会社化するという決断に至りました。
―― エンジニアの中には、ビジネスをめんどくさいものと思い、できればプログラミングに専念したいと考える人もいます。Shayさんはどうでしたか?
人生のタイミングにより考え方は変わったというのが、質問に対する答えです。
妻がシェフになるのをサポートしていたころは、私は銀行でプログラマーをやっていましたが、彼女の決断をサポートすることが最優先の事項でした。
しかしその後、良いビジネスアイデアが見つかったため、起業してもいいだろうと考えるようになりました。
コードを書くことも大事ですが、会社をどうやって起業するかなど、ビジネスサイドのことを考えるのも、同様に大事だというのが私の考えです。
ユーザーの声に耳を傾ければ自ずと解は見えてくる
―― 世界中に多くのリモートワーカーを抱える会社のCTOとして、働き方に関するこだわりや流儀はありますか?
リーダーは、マーケティングやビジネス戦略など、エンジニア以外の視点も持つ必要があると思います。でなければ、「なぜ自分たちはそれをやっているのか」というストーリーを語ることができないからです。
そういうストーリーが社員のモチベーションを生み、彼らをイノベーティブにさせるのだと思っています。
また、こちらから社員に伝えるのは、重要ないくつかのことだけです。後はそれぞれに任せるようにしています。社員1人1人が真剣に考えるからこそ、OSSのパワーは発揮されると考えているからです。
オープンソースのプロジェクトの強みは、プロダクトの背後に多くのユーザーがいることです。一般の会社であればロードマップが必要ですが、オープンソースでは、彼らの声に耳を傾けさえすれば解は出てきます。
グッドリスナーでありさえすれば良いのです。
―― チーム運営に関して、今のようなお考えにたどり着くまでに失敗や試行錯誤はありましたか?
もちろん。例えば世界中からリモートで働くスタイルは、最初から意図したわけではありません。世界中に散らばっている各分野の専門家を採用していったら、結果的にそうなったということです。
リモートで働くにあたっては、最初はどういうコミュニケーションの方法がベストなのかも分かりませんでした。そこで、社員が10人くらいになったタイミングで一度、採用をストップしたんです。
一度立ち止まり、どうすれば良い形で仕事ができるかを徹底して議論し、回答を出しました。感情をあらわにしてぶつかり合ったことも何度もありました。
その時立ち止まって考えられたことは、本当に誇りに思っています。結果論に聞こえるかもしれませんが、それがあったからこそ、強い会社になれたんです。
変化に気付くことができたのは、学び続ける姿勢があったから
―― 世の中には失敗に終わる多くのオープンソースのプロジェクトがあります。Elasticは他のモノとどこが違ったのでしょうか?
当然、数あるアイデアの全てが良いモノというわけではありません。コントリビューターから寄せられるどの声を採用するのか、そしてどの声を採用しないのか。こうした采配が非常に大切です。「目利き力」と言ってもいいでしょう。
そのためには、自分を他人の立場に置いて考えてみることが必要です。弊社では、社員1人1人にもそれを求めています。
―― ダメなアイデアはどう見極めればいいのでしょうか?
その質問に答えるのは難しいですが、記事やコードをたくさん読んだり、人と話したりして、いろいろなことを学ぶ姿勢が重要なのではないでしょうか。そのためには、テクノロジーに対して好奇心を持ち続ける必要もあります。
Elasticを始めた当時、世の中にはJavaプログラマーとRubyプログラマーという2つの派閥がありました。どんどん複雑化することを是とするJavaの考え方が当時の多数派でした。シンプルなものを良しとするRubyの考え方は、まだ少数派だったんです。
しかし、私は今何が起きているのかを慎重に見極め、RubyとRuby on Railsがなぜ広まったのかを徹底的に調べることにしました。結果、RubyやRailsの考え方に倣うことに決めたのです。今にしてみればそれは正解で、Javaも今では方向を修正しています。
変化に正しく気付くことができたのは、多くの人の話を聞き、学ぶ姿勢があったからです。その際には単に過去に起こったことを知るだけでなく、将来にフォーカスして考えることも重要でしょう。
―― そうやって世界中のコントリビューターの意見に耳を傾けるのは疲れませんか?Shayさんはユーザーからの問い合わせにも自ら回答し、かなりのハードワークをしていると聞きます。
疲れていないですよ、まだ(笑)。
家庭において、まだ小さい子供が「お父さん、お父さん」としつこく質問をしてくるのと一緒だと思うんです。
質問してくるということは、新しい知識を得たいと考えているからでしょう。もし重要なアイデアに対して私が答えなかったら、大事なイノベーションが生まれるのを邪魔していることになる。全てに回答するのは自分の責任です。
もちろん、時には疲れることもあります。でも、メールを書いたりミーティングしたりという仕事が多くなってきている中で、コーディングはいまや、私にとっての瞑想のようなものになっているんですよ(笑)。
―― 多くの人の意見を聞くことがイノベーションにつながるという考えはよく分かります。ですが一方で、ソフトウエアエンジニアは1人でもイノベーションを起こし得る仕事ですし、独創的なアイデアは合議制では生まれないとも言われます。みんなでイノベーションを起こす上で重視していることは?
オープンソースコミュニティでは、何かを変えようと思って誰かが提案したら、そのコードを他の誰かがレビューし、ディスカッションを行います。Elasticはオープンソースがベースの会社なので、その流儀にしたがうということです。
そこでは、1人1人の背景やアプローチの良し悪しは問われません。問われるのはイノベーティブであるかどうかだけです。
例えば1カ月半前にElastic社でハッカソンを行った際、2人のエンジニアが素晴らしいモノを作ったんです。それは私の描く開発ロードマップの中にはなかった発想でした。でも、このアイデアをすぐにも取り上げなかったことは、私の失敗でした。彼らはこのアイデアについて、とても情熱的だったからです。
仕事を楽しくするのは情熱です。そして、情熱を活かすことがイノベーションにつながるのです。
―― なるほど。では最後に、Shayさん個人のプログラマーとしての最終目標は何ですか?
最後にこうなろうというものはないし、考えたくもないですね。
自分は勉強し続けたいという気持ちが強いんです。世の中はどんどん変わっていきますから、プログラマーは学び続けなくてはならない。究極的なゴールを考え始めたら、その時点で、自分はダメになったということだと思います。
想像してみてください。20年前に大学を卒業した時点で学ぶのを辞めた人が、自分のファミリードクターだったら嫌ですよね? 常に学び続けるのが重要だというのは、そういうことです。
だから、私から一つ皆さんに提案するなら、自分がチーム内で一番頭がいいと感じられるのなら、今すぐそのチームを辞めた方がいいということです。私はまだそこまでいっていないから辞めていないということです。毎日気付きがあるし、学びがあるんですよ。
取材・撮影/伊藤健吾 文/鈴木陸夫(ともに編集部)
RELATED関連記事
RANKING人気記事ランキング
NEW!
ITエンジニア転職2025予測!事業貢献しないならSESに行くべき?二者択一が迫られる一年に
NEW!
ドワンゴ川上量生は“人と競う”を避けてきた?「20代エンジニアは、自分が無双できる会社を選んだもん勝ち」
NEW!
ひろゆきが今20代なら「部下を悪者にする上司がいる会社は選ばない」
縦割り排除、役職者を半分に…激動の2年で「全く違う会社に生まれ変わった」日本初のエンジニア採用の裏にあった悲願
日本のエンジニアは甘すぎ? 「初学者への育成論」が米国からみると超不毛な理由
JOB BOARD編集部オススメ求人特集
タグ