あなたがバスに轢かれてもプロジェクトは大丈夫ですか？ / 読書記録『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』☆☆☆☆

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

ということでチーム開発するときの人間の話が書かれた本

個人的におもしろかった部分の一部をメモしておく

バス係数

ソフトウェア開発はチームスポーツである

一人でやっていると失敗のリスクが高くなる
間違いや車輪の再発明のリスクが高まり、フィードバックも得られない

プロジェクトの知識を持っているのが一人だけだと、その一人がバスに轢かれたらプロジェクトは終わってしまう
早い段階から知識や成果を共有することで、チームメンバーの一人がいなくなってもプロジェクトが継続できるようになり、プロジェクトのバス係数(bus factor)を高めることができる

Bus factor - Wikipedia, the free encyclopedia

HRT(発音はheart)

チームで仕事をするときには、他の人に対して以下の3つを心がける

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

チームの文化をよくする

チームのミッションステートメント: チームでやること、やらないことを明確化する

同期コミュニケーション(ミーティングなど)の人数を減らし、非同期コミュニケーション(メールなど)の人数を増やす

ミーティングの5つのルール

絶対に必要な人だけを呼ぶ
アジェンダを作ってミーティング開始前に配布する
ミーティングのゴールを達成したら時間前でも終了する
ミーティングを順調に進める
ミーティングの開始時間を強制的に中断される時間(お昼休みや就業時間)の前に設定する

感想

上にメモしたのはほんの一部だけどこの手の本を読むと思うのは、「有害な人ではなく有害な振る舞いを追い出す」とか「君は君の書いたコードではない」言いたいことはわかるけど実践できるかどうかは別だよねーという感じ

仕事で参加してるプロジェクトは少人数でやるものが多くて、一人か二人バスに轢かれたらひどいことになりそうな感じで心配(どっちかっていうと人月が足りなくなる的な意味かもしれないけれど)

ミーティングで人が集まるとみんななかなか意見を言わないか、はたまたすごく自分の意見を言いたがったり雑談が始まってしまったりいろいろ難しい。ひどい時は議事録もちゃんと録ってなかったり共有されなかったりするし
できるだけミーティングには参加したくないけど、自分の関わるものがいつの間にかどこかで決まっていてやらされるだけっていうのも精神的によくないのでよしあし