こちらはqiitaさんのブログを読み、ずっと読みたいと思っていたオライリーのTeam Geekを読みました。

そのqiitaさんの記事はこちら。

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


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

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

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

はもちろん

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

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

HRT

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

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

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

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


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

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

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

バス係数

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

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

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

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

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

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

とりわけ若いエンジニアは、そもそも相談のタイミングが分からなかったり、トラブルがあってもため込む傾向が強いですよね。
そもそも、「こんなことで相談して良いことかどうか分からない」とか、「なんとか自分で解決したい」のか、、、わかりませんが。

本当にあった話を一つ

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

それは、順調に進行していると思われた新規プロジェクトだったのですが、リーダー格の一人が怪我をして入院してしまい、突然数日間も連絡が付かなくなってしまったという大きなトラブルでした。

同じパートのメンバーがリーダーを引き継ぐ格好になりましたが、怪我をしたリーダーが頭の中だけで展開していたことがあまりにも多く、調査や情報の整理に膨大な時間がとられるというかなりの痛手を受けました。
これは、「彼しか知らないコードが山のようにある==バス係数が極端に低い状態」であったと言えます。

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

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

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

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

この記事を書いた人はtomita@atuwebでした。



2015年12月29日:文章を少し修正
2015年09月09日:前進ブログ「僕の見たソシャゲ開発」で公開した記事を、加筆、修正、タイトル変更して再公開しました。

スポンサーリンク
ad_336
ad_336
  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存
スポンサーリンク
ad_336