GitHub活用の最前線｜シリコンバレーの企業でGitHub導入が進む背景、そして成功ケースとは？

「9歳だった頃の夢を叶えている最中」 GitHub マシュー・マックロー氏

GitHubのマシュー・マックロー氏は、とてもユニークなキャリアの持ち主だ。

もともとCSG Systemsにてソフトウェアエンジニアとして働き、その後、Javaのコンサルタント、O'Reillyなどで記者を経験。現在、GitHubにてトレーナーやコンサルティング、セールスを担うフィールドサービスディレクターとして働く。

ソフトウェア開発に約10年携わった後、記者、トレーナー、コンサルタント＆セールス…と異色の経歴。その背景には「教育」に対する思いがあったという。

9歳の頃からエンジニアを志していたというマシュー氏。より多くの人に学習の機会をつくるために自身が進む道を選んできた。そういった意味でオープンソースコミュニティへの貢献、そしてGitHubへのジョインは自然な流れだったのかもしれない。

マシュー氏は現在、世界中を飛びまわり、企業でのGitHub導入・活用を支援する。オープンソースを用いてどうプロジェクトを成功させるか。日本の企業にも広まっていくか。シリコンバレーでの成功事例をもとにお話を伺った。

「優秀な人」と「良いツール」が揃ってこそプロジェクトは成功する

― シリコンバレーでは大企業でもGitHubの活用が進んでいると伺いました。その背景について教えてください。

まずシリコンバレーの企業、特にソフトウェアのディベロッパーが理解しているのは、プロジェクトを成功させるためには「優秀な人」と「良いツール」、その双方が必要だということです。

優秀な人を採用しようと思ったら良いツールが必要です。それは効率よく仕事がしたいから。お互いは磁石のように引かれ合い、両方が揃ってこそ成立する。そういった意味でもGitHubや、オープンソース・ソフトウェア（OSS）はとても有効だといえるでしょう。

― 日本ではWebベンチャーだと積極的にOSSが用いられますが、大手のIT企業ではあまり活用が進んでいない印象です。

たとえば、IBMとGitHubは協業をしていくことになりましたし、これからという段階といえるのかもしれません。

― 情報の管理など安全面など懸念する声もありそうです。

たしかに、すでにシステムが構築されているなか、仮にゼロから開発環境を構築しようとしたら多くの反対が起こるでしょう。ただ、オープンソースにおける利点はゼロからつくるのではなく、既にある「核となる情報・ノウハウを活かす」などエンジニアたちがやってきた事をより良くするものであるということです。

部署間における承認・決裁・意思疎通など「プロセス」を効率化できます。つまり“しがらみの突破”を意味しているのです。

たとえば、エンジニアたちがMacに貼っているステッカーをイメージしてみてください。「何にも縛られない自由な新規事業」の象徴として、OSSやGitHubのステッカーがMacに貼ってあったとします。

「なぜそのステッカーを持っているの？」「GitHubをどう使っている？」「僕も参加できる？」といった「現場での会話」が起点となり、スタートしたプロジェクトは熱量が違います。

GitHubがシリコンバレーの大企業で積極的に使われるのも、上司へ提案からではなく、現場のエンジニアたちの会話によってですね。

― 具体的にはどのような企業で使われているのでしょうか？

たとえば、数万人規模の従業員が在籍している欧SAPがいい例ですね。それまで、新規事業のメンバーは社内で公募をしてきたのですが、Macに貼ったGitHubステッカーから会話が生まれて「やりたい」と手があがり、新規事業のプロジェクトメンバーが構成できました。

そのプロジェクトは運用フェーズでも成功しています。それはデザイナー、ディベロッパー、プロダクトマネージャー、フロントエンド、サーバサイド、それぞれのエキスパートがGitHubという同じプラットフォームで作業を行っており、意思疎通ができているからです。「まるで全員が同じテーブルの席についているようだ」これが彼らの感想でした。

プロジェクト成功の秘訣は、ちょっとずつ間違えること

― 組織変革・チームビルディングなど、本質的な視点からツールを見直すということですね。

はい、おっしゃる通りです。

もうひとつ、ソフトウェア開発のプロジェクトを成功させるために重要なのは「アジャイルアイデア」という考え方ですね。

たとえば、先にご紹介したSAPも何かをデプロイする時、1週間単位で表に出せるレベルでつくり続けました。社内で「そんなことは不可能だ」と言われていたスピードです。この「すごく短いスパンで動かせるものをつくる」ということが非常に重要なのです。

たとえば、プロジェクトがスタートし、3ヶ月後に狙っている成果（TARGET）があったとします。しかし、多くの場合、3ヶ月後にTARGETに到達できていませんでした。それはなぜでしょうか。

じつはプロジェクトが開始して3ヶ月間、1方向にしか進んでいなかったのです。そもそもスタート地点で方向性を誤っていたら、どこまで引き返せばいいのか、検討さえつきませんよね。

それが、1週間ごとにピボットできたらどうでしょう。

同じ3ヶ月でも、よりTARGETに近づくことができています。すごく早いサイクルでピボットしながらトライアル＆エラーを繰り返す。これがGitHubを用いてプロジェクトを成功させるために重要な考え方です。

この短いスパンでのピボットにあたって、GitHub上の「Pull Request」の活用を推進しました。Pull Requestは変更依頼を出し、小さな変更を繰り返すために使うもの。Pull Requestの概念は、アニメの設定にもよくある「パラレルワールド」のイメージに近いかもしれませんね。

自分の生きる現実世界とは別の世界、「仮の人生」でいろいろと試す。上手くいったそれぞれの人生を統合、つまりマージすればいいというわけです。しかも安価、安全な方法でできます。

これがタイプライターや書籍など、物理的なプロダクトであれば、同時にいくつも作り、統合させることはできません。ただ、ソフトウェアの世界では実現ができます。他の業界からするとスーパーパワーに映るかもしれませんね（笑）

また、Mentionを飛ばすことで、専門家たちに直接、質問することもできます。

全てのプロセスをオープンにして、プロジェクトメンバー以外の社員も参加・閲覧できます。そうすることで得られる最も大きなメリットは「学びのプラットフォームになる」ということです。

どのプロセスでも必ずチャットが行なわれ、どんな経緯でPull Requestしたか、マージしたか、あとから追うことも可能です。また、公開されている他のプロジェクトを参考にすれば、Rails、Bootstrap、Spring Framework、Scala、さまざまな専門家たちの視点が学べていつだってレッスンが受けられるというわけです。

「常に正しくある必要はない」

― プロジェクトを成功させるために「失敗」を前提におけるか。ここがポイントと言えそうですね。

多くのソフトウェア開発を見て学んできたのは、「常に正しくある必要はない」と言うことです。ちょっと間違えてどんどん修正することがゴールへの最短ルートになる。これは「間違えてもいいんだ」といった社内文化の構築にも大きな影響を与えていくはずです。

たしかに多くの企業が不安視するのは、「失敗を許すカルチャー」をどう醸成していくかということ。シリコンバレーでもよくあることです。ただ、それを乗り越えてきた企業がより大きく成長しています。

― 最後に、すでにオープンソースの素晴らしさを理解したエンジニアがどう社内での利用を広めていくか。ポイントがあれば教えてください。

どれだけのコストと時間が削減できるか、オープンソースがもたらす恩恵について伝えていくことはひとつの手段かもしれません。

また、OSSをどう有効に活用していくか、ここは国際的な競争力を考える上で、もはや無視できないもの。日本でもDeNAやGREE、クックパッドなど、オープンソースと共に成長してきた世界的な企業がありますよね。いかに彼らが海外と仕事をしているか、大いに参考となるはずです。

日本においては、和歌山県などの自治体でも活用され、プロジェクトの規模、官民に関わらず、使われていく。こういった実績にもぜひ注目をしてもらえればと思います。

― 日本企業で導入を検討している方など、参考になる部分も多かったと思います。本日はありがとうございました。

文 ＝ 白石勝也