0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

覚書 - TeamGeek Brian W. Fitz., Ben C.

Posted at

TeamGeek

本書は、職場のエンジニアが話題に挙げていた。
そのチームは本書の良いチームを体現しており、すこぶる尊敬できた。
自分もその精神を持ちたく、覚書を書いた。
なお、フォーマットの策定に当たっては、以下の記事を利用させて頂いた。

新人エンジニアにレポートを書かせて技術書の読み方を伝える。

概要(著作、著者、著者経歴)

Brian W. Fitzpatrick / Ben Collins-Sussman:
両名ともに、2005年までSubversionの開発を行っており、プロジェクトにおける協力の重要性に関する知見を得る。
2005年にGoogleのシカゴオフィスに移り、各所における講演が本書へつながる。
他の著作には、Subversionに関するもの等が存在する(リンク先参照)。

角 征典:
ご本人様のWebページより引用

主な訳書に『リーダブルコード』『Running Lean』『Team Geek』(オライリー・ジャパン)、『エクストリームプログラミング』『アジャイルレトロスペクティブズ』(オーム社)、『図解リーン・スタートアップ成長戦略』(日経BP社)、『Clean Coder』(KADOKAWA)など。

要約

チームの状態は個人の生産性や幸福に直接影響する。
良いチームを作り、機能させるためには良い行動(本書に記載)が必要だが、その根底は、コントロールできる自分から、HRTの原則に基づいて行動することから始まる。

  • Humility 謙虚:
    • 自分は全知全能ではない!(天才でもない。)
  • Respect 尊敬:
    • 相手を1人の人間(大人)として扱い、評価しよう。
  • Trust 信頼:
    • 相手は有能であり、正しいことをすると信じよう。

面白かった章とその理由

「2章 素晴しいチーム文化を作る」と「4章 有害な人に対処する」が有意義と感じた。
生き残れる強い文化の作り方と、それを外的要因から守る具体的な方策が記載されている。
どのような目的なプロジェクト・集団であれ、効率よく、幸福な結果を得ようとするならば、役に立つだろう。

理解できなかった章とその理由

全ての章で納得が行くことが記載されていたが、強いて言えば、チームを子供として扱うアンチパターン例での、設備を扱うための言伝がなかったケースについては違和感があった。
細部が省略されているだけだと思うが、単に施設担当者が伝え忘れただけではないかな…
また、マネージャーをリーダーに置き換えないことにも若干違和感があった。
人間関係の問題やユーザビリティに関する知識については、他にも参照すべきだろう。

仕事に活かせそうな知識、活かせそうな状況と活かし方

この書籍では最後にどう行動すればよいか、まとめてくれているので、それを引用しよう。

物事はシンプルに考えよう。他のことは忘れても、HRT(謙虚・尊敬・信頼)だけは覚えて欲しい。
…(中略)…HRTはあらゆる影響「範囲」に適用可能だ。

その他

  • さぼりがちな自分への戒めとしては、信頼しても自分の責任を放棄してはならないことを記載しておく。
    • 依頼した仕事は、コストをかけてチェックする。チームで動いているのだから。
    • 改めて欲しい事があれば、尊敬を込めて伝える。それは難しく、訓練が必要なことだ、時間をかけよう。
  • 記載内容のテーマが散らばっている場合、要約するのが難しい。
  • 覚書として書く場合、あまりフォーマットにこだわり過ぎないほうがよいかもしれない。以下に自分が後で参照したい情報をメモとして書いておく。
  • 本書では、そもそも「優秀な」エンジニアを前提に話を進めている。つまり、いま優秀ではない自分は、そもそも実践する機会さえ、得られていないということだ。
    • とはいえ、全ての人は等しい時間の中にいるのだから、いつまでも蚊帳の外にいるわけでもない。精進せよ。

キーワードメモ

  • 1章 天才プログラマの神話
    • HRT
    • バス係数
    • 戦いを避けるために、エゴ(固執)をなくす
    • 君は君の書いたコードじゃない
    • ポストモーテム
    • 学習のための時間
    • 忍耐
  • 2章 素晴しいチーム文化を作る
    • 文化は自己選択的
    • 文化を作れるのはチームメンバー
    • 優秀な人を集めるには、合意ベースのマネジメントが必要
    • コミュニケーションの原則は、非同期コミュニケーションを増やすこと
    • ミッションステートメント(目指すこと、目指さないこと)
    • アジェンダが終わったら終了するミーティング
    • 設計文書を適切に書く。一人がオーナーで、二人がレビュアー。
    • 検索可能な議論の場
    • 課題管理ツール
    • コメント・プロジェクトレベルのAuthorリスト・レビュー・自動テストとデプロイ
  • 3章 船にはキャプテン(リーダー)が必要
    • リーダーは自然発生する
    • @Deprecatedマネージャー!@Deprecatedマネージャー!
    • リーダーはベビーシッターではない!チームメンバーはベビーではない!(ベビーを入れてはいけない??初心者であっても、ベビーになってはいけない)
    • リーダーの仕事はエンジニアの仕事と違う成果を生む
    • 無能なマネージャーは無能なプレイヤーではなかった。有能だったから、階層がそうさせたのだ。(階層的な組織や、昇進という仕組みが、概ねの場合、効率的ではないのでは)
    • サーバントリーダー
    • アンチパターン: 言いなりを採用・低パフォーマンスに対する無視・人間問題の無視・リーダーではなく友達になる・採用を妥協する・ベビーとして扱う
    • 成功パターン: エゴをなくす(再度!)・平静を保つ・人を繋ぐ・メンターになる・目標を明確にする(チームの範囲内で)・正直になる・チームで幸せを求める・「何か必要なものはある?」
    • 成功パターン(Tips): 半移譲する・自分自身を置き換える・必要なときに事を荒立てる・カオスからチームを守る・上層部の今を伝える・良い所もフィードバックする・やり直しが簡単に効くなら「いいよ」という
    • 人によって必要なサポートは違う。方向性/モチベーション
  • 4章 有害な人(ではなく振る舞い!)に対応する
    • 「有害」の定義は、文化的に、ネガティブな「振る舞い」(善悪ではない)
    • 個人的に賛同する例: 他人の時間(唯一無二のリソース)を尊重しない・異なる意見に耳を傾けない・貢献無しに権限を求める・言語を上手く使おうとしない・プロダクトに対する完璧主義
    • いかに文化を守るのか: 完璧の対象を変える・餌を与えない・平静を保つ(再び)・真実を掬い出す・HRTを心に諦める
    • 悪意に見えるそれが、悪意であることは少ない
  • 5章 組織的操作の技法
    • 目に見える仕事には一定の時間を割り当てよう
    • 高い能力を持っていれば、自分自身の将来をコントロールできる
  • 6章 ユーザーも人間
    • 一般的な人にどう見られるか、管理する
    • 第一印象に拘る
    • 小さく約束・大きく届ける
    • 観客を選ぶ
    • 速いことは、いいことだ
    • 少ないことも、いいことだ
    • 複雑であることをひけらかす必要はない
    • プロダクトは、ユーザーを豊かにするためにある
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?