Google のソフトウェア・エンジニアリング

Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」

Google の研修

• 入社して最初の 3ヶ月は本社(Mountain View)で研修
• 研修中は、メンターがついて「Google での開発の仕方」を学ぶ
• 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習

Google のプロジェクト・チーム

• 開発拠点は米国、スイス、オーストラリア、インド、日本など
• 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム
• 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同じ人)が全部やる
• プロジェクトはたくさんある。多分、エンジニアの数以上にある
• チームは少人数 (2〜6人)。これ以上に増えると、プロジェクトのフォーカスを絞ってチームを分割
• プロジェクト横断的な共通機能(自動テスト、国際化など)は intergrouplet と呼ばれる「プロジェクトをまたがったアクティビティ」として活動

Google のソフトウェア・ライフ・サイクル

• 基本的にボトムアップ。エンジニアが「こういうのがやりたい」と思ったら、人を募ってプロジェクトにしていく
• 例の「20% ルール」。「とにかく 20% は、まったく違ったことをヤレ」ということになっている。他のプロジェクトに協力するとか、今までやったことの無いことをやるとかして、新しいアイデアを生み出す
• 売れるかどうかは考えない。それがたくさんの人に使ってもらえそうかどうかが大事。社内のデモ・サイトで使われなかったり、Google Labs で人気が出ないヤツはまずダメ
• アイデアが出たら、Design Doc と呼ばれるドキュメントを書く
• イノベーション重視。デザイン・フェーズで方向性が決まったら、さっさとコーディング
• 社内デモ・サイトを立ち上げる(デモ・サイトは、社内ポータルからリンクされる)。デモができれば、他の人から意見を貰えて、そこからさらに、どんどんと改善していける
• 社内デモで改善を重ねた後、Google Labs (βリリース)へ
• Google Product として登場!

Design Doc

• Google で必ず書くことになっているドキュメント
• プロジェクト立ち上げ時の 1〜2週間をかけて書く。ある程度ポイントが書け たら、もうコーディングへ。
• 一般的にはあんまり長くない。詳細を書かなきゃいけなくなったら、それ はまた別プロジェクトになることが多い
• Design Doc の内容
  • プロジェクトの背景、目的
  • おおまかな設計(コードを見ただけでは判らないような、アーキテクチャ)
  • プロジェクトの参加者(このプロジェクトに関して、誰に連絡を取ればいいのか)
  • セキュリティやプライバシーについての考察(問題と対処方法)
  • テスト、モニタープラン(運用時の考慮。障害の発見と復旧手法など)
  • レポジトリ上の位置やサーバのアドレスなど
• コードを書いていると解離していくので、できるだけ解離しないようにアップデート

Google のコーディング

鵜飼さんは普段、毎週 0〜20個のパッチを書く。年間 3万5千行くらい。シニア・エンジニアやフェローになると、もっと書いていて、Google では、偉い人ほどコードを書きまくっている。

• C++ (インフラ), Java(フロント・エンド)、Python(社内システム)が三大 言語。その他、Sawzall (Google 独自言語)、JavaScript、ActionScript も
• リポジトリは世界で一つ。チームごとにディレクトリを切ってあるが、全員が 全てのコードを見ることができる。
• 誰かが書いたコードは、必ず他の人にレビューを受ける。開発者とレビューアーがお互いに合意した時点で、はじめてチェックイン
• レビューは 2種類。プロジェクト・オーナによるレビューと、readability review (コーディング・スタイルを統一するためのレビュー)。言語ごとにレビューアーがいて、誰が書いても同じコーディング・スタイルになるようになっている
• ユニット・テストは必須。ユニット・テストを自動で実行するシステムもあり、テストが通らなくなると「直せ」とメールが飛んでくる
• "testing on the toilet"。テストに関する intergrouplet が、トイレの壁に「テストのコツ」を書いて貼っている。単体テスト普及活動の一環。

Google の開発方針

• 基本的に「自分たちで作る」。オープンソースは別階層のリポジトリに登録して、自分たちのコードとは区別。オープンソース以外のプロダクトは使っていないはず
• パフォーマンス重視(まず計測、とにかく計測、良いアルゴリズムの採用、コーディング・テクニックの積み重ね)。Google グラフ書くのが好き。数値化重要。
• スケーラビリティ重要(いずれは Google Product になるのだから当然)。たくさんのマシンで並列化できるように
• 信頼性(Google はマシンが大量にあるので、ハードウェアは毎日壊れる。レプリカを作ってデータは多重に持つ。障害監視と自動的な障害復旧に力を注ぐ)

Eric Schmidt の言葉「Don't accept anything less than beign the best」。

Google の情報共有

「創造的であるためには、情報は共有しなくてはならない」がモットー。コミュニケーションは活発で、プロジェクト内はもちろん、プロジェクト間の壁もあまり無い。

• 様々なデータベース

  プロジェクト DB

  プロジェクトの内容、誰がやっているか、進捗を一覧できる

  アイデア DB

  何かアイデアを思いついたら登録。アイデアのレーティングやコメントなど

  バグ DB

  問題があったときに登録、トラッキング

• 進捗は snippet (週報。何をやったか、何をするか)を書く。他の人が何をやっているのか、何で困っているのか、どんなウマイことやったのかを、全員で共有
• ドキュメントは、コードと同じくらい書く。マニュアルとか今後の方針とか頻繁に更新されるものは Wiki。最近は Google Docs & Spreadsheets に移行しつつある
• バージョン管理は Perforce。Guido van Rossum が書いたレビュー・システム Mondrian(ソースにコメントを付けられる)
• エンジニア同士のコミュニケーションは IM や ML
• 一部屋に 2〜4人。同じ部屋で開発。ちょっとしたバッドノウハウをすぐに後の人に聞けるので、個室よりもいい
• 食事の時間も例の無料社内レストランなので、そこも情報共有の場
• Tech Talk。エンジニアが自分の知っている技術的な内容を他の人にプレゼンテーションする。Mountain View ではほぼ毎日、日本でも可能な限り頻繁に。聞く方はもちろん、喋る方にもメリットがある
• ユーザ情報やプライバシー情報は共有されない(ほとんどのエンジニアは触れないように厳密に管理されている)

Google のエンジニア評価

• Objectives and Key result (四半期ごとに目標と達成度を書く。定量的な数字で書くことが推奨)を、個人、チーム、会社の単位で作っている
• コード・レビューした人の評価や、ML やビデオ会議での議論内容、Snippet も評価対象
• Google Resume と呼ばれる履歴書を書く。プロジェクト間を移り歩くときにも必要
• パフォーマンス・レビュー(評価面接)は年に二回。基本的に本人が指名した同僚が、その人を評価する。上司の評価だとパフォーマンス・レビューのときだけ巧く立ち周る人の評価が高かったりするけど、一緒に働いている同僚のレビューなので、日々の仕事がそのまま評価に反映

Google のエンジニア気質

• 自主的にやることを見つける。スキルも自分で身につける
• 上から「何をやれ」というのはまったくない。上司は「こういうプロジェクトがあるよ」とか「これはこの人に聞けばいいよ」とかルーティングしてくれるだけ。エンジニアの視点から見て詰まるところをうまくフォローしてくれるのが上司。
• 自分で改善すべき点を見つけて改善する。直すべきところを見つけて直す。「でも、それ僕のプロジェクトじゃないから」はダメ。不具合を報告するだけではなくパッチを書くことが推奨
• レビューが必須なので、個人プレイはダメ。チームでの活動が必須
• 変化についていく。Google 社内は変化が早い。社内システムの入れ変わりも早い
• よく働き、よく遊ぶ

Comments

1. Posted by rui   2007年06月08日 00:14

YouTubeをチラ見してこれは誰かがまとめてくれるだろうと思ったんですが、すごくわかりやすくてうれしいです。感謝！

2. Posted by 名無しさん   2007年06月14日 20:15

GJ!

3. Posted by 通りすがりの社員   2007年06月14日 22:32

先生、ちゃんと元の会社に帰って来てくださいよ・・・

4. Posted by groove   2007年06月15日 18:46

s/beign/begin

5. Posted by marinworld   2009年08月15日 07:00

初めてコメントします。この記事、とてもわかりやすいです。今後もグーグルさんには、しっかりとがんばってもらいたいです。グーグル様のことが大好きですからね。評価も最高にしておきますね。

6. Posted by ユッキー   2013年04月30日 20:35

はてなブックマークからきました

とても参考になりました

ありがとうございます

7. Posted by 毒舌野郎   2013年04月30日 22:01

なるほど

参考になりました

他の記事も拝見させていただきます

ありがとうございます

記事の更新期待しております

8. Posted by ネットで学ぶソフトウェア工学   2019年08月27日 21:50

ナイス纏めです。

なんかストレスが少なくて軽いところがいいっすね。

優秀な開発者が集まっているから、できるのかなー。

楽しそうだから、また優秀な開発者が集まってくるみたいな正のスパイラルになっていそう。