-
技術者は時として頑固であり、考え方もそれぞれ異なる。
優秀な人間ほど自分を曲げなかったりするものだ。
だが、良い製品を完成させるというゴールのためには、同じ価値観を持つ必要がある。
価値観といっても、必ずしもまったく同一のものである必要はない。
ただ、技術への愛、技術の持つ可能性への夢、そのような価値観は共通であるべきだ。チームをまとめるリーダーも同じだ -
ソフトウェア開発の「人間的な」側面を扱ったものである。人間は複雑だ。
ぼくたちはよく「人間は断続的なバグの大きな塊だ」と言っている -
いつも1人でやっていると、失敗のリスクが高くなる。そして、成長の可能性が低くなる
早い段階で設計ミスをしやすくなるし、車輪の再発明をする可能性があるし、だれかと協力するメリットが失われる -
検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神を忘れないようにしよう
-
早い段階で成果を共有することで、躓きを回避したりアイディアを検査したりできるようになるが、プロジェクトのバス係数を高めることもできるようになる
-
三本柱HRTの原則 謙虚（Humility） 、 尊敬（Respect）、信頼（Trust）
-
あらゆる人間の衝突は、謙虚、尊敬、信頼の欠如によるものだ
-
組織（開発チーム）を使う必要があることを認識し、組織を自分の仕事に使うことを学べば、組織を自分の要求に合わせられるようになる
-
プロのソフトウェアエンジニアリングの世界では、批判は個人的なものではなく、優れたプロダクトのプロセスの一部にすぎない
-
君は君の書いたコードではない
-
失敗は選択肢の一つ
-
エンジニアは、チームリーダーがチームの文化を作ると勘違いしている。これは真実とはほど遠い。
-
オープンソースの世界では、クリーンでエレガントで保守性の高いコードを書くことに集中すると、クリーンでエレガントで保守性の高いコードを重視する人たちが興味をもってくれる
-
採用ミスを回避するため、技術インタービューの前に、文化のインタビューをする会社もある
優秀なエンジニアは、自分で運転できるパスに乗りたいからだ
-
コミュニケーションの原則は、同期コミュニケーション（ミーティングなど）の人数を減らし、非同期コミュニケーション（メールなど）の人数を増やすこと
-
コミュニケーションとプロセスを充実させていけば、新来者がチームに入りやすくなる
-
TL（チームリード）とTLM（テクニカルリードマネージャ）
TLはプロダクトのすべての技術的な方向性に責任を持つ。TLMはそれに加えて、チームにいるエンジニアのキャリアや幸せにも責任を持つ -
チームの幸せと生産性を高めることがマネジメントの仕事の指標になる
-
ピーターの法則
階層的な組織に属する人間は、必ずその人の無能レベルまで昇進する -
マネジメント病の治療法は「サーバントリーダーシップ」である
-
サーバントリーダーが管理するのは技術的な側面とチームの人間関係である
-
Aランクの人はAランクの人を採用する、Bランクの人はCランクの人を採用する
-
リーダーの仕事はチームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきことだ
-
ミスをしたとき謝る
-
会社の組織図は歯車のように見ればいい P79
CEOが一番おおきな歯車であり、CEOの歯車を動かせば、糸巣rうしないにかかわらず、そこにつながる小さな歯車を拘束に動かせるのである -
委譲せよ、ただし手を汚せ
-
エンジニアによって、成長にひつようなものは違う
-
HRTをベースにした強い文化はかけがえのないものである。技術的に貢献できる人は、確実に交換可能だ
-
FitzがGoogleに入社した最初に週に、Gmailのタイポをみつけたことがある。ソースコードを開いて、タイポを修正して、Gmailチームにパッチをメールすると、心から感謝してもらえた。大企業であっても摩擦のないところはあるのだ
-
許可を求めるより関与をもとめるほうが簡単
-
道がないなら道を作る
-
誰かを説得するときには、あらかじめ賛同してくれる人を探しておいて、対象となる相手との会話の中でアイディアについてふれてもらうと成功率が上がる自分のアイディアが自分以外の人の口から出てくるのを耳にするのは苦痛かもしれない。でも、それがアイディアを広める勇逸の方法だったりする
-
組織の悪い習慣を排除するのは難しい。悪い習慣をやめることはできない、良い習慣と置き換えなければいけない
-
エンジニアとしては、何よりもプロダクトのローンチにエネルギを注ぐべきだ
-
「攻撃的」な仕事と「防御的」な仕事
ぼくたちは、技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3~1/2をかけないというルールを作っている。それ以上は政治的自殺行為に繋がるからだ -
運のよい人はチャンスに気が付く
-
正しいことをして、解雇されるのを待とう！
-
ユーザーに集中すれば、ほかのことはすべてういてくる
-
利用のハードルを下げて、ユーザーのプロダクトの最初の体験が超重要
-
ユーザーではなく、利用を計測する
-
利用を上げてユーザーを満足させるには、レイテンシーを改善するのが一番だ、Googleの創業者たちも「速度は機能だ」といっている
-
ユーザーは自分の意見を聞いてほしいだけだ。無意味な提案や根拠のない不満を言ってきても、そのことを認知することが重要である。議論や開発のプロセスに参加してもらえれば、ユーザーはそれだけ忠実で幸福になっていく
-
ユーザーとやり取り時の基礎：信頼と喜び
信頼はもっとも大切なリソースだ、残高に気を配ろう。何か行動するときには、必ず残高への影響を考えよう