![見出し画像](https://assets.st-note.com/production/uploads/images/145467273/rectangle_large_type_2_e24da4c62dff3b848c3afb7423278dd7.png?width=1200)
Team Geekを読みました
なぜ読んだか
CTOおすすめ
5年前にも読んでおり、そのときとは違う感想を抱くかも、と思い再度読み直したくなった。
1章 天才プログラマの神話
ソフトウェア開発はスポーツチームである。
謙虚、尊敬、信頼の三本柱を大切にする(HRT)
2章 素晴らしいチーム文化を作る
チーム文化はパンのようなもの。スターター(創業者)がパン生地(新来者)に菌(文化) を植え付ける。イースト菌と乳酸菌(チームメンバー)が発酵(成長)すると、美味しいパン(チーム)の出来上がり。スターターが弱ければ、新来者が持ち込む未知の菌(文化)に耐えられない。
ハイレベルな同期を達成するために、ミッションステートメントを設定する。ミーティングは5つの決まりを意識する。メールやチャットはとてもいいコミュニケーションツール。
3章 船にはキャプテンが必要
伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考える。
信頼できないからマイクロマネジメントが必要だと考えているのだとしたら、そもそもそれは採用を失敗しているのである。
エンジニアが相談を持ちかけるのは、問題解決をして欲しいからではない。"彼"が問題解決するのを手伝って欲しいからだ。
エンジニアは植物のようなもの。人によって必要としているものは違う。
4章 有害な人に対処する
「有害な人」という言葉は乱暴。排除するのはあくまで「振る舞い」
5章 組織的操作の技法
リスクを取り、自分の責任範囲を広げ、期待以上の仕事をする。こちらから上司によく報告するようにし、マイクロマネジメントを避ける。
できない約束はしない。
6章 ユーザーも人間
第一印象を大切に
想定するユーザーを絞る
使い方のハードルを下げる
累計ダウンロード数ではなく"今使っている人の人数"を意識する
まとめ
5年ぶりに読みましたが、改めて読んだら"ギークな表現"が多くて難しかったです。
この5年間で個人で作っているプロダクトは信じられないくらい成長しましたし、私の仕事のやり方も変わりました。だからこそ、文化の部分や、組織の部分は改めて読むと新しい発見、そして今の振る舞いを反省する部分も多くありました。
この記事を書いた後に、5年前の記事を読み返したらほとんど同じところを重要だと思って引用してて笑ってしまいました。人間って、そう簡単に変われるものじゃなさそうですね。これからも頑張ります。