オープンソース - みる会図書館


検索対象: Team Geek : Googleのギークたちはいかにしてチームを作るのか
29件見つかりました。

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

42 ー 2 章素晴しいチーム文化を作る これってどういう意味たろう ? 何も言っていないよね。この会社で働いてい たら、ソフトウェアを書けばいいのか、水漏れを修理すればいいのか、ピザを 届ければいいのかわからない。こうしたわけのわからない事例がミッションス テートメントをダメにしている。 工ンジニアリングチームのミッションステートメントであれば、チームの方向 性を定義して、プロダクトのスコープを制限するだけでいい。 ッションステー トメントを書くには時間や手間がかかるが、やること / やらないことを明確にし ておけば、年単位で仕事の節約になる可能性もある。 数年前、 GoogIe が GoogIe Web TooIkit(GWT) の開発をオープンソースプロ ジェクトに移行すると決めたとき、ほくたちはチームのメンターになった。そ して、クローズドソース開発とオープンソース開発のさまざまな点を比較した。 なかでも、設計・議論・ソフトウェア開発の難しさに注目した。オープンソー ス開発では、誰もがプロダクトについて意見を述べたり、パッチを書いたり、 些細なことを批判したりすることができるからだすす。それが終わると、プロダク トが目指すこと ( と目指さないこと ! ) を外部に知らせるために ッションス テートメントが必要だとチームに伝えた。 ミッションステートメントと聞くと ( 先ほど説明したように ) 尻込みをするェ ンジニアもいる。だが、興味を持つ工ンジニアもいるし、チームリーダーがい い考えだと思うこともある。ただし、内容やスタイルについては議論が必要に なるだろう。何度も議論 ( とミーティング ) を重ねてから、 G のチームは簡 潔なミッションステートメントだけでなく、「 MakingGWTBetter 」と呼ばれる ドキュメントを記述した これはミッションステートメントをフレーズごと す すす こは超重要。集中するにはやらないことを決めるべきだ。 オープンソースソフトウェアの開発は、トランポリンでトランプの家を作るようなもの である。手が震えてはいけないし、忍耐力も必要だ。それから、トランポリンを跳ばう とする人に注意しなければいけない。 すすす「 Making GWF Better 」は http://code.google.com/webtoolkit/makinggwtbetter.html にある。ミッションステートメントの参考になるので読んでみてほしい。

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

はじめに一 XXVII 自分たちも講演するようになった。会社とオープンソースのプロジェクトの両 方で働いてみてわかったのは、ソフトウェア工ンジニアリングチームの働き方 に関する知識や逸話が自然と耳に入るということだ。そこからネタ的な講演を するようになった。うまくいかない開発プロセスの話から始まり ( 「 Subversion の最悪プラクティス」 ) 、最終的にはバカからチームを守るなんていう話まです るようになった ( 「オープンソースプロジェクトのための有害な人との付き合 い方」 ) 。参加者が増えていくと、ソフトウェア開発者のための「グループセラ ピー」のようになってきた。誰もがばくたちの講演内容と同じ問題を抱えてい て、みんなで愚痴を言い合いたいと思っていたのである。 それから 6 年後。ソフトウェア開発における社会的問題の話が山のように集 まった。講演はいすれも大人気で、立ち見が出るほどの盛況だ。 O'ReillyMedia の編集者 MaryTreseler から、これらの講演の内容を 1 冊の本にまとめるべき だと言われた。あとはご覧のとおりである。 対象読者 本書はソフトウェア開発者を対象にしている。特に上昇志向の強い人や優れ たソフトウェアを届けたい人だ。 CEO ・心理学者・「マネジメント」・コンピュー タサイエンスの理論家・電子基板にハンダ付けするような人は対象外とする ( 最 後の人は楽しめるかもしれない ) 。読者の前提条件としては、以下の 2 つを挙げ ・他のプログラマとチームで仕事をしている。会社で働いてるかもしれない し、オープンソースや学校のプロジェクトに参加しているかもしれない。 ・ソフトウェア工ンジニアリングを楽しんでいて、やりがいのある楽しい活 動だと信じている。借金の支払いのためにコードを書いているのであれば、 自己実現や仕事の満足度には興味がないかもしれない。

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

ェンジニアリングは簡単だ はじめに 人間は難しい。 BiII Coughran 人生は予測できない展開に満ちあふれている。ばくたちは 2 人ともソフトウェ アェンジニアリングに関する本を書くとは思っていなかった。 ほとんどのコンピュータギークがそうだと思うけど、ばくたちも大学を卒業 したあとに趣味 ( コンピュータで遊ぶこと ) で生計を立てられることがわかった。 同世代のハッカーと同じように、 1990 年代は余ったパーツで PC を作ったり、何 枚ものフロッピーディスクを使ってリリース前の Linux をインストールしたり、 Un ⅸマシンの管理方法を学んだりした。最初はシスアドとして働いた。それか らドットコムバブルの兆しがあるときに小さな会社でプログラマになった。バ プルがはじけたあとは、シリコンバレーの企業 ( Apple 社など ) を渡り歩き、ス タートアップ ( Co Ⅱ abNet 社 ) でオープンソースのバージョン管理アプリケーショ ンの設計・実装をすることになった。そのアプリケーションが Subversion だ。 2000 年から 2005 年の間に予測できないことが起きた。その頃も Subversion を作り続けていたが、仕事の責任がゆっくりと変化してきたのである。 1 日中 コードを書くのではなく、オープンソースプロジェクトをリードするようになっ ていた。つまり、ボランティアの十数人のプログラマと一緒にチャットルームで 過ごし、彼らが何をしているかに気を配ることになったのである。新機能につ

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

56 ー 2 章素晴しいチーム文化を作る スタイルガイドではそうした機能を挙げるどどもに、なぜ使用を制 限したのか、その理山についても説明しています。 Goog にか開発しているオープンソースプロジェクトは、このスタ イルガイドにしたがっています。 これは C + + のチュートリアルではないこどに注意してください。 読者は c + + についてよく知っているこどを想定しています。 28.2 ソ - スコードに名前を書く ( 別名 : 「 Autho 「タグ」問題 ) 一隹もが作品にクレジットを入れたがる。画家は絵画にサインを入れるし、作 家は背表紙に名前を入れる。プロガーもプログのトップに名前を入れている。 何とかして他人から認めてもらいたいというのが人間の本質だ。でも、ソース ファイルに名前を入れると、あくまでもばくたちの意見だが、百害あって一利 なしだ。たとえば、以下のような記述がソースファイルのトップに書かれてい るのを何度も目にしたことがある。 二一口 # Created: 0ctober 1998 by Brian W. Fitzpatrick く fitz@red-bean.com/ ソースコードのトップに名前を入れるのはもう古い ( 昔はばくたち 2 人もやっ ていた ) 。チームではなく個人でプログラムを書いていた時代はそれでよかった のかもしれないけれど、今では多くの人たちがコードに触れる。ファイルに名 前が書かれていると物議を醸すことになる。それは時間のムダだ。嫌な感情も 生み出してしまう。したがって、ソースコードに所有者としての名前を書くべ きではない ( レビューアとしての名前を書くのはいいが、その場合も所有権を示 すものではない ) 。 たとえば、チームのプロジェクトに新しいファイルを作ったとする。数百行

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

はじめに いては、メーリングリストで調整した。そのなかで気づいたのは、優れたコー ドを書くだけではプロジェクトは成功しないということだ。最終目標に向かって みんなが協力することが重要なのである。 2005 年から Google のシカゴ工ンジニアリングオフィスでプログラマとして 働くようになった。このときはすでにオープンソースの世界にどっぷり浸かって いた。 Subversion だけでなく、 Apache ソフトウェア財団 ( ASF ) にも参加する ようになった。 Subversion を Google の BigTable のインフラに移植して、オー プンソースプロジェクトのホスティングサービス ( SourceForge みたいなもの ) を GoogIe Code という名前でローンチした。 OSCON ・ ApacheCon ・ PyCon ・ Google I/O などの技術系のカンファレンスに参加するようになり、その後は ツ ' ログ、ラ、マ 優れたソフトウェアを書きたい ? 本書は君のための本だ

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

VII 推薦の言葉 心のギークの部分に訴えかける素晴らしい本だ ! バイスは読む価値がある。 ギークでなくても本書のアド Vint Cerf 私はエンジ二アとして 30 年間働いてきた。そこで学んだのは、エンジ二アは科 学や技術と同じだけ人間を扱うということだ。それなのに、誰かと一緒に働くこ との重要性を理解しているエンジ二アはほとんどいない。創作や発明を効果的か つ効率的にしたいなら本書を読むべきだ。 Dean Kamen Ben と Fitz はソフトウェア開発チームのバターンとアンチバターンを集めてく れた。本書はチームを生産的にしたい人のために書かれている。自分でコードの 世話をする人、その人たちのマネージャー、その周囲にいる人たちすべてが対象 だ。ここには優れたオープンソース開発者の本質が書かれている。数年前に欲し かった。 Brian Behlendorf

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

4.2 チームを強化する一 る振る舞いの基準を作っておけば、それが何年も続いていく。 IOI 著者の 2 人はオープンソースプロジェクトに長年携わってきたが、そこで得 た経験はこの考えと完全に一致している。 最も関わりのあるプロジェクト (Subversion) は、最初は小さなチームで始 まった。そこには、謙虚と信頼と尊敬の文化があった。 11 年も過ぎると世代 は 3 ~ 4 回ほど変わった ( 初期のメンバーの多くはいなくなった ) が、文化はそ のまま残っていた。みんな親切で、礼儀正しくて、お互いに期待する振る舞い をしている。文化が長続きしているのは、高い基準を設けているからではなく、 その文化が自己選択的だからだ。素晴らしい人たちは、素晴らしいコミュニ ティに引きつけられるのである。 自己選択的は逆方向にも作用する。攻撃的な連中がチームを作ったら、やは り同じような連中が集まってくる。終わりの見えない口論・威嚇・中傷・・ から 信頼 図 4-1 いせつな要 バランスの とれた職場 受け入れられない振る舞いの耐性を強化する 0 / - 2 ら

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

2.2 なせ気にかける必要があるのか ? ー こを重視しているのかがわかる。チームがどのように働いているのか、どのよ うにやり取りをしているのか、どのように問題に取り組んでいるのかを観察す ることで、チームの文化がわかるようになる。 強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防 御的だ。優れたチームの文化は、ソフトウェアを届けることに集中している。 それ以外 ( 飲み会・ミーティング・技術力向上など ) に集中しているのであれば、 チームの結東カは高まるかもしれないが、ソフトウェアを書くことにつながらな い。コードを書いたりプロダクトを届けたりすることが好きであれば、そのこと を大切にしているチームを見つけて、その環境を維持すべきである。強くて生 産的な文化がなければプロダクトを届けることができないというわけではない が、文化を作るには思っている以上に時間や労力がかかる。強い文化は、集中・ 効率・強度をなえる。それらがみんなを幸せにするのである。 チームの文化で興味深いのは、強固な文化を構築すると「自己選択的」にな ることだ。オープンソースの世界では、クリーンでエレガントで保守性の高い コードを書くことに集中すると、クリーンでエレガントで保守性の高いコードを 重視する人たちが興味を持ってくれる。敵対的でいじわるで個人を攻撃するよ うな文化のチームは、敵対的でいじわるで個人を攻撃するような人を引きつけ ることになる。 自己選択的な文化は、 Apache ソフトウェア財団 ( ASF ) で何度も目にしたこと がある。 ASF はコミュニティベースのソフトウェア開発チームの集まりであり、 合意モデルで運営されている。そのことを知ってか知らずか、新しいコントリ ビュータがメーリングリストに参加して、チームの文化に反する振る舞いをす ることがある。コミュニテイメンバーはその参加者を教育しようとするが ( もち ろん優しくね。ときには・・・・・・その、なんていうか、「優しくない」こともある ) 、 それでも ASF チームのやり方に納得できなければ、もっと心地のいいプロジェ クトを探しに行ってしまう。 会社では採用のときにチームが自己選択をする。応募者にスキルや強みがあ るかどうか、文化が合致しているかどうかを見極めるのだ。 Google では、文化

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

1 . 1 コードを隠して一 3 本書は、ソフトウェア開発の社会的危機について扱ったものだ。したがって、 君が確実にコントロールできる変数を取り上げたい。君自身だ。 人間は本質的に不完全である。だが、他人のバグを理解する前に、君自身の バグを理解しなければいけない。君自身の反応・挙動・態度をよく考えてもら いたい。そして、成功を収める有能なソフトウェア工ンジニアになるための方 法を身につけてほしい。そうすれば、人間が関わる問題にうまく対応できるよ うになり、優れたコードを書く時間がもっと増えるようになる。 本章で伝えたいのは、ソフトウェア開発はチームスポーツであるということ だ。ェンジニアリングチームで成功するには、自分が「謙虚・尊敬・信頼」の原 則に基づいて行動できているかを認識しなければいけない。 話を進める前に、プログラマがよくやる行動を見ていこう。 1.1 コードを隠して ばくたち 2 人は、過去 6 年間に何度もカンファレンスで講演を行ってきた。 GoogIe でオープンソース向けのプロジェクトホスティングサービスを 2006 年 に立ち上げたメンバーなので、プロダクトに関する質問やリクエストをよくいた だく。 2008 年の中頃に話を戻すが、そうしたリクエストには特徴的な傾向があ ることに気づいた。 Goog に code の su ト version でプランチを隠せるようにしてもらえませ んか ? 最初はコードを非公開にして、準備ができたら公開できるようにな りませんか ? スクラッチからコードを書き直したいので、履歴を削除してくれま せんか ?

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

推薦の言葉ー IX ソフトウェアは人で成り立っている。本書にある原則を使ったチームは、個人の ハッカーよりも深く考え、よりコードを書き、多くのソフトウェアを届けてい る。汝、これを学ぶべし ! 」 ohnathan Nightingale fTeam Geek 』はプログラマのための『人を動かす』だ。技術チームが幸せに生 産的で効果的になるためのアドバイスが満載である。どれも明快ですぐに実行で Ben と Fitz は、これまで私が実践してきたが、言葉にしていなかったことを きる。素晴らしい。これそ求めていたものだ。 語っている。 FreeBSD コアチ 3 月までに Adrian HOIovaty Guidovan Rossum PouI-Henning Kamp ームの Poul-Henning Kamp に 1 冊送ってほしい。 1994 年 Ben と Fitz は孤独なプログラマを賞賛していない。彼らは最も複雑なシステム をハックする方法を教えている。そのシステムとは人間だ。人間味のあるソフ トウェアは優秀なチームが作っている。 fTeam Geek 』はその方法を示したも のだ。 」 ohnToIva ソフトウェア開発の社会学について書かれた素晴らしい本だ。本書はオープン ソースソフトウェアと大企業に重点が置かれている。上司をうまく使うところや ボリシーを扱うところのセクションは、会社で働く新人工ンジ二アは絶対に んでほしい。すべてのエンジニアにオススメだ ! 工ンジ二アのための社内政治 の本なんて初めて見た。「難しい人との付き合い方」の物語や実践的なヒントも 素晴らしい ! これは他では手に入らない内容だ。 Piaw Na