Google　Depveloper Day Tokyoには行けなかったが、
Google Developer Day 2007 東京のセッション公開ビデオまとめ
でYoutube動画が見れる。便利になったものだ。

その中でも、鵜飼さんのGoogle Engineerの話は大変興味深かった。
へ～たさんの
Google のソフトウェア・エンジニアリング
がよくまとまっていて、参考になった。

Googleの技術者の話は有名なので、知っている部分もあったけども、
非常に興味深い部分を何個かピックアップしてみた。

プロジェクトはたくさんある。多分、エンジニアの数以上にある

私たちが使っているGoogleのプロダクトはごく一部ということですね。
社内ツールなどのプロジェクトもあるとは思うけども。
やはり数を打たないと当たりはでないということですかね。

売れるかどうかは考えない。それがたくさんの人に使ってもらえそうかどうかが大事。社内のデモ・サイトで使われなかったり、Google Labs で人気が出ないヤツはまずダメ

ここは激しく同感です。インターネットビジネスの場合、まずは利用者
を増やすのが重要ということ。収益化は人がいればある程度は
なんとかなるものだし。

  • アイデアが出たら、Design Doc と呼ばれるドキュメントを書く
  • イノベーション重視。デザイン・フェーズで方向性が決まったら、さっさとコーディング
  • 社内デモ・サイトを立ち上げる(デモ・サイトは、社内ポータルからリンクされる)。デモができれば、他の人から意見を貰えて、そこからさらに、どんどんと改善していける
  • 社内デモで改善を重ねた後、Google Labs (βリリース)へ
  • Google Product として登場!

このスピード感がうらやましい。普通の会社なら、上司を説得するための
資料を作ったり、収益表を作ったり。。。というプロセスが必要なんでしょうが、
まずは作ってみるというところから、また新たなアイデアにつながるのでは
ないか。

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

エンジニアも昇格すると得てして、管理業務に追われたりもするが
Googleでは逆なんですね。経験あるエンジニアが現場にいて
実際に動いていることは後輩のためにもなるし。

Google のエンジニア評価

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

自社サービスをやっているエンジニアの評価は難しいが、
この方法だと納得感も高いのかなと。

Google のエンジニア気質

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

同感です！
Googleに優秀なエンジニアが集まるのは、やっぱりエンジニアの心を
とらえる環境が揃っているからなんでしょうね。

とはいえ、一貫して思ったのは、個人力に依存しているということ。
ひとりで状況を切り開けない人には、厳しい職場と言えると思います。

blogranking←ぽちっとな