Team Geek ―Googleのギークたちはいかにしてチームを作るのか

  • オライリージャパン
4.03
  • (107)
  • (163)
  • (67)
  • (11)
  • (2)
本棚登録 : 1464
感想 : 119
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (228ページ)
  • / ISBN・EAN: 9784873116303

作品紹介・あらすじ

複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しない。全員が最終目標に向かって協力することが重要であり、チームの協力はプロジェクト成功のカギとなる。本書は、Subversionをはじめ、たくさんのフリーソフトウェア開発に関わり、その後Googleでプログラマを経てリーダーを務めるようになった著者が、「エンジニアが他人とうまくやる」コツを紹介するものである。「チームを作る三本柱」や「チーム文化のつくり方」から「有害な人への対処法」までエンジニアの社会性について、楽しい逸話とともに解説する。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • リモートワークについて調べていたところ、本書の存在を知った。リモートワークに限らず、チームで働くということ、チームメイトとの関わり方について書かれているようだと分かり、興味を持って購入。

    6章からなる本書。構成は分かりやすく、展開も自然。個人の話から始まり、組織への話が展開される。その後、外部のユーザについて言及し、完結となる。非常に読みやすく、自分に当てはめて考えやすい。

    想定している読者はソフトウェアエンジニアとのこと。技術的なことではなく、ソフトウェアエンジニアとしての在り方について学びたい人にはオススメの一冊。

    自分自身、これまでのキャリアを振り返った時、本書で書かれていることを実践できていたらもっと上手く立ち回れていたかもしれない、と思わされた。

    とは言え、新参エンジニアがいきなり読むべきかと言われたらちょっと早すぎるかもしれない。幾ばくか経験を積んだエンジニアがさらなるレベルアップを実現するための書籍と言った印象。

    挿絵が多いので、見た目以上に分量は少ない。かつ、ウィットに富んだジョークや海外特有の言い回しを学べるという点でもユニークな一冊。

    (書評ブログの方も宜しくお願いします)
    https://www.everyday-book-reviews.com/entry/%E8%A6%81%E7%B4%84%E6%8A%9C%E7%B2%8B_TeamGeek_%E3%83%96%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%95%E3%82%A3%E3%83%83%E3%83%84%E3%83%91%E3%83%88%E3%83%AA%E3%83%83%E3%82%AF_%E3%83%99%E3%83%B3%E3%82%B3

  • チームでのソフトウェア開発をどうやって上手にやっていくか?についてのアドバイスが沢山書かれていて面白かった。
    チームリーダーはどう動くべきか?逆にアンチパターンは?チーム内に困った人がいたらどう乗り越える?とか、ユーザビリティを大事にしよう!…などなど盛りだくさんな内容。
    ソフトウェア開発以外の生活でも、組織で働く上で知っておいて損はないアドバイスが多い。

    本当になんか色々アドバイスが書いてあって全部覚えきれないけど、とにかく「HRT(謙虚、尊敬、信頼)」と「ソフトウェアは自分や会社のために開発するのではなく、ユーザーの生活を豊かにする為に開発する」って事だけ胸に刻んでおけば、この先楽しく仕事できそうだなと感じた。

  • プロダクトは一人で作ることもできるが、
    大きな成功を成し遂げるためにはチームで開発する必要があると思っている。
    それは理論的にも、数値的にも、
    一人よりも10人のほうが成し遂げられることは多いはずだから。

    現実はなかなか難しく、とは言え一人より多人数のほうがやれることは多い。
    だがそのためには越えなくてはいけない壁も多く、また欲は尽きない。

    そんな中で自分がいるチームを最高のものにしていきたい。
    それは生産性や品質というだけでなく、
    一緒に働いている仲間の楽しさや幸せという意味で最高のものになったらいいだろう。

    現状を振り返りながら考える時間と、そのための学びと示唆を与えてくれた気がする。
    問題は多く尽きないが、一緒に働いている人たちと、いいチームが作りたいと思えた。

    (以下抜粋。○:完全抜粋、●:簡略抜粋)
    ○あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。(P.15)
    ○コンフォートゾーンの外側に自分の身を置くのである。
     自分よりも大きな魚のいる金魚鉢を見つけ、
     彼らの助けを借りて何でも挑戦していくのである。(P.25)
    ○チームの文化の定義・維持・防御に責任を持つのはチームメンバーだ。(P.34)
    ○まずは最悪なミーティングから紹介しよう。スタンディングミーティングだ。
     このミーティングは毎週開かれる。
     1人ずつ状況(何か重要なことがあるかどうか)を報告していくのだが、
     時間のムダだし、目が回るし、死にたくなってくる。(P.45)
    ○ミーティングを開くときの5つの簡単なルールがある。
     1. 絶対に必要な人だけを呼ぶ。
     2. アジェンダを作ってミーティング開始時に配布する。
     3. ミーティングのゴールを達成したら時間前でも終了する。
     4. ミーティングを順調に進める。
     5. ミーティングの開始時間を
     強制的に中断される時間(お昼休みや終業時間)の前に設定する。(P.47)
    ○コメントはコードのなぜを説明するものであり、
     コードが何をしているか説明するものではない。(P.54 )
    ○TLは、プロダクトのすべて(あるいは一部)の技術的な方向性に責任を持つ。
     TLMは、それに加えてチームにいるエンジニアのキャリアや幸せにも責任を持つ。(P.67)
    ○サーバントリーダーはチームにアドバイスを与えるだけでなく、
     必要であればチームが順調に進めるように穴を埋める。
     自らの手を汚すのがサーバントリーダーだ。(P.70)
    ○チームに5人のエンジニアを採用するときは、
     大量の応募者をふるいにかけてから、40~50人に面接して、
     上位5人を採用基準と関係なく採用することが多い。
     これは最速でダメなチームを作るやり方だ。(P.74)
    ○チームの幸せを追い求めるためには、
     1対1のミーティングのあとに「何か必要なものはある?」と質問するといいだろう。
     詳細を知るためにはもっと調査が必要だが、
     チームメンバーが生産的で幸せになるために必要なものを簡単に把握できる。
     1対1の面接の後に必ずこの質問をするようにしておけば、
     いずれ長いリストを持参するようになるだろう。(P.87)
    ○      興奮          退屈
    自発的    スイートスポット    マンネリ  ↑ 方向性
    注意散漫   見て!リスだ!     漂流    ↑ が必要
            ←← モチベーションが必要(P.92)
    ○数年後、彼の予言は的中した。
     それでも、Subversion は大きな成功を収めた。
     少なくとも企業では広く使われるようになった。
     誰が正しいか間違っているかではなく、結論にたどり着くかどうかが重要だ。
     いずれかの時点で損切りをして、前へすすまなければいけないのである。(P.105)
    ○短期的なメリットのために文化を妥協する必要はない。
     HRT の重要性を認めない「頭のいい」コントリビュータには気を付けよう。(P.116)
    ●マネージャーの仕事を楽にできる簡単なことがある。(P.122)
     (中略)
     自分の責任範囲を広げよう。(P.123)
     (中略)
     リスクをとろう。(P.123)
     (中略)
     物わかりのいいマネージャのいるところで失敗すれば、
     すばやく学習できるし、何ができて何ができてないのかがわかるし、
     時間をかけて成長していくこともできる。(P.124)
    ○悪い習慣をやめることはできない。
     よい習慣と置き換えでなければいけない。(P.134)

  • 謙虚さは、どの職種でも必要と感じる一冊

  • ギークに限らず、ナードも、ビジネスマンも、みーんな皆んな、読むべき本だ。

    一生懸命夢中になってやりたいことがある人ほど、周囲・環境とうまくやることが疎かになってしまいやすい。そんな時に改めて気をつけるべき3つのポイント(HRT)について触れている。というか、それを懇切丁寧に語ってくれている。

    マネジメント本と思って読んでも良いけれど、よくあるビジネス書のように堅苦しく無い。エンジニアだったら「あるある」と親近感を抱きやすい。エンジニア向けビジネス書と言ったほうがしっくりくるかも知れない。

    でも、この本は誰もが一度は手にして欲しい。
    私は愛蔵書の一つになりました♪

  • 最初に手に取っていれば高評価だったと思うが、
    カイゼンジャーニー、エンジニアリング組織論への招待、Google reworkあたりを読んだ後だったので、「あーわかるわかる」という凡庸な感想になってしまった。

    HRTはエンジニアに限らず、誰と働くにしても必要かつ重要なマインドだと思う。

  • リーダーにカリスマは必要ないが、向き不向きはあると思う。向いていると思う人がリーダーシップの技術を学ぶには適している。結局平社員がいくら頭をひねっても日本の組織(中小)ではどうにもならない。それは慣性の法則同様、変えようがない。それに嫌気がさして転職しても日本株式会社の中では配置転換程度の意味しかない。前半部分はマネージャーを否定しているが、後半で昇進のメリットを強調している。

  • 創造的な仕事にマネジメントは不要。必要なのはリーダー。PMBOK のようにマネジメントの体系化が一番進んでいる IT 業界にいて、意外な気付きだった。

    本書は、謙虚、尊敬、信頼のマインドセット "HRT" をひたすら説く内容となっている。また筆者がオープンソースプロジェクトに貢献してきた人物だけあり、オープンソースコミュニティからの知恵が多分に含まれる。Google のオープンな姿勢もきっと筆者たちの貢献の成果なのだろう。

    ミッションステートメントを書こう。そこには理想だけでなく、やらないこと、制約事項も明文化しよう。

    悪い人はいない。振る舞いがそぐわなければ、求める振る舞い方へ導けば良いだけだ。

    I (HRT) YOU.

  • ・文化は自分の手で丁寧に育てなければならない
    ・期待に応えない人をどうするかは非常に厄介。立ち去ってもらうのが一番…というのを読んで肝が冷えた。
    ・リーダーシップパターンは非常に参考になった。自力学んでもらうための勇気づけが大事。

  • Googleの良いチーム作り、良いエンジニアとしてのマインドセットなどを述べた本。
    ギークの軽快な語り口で、謙虚・尊敬・信頼のHRTをはじめとする素晴らしい文化醸成のヒントがある。
    振る舞いに問題がある人との接し方や、ユーザーとの接し方などを含め、エンジニアにまつわる人付き合いのやり方が参考になる点が多いと感じた。
    また、速く失敗してフィードバックループを回すという考えはマイクロソフトでもFail fastの精神で取り組まれているものと読み返して気付いた(世界一流エンジニアの思考法より)。
    人間関係にまつわる様々な取り組み方が書かれているが、いちばん重要なのはHRTとある。この考えを忘れずに、良い組織や製品づくりに取り組んでいきたい。

全119件中 1 - 10件を表示

Brian W. Fitzpatrickの作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
ジェームス W....
有効な右矢印 無効な右矢印
  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×