ユーザーの人生にインパクトを与えるコミュニティを作りたい

僕は2011年に新卒でサイバーエージェントに入社しました。入社の決め手になったのはAmeba事業です。というのも、僕が学生の頃にmixiやニコニコ動画が流行っていて、そういったコミュニティに強く影響を受けました。

コミュニティ系のサービスにはユーザーの人生を変える力があるなと感じていて、そのフィールドで誰かの人生をハッピーにしたいなと。その軸で就職先を考えたとき、Amebaを運営しているサイバーエージェントに魅力を感じて入社しました。

入社してからは色々な事業に関わっていて、中高生向けSNSの「Candy」やトークラジオアプリ「ラジ生？」、ゲームアプリ「もやしびと」などを立ちあげました。

エンジニアの業務としてはサーバーサイドがメインなのですが、Androidアプリの開発を担当していたこともあります。現在はAbema（アベマ） TVに出向し、サーバーサイドエンジニアを務めています。

GitHubベースの開発で、正確にレビューの意図を伝える工夫を

弊社のチーム開発の中心にあるのがGitHubです。2013年頃から使い始めていて、Pull Requestベースで開発をしています。チームごとに様々なコラボレーションツールと組み合わせて使っています。

Pull Requestを使ってレビューをしていくのですが、誰でもすぐにレビューが出来るという訳ではないです。前のプロジェクトのフローに馴染んでいるとか、GitHubの使い方が異なっているなどバックグラウンドが人それぞれ違うので、そこを統一する必要があります。そのため、いくつかのルールを決めています。

例えば、レビューするときに「Must」「IMO」といったレベルを付けるようにしています。「Must」が付いた指摘は絶対に直さないといけないものです。一方「IMO」はIn My Opinionの略で、「問題はないけど、僕だったらこういう書き方の方が良いと思うけど、どうだろう？」というくらいのニュアンスです。

他にはコードの意図が分からなかった時は「Question」を付けたり、「+1」を付けて書き方を褒めるということもしています。このレビューは何を伝えたいのか、というルールを統一することで間違った伝わり方をすることもなくなりますし、誰がいつ入ってきてもスムーズにチーム開発を進められる仕組みができています。

「コードを読めば分かる」はNG！仕組みは全てドキュメント化

もうひとつレビューをスムーズに進めるために気をつけている点があって、「コードをきちんと理解した上で、何が悪いのかを明文化して伝える」ということです。

何となくとか、よく分からないけどこれはおかしい、という指摘ではダメで、しっかりと直すべき点を自分の言葉で表現してアウトプットすることが重要だと考えています。

このようなレビューの仕組みはしっかりとGitHubのREADMEに明文化して残しています。レビューやブランチ運用のルールや、パッケージ構成のような技術的な話もしっかりとドキュメント化しています。

一部のエンジニアには「コード読めばわかるじゃん」という考えもあると思います。その気持ちも分かるのですが、会社からお金をもらってプロとして仕事をしている以上、「自分がいなくても回る」仕組みをきちんとドキュメント化して残していくことが本当に重要だと考えています。

メンバーの成長という軸でレビュアーをアサイン

実際にレビューをどうしているかというと、必ずクロスレビューをして、レビューが通らなければ絶対にマージはしないように徹底しています。

レビュアーは基本的にユニットリーダーなのですが、レビュアーが1人だとそれだけで1日が終わってしまうほどの量が存在するので（笑）、難易度を考えながらチームメンバーにもアサインするようにしています。コードを読むことで成長する部分も大きいので、レビューをするという事も成長する機会と捉えています。

ひとつのPull Requestの粒度はレビューが出来るレベルで、かつそれぞれの依存性ができるだけないように気をつけています。全てのPull Requestがシーケンシャルに繋がっていると作業が止まってしまうので、レビューがボトルネックにならないようにしています。

プロダクトのコードはプロジェクトを越えて全社に公開！

サイバーエージェントの社内ではGitHub上のほとんどのソースコードが、プロジェクト横断で雇用形態関係なく誰でも見られるようになっています。

コードの公開範囲を広げるのは、情報の流出や改ざんなどの可能性を考えるとマイナス面もありますが、個人的には確実にメリットの方が大きいと思っています。

公開することで、全員でコードを良くしていく事が出来ます。自分の作ったツールをGitHubで社内に公開すると、他の事業部のメンバーから「ここバグっていたので直しておきましたよ」ってPull Requestが飛んできたりするんです。

単に「バグってますよ」と伝えるのではなく「直しておきましたよ」とまで言えるのが理想的なエンジニアだと思うのですが、弊社にはそういう人が多いと思います。チーム問わず、気になる箇所のレビューを技術のある人にお願いすることもあります。

僕も以前、面識の無かった人にPull Requestを送ってマージされたことがあって、後ほど社内で会った時に「あのPull Requestを送ったのは僕ですよ」「君だったの？ありがとう」みたいなやり取りがあったこともありました。エンジニア特有のコミュニケーションだと思います。

プロジェクトや業種の壁を超えたコラボレーションも

もうひとつのメリットが、サービスの垣根を超えた情報共有ができる事です。今のチームはGo言語を使って開発しているのですが、そこで使っているGinというフレームワークは色々なミドルウェアを組み込んで拡張することができます。

ロギング機能のように共通で使えるようなものあるので、それをオープンにして別のプロジェクトメンバーとコラボレートして開発しています。自分が欲しいと思って作ったものは他の人も欲しいはずですし、自分では気付けなかったバグを教えてもらうことも多いです。

今後はエンジニアだけではなくデザイナーやプロデューサーの人もGitHubを使いこなせるようになったらいいですね。最近ではpsdファイルの差分も見られるようになっていたり、デザイナーの人にとっても以前より使い勝手が良くなっていると思います。

GitHub Issueをカンバン風に見せるZenHubというツールなども出てきているので、エンジニアリング以外の作業もうまくGitHubに集約できるのではないかなと。非エンジニアにはハードルは高いと思うのですが、諦めてはいないです！

GitHub上の「スター」を社内評価に反映する仕組みも

弊社の特徴的なGitHubの活用法として、オープンソースとして公開しているリポジトリのスター数に応じ、エンジニアがインセンティブを得られる「スターインセンティブ」という制度があります。「世の中的に評価されているもの」をきちんとアウトプットとして会社が認めてくれるという仕組みです。

僕はこの制度は非常に良いと思っています。弊社のエンジニアも他の人が公開しているソースを参考にすることも多いですし、こちらでもやっていくべきだと考えています。会社が制度としてコードの公開を後押ししてくれているので、安心してどんどん出せるようになりました。

僕は今使っている言語がGo言語なので、閲覧数も少なくあまりスターが付かないのですが（笑）、AndroidやiOSのインタラクション系のライブラリですとニーズも高いので、スターが千個以上ついている人もいます。

自分の書いたものをオープンにして外部の評価を受けることで、業界内で個人のバリューを高めることにもなり、例えば講演の依頼などにも繋がっていきます。

そして「あのライブラリを作った〇〇さんはサイバーエージェントにいるんだ！」となれば、組織としても効果的なコーポレートブランディングになりますよね。コードを公開することで他のWebエンジニアの役にも立つし、個人にも会社にもメリットがある。「3方よし！」でうまく循環している取り組みだと感じています。

世界的大企業がコードを公開し、「公開しないリスク」の時代に

公開可能になったソースコードは企業の中に留めておかず、どんどん公開すべきだと思っています。プロダクトのコードはさすがに公開出来ないですが、汎用的に使えるようなものは積極的に公開することで見る側にも見られる側にもメリットがあります。

ただ、弊社も最初からこのようなカルチャーが浸透していたわけではなく、根付いたのはここ2、3年です。僕の入社当時はまだ知的財産の話や、自社の優位性になり得るものを公開して大丈夫なの？　という意見が大多数でした。

でも、もうそんなことは言っていられません。いわゆるITベンチャーだけでなく、例えばソニーやディズニーなどの世界的大企業もGitHubに自社のOrganizationを作ってリポジトリを公開し始めています。

この世界的な流れに乗らないのはもはや時代遅れで、その人達と戦う上で公開しない理由はもうあまりないと感じています。むしろコードを公開しないほうがリスクになる時代です。今後も弊社の新しい時流に抵抗なく乗っていくカルチャーを活かして、常に変化し続けていきたいです。

▼GitHubを使ったコードレビューの方法を知りたい方はこちら

• チーム開発を変える「GitHub」とは？〜Pull Requestの使い方〜