東京のセッション公開ビデオまとめでYoutube動画が見れる。Engineerの話は大変興味深かった。ソフトウェア・エンジニアリングがよくまとまっていて、参考になった。非常に興味深い部分を何個かピックアップしてみた。プロジェクトはたくさんある。エンジニアの数以上にある私たちが使っているGoogleのプロダクトはごく一部ということですね。社内ツールなどのプロジェクトもあるとは思うけども。数を打たないと当たりはでないということですかね。売れるかどうかは考えない。それがたくさんの人に使ってもらえそうかどうかが大事。人気が出ないヤツはまずダメここは激しく同感です。インターネットビジネスの場合、まずは利用者を増やすのが重要ということ。収益化は人がいればある程度はなんとかなるものだし。呼ばれるドキュメントを書くイノベーション重視。デザイン・フェーズで方向性が決まったら、さっさとコーディング社内デモ・サイトを立ち上げる(デモ・サイトは、社内ポータルからリンクされる)。して登場!このスピード感がうらやましい。普通の会社なら、上司を説得するための資料を作ったり、収益表を作ったり。いうプロセスが必要なんでしょうが、まずは作ってみるというところから、また新たなアイデアにつながるのではないか。0~20個のパッチを書く。偉い人ほどコードを書きまくっている。エンジニアも昇格すると得てして、管理業務に追われたりもするがGoogleでは逆なんですね。経験あるエンジニアが現場にいて実際に動いていることは後輩のためにもなるし。(四半期ごとに目標と達成度を書く。呼ばれる履歴書を書く。プロジェクト間を移り歩くときにも必要パフォーマンス・レビュー(評価面接)は年に二回。基本的に本人が指名した同僚が、その人を評価する。自社サービスをやっているエンジニアの評価は難しいが、この方法だと納得感も高いのかなと。自主的にやることを見つける。スキルも自分で身につける上から「何をやれ」というのはまったくない。上司は「こういうプロジェクトがあるよ」とか「これはこの人に聞けばいいよ」とかルーティングしてくれるだけ。エンジニアの視点から見て詰まるところをうまくフォローしてくれるのが上司。自分で改善すべき点を見つけて改善する。直すべきところを見つけて直す。「でも、それ僕のプロジェクトじゃないから」はダメ。不具合を報告するだけではなくパッチを書くことが推奨レビューが必須なので、個人プレイはダメ。