パスワードを忘れた？ アカウント作成
Close
15670 story
Google

Googleのソフトウェア・エンジニアはこんなことをしています 76

ストーリー by yoosee
動くものを作ってナンボ! 部門より

highness 曰く、

5月31日に開催されたGoogle Developer Day 2007で鵜飼文敏氏が行ったセッション「Software Engineer in Google」の書き起こしとして、へ〜たのめも：Google のソフトウェア・エンジニアリングという記事がポストされています。 Googleの待遇や業務方法などは今まで色々な形で報道されていますので、20%ルール(全てのエンジニアは、20％の時間を自分が重要だと思うプロジェクトに費すことが出来る)など有名なものも含まれていますが、目新しいものも多く、非常に興味深い内容だと思います。
エンジニアの皆様、Googleのソフトウェア・エンジニアの仕事を見てどんなことを感じましたか? ぜひ御意見をお聞かせください。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • 真似できるところとできないところ (スコア:5, 興味深い)

    by Anonymous Coward on 2007年06月14日 20時39分 (#1173747)
    人材も資金も「富豪的に」使ってるなぁというのが第一印象。「20％ルール」とか「売れるかどうかは考えない」とか、真似しようと思って真似できそうな企業は、MSとIBMくらいだろうな。自社で使うものを自社で開発してる強みもある。

    社内コミュニケーションが円滑で活発だというのは、どこの会社でも少なからず取り入れられる点だと思う。他人が作った/作ろうとしてるものにバンバン口を出す（どころかパッチまで投げる）という風潮はすごく生産的。そこまでいかなくても、社内で他の人が何をやっているのか把握する/把握できるってのは画期的だと思う。

    • Re:真似できるところとできないところ (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2007年06月14日 21時45分 (#1173796)
      続く「それがたくさんの人に使ってもらえそうかどうかが大事」であってこれは売れるた物の種であり紙一重。
      つまり「売れるかどうかは考えない」とは技術者が素人マーケッターごっこは止めろとも読める。

      この部分が一番感じ入って
      ・社内のデモ・サイトで使われなかったり、Google Labs で人気が出ないヤツはまずダメ
      という、高度な職人同士の評判で決まる思いの外厳しい世界かも知れない。
      シェア
      親コメント
    • 本当にそうかな。「売れるかどうかは考えない」は別にしても、少なくとも「20％ルール」は実現しようと思えば実現できるのでは？
      単純計算で8時間の20パーセントって、2時間切るくらいでしょう？

      • Re:真似できるところとできないところ (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2007年06月14日 21時05分 (#1173769)
        え？ 2時間好きに使っていいって？
        んな暇あったらサビ残してねぇよ

        ってなりそうだ
        シェア
        親コメント

      • Re:真似できるところとできないところ (スコア:2, すばらしい洞察)

        by pick (6811) on 2007年06月14日 22時10分 (#1173810)
        20%違うことをやることではなく、Googleの場合、20%違うことをやらなければならない、 20%分も評価対象になると聞いた気がします。 個人的なものではなく、企業の姿勢としてそこが大事なのだと思います。
        シェア
        親コメント
        • >個人的なものではなく、企業の姿勢としてそこが大事なのだと思います。

          結局、企業側からは「今あるプロジェクトだけをやるのではなく、別の視点を取り入れたものを作ってほしい」というわけなんでしょうか？

          つまり、別の分野に足を突っ込んでそれをフィードバックさせることを望んでるのではないかと
          シェア
          親コメント
      • 自主的に50%ルール作って実践しています(ぉぃぉぃ

        #多分冗談なのでID
        シェア
        親コメント

      • 分量の問題ではなくて契約の問題ではないかと。完全に自社開発で固定の顧客が存在しない仕事ばかりの職場であればいいのでしょうが、他所から仕事をもらってきている会社や、自社開発でも固定の顧客が存在して人月単位とかで開発費を頂いているようなケースではまず不可能です。

        そもそも日本は純然たるソフトウェアベンダー自体が少ないからなー。。。

        --
        むらちより/あい/をこめて。
        シェア
        親コメント

      • Re:真似できるところとできないところ (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2007年06月15日 0時50分 (#1173896)
        > 単純計算で8時間の20パーセントって、2時間切るくらいでしょう？

        「20%か。うちだと5時間ぐらいだな」と上司が言うんです。
        シェア
        親コメント

      • Re:真似できるところとできないところ (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2007年06月15日 1時10分 (#1173905)
        /.を読むのを止めれば、20%とはいかなくとも5%くらいは捻出できるんだよな、と気づいてしまった訳で...oTL
        シェア
        親コメント
      • > 少なくとも「20％ルール」は実現しようと思えば実現できるのでは？
        いや、「実現しようと思えば実現できる」といいだすと大概のことはできるという結論にならざるをえないんですが、「20％ルール」はなかなかできるもんじゃないと思いますよ。

        就業時間のうち20%=1/5なわけで、固めてみると月から木まで仕事して、金曜日は好きなことしていいってわけでしょう？ 世間で週休三日なんて制度の会社がほとんどない現在、そう簡単に実現できるとは思えません。

        • Re:真似できるところとできないところ (スコア:2, 興味深い)

          by TarZ (28055) on 2007年06月14日 21時14分 (#1173774) 日記
          そうかなあ。デスマ中でもなければ十分実践可能じゃないですかね。

          むしろ、「普段から100%の力で仕事している」というのが事実なら、
          体力的にも精神的にもきつくないですか？

          ほとんどの人は、現在の職場のままでも20%の余力をヒネり出すことは
          可能だと思うし、今の職場でそれができないというのなら、職場を変えたと
          しても（それこそGoogleに転職したとしても）やっぱり難しいと思いますよ。
          シェア
          親コメント

          • Re:真似できるところとできないところ (スコア:2, すばらしい洞察)

            by juli (26219) on 2007年06月15日 9時32分 (#1174024)
            そもそも 20% ルールの意義は、「イノベーション重視」、「基本的にボトムアップ」などの企業方針から来ているものでしょう。
            就業時間の 1/5 を自由時間として良いというルールは、あくまで Google という組織のためのものだと思います。
            確かに技術者のモチベーションやスキル向上という効果もあるでしょうがそういう側面だけでなく、組織全体への貢献がそこに無ければ実施する価値はないのでしょう。

            つまり、真似すると言っても、20% ルールでの時間を役立たすことのできる技術者が集り、それをイノベーションに繋げられるだけの枠組みを持つ組織でなければ意味がないのではないでしょうか。

            そう言う意味で IBM はありそうですが、IBM の力はどちらかというとトップダウンで発揮されているイメージなので微妙かもしれません。いや、IBM にもそういうベンチャー気質なところがありそうにも思えますね。(根拠無しの主観です……)
            シェア
            親コメント
          • デスマーチ中と仮定する・・・
            1日16時間×31日の20% ⇒ 約100時間ですね
            シェア
            親コメント
        • とりあえず、サイボウズが50%ルール [cybozu.co.jp]を実践しています。
          20%ならまだ分からないでもないですが、50%ともなるとどうやって実現してるのかすごく気になるところです。
          シェア
          親コメント

        • Re:真似できるところとできないところ (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2007年06月14日 22時18分 (#1173815)
          Googleに行くような人は
          好きなこと＝技術で遊ぶこと
          だったりするんじゃね？
          そういうのを禁止するのは非効率的だと思う。
          シェア
          親コメント

        • Re:真似できるところとできないところ (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2007年06月15日 4時34分 (#1173952)
          そうではなく、自分自身をマネジメントして「20%は現在の業務と関係ないことを出来るようにせよ」ということですよね。
          月ー金の内一日を割り当てるか、毎日毎日、少しずつ時間を捻出するかは、社員に任せられていて。

          そもそも「20%ルール」を「一日は休日」なんて読んでいる時点で、伝わっていないのでは・・・
          当然、20%ルールに関しても評価されるわけでしょうし。
          シェア
          親コメント

        • Re:真似できるところとできないところ (スコア:1, 興味深い)

          by Anonymous Coward on 2007年06月15日 11時26分 (#1174119)
          技術職が勤務時間の100％をひたすら実装だけに時間をかけているようならその会社、人間はつぶれますな。
          10％から30％は技術の取得に当てないと新しいものについていけなくなったりする。

          出来る人のほとんどは自腹を切って勤務時間外で身に着けているわけで、デスマってくるとそれも上手く回らない。
          改善や提案が出来ない企業はつぶれるでしょう。

          そうして受託開発をやめ、楽をできる偽装請負ばかりになっていくのです。技術力は求められない、むしろ低いほうが喜ばれる、と。
          結果、技術者が消えていくのです。
          シェア
          親コメント
  • 全般的に賛同できるし、個人的に目指しているところに非常に近いですね。
    ただ、だから「Googleいいな、転職したい！」とはストレートには思わない。

    Googleならよりよい職場ではあるだろうけど、大部分は今の職場でも実践
    できることだと思います。（とはいえ、いくつかは自分の職場で実践して
    いるものの、自分と同等の技術者が多くいないとなかなか難しいところも
    あり。そこは正直羨ましい）

    よく働き、よく遊ぶ
    ここ、テストに出ますね。;-)

    なにより高いモチベーションが持続する環境じゃないと、良い仕事はできない。
    でも、「今の職場はダメダメだから…」で逃げちゃだめ。ダメな職場なら、自分
    から率先して「よく遊ぶ」。

  • 自分の状況と比べて一番の違いは、 (スコア:4, 興味深い)

    by maoyam (16680) on 2007年06月14日 22時07分 (#1173809) 日記
    ます、導入すること自体が無理だなって思うのは、
    “単体テストはプロジェクト横断で実施する部隊が存在し、動かないと「直せ」といえる”
    という点ですね。単体テストは開発担当がやっているものとしてエビデンスの整合性を目視確認するだけで精一杯なテスト部隊が現状です。

    これをやれないのがGoogle式と現状の大きな違いだな、と思ったのは、
    “他人のプロジェクトでも構わずにバグを見つけてパッチ書いて送りつける。”
    という点ですね。その次に大きい違いは、
    “プロジェクトは2～6名程度の規模で、詳細を別に書き出さなきゃいけない場合は別のプロジェクトにする。”
    ってところですね。

    ここからここまでが俺のプロジェクトって意識をエンジニアが持ちすぎているのは、作業の実質が2次請け以下の下請けさんに分割して投げなれていることと、その下請けさんにぶら下がっている派遣さんが“決められた仕事の分だけをキッチリやらせていただきます”となってしまっているからでしょうね。

    改良できるアイデアを実装してみて他人のレビューを受けるなんてことをフツウにスムーズに実践するまでに、いくつもの垣根や障害を取り払わなければならない。実践する頃にはアイデア自体が陳腐化してしまう。
    それでも、よりよいものを作り出さなければ利益が減るのは確実で、どうにかしなきゃならない。
    では、調整と管理を強化して効率的なプロジェクト遂行をしようなんて生涯を増やすだけの後ろ向きな動きが勢いを得てしまう……
    こんな現状で、20%を関係のないプロジェクトに力を振り向けても、新しいアイデアには結びつきにくいでしょうね (アイデアよりも自分の興味を満たすだけで空費されるでしょう)。ヘタすると、アイデアを思いついても出さずにおいて起業されかねないなんて余計な危惧を管理層に抱かさせるかもしれませんし。

    底には、大きさが決まったパイの再割り当てとしてしか機能・発想しない日本のソフトウェア屋さんと、新しい市場やリソースを開発して競合社が分割するという機能を担っている亜米利加のIT屋さんの違いもあるでしょう。

    ※エライやつはエラクないやつより多くのコードを書け！ってのは、是非とも日本に取り入れるべきルールですね。

    • 日本式だめっすよ～ (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2007年06月15日 0時05分 (#1173873)
      ＞※エライやつはエラクないやつより多くのコードを書け！ってのは、是非とも日本に取り入れるべきルールですね。

      違う違う、強制されてやったら意味がないｗ

      コードを多く書いている奴が尊敬される
      もっと極論するとコード書けない奴は偉くない。
      (あと屑コードを書く奴は屑、と)

      こういう企業風土が必要なのでは。

      # 寧ろどこまで上に行っても甘える場所のない戦場とも・・・
      シェア
      親コメント
      • いや、マジレスすると上の人の仕事はコードを書くことじゃないでしょ。
        自社パッケージ開発オンリーだったらまだしも・・・。

        資金を何とかしたり、社員にヒアリングして興味を持ちそうな仕事取ってきたり、
        優秀な助っ人を引っ張ってきたり、プロジェクト全体の段取りをキッチリしてたり、
        そういう仕事こそをしっかりして欲しいです。

        受託開発メインの会社の場合、「コード」レベルの問題でピンチになることは
        ほとんど無いですので。
        --

        --- （´-`）｡oO(平和な日常は私を鈍くする) ---
        シェア
        親コメント

        • Re:日本式だめっすよ～ (スコア:1)

          by techstrom (23460) on 2007年06月15日 14時09分 (#1174240)
          > 資金を何とかしたり、社員にヒアリングして興味を持ちそうな仕事取ってきたり、
          > 優秀な助っ人を引っ張ってきたり、プロジェクト全体の段取りをキッチリしてたり、
          > そういう仕事こそをしっかりして欲しいです。

          Googleではこういうのは上ではなく横の人がやってくれるってことですかね。
          技術者は生涯一技術者としてやっていけると。

          マネージャとエンジニアは違う職種なのに、レベルあがるとクラスチェンジしなきゃ
          ならんってのが多いですからね。

          そういった意味では、Googleってエンジニア以外の人たちってのもものすごい
          人たちなんでしょうね。
          シェア
          親コメント

    • Re:自分の状況と比べて一番の違いは、 (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2007年06月14日 23時04分 (#1173850)
      ＞※エライやつはエラクないやつより多くのコードを書け！ってのは、是非とも日本に取り入れるべきルールですね。

      間違いなくコピペだらけのコードが横行しますな。
      シェア
      親コメント

    • Re:自分の状況と比べて一番の違いは、 (スコア:1, 興味深い)

      by Anonymous Coward on 2007年06月14日 23時53分 (#1173870)
      いまだにウォーターフォールモデルで開発しているので、改良案を出しても
      「もう決まったことだから」「今から全体の合意を取れない」と却下され、
      若いころは悶々としていました。
      結局客先からの改良要望に対してのみ四苦八苦して修正している現実。

      今は自分のプロジェクトの中にだけ、工程に改良期間マージンをこっそり入れて対応してます。
      いくら上流設計に力を入れても、動かしてみてはじめて分かる問題というのは消しきれないよ。
      シェア
      親コメント

  • で、成果物は？ (スコア:0, 興味深い)

    by Anonymous Coward on 2007年06月14日 22時51分 (#1173835)
    天才ばかり集めて、すばらしいプロジェクト管理をしてると素直に思うのですが、成果物はどうなんでしょうねえ。
    どうもイマイチな成果物 [google.com]が多い気がするのは、私が天才についていけてないからでしょうか

  • ヲヒヲヒ (スコア:0)

    by Anonymous Coward on 2007年06月14日 23時30分 (#1173860)
    Video [youtube.com]があるってばさ。
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人