Team Geek

ソフトウェア業界を生き抜くための本音ガイド。開発者に必要な社会性とは!
現在いかなるプロジェクトでも、一人で開発を行うことはほぼ皆無であり、誰かしかと共同で開発を行うことは回避できないことです。チームが置かれている状況、チームの規模、また相手との関係性など、複数人での開発には多くのストレスが付き物です。本書は、そういった回避できないチームでの開発に伴う、摩擦や問題の要因をつまびらかにし、その対応を楽しい例とともに書き記した書籍です。

『Team Geek』 (Brian W. Fitzpatrick、Ben Collins-Sussman 著、角 征典 訳、オライリー・ジャパン、2013 年 7 月刊) は、エンジニアが他人とうまく仕事をするための考え方と振る舞いを、ソフトウェア開発の現場の逸話とともに解説した本です。副題は「Google のギークたちはいかにしてチームを作るのか」。版元の紹介によれば、著者は Subversion をはじめ多くのフリーソフトウェアの開発に関わり、その後 Google でプログラマを経てリーダーを務めるようになった経歴の持ち主で、技術力だけでは片づかない開発者の社会性を主題にしています。コードは書けるのにチームの中で消耗している人、あるいはリーダーを任されて戸惑っている人に向けた一冊です。

天才プログラマの神話から始まる全 6 章の構成

1 章「天才プログラマの神話」は、コードを隠して完成まで一人で抱え込む振る舞いがなぜチームを弱くするのかを入口に、チームを作る三本柱を示します。目次にある HRT は謙虚 (Humility)、尊敬 (Respect)、信頼 (Trust) の頭文字で、エゴをなくすこと、批判を受け止めて早く失敗し学ぶことが具体的な実践として並びます。2 章「素晴しいチーム文化を作る」は、ミッションステートメント、効率的なミーティング、設計文書、メーリングリストやオンラインチャット、課題管理ツール、そしてすべてのコミットにコードレビューを付けることまで、文化をコミュニケーションの仕組みとして組み立てる章です。3 章「船にはキャプテンが必要」はサーバントリーダーの考え方とリーダーのアンチパターン、4 章「有害な人に対処する」はチームを守るための見極めと対応、5 章「組織的操作の技法」は理想どおりに動かない会社の中で成果を出すための立ち回り、6 章「ユーザーも人間」は第一印象の管理や使いやすさの考え方まで、視野をチームの外へ広げていきます。

チームの問題が技術の問題として現れる理由

ソフトウェア開発の失敗は、多くの場合、設計や実装の誤りとして表に出ます。ところがその根を辿ると、レビューを避けて大きな変更を一度に出した、設計の議論を記録に残さなかった、特定の人しか触れない箇所を放置した、といった人の振る舞いに行き着くことが少なくありません。特定の人に知識が偏っている度合いを バス係数 という言葉で表すことがありますが、これは技術の指標であると同時に、チームの文化の指標でもあります。本書が三本柱を個人の心構えにとどめず、設計文書やコードレビュー、課題管理といった仕組みの話へつなげているのは、チームでの開発 の質がこうした日々のやり取りの積み重ねで決まるからです。

2013 年の本として読む前提と、向かない目的

刊行は 2013 年で、2 章で扱われるコミュニケーションの道具はメーリングリストやオンラインチャットといった当時の環境を前提にしています。チャットツールや開発基盤は刊行後に大きく入れ替わっているため、個々の道具の使い方を学ぶ本として読むと古さが気になるはずです。一方で、議論を記録に残す、レビューを前提に小さく出す、ミーティングの目的を絞るといった原則は道具が変わっても通用します。また本書は逸話と原則を中心に組み立てられた読み物で、評価制度の設計や 1on1 の進め方、採用の手順といったマネジメントの実務を体系立てて学びたい人には物足りません。そうした目的なら、チーム開発とマネジメントの本の選び方 を参考に、役割に合った一冊を選び直すほうが近道です。

逆に、レビューで指摘されると身構えてしまう、チームの中に議論を壊す人がいて困っている、リーダーになったものの何から変えればよいか分からない、といった状況にある人には、本書の 1 章から 4 章が具体的な言葉と対処の型を与えてくれます。プログラミングの技術書とは違い、読んだ翌日からのレビューの返し方やミーティングの進め方にそのまま反映できるのが本書の強みです。チームで働くことにすり減っているエンジニアほど、手元に置いておく価値があります。