ウクライナのソフトウェア開発者Dmitry Zaporozhets氏が2011年10月に、たった1人で開始したオープンソースプロジェクト「GitLab」。それが、ちょうど10年を経て時価総額1兆円もうかがうほどの大成功したDevOpsのSaaSプラットフォームへと進化することになると想像した人は、ほとんどいなかったと思います。GitLabのライセンス・SaaSビジネスを展開するGitLab Inc.は9月17日付けで米国証券取引委員会(SEC)に対してFORM S-1を提出し、IPOへ向けて最終段階に入りました。
開発初期から生まれたモメンタムと、それを生かした分散開発の組織化、VC投資を組み合わせた株式会社としての成長といったことから学べることは少なくないと思います。この記事では、GitLabの成功から学べる4つの教訓について書いてみたいと思います。
DevOpsという言葉が広まる前にスタート
まず、GitLabがどんなサービスを提供しているかを振り返ってみましょう。
GitLabはソフトウェア開発において分散ソースコード管理と、常時ソフトウェアが正しく動作することを検証する「継続的インテグレーション」を統合したDevOpsのためのSaaSプラットフォームです。こう書くと2つか3つのトレンドの波に乗った成功に思えるかもしれません。しかし、2011年にはDevOpsという言葉は一般的ではなく、SaaSというビジネスも今とは比較にならないくらい小さな市場でした。
GitLabは、もともとは3年ほど先行していたGitHubの「丸パクリ」のプロジェクトとしてスタートしています。登場当初はGitHubの有料プランを使わなくても自分でGitLabのソースコードをダウンロードして社内サーバーにデプロイすれば、基本機能が無償で使える「GitHubの代替ツール」だと見られていたように思います。GitLabが当初使っていたロゴはお世辞にもカッコいいと言えるものではなく、そのこともあって「劣化版のコピー品」というのが当初の私の見方でした(同意してくださる方も多いと思います)。
ところが10年が経過してみたら、GitLabの大口顧客リストにはシーメンスやUBS、T-Mobileなど各産業のリーディングカンパニーが含まれていますし、SaaS企業としてのメトリクスを箇条書きに抜き出してみても、以下のようにピカピカです。
- 直近の2022年第2四半期の売上をARRに換算(つまり4倍)したRun Rate Revenueは$233m(258億円)
- 四半期ごとの売上はYoYで69%の伸び
- ARRが5,000ドル以上の顧客数は3,632(社)
- ARRが10万ドル以上の顧客数は383(社)
- ドルベースのNRR(Net Retention Rate)は約150%で推移
力強い成長とトラクションです。特に既存ユーザーのチャーン(解約)を計算に入れた上での同一コホートからの売上の増加を示すNRRが150%というのは、SaaSビジネスとして素晴らしい数字です。小さく導入した顧客が、利用するとともに上位サービスや付加サービスへと移行していることを示していて、CEOのSijbrandij氏も、企業内の開発者からスタートして経営者へとターゲット層を広げる販売戦略を取っていると説明しています。
DXの流れで非ソフトウェア系の大手企業もソフトウェア開発に力を入れるようになっています。そうした企業ではインハウスでのソフトウェア開発が増え、そこで分散開発や品質管理とソフトウェア更新といったオープンソースの世界で培われたベストプラクティスが使われ始めています。そのニーズが、今まさに顕在化してきているということでしょう。
教訓1:ユニコーンはどこからでも出てくる
大半のオープンソースプロジェクトは1人の開発者が始めるものなので、そのこと自体は驚くことではありません。しかし、GitLabはシリコンバレーやスタートアップ都市から生まれたわけではなく、ウクライナで水道も引かれていない家に暮らしていた共同創業者Zaporozhets氏が「毎日の井戸への水汲みよりもソフトウェア開発者たちがコラボレーションする良いツールがないことのほうが大きな問題だと感じていた」(もう1人の共同創業者でGitLab CEOのSid Sijbrandij氏のS-1内での回想)ことから開始したプロジェクトだと言います。
GitLabはリリース後1年で300件ほどのコードの貢献が寄せられました。ウクライナの開発者のプロジェクトでしたが、テック系掲示板でその存在を知ったオランダ人の共同創業者でCEOのSijbrandij氏はコードが美しいことに感銘を受けていたと言います。さらにその1年後の2013年に「フルタイムでGitLabに取り組みたい」とZaporozhets氏がツイートしたのを見かけたSijbrandij氏がコンタクト。2014年には法人設立をして、2015年にはY Combinatorに参加してスタートアップとしての成長に勢いが付きました。
まとめると、こうです。ウクライナの開発者がオープンソースで始めたプロジェクトに、すぐに世界中から協力者が現れ、ツイートをきっかけにオランダ人と共同創業。シリコンバレーの名門アクセラレーターに参加して大きなイグジットとなる成長を遂げたということです。GitLabは最後の資金調達ラウンドでのバリュエーションは$6b(6,640億円)で、IPO後には1兆円の大台、いわゆるデカコーンに届きそうなところまで成長しています。
今やユニコーン企業は途上国の、水道もない1室からでも出てくる時代になったのです。
教訓2:完全な分散型組織でもスタートアップは成功できる
GitLabは分散型開発、あるいは組織運営のお手本としても非常に参考になります。GitLabには2021年9月末時点で66か国(地域)、1,464人の社員がいて、これまでオープンソースのGitLabに関わった開発者は3,000人を超えますが、ここも含めて完全な分散型組織です。これは既存の組織運営にリモートワークを取り入れていくこととは違い、最初から地理的にバラバラなメンバーが協働して成果を上げていく仕組みと文化を作ってきたかという話です。
この分散組織の運営のコアにあるのは、実はGitLabという広い意味での文書管理ツールそのものかもしれません。会社の組織や文化に関して言語化した1万3,804ページに渡るドキュメント「GitLab Handbook」が公開されていて、これを常にGitLab(もしくはそのベースにあるGit)で少しずつ更新し続けているのです。この文書群には組織構造、役職と期待する役割に関する文書、役職者の氏名や所属・連絡先、仕事や会議の進め方、リモートワークの要点をまとめたハンドブック、GitLab社員の意思決定の指針となるカルチャーを詳述した文書、多様性性や帰属意識や方針を説明した文書などが含まれます。企業として機密が必要なものを除くと、基本的に全てネット上に公開しているというほど言語化と透明性が徹底しています。抽象的な議論だけでなく、「1人のマネージャーがピープルマネジメントで見るべき人数は7人まで」とか、「懸念点があったら直接1on1で当事者に話そう」「会議は次の予定の5分前に終わろう」といった具体的で細かな指針なども書かれています。良く見てみると、日本であれば上司や先輩から教わったり、ビジネス書に書かれていそうな「外部の人との打ち合わせが終わっても、最低2ブロック離れてから議論の結果について話そう。自分のことが議論されてるのをトイレで聞いてしまって嬉しい人などいないのだから」といったコミュニケーションスタイルに関するマナーのようなことも書かれています。
一般的な企業ではミッション・ビジョン・バリューといった形で指針を示して現場の仕事のやり方や意思決定に方向性や安定性を持たせますが、あくまでも結晶化した短いセンテンスであることが普通で、1万ページも書くようなことはありません。急成長する分散型組織でメンバーの出入りも少なからずあることを想定すると、このくらい徹底する必要があるのでしょう。新しく入ったメンバーでも読むべき文書や見るべきCEOの動画がたくさんあります。維持コストはかかりますが分散型組織をうまく運営する1つのやり方なのだろうと思います。多様な地域から多様な文化的背景を持ったメンバーが集っていることもあり、コミュニケーションがハイコンテクストでは成り立たないのだと思いますし、「お作法」についても統一することの意味が大きいのだと思います。
GitLabは組織運営に透明性をもたせ、CEOはもとより各メンバーについてもアカウンタビリティーを持たせることを徹底しています。
まず、組織全体では主要KPIが外部にも公開されています。例えば構成員の地域・属性とその比率、顧客サポートの満足度や平均待ち時間、SLAの状態なども公開されています。
GitLabは上位分類で4つチームに分かれていて、各VPは全社向けに進捗報告をしていますが、その様子はYouTubeの「GitLab Unfiltered」というチャンネルに公開されています。社員たちの議論やプレゼンの動画も含めて、あり得ない量の会議動画が公開されています。例えばCEOとVPが中心となったUX改善に関する議論では「(公開予定の議論なので)顧客名を口にしないように」と前置きしつつ、かなり具体的なUIの改変について1つ1つ話をしていたりします。マーケティングチームの隔週全体会議では各KPIの進捗と課題について共有する議論まで全部公開されています(将来、外資系企業で働くことを考えている人には勉強になるかもしれません)。
ほとんどの動画は数十再生と、関係者しか見ていないか、事実上「誰も見ていない」状態です。しかし、すべての議論が「見られている」と参加者が意識すること、いざとなれば、誰でも、どの部分でも見ることができる意味は極めて大きいと思います。誰が賢明な意思決定をしているか、建設的な議論をしているのか、誰が良い仕事をしているのか、誰の仕事が不必要に遅れているのかなど、やり取りを見れば一目瞭然です。私は全部で20分ほど見ただけですが、GitLabのビジネスや社員たちの様子が非常に良く分かりました。また、いかにCEOが説得力のある議論を展開しているかも良く分かりました。例えば言い訳のできないUXチームの進捗の遅れに対して、CEOがストレートなフィードバックする場面がありました。決して難詰口調にならず、淡々と「当事者意識を持ってください。あなたたちがやらないなら、私が片付けます。これは今も顧客が頭を抱えている問題です。時間がかかりすぎています」と指摘したりしています。
アカウンタビリティーで言えば、GitLabはDRIを採用していることでも知られています。DRIはDirectly Responsible Individualの略で、課題やタスクに対して誰が責任を持っているかを常に明確にするフレームワークです(以前、「メンバーが増えると出力が落ちる『リンゲルマン効果』と対策としてのDRI」という記事を書きました)。ほかにも、社員から選ばれた2人が2週間にわたってCEOの出る全ての会議に出席する「CEO Shadow」というユニークな仕組みもあり、CEOも透明性が高い状態に置かれています。
組織運営の方法論と文化の言語化・文書化。それに加えて日々の会話の見える化。この2軸を徹底することで、GitLabは分散型組織として業績を伸ばし、事業価値が6,000億円を超えるところまで成長したということだと思います。
教訓3:丸コピーから始まってもイノベーションはできる
すでに書きましたが、競合のGitHubはGitLabよりも3年ほど早い2008年に立ち上がっています。GitHubは開発者やプロダクトマネージャーたちに熱烈に迎え入れられ、「ソーシャルコーディング」という言葉で呼ばれる一種のムーブメントを巻き起こしました。私自身も2011年にはプロダクトオーナーとしてGitHubを使った新規事業開発をしていて、いかにGitHubが委託開発の世界すら変えるかについて講演したこともあります。
GitHubの登場によってソフトウェア開発の作業対象であるソースコードをクラウドで共有して、一連の開発プロセスにおいて開発者1人1人の顔(アイコンが多いですが)や貢献が分かりやすく見えるようになったのです。GitHubにはタイムラインがあり「開発者をフォロー」「プロジェクトをウォッチ」することなどができ、それは画期的なことでした。従来はプロジェクトの周囲にメールアドレスで紐付いた開発者がいただけですが、開発者ベースでソフトウェアの開発が見える化されたのです。GitHubは創業して4年間は資金調達をすることもなくサービス初日から黒字経営というブートストラップに成功した企業で、最終的にはマイクロソフトが2018年に$7.5bn(約8,300億円)で巨額買収しています。
GitLabは、タイミング的にも名前の響き的にも「GitHubクローン」という登場の仕方で、悪く言えば丸コピーでした。ただ、そう見えたのはおそらくGitHubのイノベーション速度が速くてキラキラしていたからだと、振り返ってみると、そう思うようになりました。
実際にはGitHubが起こしたイノベーションのベースにはgitというコマンドライン(エンジニアが使う文字だけの黒い画面)で使うツールがあるのですが、「gitをSaaS化する」ことによって市場ニーズに応えるという視点で見ると、その実装がGitHub1つだけというのは自然なことでも健全なことでもなかったのだと思います。
第1に、市場ニーズは多様だったという点があります。GitHubがオープンソース開発コミュニティーにとってのハブとなったのに対して、GitLabは当初から企業向けの利用ニーズにうまく応えたように見えます。企業が扱うソースコードのニーズは、オープンソースプロジェクトと異なります。たとえ非公開設定にしていても「クラウド上に知的財産を預ける」ということに対する心理的・法的なハードルは高かったため、この2つは違うアプローチが必要でした。GitHubには「GitHub Enterprise」というオンプレミス向けライセンス販売パッケージがありましたし、今ではGitLabもライセンス販売よりもSaaSの伸びが速いので、最終的に向かう先はいずれもSaaSモデルでしたが、当初は明らかにGTM戦略が違いました。
もう1つ象徴的なのが、GitLabが早い段階で継続的インテグレーション/デリバリー(CI/CD)をプラットフォームに統合したことです。CIの実装はTravis CI、CircleCIなど複数あり、どれがベストなのかは利用者によって考えが違いましたし、後から登場したものが一気に人気になるなど、ある意味では健全なオープンソースのイノベーションが続いていました。GitHubでCIを使う場合には自分で好きなものを組み合わせて使うことができる、いわゆる「ベスト・オブ・ブリード」の世界観でした。
しかし、企業ユーザーから見れば話は全然違います。どれが良いCIツールかを比較検討するのはコストですし、選んだ後にCI/CDツールを連携させるために設定をするのもコストにすぎません。どれを選ぼうとビジネス的なインパクトは、そこまで変わりません。また一般論として、企業内のエンジニアは仕事としてコードを書いているケースが多く、「どのCIが今いちばんイケてるか」を楽しそうに延々と話すタイプが多いオープンソースの開発者と異なるように思います。結局、GitHubも2019年にはCIをプラットフォームに統合していますが、これは「GitLabの後追い」となった形です。そして、こうした動きがあった頃に出てきたバズワードが「DevOps」でした。振り返ってみるとGitLabはGitHubよりも一足先にエンタープライズの世界のDevOpsのニーズに対応したように思えます。
他にも、GitLabで実装された機能がGitHubにもコピーされるなど、もはやGitLabがコピーに過ぎないという状況ではなくなっています。単一企業に市場が独占されるとイノベーションが止まるという常識的な話から考えて「gitのSaaSプラットフォーム」が2つあったことは利用者全てにとって良いことだ、と言えそうです。
ここからスタートアップ関係者が改めて読み取るべき教訓は、力強く伸びている市場があれば、2つか3つのプレイヤーが出て当然であるし、それは業界全体として好ましいことであるということではないかと思います。また、大きな市場では「似て非なるニーズ」に応えるGTM戦略により、異なるユーザー層からの支持を得て成長できるということも言えると思います。
教訓4:「株式会社」という器はインパクト最大化に有効
GitHubが登場した頃、オープンソースプロジェクトのソースコードの置き場としてはSourceForgeという非常に強い先行者がいました。また同時期にはGitorious、BitKeeper、Bitbucket、Codeplexなどもありました。なぜGitHubがごぼう抜きにしたのでしょうか?
まず大きな違いはベースにあるソフトウェアがGitかどうかです。コードのバージョン管理ツール(VCS:version control system)としてはSubversionやPerforceが先行していましたし、Mercurialというライバルもいました。しかし、最後にはGitが圧勝しています。
GitはLinuxの生みの親であるLinus Torvalds氏が放った2本目の場外ホームランです。これはこれでとても興味深く、重要な話ですが、ここではGit成功の背景については書きません。
むしろ私が指摘したいのは、オープンソースプロジェクトとして見たときのGitLabと、その他のプロジェクトの対比です。ブラウザのFirefoxやブロックチェーンのEthereumは、実はGitLabと対照的ではないかと思うのです。
一時は大変な人気となったオープンソースブラウザのFirefoxですが、その開発には信じられないぐらい長い年月がかかりました。単なるブラウザ以上の革新的プラットフォームを生み出そうという野心的なプロジェクトでしたが、振り返ってみれば理想が高すぎたように思えます。ローンチ後、特にFirefox 2.0は一時はIEを打ち倒すほどに成功しましたが、さらにその後には、後ろから来たChromeに一瞬で抜き去られました。
FirefoxとChromeの最大の違いは技術的に言えば「プロセス分離」と呼ばれるもので、OSから見たときタブごとに別アプリが稼働しているかどうかでした。Firefoxは単一アプリが多数のタブを扱っていたため、何か不調になると全体が重たく不安定になりましたが、Chromeでは、これをタブ単位にアプリ化することで解決したのでした。さらにChromeではJavaScriptエンジンの高速化・最適化が劇的に進み、結果として体感速度が桁違いに上がりました。現在、SaaSが興隆している背景には2008〜2010年に起こったブラウザの非連続な進化があります。
では、この技術進化や実装スピードの差を生んだのが何だったかというと、私には会社という器があったかどうかだと思えるのです。SDGsや経営哲学のような縛りを引き受けつつも株主利益を追求することで成長への強い圧力がかかること、良い意思決定をできるガバナンスがあること、目標・進捗管理を行うこと、メンバーに正しいインセンティブが与えられていること、といった点で、会社組織はきわめて強いと思います。これはオープンソースとしてスタートし、後に上場したMongoDBも同様です。
もう1つ、Bitcoinに次ぐ注目のブロックチェーン、Ethereumについても考えてみましょう。
Ethereumは理屈上はトラストレスのコンピューターが出現したという人類史に残る可能性のある画期的なプロジェクトです。政府や特定企業、グループ、個人など、誰かを信用する必要なしに、コードが正しく動作していることを、誰もが検証できる人類初のコンピューターです。しかし、Ethereumというプロジェクトは「何兆円もの資金と熱狂が集まった、ガバナンス不在の革命」のように私には思われます。Ethereumは今のところスケーラビリティーが課題ですが、これは何年経っても解決していません。Ethereumコミュニティーではブロックチェーンの最も本質的な部分であるコンセンサスアルゴリズムをPoWからPoSにアップデートして電力消費やトランザクション速度を改善する取り組みが続いていますが、うまく進捗しているようには見えません。創始者であるVitalik Buterin氏は、最近またLayer 2 Rollupsという技術方針を打ち出していますが、混乱しているように見えます。
大きなイノベーション初期の混沌であると見れば、ただ単に私が本質を見落としているだけかもしれませんが、結果を見てみれば、Ethereumはどこに向かっているのか良く分からない状態に思えます。ですから、法人形式を取ってa16zから資金調達をしているブロックチェーンスタートアップのSolanaのほうに私は可能性を感じています。
GitLabは過去6年で累計$426M(約472億円)の資金調達をしています。投資家の顔ぶれはY Combinatorばかりでなく、Khosla Ventures、August Capital、GV(Google Ventures)といった著名VC、レイターステージではBlackRockやGoldman SachsもGitLabに出資しています。冒頭で売上成長が力強いとグラフで紹介しましたが、それでも2021年度の収益は$192M(約213億円)の赤字です。グロース資金を得て成長へ投資している様子がわかります。
個別の事例については私が間違っているところもあるかもしれません。ただ、大枠として次の指摘には意味があるのではないでしょうか。
株式会社という社会技術は19世紀から20世紀にかけて世界的に普及し、かつて株式会社という形態を取らなかった事業が次々と株式会社になっているという事実があります。最近オープンソースプロジェクトがSaaSスタートアップとして上場することが増えているのも、同じトレンドの中にあるのではないでしょうか?
法学者・神田秀樹氏の著書『会社法入門』によれば、例えば日本の証券取引所は、かつては証券会社を会員とする特別な法人でしたが、今は証券取引所は株式会社形態となっていて、これはグローバルで起こった現象だと言います。生命保険も相互互助の特別な法人から株式会社に移行するトレンドが各国で起こっています。少し引用します。
「株式会社形態は経済的分野で普及しつつあるだけではない。営利事業以外の分野であり、伝統的には株式会社形態になじまないと考えられてきた社会的分野においても、株式会社形態の導入(強制ではなく、望めば株式会社形態をとってもよいという意味である)が始まった。医療・福祉・教育・農業といった分野がその例である。日本でも病院や学校の経営、農地保有への株式会社形態の導入などが始まっている」(神田秀樹著『会社法入門』、岩波書店、2015年)
「オープンソースと株式会社」というのは、オープンソースムーブメントが資本主義へのアンチテーゼとして始まったこと考えると、水と油のようにも思えます。しかし、医療・福祉・教育・農業などでも株式会社が成果を挙げています。オープンソースだけは違う、と私には思えません。開発活動を組織化し、持続可能な成長を果たしてインパクト最大化を狙うとき、株式会社という器は強力なツール。GitLab上場は、そのことを示しているのではないでしょうか。
Partner @ Coral Capital