News

GitHub COO PJ Hyett氏が語る”GitHubの作り方”

イベントイメージ03

Open Network Labは、 2013年1月30日(水)・2月1日(金) に東京・京都にて GitHub, Inc.、COOのPJ Hyett氏と、CIOのScott Chacon氏をお招きしディスカッションイベントを開催しました。

イベントの概要はこちら:
GitHub創設者が語る”立ち上げから利用者300万人までの軌跡”【1月30日(水)東京・2月1日(金)京都にて開催決定!】GitHubCOO PJ Hyett氏・CIO Scott Chacon氏来日講演

 

GitHubの作り方

GitHubのミッションは、1人で作業するよりも複数の人とコラボレーションして作業することで技術者のために素敵な環境をつくる事。2008年4月、共同創業者の3人で夢を持ってGitHubを作ってから5年が経ち、現在では300万人の登録ユーザーと500万のレポジトリを持つ。

DSC_0236

超満員の京都会場の様子

Before GitHub

PJ氏が初めてプログラミングを学んだのは14才の時で”First Programming Book”を読み、高校生の時にはDiito.comというサイトをインターンで作った。様々なProgramming言語を学ぶ中で、ASP,PHP,C++など、その後Rubyを学び恋に落ちた。

Rubyを使った実践的な経験がほしいと考えていた時、サンフランシスコでウェブサイトの立ち上げを助けてほしいとの内容のメールが入った。当時PJ氏はシカゴに在住していたが、Rubyでの実践経験を積む良いチャンスだと考え、サンフランシスコに居住地を移し無償にてサイトの立ち上げを手伝った。立ち上げたウェブサイトは、”Wayfaring”というサイトで、Google Mapsのような機能を搭載したサービスだった。これは、当時Google Mapsで情報を登録することができなかった時代にとっては最先端のサービスだった。その時のメンバーがPJ氏に最初の働き先を紹介してくれたという。

いちばん始めに就職した会社はCNET Networksだった。CNET Networksは”CHOW”という会社を買収したことろで、”CHOW”のサイトをRubyへ書き直す仕事を行いそしてその時に一緒に働いたのが、後のGitHub共同創業者となるChris氏だった。

PJ氏とChris氏は、自分たちがRubyを使って作ったプロダクト、プラグイン、面白い情報などを載せるBlogを立ち上げ、彼らはBlogを通してサンフランシスコのRubyコミュニティの中では名前が通る存在になった。

そして、大企業で働き続けることに疑問を抱いたPJ氏とChris氏は、Err FreeというRubyのコンサルタント会社を始めた。管理される立場として働くのではなく、自分たちが自分たちの”ボス”になりたいと思って始めた会社だった。起業したことで自由に働けると思いきや、コンサルタントビジネスでの”ボス”はクライアントになることにすぐに気づいた。「良いクライアントの元では良いサービスを作れる」というわけではなかった。事実「犬のためのソーシャルネットワーキングサービス」など、彼らにとって納得がいかないサービスを作らなくてはならない場合が多かったのだ。

そこで、自分たちが自分たちの”ボス”になれるようにはじめたことが、自身のプロダクトを作ることだった。いちばん始めに作ったのは家族向けのメーリングリストで、特定のメールアドレスに写真を送ると家族でその写真をシェアできるもの。作っているときは楽しかったがまったくお金にはならなかった。

Parallel Story

サンフランシスコではRubyミートアップがあり、Rubyについてオフィスで語った後にバーでRubyについて語りあっていた。このMeetupを通じてChris氏がもう一人の創業メンバーTom氏と出会い、バーの中でGitHubのアイディアが生まれた。

Tom氏はデザイナーでもあったことから様々なモックを作成した。その中でいちばん重要な発明は「フォーク」という機能だった。フォークとは、他ユーザーが作成したソースをコピーして、カスタマイズすることで、当初フォークはネガティブな印象が強かった。しかしGitHubでは、フォークという行為自体をポジティブなものに改善したいという想いがあり、GitHubの機能の一つに取り入れた。

DSC_0198

GitHubはPJ氏、Tom氏、Chris氏の3人のサイドプロジェクトとして始動し、全員が別の仕事を続けながら週末・夕方以降を使ってコーディングを行っていた。GitHubは自分たちが本当に欲しいと思って作ったサービスで、エンジニアにとっていちばんコラボレーションしやすい環境を作りたかった。

3人がLOGICAL AWESOMEという社名で会社を設立した当初、GitHubは「たくさんのプロダクトの中の1つ」になると考えていた。しかしその後、GitHubがビジネスになると考えたターニングポイントが訪れた。それは、ユーザーから「お金を払ってでも使用したい」という声が生まれた時だった。

そしてGitHub設立初期、Engine YardというRubyのHosting Serviceの会社と重要なパートナーシップを結んだ。この頃、GitHubの運営で人件費の次に高いのがHostingにかかる費用だったのだが、Engine YardとのパートナーシップはGitHubサイトにロゴを掲載することで、Hosting費用を無償で提供してくれるという契約だった。このパートナーシップも、Rubyミートアップでの出会いから生まれたものだった。

Beta Invites

限定公開では、Beta招待を実施した。これは、ゆっくりスケールするためには良い仕組みだった。GitHubの最初の限定公開では、登録フォームを用意せず招待でのメールアドレスのみでしか登録ができないようにした。招待がなければ登録できず、招待された人は10人のみ招待できるという仕組みにした。偶然にも、これがバイラル性を生み出してゆっくりとした成長できた。

Office 0.1

GitHubの最初の2年間はオフィスがなく、カフェ、レストラン、自宅でコーディングをしていた。

GitHubは世界中どこでも誰でも1つのプロジェクトにコラボレーションできる仕組みになっているため、自分たちでもオフィス環境としてGitHubを使用しサービスを改善していた。自分たちのサービスを改善すればするほど仕事の作業効率が上がり、ユーザーにとってもユーザビリティが上がっていった。仕事をすればするほど、双方にとっての良い環境作りに繋がっていった。もう一つ重要なツールは、バーチャルなオフィスとしての”Campfire”というツールを使用していた。Face to Faceのミーティングは一つもなく、GitHubではOnlineで決まりOnlineで実行される文化になっている。会社に行くことも必須ではないのでサンフランシスコに住んでいるメンバーでも、半分は会社に来ずに自分たちの自宅などから作業をしている。

Public Launch

2008年4月10日、GitHubをパブリックローンチし、ローンチ1日目から課金に成功。売上げが出た。重要なポイントは、ローンチしたその日にRuby On RailsのオープンソースのプロジェクトがGitHubにホスティングされたことで、これもRubyミートアップを通じてRubyコミュニティの一員だったからこそ成し遂げられたことだった。

Team Building

DSC_0237

3人の間でもっとも注力していたのはチームビルディングだったのだが、その中で活用していたのはPodcastだった。3人で定期的にPodCastの配信をした。ちなみに、最初はRubyやGitの話をすることを考えていたのだが、最終的には全然違う話ばかりして楽しいものだった。また、GitHubでもGitのMeetupを開催し、Rubyミートアップと同じように参加者それぞれがトピックについて話し合い、お酒を飲む”GitDown”というDrink-upイベントを行っていた。このDrink-upを通して最初に採用したのがScott氏だった。彼は本当に頭がよく、Gitについての熱意、知識、ノウハウを持っていて、毎週Gitを違う言語で書き換えたりしてきた。

Staggered Salaries

GitHubをローンチした時にコンサルティングの仕事を辞めたが、最初の半年は、自分たちに給料を払っていなかった。その後、10月にScott氏を雇った際に給料を支払始めた。その当時は自分たちが前職で稼いでいた金額を給与として支払うことは売り上げ上難しかったため、スタートは少ない給与額から始め、毎月毎月の売上げの目標設定を行い、その達成度により自分たちの給料が上がっていく仕組みにした。それから1年後には、コンサル時代に支払っていた額と同額の給与を自分たちに支払うことができるようになった。その売上げを達成した日は、GitHubをローンチした日と同じくらい嬉しかった1日だった。

Summits

社員の殆どがオフィスで働いておらず、6割がサンフランシスコ以外で採用した社員。そのため3ヶ月に1回程度のペースで全員が集まり、好きなことを話すSummitというイベントを行っている。内容はロッククライミングだったり何でも自分の好きなことを話している。Summitでは旅行をして社員が交流して知り合える場所を作った。

Office 1.0 → 2.0

2009年になって社員が10名ほどになり、カフェでは事足りなくなったためオフィスを借りた。GitHubの文化では自宅、カフェ、旅先でもOnlineで作業ができて、決まった時間に出社する必要がないため、オフィスはみんなが集まり交流する場としてデザインした。始めのオフィスは、大きなテーブルで作業ができるカフェのような感じだった。2010年にはチームが大きくなったため、さらに大きなオフィスへ移動した。自分たちがオフィスをデザインする時には、楽しいものにするというモットーで、楽しく交流することに重きをおき、エキストラスペースではラウンジをつくったりクリエイティブな空間にした。

 

Q&A Section

Q.
GitHubは今まで社員を解雇したことがないと聞いているが採用までに何回面接したり判断の機会をもつのか?

誰も辞めていないことは嬉しい限りだけれど、それをKPIにしている訳ではない。採用においては、自分たちが信頼できている人の紹介を大切にしている。良い人は周りにいる良い人を呼び込む力があるので、できるだけ良い人間を会社へ採用している。採用のプロセスは特に決まったものはなく、採用する人間をできるだけ知ることにフォーカスしている。

GitHubでは面接に関わった社員全員が投票するシステムがあり、採用を決めるときには-1、+1、+100という項目で行い、+100は自分がメンターとして責任をとるという意味を表している。このシステムにより質の良い人、みんなが好む人が入社する仕組みになっている。尚、社員の6割であるサンフランシスコ以外の地域からの採用を行う際には飛行機代、ホテル代も全てカバーして1週間サンフランシスコでGitHubと一緒に過ごしてもらうというプロセスもある。

Q.
ユーザー数を増やすためにいちばん重要なことは何か?

面白いOpen Sourceのプロジェクトが乗っていること。GitHubはYoutubeのProgrammer版と考えていて、ユーザーはYoutubeに行きたいからいくのではなく、面白い動画があるからYoutubeにいく。それと同じようにGitHubというサイトにいくのではなく、”GitHubにいけば誰かが書いた素晴らしいコードがある”ように、たくさんホスティングをして拡散してもらうことがGitHubのマーケティングである。

Q.
プログラマーにとってより良い職場環境とはどのようなものか?

組織自体もオープンソースと同じようになっていて、好きなときに好きな時間でプロジェクトへ関わることができ、どこからでも作業ができ、新しい機能、改善点があればみんなで次の改善を決めることができる。GitHubではオープンソースのやり方でマネジメントを行っていて、実はGitHubにはマネージャーのような上から指示を送る人間はいない。プログラマーが自分たちで課題を定義し、どこを解決したいか、どこの改善を行いたいかなどを決めていく。重要なことは、自分たちが働きたい場所を自分たちで作ること。

Q.
売り上げに応じて給料をどのように決めたか?

10%ほどずつ有料ユーザーが増えていく時期があって、半年で自分たちが納得する給料を払えるような目標設定を行い、実際に半年で達成した。達成した後の2年間は全員の給料は同じという時期があり、新しく入社した人にも同じ給料を与えていた。最近ではシニアマネージャークラスの方を雇用する際には、そこから少し変わってきたがそれまではずっと同じ給料で行っていた。

DSC_0266

Q.
たくさんの言語の中でどうしてRubyが良いのか?

PJ氏:
個人的には読みやすいこと。2年前のコードを見てもすぐに分かる。読みやすいことが重要なポイント。
Scott氏:
ActionScript、Pythonなど書いていて、Gitで非効率な部分がありそれぞれの言語でライブラリを作らなくてはならない部分がたくさんある。GitHubではどこからでもライブラリにリンクし使うことができるようなプロジェクトを立ち上げている。

Q.
GitHubではオープンソース的な働き方で自分の好きな課題に取り組めることができるが、リーダーシップがない人がだけでプロジェクトはまわるのか?

GitHubの作業スタイルはとてもユニークでマネージャーがいないためとてもフラットになっている。課題定義を自分たちで行い、好きな部分にオープンソースと同じように行うが、GitHubでは1人で作業しないというモットーがある。必ずペアを必ず組ませるため、リーダーシップがないガイダンスが必要とする社員も働きやすい場となっている。マネージャーはいないがクオリティ管理を行うポジションの人はいる。

DSC_0255

Q.
GItHubの質の高さはどのように保っているのか?

ポストされているコードやユーザ、そしてGitHubのコミュニティ自体の質が高い。しかしながらGitHubのデベロッパーは、他の企業のデベロッパーより必ずしも優秀という訳ではなく、他の会社にも優秀なデベロッパーはたくさん存在する。その中で肝になっている部分がマネジメント法で、トップダウンにて仕事をさせるのではなく、自由に各自の好きなことをパッションを持って働ける環境を作ったことが成功の秘訣である。

DSC_0209

Q.
なぜ最初から課金するビジネスモデルがあってローンチしたか?

創業者の1人TomがGravatorというサービスを無料で一般公開したが、人気がですぎてしまいサーバーコストで破綻しそうになってしまった。同じ失敗をしない様、プライベートリポジトリを月額課金にてローンチした。

起業家育成プログラムを運営するOpen Network Labは今後も様々なイベントを開催する予定です。今後のイベント情報はメールマガジンにて発信しております。

新着記事

ニュース一覧