今回より始まった本インタビュー連載では、
【インタビューされた人】
堀江大輔（ほりえだいすけ）
ギットハブ・堀江大輔
GitHub：dice
Twitter：@dice
GitHubのプロジェクトチーム
- ──GitHubの従業員数は今、
全社で560人程度だそうですが、 チーム数はどれぐらいですか？ 堀江：バックオフィス、
営業、 セキュリティ、 プロダクト、 テクノロジ （開発）、 サポートなどにチームが分かれています。特に営業と開発が大きいですね。 「プロダクト」 というのはプロダクトマネージャーがいる組織で、 エンジニアのチームとは分かれています。もちろん分かれているといっても一緒に仕事はします。 - ──ではプロジェクトごとにプロダクトマネージャーとエンジニアとがチームを作って仕事するということですね。
堀江：そうですね。そのチームにさまざまなメンバーが、
たとえばリリースのタイミングになると広報が入ってきたり、 場合によっては法務が入ってきたりします。サポートもお客様からの問い合わせだったりアップグレードのサポートだったり、 何か問題があった場合や問題を事前にキャッチするためにチームに入って動きます。チームとしては分かれていますが、 組織上のチームと実際動くチームは違いますよね。プロジェクトやプロダクトによって、 交流する人が変わっていきます。 - ──プロジェクトが始まるごとに小さいチームが生まれて、
プロジェクトを進めて、 一段落したらまた別れて……といったように流動的ということですね。
プロダクトマネージャー職の確立
- ──プロダクトマネージャーチームがあるというお話ですが、
GitHub. comとGitHub Enterpriseとでそれぞれいらっしゃるんですよね。 堀江：それぞれいっぱいいますね。プロダクトと言ったときにGitHub.
com全体だけを指すわけではなく、 アプリケーション全体を見る人もいつつ、 それぞれの機能単位で見る人もいます。 - ──
「GitHubはエンジニアがエンジニアのためのサービスを作っている」 というイメージがあったのですが、 プロダクトマネージャーという人が出てきているんですね。 堀江：組織が大きくなる中で、
体制として一番大きな変化はプロダクトマネージャー職ができて、 エンジニアが解決すべき問題を明確化する人たちが出てきたということですね。主にエンジニア経験のある人が務めています。GitHubがローンチした当初は、 エンジニアがエンジニアのためにサービスを作っていたと。エンジニアがどういうものを欲しいかっていうのは、 自分が欲しいものを作ればどうにかなっていました。なかでも最初はオープンソースでの利用が多かったんですね。でもいろんな企業やスタートアップが 「自分の仕事にも使いたい」 となってきた。そうすると、 「なるほど、 じゃあそれはどういうふうに解決すべきなのか」 と考えたときに、 エンジニアが考えてできることもあるし、 もう少し研究して決めることもあります。僕はGitHubに入社するまでずっとプロダクトマネージャーをやってきたんですが、 開発における一番の罠って、 お客様に 「これが欲しい」 って言われたものをそのまま作っちゃうことじゃないですか。 - ──そうですね。
堀江：お客様が欲しいって言っているものをそのまま作るんじゃなくて、
お客様の抱えている問題を理解するのが重要じゃないですか。そこで問題の定義を分担するためにプロダクトマネージャーチームができました。これができることによって、 お客様の問題を本当に掘り下げて、 問題定義をどんどんできる人が出てきたというのは大きな変化ですね。エンジニアは問題を解決するのが得意なので、 そこは分担しようと。これがここ3年くらいの大きな変化なのかな。
拡大し続ける組織で、どう良い文化を保つか
- ──プロダクトマネージャーのいる組織体制に移るなど、
組織として変化してきたんですね。 堀江：成長していくなかで一番怖いのは満足してしまうことです。常にゴールには到達できていないので、
体制もそれに合わせて変わらないといけないですね。ステージが変わることによって、 どれだけ会社として体制を変えるのか。さらにGitHubらしさを維持しつつ、 お客様とのコミュニケーションもしつつ、 どうやって成長するか。 - ──良い文化を保ったまま規模を拡大することについては詳しく聞きたいですね。文化は最初は創業メンバーが作って、
10人ぐらいの規模までは明確に言わなくてもなんとなく汲み取れるとは思います。でもそこから数十人とか百人規模になると 「ウチはこういうことを大事にします」 とか 「こういうことはしません」 ということを明確にして、 全員が理解した状態を作らないとけないと思うんですけど、 GitHubだとそのあたりはどうですか？ 堀江：難しいですよね。500人どころか100人、
200人の段階で我々がやろうとしていることを全員が本当に理解するのは難しいですし、 社内でもチームによって文化は多少変わってくるところもあるでしょうし。その中で社員どうしが何か気付いたら話し合ったりしますが、 一番重要なのは、 どんなコミュニケーションでも悪意がないという前提で会話することですね。たとえばチャットで話していて 「なんかこの人は嫌なやつだ」 と思っていても、 実は誤解していたりとか。GitHubとして行おうとしていることはいろいろありますけど、 成長の途中なのでいろいろ実験している最中ですね。
組織の拡大で変わること、変わらないこと
堀江：以前GitHub以外の人から聞いたのは
「3倍になるごとに会社の文化を再確認してチェックしないといけない」 というものです。1人から3人になったとき、 3人から10人、 30人、 100人、 といった段階でチェックして、 みんなが会社の文化を理解してサポートしているのかを確認して、 もしできていなければ何かを変えないといけない。人数が3倍になるとコミュニケーションの質や内容などが全部変わってきます。10人ならみんなよく知っているのでどうにかコミュニケーションを取れるんですけど、 30人になったときはまた違いますよね。学校にいたときも1クラス30人で全員友達ってわけじゃないですよね。 - ──そうですね。毎日会って1年間過ごしていても、
全員と友達になるということでもないですし。 堀江：規模が大きくなっても変わらないところは、
GitHub Issueやチャットなどを使ってコミュニケーションを取ることですね。コミュニケーションの基盤がしっかりしてるところはまず大前提ですね。 - ──チームがどんどん組み変わる形だと、
使っているツールや開発手法などは全社として統一されているんでしょうか？ 堀江：共通化されているものもいくつかありますし、
プロジェクトごとに合うツールを使っている場合もあります。共通しているのはGitHubとチャットだけですね。GitHubについては、 IssueやPull Requestだったり、 Markdownファイルをアップしたり、 Gistを使ったりして情報共有しています。あとはチャット。場合によってはビデオチャットで話し合って、 話した内容をチャットやIssue、 Gistに書いて共有しています。
リモートワークと採用
- ──チャットやGitHubはリモートワークにすごくフィットしたサービス、
ツールですよね。Incrementでもリモートワークできるようにしているんですが、 採用のときはリモートワークでもやれる人かどうかはどう見ているんでしょうか？ 堀江：総合的な判断をしていますが、
採用の際にリモートワークできるかどうかの確認はします。たとえばリモートワークをしたことがない人であれば 「もしリモートワークしたとして、 どういう問題が起きると思いますか？」 「全然会ったことのない人と仕事していて、 こういう問題が出ました、 どういうふうに対応しますか？」 とか。 - ──なるほど。
堀江：面接もビデオチャットですることが多いので、
こうした質問をしたり、 ビデオチャットできちんとコミュニケーションがとれるかを見たりして採用していますね。サポートチームの場合は9割以上リモートなので、 一人でいることを孤独に感じないっていうのも大事ですね （笑）。 - ──たしかにそうした性格的に合う合わないというものありそうですね。
堀江：あとはどれだけ自分で仕事を進められるか。ちなみに、
採用したあとのフォローで一番気を付けているのは 「インポスターシンドローム」 です。自分はどうして採用されたのか？ はたして自分はスキルがちゃんとあるのか？ 採用されちゃったけどできないんじゃないか？ って思う人が多いんです。 - ──へー、
そうなんですか。 堀江：結構多いんです。そこで、
採用のプロセスでもたとえば10回くらい面接するのが普通なので、 ここまで来たんだから自信を持ってくださいとか、 そういうフォローがけっこう大事です。リモートだと相談できなくて一人で悩んじゃったりする人もいますし。フォローするために積極的に新しいチームメンバーに連絡をとったり、 メンバーの状態を見て声をかけたりしています。 - ──しっかりフォローされているんですね。
堀江：採用ですごく失敗することってあまりないじゃないですか。ちょっとサポートすればレベルアップしてすごく良いチームメンバーになる人が多いので、
そのフォローには気を付けています。あとは入社したときに 「最初の半年間はあなたはこれしかしないで大丈夫です、 それ以外は心配しないでください」 と言ったりとか。 「それ以外のことは、 たとえばほかの人からリクエストが来たら、 あなたはすごく優しい人ですし、 いろんな人を助けたいのはわかるけど、 もし自分のキャパを超えているんだったら断っていいんだよ。断れないなら僕に言って。僕が代わりに断るから」 って。そうしたことを伝えていますね。
オンラインで得られる情報の取捨選択
- ──以前Rebuild.
fm でも、入社直後にやりがちな失敗としてあらゆるIssueに首を突っ込んで仕事ができない、 という話をしていましたね。 堀江：そうですね。入社して一番大変なことは情報量。英語で
「消火栓からの水を全部飲み込もうとする」 と言いますが、 無理じゃないですか。 - ──無理ですね
（笑）。 堀江：そこで僕が言ってるのは横からストローを突っ込めばいいということ。自分が知るべきことにフォーカスしてもらって、
知らなくていいことをちゃんとわかるのが大事じゃないですか。採用ではやはり好奇心旺盛な人を選ぶんですが、 そうした人にも今知らなきゃいけないことに集中してもらいつつ、 その人のやる気を削がないようにしないといけない。 - ──これだけをやれ、
と命令する感じにはしたくない。 堀江：そうです。自主的に動ける人を採用しているので、
特にそういうフォローが重要です。でもおもしろい情報はたくさんあるんですよ。たとえばオペレーションチームのチャットでのBot利用とか。 - ──Hubotですか。
堀江：はい。何て言うんですかね、
SFの世界みたいな感じで、 世界中にいるエンジニアがチャットにコマンドを打ち込んで、 Hubotを使うんです。Hubotはいろんなツールと連携していて、 今サービスがどんな状況かという情報を取ってこられるんですが、 それを見て 「じゃあトラフィックをこっち経由に全部動かそう」 とか、 そういうのを全部Hubot経由でやるんです。宇宙系の映画だと、 管理室があってみんな集まって話し合ってあれこれやるシーンがありますが、 そんなやりとりが全部チャット上で見られるので、 すごくドキドキしますよ。映画を見ている感じ。 - ──かっこいいですね。
堀江：ただそうしてチャットをずっと見ていると2時間とかすぐに過ぎちゃいます。なので、
そうしたところには気を付けてもらうようにしていますね。
良いチームとは
- ──最後に難しい質問になるんですが、
堀江さんの考える良いチームとはどういうチームでしょうか？ 堀江：みんなオープンにコミュニケーションできて、
お互い信頼できるというのがすごく重要だと思うんですよね。信頼できる＝みんなが何かの形で貢献できるチーム。そして自主性が高いチーム。 - ──自主性ですか。
堀江：ウチのチームでは何か作業しようとすると、
誰か一人が必ず手を上げるんですよ。なぜかはわからないですが、 うまい具合に 「これ僕だな」 ってみんな手を挙げて、 進められるんです。こうして全員が貢献していいと思う環境であること。あとはお互い違うことを活かす。特にテクノロジに関しては全部が得意分野の人っていないじゃないですか。 - ──そうですね、
全部に尖っている人はいないです。 堀江：なので、
うちのチームだとMySQLが得意だったりRailsが得意だったりハードウェアが得意だったり、 いろんな人がいるんですよ。そしてお互いがサポートし合ってお互いのスキルアップを手伝えているんですが、 このおかげでチームとして成長してさらに良いチームになっていきます。なので、 良いチーム、 理想のチームというのはみんながすごいスキルを持っていて、 それによってみんなが貢献して、 良いものを作って、 良い成果物を出せるチームです。採用するときも自分よりデキる人、 自分のチームを次のレベルに引っ張りあげてくれるような人を選んでいます。良いチームだとそういう人がいても悪い危機感を感じない、 良い刺激を感じられる。 「こういう人がくるんだ、 やったー！」 って。 - ──
「こういう人がいたら自分のやることがなくなるぞ」 といったネガティブな意味ではなくて。 堀江：そうです。チームメンバーがすっごいスキルあって、
必死についていくほうが絶対楽しいですよね。自分の存在価値をどんどん作っていかなきゃいけないという危機感を感じているほうが僕はすごくやりがいがありますが、 GitHubに入って一番それを感じていますね。 - ──先ほど組織が大きくなる中で課題もあるっておっしゃっていましたけど、
GitHubはかなり良いチームみたいですね。 堀江：チームとしても会社としても課題もありますけど、
成長していく中での課題なのでポジティブにしか考えられないですね。課題が浮き彫りになっていて、 それを良くしていくために人が動いていく。課題を隠さず、 後回しにせずに向き合って、 解決していける。 - ──改善し続けられるというのも良いチームの条件の一つですね。本日はありがとうございました。
本誌最新号をチェック！
WEB+DB PRESS Vol.130
2022年8月24日発売
B5判／
定価1,628円
ISBN978-4-297-13000-8
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！ - 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう - 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、 NFT