GitHubの組織が成長する過程で変えたことと変えなかったこと

http://zachholman.com/talk/how-github-no-longer-works/

1 comment | 0 points | by WazanovaNews 2年以上前


Jshiike 2年以上前 | ▲upvoteする | link

GithubのZach Holmanが語る組織戦略です。まず最初に、



  • Step #1: ロックスターエンジニアを雇う

  • Step #2: ものすごく透明性のある経営をする

  • Step #3: ブログ/ソーシャルメディアなどでテクノロジーについて発信する

  • Step #4: カンファレンスで会社について話す

  • Step #5: カネに余裕ができる

  • Step #6: 社員を大勢雇う

  • Step #7: 会社のことを話さなくなる

  • Step #8: コミュニティを無視する

  • Step #9: 創業者が株を売って儲ける

  • Step #10: 別の会社をはじめる


という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。



Dunbar's numberとしてよく知られるとおり、人間が良好に関係を保てる最大規模は150人。Githubは217名。150人という閾値を超えたことで組織は幸いダメにはならなかったが、もろもろの工夫は必要であった。


まず、Githubの組織の特徴としては、



  • 60%がリモート勤務

  • pull request / chatを中心にコミュニケーションは非同期スタイル

  • 会社にマネージャーはいない


(開発するプロセスはgithubを使ってブランチをわけても、)コードをアップするプロセスをシンプルにすることが重要。本番アップするターゲットは、本番環境の全ユーザに提供、もしくは本番環境の社内スタッフ向けサーバーの2パターンのみ。ステージング環境は、ネットワーク関係などどうしても本番環境で再現しづらいことを確認するために残しているが、基本的には使わない。何十人ものスタッフが平行してGithub.comの開発作業をしているが、github機能とチャットで各ブランチの状況を確認 & マージしていくことでうまくコーディネートできている。


社外のベータテスターには頼らない。かえってスピードが落ちる。社内スタッフ向けの本番サーバで数週間、数ヶ月単位で新機能を試す。この環境は、特定のチームに絞ることができるので、コードを徹底的に磨き上げる前に担当チームだけで素早く本番確認ができて有効。


情報は抱えないで、wiki / chat などを使ってとにかく共有する。社内の特定の人だけに情報が留まるとセクショナリズムにつながる。(追記: 短く意訳してますが、ビデオでは「このことは専門であるあの人に聞かなくてはいけないという意味のない権威主義がはびこるので組織が硬直する。」的な説明がされてます。


新入社員はGithubイシュー、チャットログ、pull requestとか読んで、自然と学ぶから邪魔しない。情報はアクセスできるようにするが、時間かけて教え込んだりしない。しかし、この放置する方式だけでは、Githubという組織に早く慣れ親しむのは無理があるので、最近は、最初の1週間はサンフランシスコのオフィスに呼んで、バディ(メンター)をアサインしている。バディの期間をもう少し長くすることも検討中。


社員を信じること。中間管理職がマイクロマネッジをして煩わせるのでなく、皆が自分の仕事に集中できる環境にする。一方、完全に任されたときの問題は、フィードバックをもらう機会が少なくなること。この対策としては、バディ制度の拡充、リモート勤務メンバとの打合せは相手の顔がみえるコミュニケーション方法をとる、社内での交流イベント増やす、サンフランシスコのオフィスには人が集りやすいスペースを用意するなどの工夫をしている。自然とインフォーマルなフィードバックが起きる環境づくりが重要。


幸い最初の5年間で退職者ゼロだったが、人は辞めるもの。しかし、採用に力を入れるのだから、退職もどれだけ最小化できるかという努力は重要。


大きな出資を受けて、大きなメディアが急に取り上げてくれるようになった。オフィスを借りるのも苦労しなくなった。会社の立上げ期に資金調達せずに、自力で黒字化し、その結果よい条件でよいVCから資金調達できる立場になれたことはよかった。


組織が大きくなってくると、チーム単位が重要になってきた。最初は、皆が色々なプロジェクトに意見をインプットすることで効果をあげてきたが、ある段階から個人の意見だけでドライブされるのでなく、既にそのプロジェクトにずっと専念してきたチームをバランスよく尊重することで進めるスタイルに変わってきた。些細な事例だが、プルリクエストにccで@チーム名をメンションすることで随分違ってくる。Githubではどのチームに参加するかは自由だが、適宜自分で重要だと思うチームに入ったり、抜けたりすることで各人がうまく必要な立ち位置を調整できる。(ここでの「チーム」は自分の工数を全て専念する単位というよりは、複数のチームに所属できる運用がされてるようです。


153のチャットルームがある。実際のオフィスと違ってつくるのは安いし、全てのチャットルームに参加するわけでなく、個人単位で選択して参加することで適宜最適化できるので、一時的なものも含めて積極的にルームをつくるようにしている。チャットルームで名前が@でメンションされるとモバイル/デスクトップにpush notificationが飛んでくる。必要なときに連絡がくるが、答えられるときに反応すればよいという非同期スタイル。


依然、会社にマネージャーはいない、各チームがどのように仕事を進めるか、ペアプログラミングで開発するか、テスト駆動型の開発をするか、などは完全に任せている。PRP (Primary Responsible Person) がいるチームがある。その機能の開発がうまく進むことを担保する責任者ではあるが、フルタイムで人を管理するマネージャーではなく、本人も開発する。オープンソースプロジェクトのリーダーに位置づけは似ている。


スピードあげるために、大きなチームを分割して小さな単位を保つようにしている。


リモートワークをうまく活用するには会社側の努力が相当大事。リモートワーカーが一体感を感じることができるように、社内でのスピーチ/講演を録画して提供したり、インフォーマルな会話を共有するためのアイデア(オフィス内を巡回して社内の雰囲気をiPadで中継する機器とか、チャットルーレットのように社内のランダムな人とビデオチャットをして社内の知り合いを増やすとか)を話し合ったり、オフィスでのイベントに招待したりなど工夫/努力している。


テクノロジーでなくてプロダクトが最先端のいいものであるべき。Ruby, C, git, MySQL, Memcachedというシンプルな構成に絞っている。最新のテクノロジーが会社を成功させるわけではない、どうワークフローをどのように信頼できるテクノロジーとツールでつくりあげていくかがもっと大事。システムを安定して運営できるということは素敵なこと。


役割を増やしたチームを新設して組織を無駄に肥大化させるのでなく、ツールを活用して解決できることも多い。組織を無駄に肥大化させるような昔からの固定観念は疑ってかかるべき。会社は成長する過程では変わらなければいけない。しかし、バリューは変えてはいけない。



Treehouseしかり、Valveしかり、Githubしかり、このような運営手法でビジネスがしっかり成り立つ会社が出現しはじめてるということがポイントかと。自分の会社の競合として、このような組織運営をする会社が現れたら、どちらの方が採用競争力があるでしょうか。「人材が一番重要」とうのは全ての会社が言いますが、「自分たちのやり方は変えられない。」とすると、一番重要な優秀な人材を採用できなくて、本末転倒になってしまいます。自分の会社の採用競争力にハンデをもたせないようにするには何をするべきかは考える必要があるかと。


http://www.infoq.com/interviews/berglund-product-owners


http://www.youtube.com/watch?feature=player_detailpage&v=Ms-8GcZXiDA#t=6881


http://www.infoq.com/presentations/github-evolution


How GitHub No Longer Works
https://news.ycombinator.com/item?id=6734277




CloudFlare: 技術的なやりがいをアピールする


Treehouse: 本当にフラット、つまりマネージャーがいなくなった会社。そして個の時代がくるのか?


Valve: ハンドブックで新入社員を迎える


「Remote: Office Not Required」を読んだ感想


Quora: 新しい社員の迎え方について



#github #人事 #組織 #働き方 #起業 #スタートアップ #リモート #フラットカンパニー

Back