2024年12月18日
株式会社Geolonia 代表取締役CEO
宮内隆行
大手重電メーカー系商社、スキューバダイビングのインストラクターを経てフリーランスのWebエンジニアとして起業。WordPressではVCCWのリード開発者で、日本人で唯一のWP-CLI、WP-APIチームメンバーとして10年以上活動。その後位置情報に興味を持ちGeoloniaを設立。書籍「WordPressプラグイン開発のバイブル」共著者。
ソースコードが公開されており誰でも利用可能な OSS は、その概念の誕生以来、ソフトウェアを軸としたビジネスのエコシステムで重要な役割を果たしています。その歴史の中で「OSS の持つ力をどう活用し、ビジネスと結びつけるか」「ビジネスの成果をどうやって OSS のコミュニティに還元するか」を、多くの人々が模索してきました。
そんな中、2019年の創業以来、開発したAPIやツールを次々と OSS として公開しているスタートアップ企業があります。「位置情報テクノロジーとオープンソースを通じて社会の課題を解決する」ことを提唱する株式会社Geoloniaです。同社は「地図」「地理空間情報」「ロケーションデータ」にまつわる自社サービスを開発して顧客企業への導入・運用支援を行っており、さらにはそのシステムを OSS化しています。
Geolonia創業者であり代表取締役社長の宮内氏は「WordPress のコアコミッターだった時代に、ビジネスの手段としての OSS の可能性に気づいた」と話します。OSS を活用したビジネス展開の肝は何なのか。また、現代のビジネスにおいて、我々は OSS とどう向き合っていくべきなのか、取材しました。
宮内:オープンソースがビジネスにおいて有効な手段となると気づいたのは、WordPress の CLI(Command line interface)チームのコアコミッターをしながら、Web制作の受託開発事業をしていたときです。
当時 WordPress は、AWS が顧客を増やすためのキラーコンテンツのような位置づけでした。しかし、AWS 上で WordPress を使い始めるときにかかる手間が、導入の障壁になっていました。そこで、コミッターである私が、AWS における WordPress 関連のノウハウを一般化したらよいのではないか?と考えたのです。WordPress のコミュニティにとっては「AWS と組み合わせれば簡単だ」と人々が認知してくれれば、ユーザー数が増える。AWS にとってはサポートコストが下がり、WordPress を使いたい顧客に選ばれやすくなる。
さらに私はコミッターなので、WordPress本体の脆弱性に関する情報などが、外部に公表されるよりも早く入ってきます。これはWeb制作の受注をする際に、かなり大きなアドバンテージになります。
ホスティング会社である AWS と、私が所属するWeb制作会社、そして WordPressコミュニティの三者がメリットを得られる状態を、自然につくることができた。この経験から「ビジネスをする上で、オープンソースであることが大きなインパクトを生む場合がある」と気づいたのです。
宮内:地図や住所などの領域は、オープンソースのライブラリやソフトウェア、データが数多くあります。「これらを組み合わせたら、GoogleMap のようなデジタル地図をつくれるかも」と考えてやってみたら、苦労はしたものの、実際にできたんです。
ならば WordPress のときのように、オープンであることをうまくビジネスに利用できるのではないか?と考えました。まっさらのデジタル地図や、地図の元データをつくるための住所の正規化などはオープンソース化する。その上で、地図と顧客が持っているデータをつなぎ合わせて特定用途のデジタル地図をつくったり、カスタマイズをして対価をいただいたりするのはどうか?と考え、事業化に踏み切りました。
宮内:たしかにオープンソース化することで、逃している顧客がいるかもしれません。でも、「それって本当にウチの会社の顧客だったの?」って思いませんか。そもそも、社内で開発リソースを工面でき、当社の OSS を使って地図をつくってメンテナンスできる企業は、顧客にはなりえないはず。彼らには「無料のツールを使って自分たちで運用したい」というニーズがあるわけですから、我々が狙うべきターゲットではないだろうと思います。
Geolonia では、つくったプロダクトは基本的にはオープンにする、という方針をとっています。その方がメリットが大きいから。
オープンソースのプロダクトは「名刺」になるんです。採用にもプラスになりますし、政府や地方自治体に当社のソフトウェアを評価してもらう時に、すぐに参照してもらえる。当社に興味を持ってもらいやすくなります。価値があるところをクローズにできているなら、オープンにしても実害はない。それに、オープンにする前提でつくっていたならその後クローズにしたいときも、コストは全くかかりません。
もちろん、最初からクローズにすると決めているものもあります。アカウント管理や課金に関係する機能や、開発者が「公開したくない」といったものなどです。オープンにしていいものをあえてクローズにするかどうかは、開発者自身に判断をゆだねています。
宮内:2020年に公開した住所正規化エンジンは、オープンソースの強みを生かし、年間でかなりの売上になっています。
オープンソースにすることで得られるメリットは大きく2つ。
1つ目は、正規化の精度を素早く、余計な手間なく高められること。正規化に失敗した住所のパターンがあれば、ユーザーからフィードバックをもらえるから、エッジケースが自然と集まってくるのです。フィードバックが届くごとに新たなテストケースを追加し、自動テストを回します。こうしてカバーできたケースは反復的に検証し続けるため、精度が下がることはありません。
もう1つは、競合よりも品質の透明性が高く、選んでもらいやすくなること。「うちのプロダクトではこの精度でできます」という言葉を、GitHub上の Issue やPull Request、ソースコードによって裏付けられるのです。これは、先述のように確実に精度が上がっていく過程や、現在のプロダクトの状態がオープンになっているからこそできることです。
最近は特に、自治体や政府との仕事の中で、「オープンであること」や「自動テストによる品質保証」が評価されています。
宮内:特にそういったことはないですね。現在は、政府や自治体から受注したプロダクトの開発にオープンソースを使うのも、そうしてつくったプロダクトをオープンソース化することも快諾してくれます。政府や自治体の IT リテラシーが急激に上昇していて、民間よりもずっと理解が深いくらいです。
この変化のきっかけは、コロナ禍でした。例えば当時、東京都が COVID19 のダッシュボードをオープンソース化していました。それを他の自治体がコピーして使い始めた。こうした出来事をきっかけに、行政の IT リテラシーがぐんと上昇したように思います。
宮内:従来のような、完成したソフトウェア自体に費用が発生するというモデルではなく、導入支援やカスタマイズといった付加価値に報酬を払うモデルが浸透してきています。
例えば、当社と取引している A という自治体と、SIer と取引している B という自治体があるとしましょう。当社が A から受注して開発し OSS化したプロダクトを、B が導入する場合、受注した SIer はその導入作業に対して、B から報酬を得ます。これは、冒頭で話した WordPress のような CMS の特性と似ています。ソフトウェア自体は無料で提供され、導入・運用の業務やシステム上で展開されるコンテンツにこそ、価値があるという考え方です。
従来の SIer のような「つくって納品する」モデルは、労働集約型で価格競争に陥りやすい。でも、ソフトウェアがオープンソースになっていれば、ソフトウェア自体をつくる労力がゼロになる。であれば開発者は、ソフトウェアをより効果的に使うための手助けなど、価値の高い仕事に集中できて、より高い対価を得られやすくなるはずだと思っています。この流れがもっと加速していくといいなと思います。
宮内:OSS は基本的に、誰がどう使おうと自由です。
もしかしたら、その OSS に貢献したり利用したりするなかで、「こういう振る舞いはよくない」と、誰かを非難したくなることもあるかもしれません。
でも、そのソフトウェアを最初に開発し、一番コストを払ったOSS の創始者は、オープンにすることのデメリットを理解して公開しています。どんなふうに使われるかわからないこと、フリーライダーが多数出ることも飲み込んで、覚悟して、「みんな使ってくれ」と差し出したんです。
オープンソースに貢献するときには、特定の誰かを「You」と指さしてしまうのではなく、「We」という主語を使ってコミュニティを一緒に成長させていきましょう。
宮内:開発についてのコミュニケーションをする際も、主語を「You」ではなく「We」にすることです。
私がコミッターだったとき、Issue に「You should fix this problem」というふうに書かれるとつらかった。「俺が悪いのか」と傷つきました。
そこで、ぜひ読者のみなさんは「We」を主語にして会話することを心がけてください。「あなたはこれをしてください」ではなく、「私たちはこれを一緒にやろう」というニュアンスです。主語を「We」にするだけで、当事者意識が生まれ、言い回しも考え方も変わります。相手にどう動いてほしいか伝えるだけでなく、相手と一緒にやるにはどうしたらいいかを心掛けるようになるはずです。
このコミュニケーションは、日本人はすごく苦手なんですよね。日本語はよく主語を省略して、「誰がやるか」が曖昧なままコミュニケーションをとるので、「私たちが一緒にやる」という意識になりづらい。私も最初の頃は特に、ここでつまずいていました。
宮内:OSS を使うことについて、人々がもっとおおらかに考えるべきだろうと思います。
OSS を用いてお金を儲ける人や企業を攻撃しているだけでは、OSS の関係者がみんな一文無しになってしまいます。多くの OSS のライセンスには「どんな用途でも、誰でも使ってよい」と書いてあります。お金儲けに使うことを禁じてはいません。私はむしろ、積極的にお金儲けをした方がいいだろうと思います。そうすればもっと大きなものを、コミュニティに返せるわけですから。
あとは、自社がビジネスとして提供するサービスのどこに価値があるのかを、明確に捉えることも重要だと思います。
「協調領域」「競争領域」という言葉があります。例えるなら、道路と車のようなものです。道路は税金を使ってつくり、皆が平等に使うものなので、協調領域です。車は、各社がそれぞれの技術やデザインで顧客に選ばれるものなので、競争領域。道路があるから車は走れるし、車の市場が成長していきます。
OSS はまさに、協調領域に該当するものだと思います。そう考えると、OSS と各社のソフトウェアの構造は、ソフトウェアが生まれるずっと前からあった、といえますね。Code for Japan の代表の関さんが「オープンソースは、デジタル公共財である」と言っていましたが、まさにその通りです。
自分たちのサービスにおいて、競争領域にあるものは何か。これを明確にすることで、OSS の特徴をうまく利用して、ビジネスができるようになるのだと思っています。
取材:光松瞳、中薗昴
執筆:光松瞳
編集:中薗昴
関連記事
人気記事