チームでうまく仕事をするには
『Google のソフトウェアエンジニアリング』第2章を読んで理解した内容を、自分の言葉で書き直したもの。 本文の引用ではない。節番号は原典を引き直すときの手がかり。
前提
仕事の大部分に天才レベルの知能は要らない。だが100%の仕事に、最低限の社会的スキルは要る。 (§2.2)
人間関係の問題に使うエネルギーを減らせば、その分をコードに回せる。 だからこれは「いい人でいましょう」という話ではなく、生産性の話として扱う。
天才神話を捨てる (§2.2)
人にはリーダーを偶像化して真似ようとする本能があり、 チームの成功を単独の人物に帰したくなる。これが天才神話。
Linux は輝かしい成果だが、Linus の元のアイデアの成果というよりコミュニティの集団的労働の成果で、 Linus の本当の業績は人々を導いて作業を協調させたこと。
天才であることは、嫌な奴でいい理由には一切ならない。 社会的スキルに乏しい人は、天才かどうかに関係なくチームメイトとしての適性が低い。
隠れるな (§2.3)
作りかけを見せたくないのは自然な感情だが、隠れて単独で作業する時間が増えるほど、 不要な失敗と成長機会の逸失のリスクが上がる。 そして最も怖いのは、間違った対象に時間の大半を注ぎ込んでしまうこと。
早期発見
根本的な設計ミスは初期に起きやすい。車輪の再発明をやってしまうリスクもある。 早期にフィードバックをもらうほどリスクが減る。「早期に失敗し、高速に失敗し、頻繁に失敗せよ」。
ただし方針やゴールがまだ不明確な段階で early すぎるフィードバックを大量にもらうのは危険、 という注意も書籍は付けている。
バス係数
バス係数 = そのプロジェクトを完全に破綻させるのに必要な、バスに轢かれる人数。 知識とノウハウがプロジェクト内にどれだけ分散しているかを問う指標。
他者と直接仕事をすると、その取り組みの背後にある集団的英知が増える。
進捗ペース
フィードバックは早く
テストは早く
セキュリティと本番環境の考慮も早く
問題を早く見つけるほど修正コストは下がる。 これはコードだけでなくプロジェクト全体でも同じで、 プロジェクトのレベルでも同種の高速なフィードバックループが要る。 見ている目の数が多いほど、プロジェクトは筋の通った状態に保たれる。
物理的な配置も効く。4〜8人を同じ空間にまとめて、自然発生的な会話が起きやすくする。 エンジニアには集中のための邪魔されない時間が必要だが、 チームとの広帯域で抵抗の少ない接点も同じくらい必要。 知識の浅いメンバーが質問することに障壁を感じているなら、それは問題。 バランスの取り方には技が要る。
チームが全て (§2.4)
世界を変える業績は、たいてい閃きとそれに続くチームの奮闘の成果。 優れたチームはスーパースターを見事に活用するが、全体は常に部分の総和に勝る。
社会交流の三本柱 (§2.4.1)
| 柱 | 内容 |
|---|---|
| 謙虚 | 自分も自分のコードも宇宙の中心ではない。全知全能でも無謬でもない。自己研鑽に開かれている |
| 尊敬 | ともに働く人を心から思いやる。親切に遇し、能力と成果の価値を認める |
| 信頼 | 他者が有能で正義を為すと信じ、適切な場面では舵取りを任せられる |
人付き合いの衝突をほぼ全部、根本原因まで辿るとこのどれかの欠如に行き着く。
豊かな人間関係を結んでおくほど、助けが必要なときに同僚が手間を惜しまなくなる。
エゴを捨てる (§2.4.3.1)
自分がその場で最重要人物であるかのように振る舞う人と、誰も働きたくない。 議論の中で自分が最も賢いと自覚していても、それをひけらかさない。
自己点検の問い。
どんな件についても自分が最初から最後まで口出しする必要があると感じていないか
提案や議論の全ての細部にコメントする必要を感じていないか
謙虚であることは、踏みつけられる玄関マットになることではない。 自信を持つのは何も悪くない。知ったかぶりにならなければよい。
目指すのは個人のエゴではなく集団的エゴ。 自分個人がすごいかを心配するより、チームの成果とグループの誇りを育てる方に努力を向ける。
「自分は自分のやり方でやる」とエゴを主張し続けると、キャリア全体を通して小さな代償を払い続け、 それが人生全体では膨大な厄介事に累積していく。 システムと戦い続けるより、システムを使いこなして自分の願望に合わせて適応させる方を学ぶ。
批評のやり方と、受け方 (§2.4.3.2)
プロの環境では、批評は個人攻撃ではなくプロジェクトを改善するプロセスの一部。 鍵は、成果物への建設的批評と人格への攻撃を、自分も周囲もはっきり区別できるようにすること。
- 人格攻撃は了見が狭く、それに基づいて行動できないので無用
- 建設的批評は改善方法の手引きになる。そして何より相手への尊敬に満ちている。 本気で気遣っているからこそ、相手や相手の仕事が良くなることを望んで言う
受け手の側も、批評の受け方を学ばなければならない。 自分のスキルについて謙虚であることに加えて、 相手が善意で言っており、自分を馬鹿だと思っているわけではないと信じること。
自分という存在と、自分のコードは別物。
言い方の実例として、書籍が挙げているのはこういう形。
ここの制御フローで混乱してしまって。
xyzzy のパターンなら、もっと明確で保守しやすくなるかもしれないと思うんだけど、どうかな
ポイントは、相手ではなく自分についての話にしていること。 相手が間違っているのではなく、自分が理解に苦労している、という形にする。 何も要求しておらず、相手が平和的に断れる裁量を残している。
高速に失敗し、反復する (§2.4.3.3)
失敗は、次の試みに向けた学習と改善の機会として扱う。 ただし書籍は釘を刺している — 同じことを何度も繰り返して失敗し続けるなら、それは失敗ではなく無能。
構想の扱い方の基準として、 同僚全員がかりでもホワイトボード上で論駁できなかった構想だけが、初期プロトタイプに進む。
非難なきポストモーテム (§2.4.4)
誤りから学ぶ鍵は、根本原因分析を行って失敗を文書化すること。 適切なポストモーテムに含まれるもの。
分析対象イベントの簡潔な要約
発見から調査を経て解決に至るまでのタイムライン
主要原因
影響と損害の評価
問題を直ちに修正するためのアクションアイテム(とそのオーナー)
再発を防ぐためのアクションアイテム
学んだ教訓
忍耐と、影響への寛容さ (§2.4.4.1, §2.4.4.2)
衝突や激論そのものは起きる。それを越えられるのは、信頼と尊敬の積み重ねた歴史と忍耐。
そして 影響に対して寛容であるほど、自分が及ぼせる影響は増える。 逆に頑固でい続けると、人は意見を聞くのをやめ、 気にも留めない障害物として「迂回」するようになる。
- 誰かのせいで自分の考えが変わってもかまわない
- 環境が不変で知識が完璧でない限り、常に正しくあることは不可能。 新しいエビデンスが出たら考えを変えるのが当然
- 過ちや力不足を認めることは、長い目で見れば信望を高める
行動の指針 (§2.4.5)
曖昧さの中にあっても成功する 変動する環境、競合するメッセージや方針の中でも合意を形成し進捗できる
フィードバックを尊重する 率直に受け、率直に与える謙虚さを持つ
現状に立ち向かう 抵抗や惰性があっても野心的なゴールを設定し追求する
ユーザーを第一に置く ユーザーへの共感と尊敬を持ち、ユーザーの利益を第一に行動する
チームを思いやる 頼まれなくても積極的に手伝い、チームの団結を強める
正義を為す 強い倫理感を持ち、誠実さを守るためなら不都合な決断もいとわない