QiitaやKobitoを作る開発チームの文化
http://blog.qiita.com/post/74997115585/increments-dev-team-culture

を見て、ずっと読みたいと思っていたオライリーの Team Geek を読みました。

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

本書は Google のギークたちが実践してきた チーム開発のノウハウ が詰まっており、

  • 組織のマネージャー
  • プロジェクトリーダーをされている方

はもちろん

  • ひどいリーダーに困っている人

にも読んでもらいたい内容です。

HRT - 一人プロジェクトは少ない

本書の主張はいくつかありますが、全体を通したテーマは次の HRT に集約されると思います。

  1. 謙遜(Humility)
  2. 尊敬(Respect)
  3. 信頼(Trust)

HRT とは 「ハート、heart、痛みを軽減するもの」です。

あらゆる人間関係の衝突は、HRT の欠如によるものなのである! 本書はそう主張します。


一人で開発するプロジェクトはほとんどありません。
メンバーの見ている方向が揃っていればチームのパフォーマンスは劇的に上がる のですが、残念ながらそううまくいくことばかりではありません。

本書では、チームをまとめるために、生産性を上げるためにどうすればよいかというお話が具体的にいくつも掲載されています。

そして(大切なことですが)読み物としても十分楽しめる内容になっています。

バス係数

筆者が本書の中で特に心に残った(そして本の最初の方に出てくる)ワードが 「バス係数」 です。

君がバスに轢かれたらプロジェクトは終わってしまう

という本書の展開から、バスに轢かれる確率とプロジェクトの人数をかけたものを「バス係数」としています。
非常にユニークなのですが、真理を突いているうまい表現だと思います。

そして、「バス係数が低い」とは、「 チームのあるメンバーが離脱してしまったらプロジェクトが即、破たんしてしまう 」状態のことです。
だからこそ「バス係数を高めることによって不測の事態に備えよう!」という主張ですね。

「一人でやっていると失敗のリスクが高まって」しまいますが、それは、早い段階から周囲の意見を求めたり、情報の報告共有を行なうことは「 つまづきを回避したりアイデアを検査 」することに繋がるからです。

しかし、困ったことに、エンジニアという生き物はそれが本当に苦手なんですよね、、、

とりわけ若いエンジニアは、そもそも相談のタイミングが分からなかったり、トラブルがあってもため込む傾向が強いと感じます。

そもそも、「こんなことで相談して良いことかどうか分からない」とか、「なんとか自分で解決したい」のか。
わかりませんが。

本当にあった、バス係数

筆者が体験したものでも、実際に「バスに轢かれて」プロジェクトが破たんしてしまったことがありました。

それは、順調に進行していると思われた新規プロジェクトだったのですが、 リーダー格の一人が拘置所に閉じ込められ、数日間、いっさい連絡できない という状況に陥ったことがありました。
連絡がとれないため、生きているのかすらわからず、大変でしたねー。

同じパートのメンバーがリーダーを引き継ぐ格好になりましたが、 前リーダーが頭の中だけで展開していたこと があまりにも多く、調査や情報の整理に膨大な時間がかかり、プロジェクトの進行にも大きな影響がありました。

これは、「 彼しか知らないコードが山のようにある==バス係数が極端に低い状態 」であったと言えます。

小さい会社、小さいプロジェクトではこのようなことが簡単に起こるという、恐ろしい話です。


しかし 予想もしなかったことが起こるのがプロジェクトの常であり、それが人生 なのです。

どんな規模のプロジェクトであれ、バス係数を高めるためのセーフネットを築いておくことは、本当に大切なことだと思います。

予算ももちろんありますが、金銭的な損失はもちろん、信頼を維持することが大切なのではないでしょうか。