今週、同じ役職名にかこつけて、Open Network Labで開催されていたGitHubのCOOの講演を聞いて来ました。
GitHubといえばいわずと知れたソフトウェア開発向けの共有サービス。
講演の内容を、かい摘んでメモにしますと、以下の様な感じです。
- COOのHyett氏は元々CNETで働いていて、
様々な言語をやっていた中でRubyに恋に落ちた。 他言語に比べて、一年前に書いたコードの意味が、 今日になっても分かる、 というのがJavaに比べて圧倒的に良い。 - サンフランシスコのRuby Meetupの最中、
バーで知り合いと副業としてやることを決定。 2007年10月にドメインを取得、平日と週末にサービスを作成し続けた。 - かなり初期にForkボタンを導入。それまで、
人のコードに手を入れることはネガティブに捉えられがちだったが 、それをポジティブな印象のものへと変えて行くことを意図した。 - ずっと無料でやっていたが、ある時「
このサービスがなくなると困るので、お金を払わせて欲しい」 と言われた。そのときに始めて、課金できるし、 副業ではなく本業でやろうと決断できた。 - オープンローンチしたのは2008年4月。
ローンチは順調にでき、 翌日にRubyに関するホスティングを開始した。その後、 大きな失敗もなく、順調にサービスは伸びた。 - 最初に採用したのはCTOのScott。彼は、
ユーザー交流ミーティングで、 毎回大変鋭い指摘をしていたほか、gitの改良をやりまくったりと、彼を採用しないわけにはいかない、という感じだった。 Gitについて、創業者二人はそれを好きだったが、 本当に深い理解ができていたわけでもないので、 彼の洞察は大変重要な物に。 - GitHubのようなウェブサービスでは、
ユーザーにこのサービスは良いのだ、と説得することはできない。 だから、作り込みが大事だし、 正しいものを作ればちゃんと報われる。 ユーザーは自らの体験をかたり、宣伝してくれるから。 そのためにも、交流ミーティングは大事。
GitHubはミッションが大変明確なサービスです。人々が互いの知恵を活用し、離れて働くことの生産性を高めていくツールでもあるだけに、本尊である同社を人が辞めない理由も、よく分かる気がしました。
さて、講演を聞きながら、私はこの半年の間、金融業界からエンジニアの世界に身を転じた中で感じたGitへの、畏怖にも近い思いを感じていました。
Gitについてはネット上に沢山の情報があり、すごい使われ方もありますが、一言で言い切ってしまうと、それはひとつの大きな作品を、複数の人が相互の仕事を尊重しながら育てていくための、極めて正確なコミュニケーション手段なのだと感じています。
昨年、マネーフォワードに参画してから、私は複数のエンジニアによる（ノンエンジニアから見ると神がかり的な）仕事の積み重ねで、サービスが作られていく過程を経験してきました。当然、様々な試行錯誤もあり、事前に完成像が見通せない中、サービスがスピーディーに作り上げられていく過程を見て、内実感動を覚えていました。
これだけ不確実で、複雑なプロセスが同時に進む過程に向き合う方法に対する適確な方法（処世術？）は、不勉強ながらMBAの世界では教わったことがなかった気がします。もちろん、最近のビジネススクールの授業では、そういったソフトな修練に向けて様々なトレーニングやツールを与えてくれるのですが（※）、この数ヶ月の経験に照らすと、Gitをベースとした工程把握・管理がなければ、スピードを保ったままサービス開発をベンチャー組織が進めるのは無理、と思えるものでした。
そして、これだけ複雑なことを可能としているのは、プログラミングという論理的な言葉が、Gitにより個々の都合に合わせて伝わることを可能としているからです。結果として、エラーを許容し、それぞれが仕事に集中できる仕組みがあり、全体にそれを還元できる、という、様々なマネジメントの教科書で理想とされるような作業が可能になっています。これは、本当にすごいことである割に一般には知られていない気がします。
日本のみならず、世界中で様々な組織が、対面でのコミュニケーションが最も信頼でき、集権的な意思決定者が上にいて、ということを前提としています。明確な言語と、明確なコミュニケーション。Gitはその代表格ではあるものの、それ以外にも、リアルタイムでの情報共有とか、情報の主成分を抜き出す方法は増えています。仕事をもっと分かりやすく、伝えやすいものとすることで、エンジニア以外の世界でも、同じようなことが今後起きていくはずだと、改めて考えたのでした。
※もしご興味あれば、昔のブログもご覧くださいませ。
Photo by Yukop
