お茶漬けびより

学んだことを整理する場所です。主に、C++, Unreal Engine 4 (UE4) を扱っていました。最近は、仕事方面で使っている言語やツールを紹介したいと思います。たまに趣味や雑記も。

Team Geek を読んだ。

2013年に出た本ですが、今さら買って読みました。 読み物として読んだのであまりしっかり読んでいないですが、大事な話は1章に集約されている感じだったので、そこだけまとめようと思います。

ミッションステートメント

本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。

というのがこの本の内容です。はじめに が来る前に書かれてあるのでそれぐらい重要な内容です。ここを理解してから本書を読み進めたほうがいいです。

全部で 6 章ありますが、進み方としては初めに自身の振る舞い良くする方法を提示し、2章でチームの文化を良くする方法、3章でチームリーダー、4章では害悪の人をなくす方法(人を排除するわけではない)、組織操作の方法、最後にユーザの扱い方を説明しています。

1章で説明されている HRT を基本としているので、他の章を読む前に 1 章を読むほうがいいでしょう。

天才プログラマの神話

世の中には、スゴいエンジニアがいるけど、その人たちのスゴさはエンジニアリングスキルではなく(もちろんそれ自体もスゴい)、チームをリードする力がスゴいという話。ソフトウェア開発は一人でするものではなく、チームで行うもの。チームスポーツなのだという。

世の中には、一人で隠れて開発したい人が多い。その人たちは自分の書いたコードやアイデアを人に見せるのが恐い。コードを見てバカにされないか、誰かにマネされて自分より先にプロダクトを世に出さないかが恐い。でも、公開されないソフトウェアは失敗する。相談する相手がいないので、過ちを犯しているのに気づかずに開発を進めているから。

早期発見

早い段階で、高速に、何度も失敗せよ

コードを書くときに全て書いてからコンパイルするだろうか? 少し書いて、コンパイル。少し書いて、コンパイル。失敗を早く見つけることで早く修正できる。これをコードだけでなくプロジェクトでも行う。環境は唐突に変わる。それに合わせて設計、計画を変えないといけない。じゃあこの失敗を早く気づくにはどうすればいいか。チームで仕事をするといい(人の数だけ早く気づける!)。

バス係数を高める

バス係数とは、プロジェクト関係者がバスにひかれても、そのプロジェクトを続けられる係数のこと。値が高いほどプロジェクトを続けられる。

これは、チームの文化、人の採用を強化することで高めることが出来る。人の採用はただ闇雲に集めればいいわけではない。本書の 3 章を参照。

集中する時間

エンジニアが開発するには、集中する時間が必要。誰にも邪魔されずにコーディングに集中できる時間が必要。邪魔して欲しくないときのルールを作ると良い。ただし、それ以上にチームとの高速で高帯域な連携は重要(たぶん 2, 4 章あたりの話)。

HRT

  • Humility(謙虚)
  • Respect(尊敬)
  • Trust(信頼)

人間関係の衝突は、この HRT の欠如によって起こる 。コミュニケーションの中心に HRT を心がけることが重要。

例えば、個人のエゴをなくす。自分の意見を押しつけない。集団のエゴを考える。それは、チームの功績や誇りなど。

例えば、批判をするときの言葉を選ぶ。相手のコードが間違っていると判断しても、相手に間違っていると言ってはいけない。提案をする。採用されないくてもいいような風に言うと良い。また、性格に対する攻撃的な非難をしてはいけない。コードはその人自身ではない。逆に批判を受けたときに非難されたと思わないこと。自分が書いたコードは、自分自身ではない。これをお互いに理解しておくことが大事。相手を尊敬していれば、非難しようと思わないはず。

信頼については、リーダーやユーザの話を参照(3 章、6 章)。

失敗から学ぶ。反復学習

過ちを犯したら文書化(ポストモーテム)する。文書化するときは、謝罪や言い訳を書かない。何を学んだか、何を変更するかを書く。見えやすいところに置いて、変更を継続できるようにする。
以下のことを書くと良い。

  • 概要
  • イベントのタイムライン
  • イベントの根本原因
  • 影響と損害の評価
  • すぐに問題を解決するための行動一式
  • 再発を防止するための行動一式
  • 学習した教訓

文書化されることで、同じ過ちをする人をなくすことができる。歴史を繰り返してはいけない。

チームの文化

チームの文化を強化することで、外部からの悪い文化を排除することができる。その悪い文化は、主に新来者が持ってくる。文化はリーダーが作るのではなく、メンバーたちが作るもの。メンバーたちが持つことで、新来者へ継承できる(バス係数が高まる)。優れたチーム文化は、ソフトウェアを届けることに集中している。

効率的なエンジニアリング文化は、同期コミュニケーションを減らし、非同期コミュニケーションを増やす。会議(同期コミュニケーション)には、必要な人しか集めない。早く終わるように工夫する。決まったことは、メーリングリストで報告する。電話、ビデオ通話、チャット、メールなど(非同期コミュニケーション)を駆使する。あらゆるツール、あらゆる手法を使ってコミュニケーションを強化し、効率的に開発を行えるようにする。

ミッションステートメント

そのプロジェクトのミッションステートメントを決める。何をして、何をしないのか。これを決めないと永遠に肥大化する。また、ミッションステートメントは変化するときがある。会社の環境やプロダクトの方向転換があれば、ミッションステートメントもそれに合わせて変える必要がある。

おわり

この本、ページ数が少なく200ページにも満たないので軽い気持ちで読めました。何か役立てるために読むというより、読み物として読んでいましたが、楽しく、興味深い内容でした。ここにまとめたのは、1章、2章が主ですが、3~6章も大事なのでいつかまた読みたいです。とりあえず HRT を意識できるようにならないといけないかなと思ってここにまとめてみました。

とても上手に翻訳していただいた角 征典(かど まさのり)さんに感謝です。

今回からここに載せている元の文書を Github で管理するようにしてみました。 github.com