Teem Geekを読んで
チーム
チームは個人の生産性や幸福に直接影響する ソフトウェア開発はチームスポーツ
- 素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのはリスクの高い大きな賭け
- 検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神
- バス係数（「プロジェクトメンバーが何人バスに轢かれたらそのプロジェクトが破たんするか」という数値）を高める
邪魔されない時間があったとしても間違ったことをしていたら時間のムダ →できるだけ同じ空間で作業をする
邪魔されないまとまった時間が必要＝クリエイターの時間
A:「break point, tenshotanaka」 tenshotanaka:「ACK」
HRT
謙虚(Humility) 自分は絶対に正しいわけではない。常に自分を改善していく必要がある。
尊敬(Respect) 相手を一人の人間として扱い、その能力や功績を高く評価しよう
信頼(Trust) 自分以外の人は有能であり正しいことをすると信じよう。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるもの
チームでの振る舞い
ほんのすこしの手間が大きな見返りにつながる。組織を使う必要があることを認識し、組織を自分の仕事に使うことを学べば、組織を自分の要求に合わせられるようになる。
何かを成し遂げるための関係を構築する
- 批判の配分と対応
- 批判するべきなのは、オブジェクトではなく、振る舞い。
- 相手に対する疑問ではなく、自分の疑問として謙虚に聞く
「このメソッドの制御フローは完全に間違ってますよ。みんなが使ってる標準的なxzxyyコードパターンを使うべきです。」 →「この部分の制御フローがよくわからないのですが、xzxyyコードパターンを使えば読みやすくなるでしょうか？」
学習のための時間をのこす チームのなかで局所最適化してしまうと学ぶのをやめてしまうこと。 → コンフォートゾーンの外側に自分を置く
影響を受けやすくする 影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる。
文化
- チームの文化の基礎を作るのは、チームや会社に最初からいるメンバーたち。
チームの文化の定義、維持、制御に責任を持つのは、かならずしもリーダーではなく、チームメンバー。
強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的。
強固な文化を構築すると「自己選択的」になる
優秀なエンジニアは他の優秀なエンジニアと働きたいと思っている。
- 優秀なエンジニアは優秀なチームリーダーを求める
- チームがエゴを持つのは大丈夫だけど、個人がエゴをもつのは良くない
- 意思決定をする際の衝突を解消するプロセスそのものではなく、衝突を解消するプロセスを持っていること、それを守っていることが重要
前向きな批判をしてくれる友達や同僚を見つけたら、貴重な存在なので、手放さないようにしておきたい
成功する文化のコミュニケーションパターン
同期的コミュニケーション(ミーティング) ＜ 非同期（チャット） できるだけ多くの人が、プロジェクトの文書からすべての情報を取得できることが重要
- ハイレベルの同期 集中するにはやらないことを決めること
効率的なミーティング
- dailyは15分なら問題ない。
- 新しいものを設計するのであれば、ミーティングに5人以上参加させてはいけない
1.絶対に必要な人だけを呼ぶ 2.アジェンダを作ってミーティング開始前に配布する 3.ミーティングのゴールを達成したら時間前でも終了する 4.ミーティングを順調にすすめる 5.ミーティングの開始時間を強制的に中断される時間(お昼休みや就業時間)の前に設定する
- FaceToFace を過小評価してはいけない。
leader
- エンジニアは代替可能な労働者ではなく、数ヶ月間かけて新しいチームに追いつく。
- リーダーの役割として最も重要なのは、執事や召使のように、チームに奉仕すること
友人関係とチームをリードすることを混同してはいけない。
リーダーの仕事は、チームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきこと
ミスをしたときに謝るということ、失敗したときに謝罪できるリーダーは尊敬される
エンジニアが相談をもちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決をするのを手伝ってほしいから。問題を整理したり調査したりすることで彼が自分で問題解決できるように支援する
リーダーは、障害を取り除くための答えを知る必要はない、取り除ける人を知るだけでいい。多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。
チームに安心感を与えればリスクを取れるようにできる。
言えないようなことや知らないことがあれば、そのように伝える。→ 答えがわからないことを聞かれたときは答えがわからないと言う。
褒め言葉のサンドイッチは、本当に伝えたいメッセージを聞いてくれないので避ける。
フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかが重要
時間を作ってチームの幸せを計測する
- 1対1のMTGのあとに「何か必要なものはある？」と質問する
- オフィスのそとに生活がないと考えてはいけない（家庭が大変な時期に余裕を与えておくと納期が迫ったときに長時間労働をしてくれたりするもの。）
- チームメンバーのキャリアを追い求める（有能なリーダーになりたければ、そのメンバーの暗黙的な目標を明確にして、どうすれば実現できるか考えるべき。）
- リーダーになって間もないころ（自分でやったほうが早くても、できるだけチームに仕事を任せる）
- チームをリードした後（自分で手を汚す。チームの尊敬を集めることができるし、仕事のペースが上がるから。特に誰もやらないような仕事を担当する。）
- 自分自身を置き換えようとする
- 事を荒立てるときを知る
- できるだけ多くの情報をチームに共有すべきだが、チームに関係ない組織の話でわずらわせる必要もない。
- チームのいいところをフィードバックする
- 優秀なリーダーは取り返しがつくかどうかの判断に優れている。
有害な人の対処
- やりたくないことを明確にする。
- 排除するのはあくまで振る舞いであり、特定の個人ではない。
- 完璧主義を回避する
- 返信した方がいい相手とそうでない相手を区別する
- 有害な人の放つ辛辣な言葉の中にも有用な知恵が埋もれている
長期的に考える
- 短期的にはチームの注意や集中を無駄にしても長期的にはプロジェクトにメリットがあるだろうか？
- その衝突は有益な方法で解決できるだろうか？ 上記の答えがノーの場合はできるだけ早くその振る舞いを中止する必要がある。
HRTをベースにした強い文化はかけがえのないもの。
技術的に貢献できる人は確実に交換可能。短期的なメリットのために文化を妥協する必要はない。
多くは、誤解や見当違いが原因。
立ち回り
誰かを説得するときは、あらかじめ賛同してくれる人を探しておいて、対象となる相手との会話の中でアイデアについて触れてもらう（提案や要求を出してもらう）と成功率が上がる。
攻撃的な仕事（ユーザーに見えるもの）と防御的な仕事（プロダクトを長期的に健全にするためのもの）があり、防御的な仕事で政治的な信頼性を獲得することはできない。→ 技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3~1/2をかけない。
自分の仕事に関係がなくても、他の人の仕事を手伝うようにすれば、いづれ誰かが喜んで手伝ってくれるようになる。
親切の経済で少しだけ信頼を稼ぐことができる。
忙しい人にお願いする方法
3つの箇条書きと行動要請のテクニック
問題について説明する（最大）３つの箇条書きと、一つ（一つだけ）の行動妖精がふくまれる 箇条書きは短い文章にする（改行なしで1行にまとめること） 行動要請もできるだけ短くすること
良いプロダクト
エンジニアは客観的に高品質で効果的なものが売れると思っている → 多くの人間は論理と感情を同じだけ使い、マーケティングの人間は感情操作に精通している。ソフトウェアに対する感情的な知覚に配慮しなければならない。一分後にどのように感じるか。
簡潔でよく考えられたユーザーインターフェース
プロダクトの最初の体験が超重要
ソフトウェアを技術系と非技術系の両方の人に使ってもらい、最初の1~2分を観察する。
アプリケーション速度（科学的に言えばレイテンシー）の重要性
成功しているソフトウェアというのは、問題を限定してそれをうまく解決したもの。あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題をうまく解決している。
コードを書く側の都合ではなく、ユーザーに集中しよう。
- 複雑なことであっても、簡単なことをしているように感じられるようにするべき。
名言
- 「人間は断続的なバグの大きなかたまり」
- 「自分は自分の書いたコードではない」
- 「できるだけ約束は小さくして、届けるものは大きくしたほうがいい。それでノーと言う機会が増えるとしても、できないことを約束しない。頻繁に締め切りを守らなかったり、機能を落としたりしていると、会社の人は信頼してくれなくなる。」
- 「ダウンロードではなく、利用されなければならない。」
- 「エンジニアの文化は「事実」に満ちあふれている。」
- 「ソフトウェア以外のことに注意と集中を浪費しない。」
