プロダクトは一人で作ることもできるが、
大きな成功を成し遂げるためにはチームで開発する必要があると思っている。
それは理論的にも、数値的にも、
一人よりも10人のほうが成し遂げられることは多いはずだから。
現実はなかなか難しく、とは言え一人より多人数のほうがやれることは多い。
だがそのためには越えなくてはいけない壁も多く、また欲は尽きない。
そんな中で自分がいるチームを最高のものにしていきたい。
それは生産性や品質というだけでなく、
一緒に働いている仲間の楽しさや幸せという意味で最高のものになったらいいだろう。
現状を振り返りながら考える時間と、そのための学びと示唆を与えてくれた気がする。
問題は多く尽きないが、一緒に働いている人たちと、いいチームが作りたいと思えた。
(以下抜粋。○:完全抜粋、●:簡略抜粋)
○あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。(P.15)
○コンフォートゾーンの外側に自分の身を置くのである。
自分よりも大きな魚のいる金魚鉢を見つけ、
彼らの助けを借りて何でも挑戦していくのである。(P.25)
○チームの文化の定義・維持・防御に責任を持つのはチームメンバーだ。(P.34)
○まずは最悪なミーティングから紹介しよう。スタンディングミーティングだ。
このミーティングは毎週開かれる。
1人ずつ状況(何か重要なことがあるかどうか)を報告していくのだが、
時間のムダだし、目が回るし、死にたくなってくる。(P.45)
○ミーティングを開くときの5つの簡単なルールがある。
1. 絶対に必要な人だけを呼ぶ。
2. アジェンダを作ってミーティング開始時に配布する。
3. ミーティングのゴールを達成したら時間前でも終了する。
4. ミーティングを順調に進める。
5. ミーティングの開始時間を
強制的に中断される時間(お昼休みや終業時間)の前に設定する。(P.47)
○コメントはコードのなぜを説明するものであり、
コードが何をしているか説明するものではない。(P.54 )
○TLは、プロダクトのすべて(あるいは一部)の技術的な方向性に責任を持つ。
TLMは、それに加えてチームにいるエンジニアのキャリアや幸せにも責任を持つ。(P.67)
○サーバントリーダーはチームにアドバイスを与えるだけでなく、
必要であればチームが順調に進めるように穴を埋める。
自らの手を汚すのがサーバントリーダーだ。(P.70)
○チームに5人のエンジニアを採用するときは、
大量の応募者をふるいにかけてから、40~50人に面接して、
上位5人を採用基準と関係なく採用することが多い。
これは最速でダメなチームを作るやり方だ。(P.74)
○チームの幸せを追い求めるためには、
1対1のミーティングのあとに「何か必要なものはある?」と質問するといいだろう。
詳細を知るためにはもっと調査が必要だが、
チームメンバーが生産的で幸せになるために必要なものを簡単に把握できる。
1対1の面接の後に必ずこの質問をするようにしておけば、
いずれ長いリストを持参するようになるだろう。(P.87)
○ 興奮 退屈
自発的 スイートスポット マンネリ ↑ 方向性
注意散漫 見て!リスだ! 漂流 ↑ が必要
←← モチベーションが必要(P.92)
○数年後、彼の予言は的中した。
それでも、Subversion は大きな成功を収めた。
少なくとも企業では広く使われるようになった。
誰が正しいか間違っているかではなく、結論にたどり着くかどうかが重要だ。
いずれかの時点で損切りをして、前へすすまなければいけないのである。(P.105)
○短期的なメリットのために文化を妥協する必要はない。
HRT の重要性を認めない「頭のいい」コントリビュータには気を付けよう。(P.116)
●マネージャーの仕事を楽にできる簡単なことがある。(P.122)
(中略)
自分の責任範囲を広げよう。(P.123)
(中略)
リスクをとろう。(P.123)
(中略)
物わかりのいいマネージャのいるところで失敗すれば、
すばやく学習できるし、何ができて何ができてないのかがわかるし、
時間をかけて成長していくこともできる。(P.124)
○悪い習慣をやめることはできない。
よい習慣と置き換えでなければいけない。(P.134)
- 感想投稿日 : 2017年6月9日
- 読了日 : 2017年6月9日
- 本棚登録日 : 2017年6月9日
みんなの感想をみる