「Google のエンジニアはどうやって開発しているのか?」について、Google Developer Day Tokyoのプレゼンから書き起こしたブログ(へ?たのめも)がありました。Thanks!
そこから更に抜書き。
Google のソフトウェア・ライフ・サイクル
- 基本的にボトムアップ。エンジニアが「こういうのがやりたい」と思ったら、人を募ってプロジェクトにしていく
- 売れるかどうかは考えない。それがたくさんの人に使ってもらえそうかどうかが大事。社内のデモ・サイトで使われなかったり、Google Labs で人気が出ないヤツはまずダメ
ニーズを捉えて商品化せよ、と良く言うが、それはニーズが明白な追従商品だけ。今までに無い商品は、シーズベースで「できるモノ」を提供し、その効用のプロモートも一緒に提供する必要があるのでしょう。
Google のエンジニア評価
- Google Resume と呼ばれる履歴書を書く。プロジェクト間を移り歩くときにも必要
- パフォーマンス・レビュー(評価面接)は年に二回。基本的に本人が指名した同僚が、その人を評価する。上司の評価だとパフォーマンス・レビューのときだけ巧く立ち周る人の評価が高かったりするけど、一緒に働いている同僚のレビューなので、日々の仕事がそのまま評価に反映
Google のエンジニア気質
- 自主的にやることを見つける。スキルも自分で身につける
- 上から「何をやれ」というのはまったくない。上司は「こういうプロジェクトがあるよ」とか「これはこの人に聞けばいいよ」とかルーティングしてくれるだけ。エンジニアの視点から見て詰まるところをうまくフォローしてくれるのが上司。
- 自分で改善すべき点を見つけて改善する。直すべきところを見つけて直す。「でも、それ僕のプロジェクトじゃないから」はダメ。不具合を報告するだけではなくパッチを書くことが推奨
エンジニアとしてのエンプロイアビリティ(雇用されるに値する能力)を評価しているようですね。自分のプロジェクトに誰も賛同してくれなかったり、また他のプロジェクトに応募しても落選したりすると、Googleを去るのでしょうか。
他人のパッチも提供すると言うのも面白い。Plan-Do-Seeのプロセスで、DoがないPlanは意味が無い。Seeだけでもダメ。「指摘するだけでなく対案を出せ」という感じでしょうか。
* * *
次の事業ネタを出すために、広告業で稼いだ潤沢な資金で最高の環境を用意して、最高の頭脳を活用している、という感じですね。至極真っ当なアプローチと感じます。
また、既存企業が簡単に真似ができない手法を取っているのも見事。普通のソフトウェアorサービス企業が、全社を挙げてGoogleのシステムを導入したら会社が持ちません^^;
でも、Googleから学び取って自社に活かしたい面もあります。「やりたい」と手を挙げることや、そのうちのいくつかを実現すること、自社のブランドと切り離して仮説検証すること、などは低いリスクで行えるのではと感じます。
コメントする