『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』第1章「天才プログラマの神話」を解説
今回からチームビルディングの名著『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』[1]Brian W. Fitzpatrick(著)、Ben Collins-Sussman(著)、角征典(訳)『Team Geek … Continue readingを読んでいきたいと思います。
本一冊をざっくりと要約するのではなく、ゆっくりと一章一章読んでいく予定です。
プロジェクト・マネジャーやソフトウェア開発のディレクターをしていると、チームビルディングに悩むこともあるかと思います。そのような時に『Team Geek』の話は参考になると思いますので、この本をみなさんと読んでいければなと考えております。
本の概要
今回が第1回目ですので、ざっくりと「この『Team Geek』とはなんだ?」、「どんなことが書いてあるのか?」をお話ししますと、この本はGoogleに勤めていた著者が、Googleのチームビルディングの方法を紹介したものです。
主にプログラマーに向けた本ではあるものの、技術的な話ではなく、チームで高いパフォーマンスを出すためにどのようなことに気を付けなければならないのかが紹介されています。
第1章「天才プログラマの神話」の構成
それではそろそろ内容に入っていきましょう。
『Team Geek』の第1章「天才プログラマの神話」の構成はこのようになっています。
- コードを隠して
- 天才の神話
- 隠したらダメになる
- チームがすべて
- 三本柱
- 実戦HRT
- 批判の配分と対応を学ぶ
- 次のステップ
今回はこれらの内容をまとめていきます。
コードを隠して/天才の神話
「コードを隠して」「天才の神話」では、ソフトウェア開発ではチームワークこそが大切であることをLinuxを開発したリーナス・トーバルズを例にして解説していきます。
LinuxとはフリーのオープンソースのOSとして知られています。このLinuxの開発はフィンランドのプログラマーであるリーナス・トーバルズによって開始されました。
これだけ聞くと、フィンランドの天才が一人でLinuxを開発したというイメージを持ってしまうかもしれません。
しかし実際には、リーナスは自分で手を動かすだけでなく、上手く協力してくれる人を見つけ、チームをまとめたことがすごいのだという話を『Team Geek』ではしています。
プログラマーやエンジニアと言えば、何となく一人で仕事をするというイメージがあるかもしれませんが、まったくそうではないということです。
たとえリーナスが天才であっても、誤りを指摘する人が必要ですし、身の回りにリーナスのような天才がいれば、そういう優秀な人と上手く仕事ができるようにすることが大切だというのが『Team Geek』の主張です。
隠したらダメになる
プログラマーにチームワークを促す時の大きな障害が、プログラマーの「完成していないものを見られるのははずかしい」という気持ちです。
プログラミングに限らず、どのような仕事であっても、アイデアや作業の方向性が誤っていれば、早期に正した方が手戻りが少なくなり、良い結果が得られます。
「プログラミングの途中で見られるのははずかしい」とか、「途中で批評されるのはいやだな」という気持ちはどんな人にだってあるかと思いますが、それでも、一人で仕事をするリスクを理解し、チームに対して自分の仕事をオープンにしていくことを『Team Geek』は説いています。
チームがすべて
ここで小括。本書で言いたいことは「ソフトウェア開発はチームスポーツである」ということです。
数百万人のユーザーを喜ばせるようなソフトウェアを作りたければ、チームで働くしかありません。
三本柱/実践HRT
ここまで『Team Geek』はチームで働く大切さを伝えてきたのですが、ではチームで働く上で大切なことは何なのでしょうか?
『Team Geek』では謙虚(Humility)、尊敬(Respect)、信頼(Trust)を良いチームを作るために必要な三本柱としていて、頭文字をとってHRTと呼んでいます。
それぞれの言葉が意味することは読んで字のごとくですが、自分を改善しようとしていく謙虚さ、周囲の能力や功績を高く評価する尊敬の念、そして優秀なチーム・メンバーへの信頼が大切だとしています。
そしてこのHRTを実践していく上で大切なのが、エゴを無くすということです。つまり、自分のやり方に固執したり、自分の意見ばかりを通そうとしたりしないようにしていくことが、HRTを実践していく上で重要です。
批判の配分と対応を学ぶ
さらにHRTを実践していくためのヒントを『Team Geek』は続けています。
まずは「批判の配分と対応を学ぶ」ということです。
他のプログラマーのコードをレビューするという時は尊敬を持ってコメントをすべきですし、逆にレビューをされたのであれば、自分のコードには改善の余地があることを謙虚に受け止め、コメントを信頼していくことが大切です。
コードをレビューされるというのはむず痒い気持ちになりますが、あなたのコードはあなた自身ではないということを覚えておくと、いろいろとコミュニケーションを取りやすくなるでしょう。
つまり、コードが批判されても、あなたが批判されているというわけではありませんので、謙虚な姿勢でどんどん他人の意見を聞くとよいでしょう。
また、レビューする側も、コードの改善点を指摘しても、コードを書いた人の人格まで批判するようなことはしてはいけませんし、言葉遣いにも注意したほうがよいです。
例えば、「こんなコードの書き方はまちがっています。○○のパターンを使うべきです。」というようなコメントだと角が立つので、「この部分は少しフローが分かりにくいので、○○のパターンを使ったらどうでしょうか?」などと言うなど、言葉遣いにも注意したほうがチームでの作業は円滑になるでしょう。
この他、HRTを実践するために『Team Geek』はこのようなヒントも伝えてくれています。
- 早い段階で失敗・学習・反復する
- 学習のための時間を残す
- 忍耐を学ぶ
- 影響を受けやすくする
これらのことを念頭において、チームでの開発を進めていきましょう。
次のステップ
『Team Geek』の第1章では、ソフトウェア開発でいかにチームワークが大切か、そしてチームで働く上でどのようなことに気を付けていけばいいのかが紹介されていました。
次回の第2章にはチームにHRTの文化を根付かせる方法が記されています。
この『Team Geek』第2章も、コラムにしていく予定ですので、またご覧いただければ幸いです。
注
↑1 | Brian W. Fitzpatrick(著)、Ben Collins-Sussman(著)、角征典(訳)『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』オライリージャパン、2013年。以下、『Team Geek』と略記。 |
---|