『Team Geek』学習メモ
mission stmt
- プログラマが効率的にソフトウェア開発するためにスキルを向上する。
- 他者理解
- コミュニケーション
- コラボレーション
はじめに
- ソフトウェア開発はチームスポーツ。
Ch1 天才プログラマの神話
- 確実にコントロールできる変数としての自分
- リーダ、ロールモデルについて
- openでない要因
- リスク
- バス係数
- オフィス
- フィードバックループ
- チームで取り組む（ある程度のこの力を備えたら）
- 三本柱: HRT
- Humility
- Respect
- Trust
- 人間関係はプロジェクトより長命
- エゴ
- 集団のエゴ
- 批判と非難
- 非難: 行動につながらないため無用
- self != your code
- 相手への疑問ではなく自分への疑問として表現
- 議論の対象がコードであり、誰かの価値やコーディングスキルでないことを明示する
- missは選択肢の1つ
- なんとなく使えるようになったらすぐリリース
- 謙虚と信頼
- postmortem: 事後分析
- what to learn && what to change
- 概要、タイムライン、根本原因、影響とロスの評価、即時対応行動、再発防止行動、教訓
- challenge
- // 謙虚さは学びで表す（p.26の内容について）
- // 謙虚の対象を定める。信頼に対する謙虚さ。
Ch2 team culture
- culture
- 作る
- not leader, but member
- strong culture
- software delivery に集中するのが良いチームカルチャ
- 集中、効率、強度を与える
- 自己選択的
- 良い人を求める
- 合意ベースのチーム
- → mission stmt
- team's ego
- 内向性
- 合意ベースのチーム
- コミュニケーション チャネル
- 非同期が〇
- mission stmt
- 方向性 + スコープの定義
- 人数、時間
- クリエイタの時間
- meeting rule
- remote teamでの合意
- 設計、ドキュメントについて
- 使っていないことも多い
- コミュニケーション ツール
- 課題管理ツール
- comment
- explain why, not what
- fn, methodに書くのがベスト
- source中の名前は×
- code review
- test
- コードを書く、届ける
- コミュニケーションはベースになる
Ch3 Captain
- leader's task
- ×人参と鞭
- 育成と時間が必要
- positive pressure
- leaderは道を作るのみ、何ができるかを示す。どうやるかは示さない。
- team lead, technical lead manager
- team lead: 製品の技術的方向性に責任
- technical lead manager: メンバのキャリアや幸せにも責任
- peter's law
- managerになるべき理由
- servant
- good manは休みをくれる
- low performanceへの対応
- 人間の問題
- 共感
- 友人にならずともよい
- 採用コスト
- 大人として扱う
- leadership pattern
- 優秀なチームと仕事の品質や評価の高い基準が必要
- 合意形成と方向性
- フィードバック、批判、謝罪
- 歯車と回転数
- questionで返す
- 合意形成と障害除去。触媒となる。
- proper answerよりproper manを知ることに価値がある
- リスクをとるための安心感
- チームで失敗。個人で成功。
- メンターの要素
- 経験、教える力、支援要求の把握
- mission stmt
- 正直になる
- 褒め言葉サンドイッチは×
- 伝え方
- 幸福
- 何が必要か
- プライベートの要求
- キャリアの共有
- 委譲 + 手を汚す
- 自分の代わりの人を求める
- 事を荒立てるべきとき
- カオスから守る
- 空中援護
- チームの良さをフィードバック
- 取り返しがつくか判断
- 必要とするものを知る
- 興奮（モチベーション）と自発（方向性）
- 方向性: what to doと構造化スキル→管理可能なタスクに分解
- 内外モチベーション
- ダニエル・ピンク『モチベーション3.0』。TEDもある。
- 外: 対価など
- 内: 自発的なもの
- 自律性・熟達・目的の3つが必要 + 給料に不満がないこと
- 自律性: 自分で考えて行動→プロダクトオーナーシップ醸成→成功への関心UP
- 熟達: エンジニアのスキルはナイフの刃
- 目的: 影響が小さな製品はフィードバックに注目。
- 自律性・熟達・目的の3つが必要 + 給料に不満がないこと
Ch4 有害な人に対処
- good culture
- 親切、礼儀、互いに期待
- 自己選択的
- 有害な人: チームに直接の脅威
- 生産性もcultureも×
- プラクティスと手続きでcultureを強くすることで回避
- 例 → p.102
- チームの注意と集中を有害な人から守る
- 無知、無関心は悪意より悪い
- 他人の時間を尊重しない
- 異なる考えを受容しない人。個人のエゴ。
- 要求→追放するしかない。
- 過大権利 → パラノイア。
- 無視がベスト
- 完璧主義
- 何度か振る舞いを警告してもダメ→人を追放
- 完璧主義への対応
- 別の問題を与える
- 不満や非難ばかりの人にも使える
- 別の問題を与える
- 返信より自制 vsトロル // → 悪意の方がましな理由。
- 争いを選ぶ
- 常に技術の議論に戻す
- 優しく追い出す
- 諦めるときを知る
- 長期で見る
- 技術は代替可能
- 短期のメリットのために文化の妥協は不要
- 破壊的なふるまいを斥ける
- HRTへの自分の期待を明らかにするのが重要
Ch5 組織的操作の技法
- 社内政治、social engineeringを組織的操作という
- good managerのとき
- managerのタスクを減らす
- ＋ より高レベルのことができることを示す
- ＋ チャレンジスピリット
- リスクをとれるとき
- 自分の期待を他人に伝える
- 質問する
- 報告する
- 障害物・うまくいったとき・何か必要なとき・何か期待するとき
- マイクロマネジメントの回避にも〇
- 悪い人と悪い組織が成功を阻む
- 悪いmanager
- 失敗への不安
- そいつなしで外とのやり取りができない
- 情報を出し惜しむ
- 悪いmanager
- オフィスの政治家
- 影響力にならず、影響力を探す
- のさばらせるとより悪くなる
- 官僚制、手続き
- 扱われ方
- 集中、ビジョン、方向性が重要
- 許可より寛容
- 悪い習慣はreplace, not remove
- 小さな約束、大きなサービス
- 製品のローンチが重要
- うまくやっていることをちゃんと伝える
- 防御的なタスクに1/3 ~ 1/2をかけてはいけない
- 攻撃的なタスクのみ政治的信頼につながる
- 運の良さ: 気づき
- 親切を投機的に用いる
- 安全なポジションまで昇進する
- 成果を記録
- 昇進プロセスを調べる。managerと相談
- コネクタ、引退プレーヤー、管理スタッフから組織図を知る
- 直接会うのが〇
- ＋ 自分自身
- 権力者は問題解決を喜ぶ
- 3つの箇条書きと行動要請
- どうしようもないとき→escape
- next carrerを考えておく
Ch6 ユーザも人間
- 成功するソフトウェア開発に欠かせない要素
- 頭のいいプログラマの小集団
- HRT
- servant leader, 合意・意思決定
- 水・日光・方向性・内的モチベーション
- 文化と進捗を破壊からま持つ
- これらに加えて、他人がソフトウェアを使いフィードバックループがあることが重要
- ユーザエンゲージメントの3フェーズ
- 知る・気づき
- 体験
- やりとり
- 論理と感情でマーケティング
- 第一印象
- 小さく約束、大きくサービス
- 受動的な攻撃は×
- ユーザにフォーカス
- 例: 検索広告の効果測定
- ドキュメント・チュートリアルに加えてUIが重要
- はじめて使うとき
- ユーザでなく利用を測る
- 7(30)日間アクティブ数
- 速度・レイテンシが何より重要
- 停滞の要因になる→図6-6
- 例: グーグルマップ
- 速度は機能
- 問題を限定しうまく解決するのが〇
- 多くのユーザの共通する問題をシンプルに解決
- less is more
- なまけない
- 設定は少ないのが〇
- 空白・句読点・ダッシュを許容する
- ユーザの時間を大切に
- 複雑に思わせない
- customer relationship
- ユーザを認知する
- 満足を時間軸測定 → 図6-11
- ユーザを人間として扱う
- 我慢、忍耐
- 語彙の統一
- 表現の確認
- 信頼と喜び
- 感情的プラスの積み重ね
- リスクも大きい。残高への影響を考える。
- 驚きと幸せで喜んでもらう
- 例: doodle
- 3点
- ユーザの生活を豊かにすることがソフトウェアを作る理由である。
- ユーザはソフトウェアの成功の血液。
