Googleでは、世界各地のGoogler（Googleの社員）たちが毎週、トイレの壁に紙をたくさん貼り出していました。コードのテストに役立つヒントを週替わりで1枚の紙にまとめたものを、社員間で共有するためです。ある週はDI（依存性注入）を取り上げて様々な言語での簡単な使用例を示し、またある週はチームのコードベースのテストカバレッジを評価するために、ツールのセットアップ法を紹介するという具合です。“Testing on the Toilet（トイレの時間に考えるテスト）”と呼ばれるこの取り組みは、エンジニアがコードを書く上で役立つ情報を共有する方法として、奇抜で面白いものです。 ^(1) そしてGoogleのエンジニアリング文化の要となる強みもここに表れています。つまり、大勢のエンジニアに対して、一連のベストプラクティスを一貫した強硬な形で、効率よく普及させるということです。

私は大学を出てすぐGoogleのサーチクオリティチームに入り、2006年半ばから2008年半ばまでそこに所属していました。Googleの社員が約8,000人から20,000人ほどにまで増えていった頃でした。 ^(2) ^(3) 私は最初のプロジェクトで非常に有能なエンジニア2人と組むことになり、わずか6カ月で、毎日何百万人ものユーザに対して 関連する検索キーワード を検索結果ページで表示するという仕組みのプロトタイプを作り、テストを行って、google.comの新機能として提供を始めました。ほんの新入社員すなわちNooglerだった私がチームで仕事をしていた中で常に強く感じていたのは、Googleは私のような新入りのエンジニアを会社の戦力に育て上げるのがいかに速いかということです。まるでボーグによる“同化”のように、 ^(4) Googleは新入りのエンジニアを社内文化に溶け込ませる方法を熟知していたのです。

もしGoogleのエンジニアリング文化で要となるいくつかの指針がなければ、私のチームがあの厳しいスケジュールの中であれほどのスケールとインパクトのある機能をリリースすることは極めて難しかったでしょう。その指針があったからこそ、私はGoogleのコードベースやツール、インフラストラクチャについて素早く理解することができ、Googleも今や50,000人超の社員を擁するまでの大企業に成長できたのです。元Googlerの中には、Googleは時流に乗り遅れお役所的になったなどと嘆く声もあるようですが、 ^(5) Googleがあの大規模でハイレベルの成功を収め続けていることは否定できませんし、米ビジネス誌『Fortune』が掲載する「 100 Best Companies to Work For （働く社員にとってのベスト100企業）」のトップを維持していることも事実です。

以下に挙げるのは、私がGoogleのエンジニアリング文化から学んだ6つの中核的指針です。皆さんも何か得るところがあるかもしれません。

共有ツールと抽象化の仕組みへのエンジニアリングリソースの割り当て

Googleは非常に早い時期から、Protocol BuffersやMapReduceやBigTableといったエンジニアの仕事で使われるツールや抽象化の仕組みを全社で統一することに巨額を投じてきました。そのように構築された、問題をいったん十分に解決しその結果を社内で活用するという方針が、大きな利益につながっています。どのツールを使ったらいいのかと各チームが悩むことはありません。専用ツールを作成するチームがエンジニアリングの生産性向上のために力を注いでいます。こうして改善されたものが、既にツールやサービスを利用している人たちに簡単に広まる仕組みがあるのです。各チームが全く違うツールを利用しているような組織とは違い、このような取り組みによって全社で統一された基礎的な考え方をいったん学べば、社内における多くのプロジェクトの裏にある仕組みをより簡単に理解できるようになります。一方、この取り組みの欠点を挙げるとすれば、そのツールが自分の仕事にとってベストなものではなかったとしても、自分のユースケースをサポートの行き届いた特定のツールに入れることにプレッシャーを感じることがあるかもしれないということでしょうか。

新入りのエンジニア向けに繰り返し使えるトレーニング資料への投資

私がGoogleに入社後、早い時期から生産性を上げることができた理由に、Googleがcodelabsと呼ばれるトレーニング用資料に多くのリソースを投じていたということがあります。codelabsでは、Googleで中核を成す抽象化の仕組みやプログラムの設計思想が説明され、コードベースの中で関連性のある部分がハイライトされていました。そして実装の演習をとおして理解度を測ることができました。codelabsがなかったとしたら、効果的な仕事をするための多くの技術について私が学ぶのに、もっと長い時間が必要だったかもしれませんし、同僚もそれらの技術を私に説明するのにもっと多くの時間を割かなければならなかったかもしれません。Googleのcodelabsにおける有意義な経験は、後に私が Quoraでの新メンバーへの教育プロセス を決める時に、codelabsの活用を推進することにつながりました。

コーディング規約を標準化すること

ホワイトスペース、大文字化、行の幅、スマートポインタを使うのかどうかなどといった決まり事は、ひとつひとつを見ると大したことではないように思えますが、Googleのような規模の企業では大きな意味を持っています。行が誤ってインデントされていたり、行の幅が規定よりも2文字分オーバーしたりしていたことを、コードのレビュアにあら探しのように指摘された時にイライラしたのは、私だけではないでしょう。しかし、みんなが同じ規約に従ってコードを書いていたので、ソースコードを読むのは非常に楽な作業でした。それに社内でチームを移った時や部門間に渡るプロジェクトに携わった時に、新たな規約を覚えなければならないというようなことは、ほとんどありません。こういった規約は小規模なチームでは無視されがちですが、コードベースやチームの規模が大きくなると、変更するのに多大な労力がかかるので、ある程度の一貫性が求められます。そのため、できれば早いうちに一貫性のある規約を定めるか、Googleが公開している スタイルガイド の利用をお勧めします。

コードレビューによるコード品質の向上

コードレビューを必須化し、コードを変更するたびに変更箇所に対してレビューを行うようプロセスに組み込むと、作業速度は落ちますが、コードの品質の最適化を図ることができます。新入りのエンジニアも自分に必要なフィードバックを受けると、ベストプラクティスを身につけ、コードの品質を許容レベルにまで高めることができました。また全体的な傾向として、より品質の高いコードを手本にした新入りのエンジニアは、初めからよりきれいなコードを書いていました。ですから、コードレビューはGoogleが大規模で高品質なソフトウェアを維持する手助けとして有益なものでした。

正しい（かつ大量の）データによる問題解決

Googleの研究本部長であるピーター・ノーヴィグは、複雑な問題の解決に当たって「データの理不尽な有効性」についてよく話をしてきました。 ^(6) ^(7) 正しいデータによってユーザの理解を助け、社内政治をかわし、議論も解決し、進捗を見ることができます。SawzallやMapReduceのようなロギング・インフラストラクチャやデータ・インフラストラクチャを開発することによって、Googleのエンジニアは大量のデータをふるいにかけることができたのです。

テストを自動化してコードを調整

Googleにはユニットテストをとことん行う文化があり、Googleが公開している取り組み“Testing on the Toilet”は、それをよく物語っています。私が取り組んだほぼすべてのコード変更は、ユニットテストが実施され、コードレビュアの厳しいチェックが入りました。そのせいで、コード変更への対応は遅くなりましたが、一方で何千人ものエンジニアが品質や信頼性を犠牲にすることなく、コードベースの同じ部分に対して拡張性のある変更を加えることができたのです。テストケースの作成をより容易にするため、Googleは共有ツールと同じように、共有可能なテストフレームワークと、テストのベストプラクティスを広く普及させるための教育にも非常に力を入れています。

後に私はOoyalaとQuoraでプロダクト構築やチームの立ち上げを手伝いましたが、Googleで機能していた（また機能していなかった）プラクティスを振り返った時、 何がいいエンジニア文化を作るのか について深く考えました。Googleの基準で機能していたある決定内容が、異なる成長過程にある別の組織でも機能するとは限りません。あらゆる技術的な決断は妥協の上に成り立っており、Googleのエンジニアリング文化は、そうした妥協の一例を見せてくれます。

この記事は私がQuoraで書いた アンサー を編集したものです。