team geekを読んだまとめ

前書き

• teem Geekを読んで気になったところ、意識するべき内容について投稿します。

開発チームの役割：マネージャー/リーダーとは？

• マネージャー
  • チームのエンジニアのパフォーマンスを最大化させることが指名
• リーダー
  • エンジニア全員がに担う必要がある
    • 機能単位で見ると、担当したものがその領域（ドメイン知識、仕様）に対する知見が一番ある
• 会社外のチームで活動する場合、リーダー意識を持つことより必要となる。

エンジニアの特性として、途中経過のものを隠そうとする。

• 完璧なものとを提供しないと、、、、
  • バグの塊でできている人間が作るものは、バグを生まないはずはない。小さいことは気にするな。
• 作業途中のものはみられたくない、、、、、
  • 作業途中のものを見せるのは怖いが、実装完了しました！！ といって動かない、要件を誤認による納期の遅れの方が怖い。
• アイディアをせきどりされる、、、、、、
  • アイディアなんて、自身が考えていることは基本誰でも思いつくことだから隠すに値しない。
• 上記を行うと、失敗するリスクが高い
  • 正しい方向性に向かっているのか、、、、
    • → どうやって、方向性が正しいか確認するの？
    • 今の自分にとって改善すべき内容
      • プログラムでは、コード実装→テスト をして、すぐ動作確認をする。
      • チェックポイントを作って、認識・方向性を確認することが大切。
  • 成長機会を失う、、、、
    • FBをもらう回数（サイクルをつくって）を多くする
    • なぜ？
      • 方向性の確認
      • 実装方法のアドバイス
      • 効率化（時間とリソースの有効活用）
      • 他のメンバーの経験や知識から学ぶ機会が増える

チーム作りに必要な三本柱

• HRT
  • 謙虚
  • 尊敬
  • 信頼
• チーム内の人間関係の衝突はHRTが欠如している。
  • ３項目を意識できれいれば、批判的な意見などは出ることはない。
  • プログラムにおいて、レビューをする際、レビューの指摘する観点を変えるなど、直接的に実装者につながるような指摘ではなく、目的があり、その目的に限りなく近づけるため指摘をしてあげることで、人間関係において、衝突はなくなると思う。
    
  • 成果に対する批判
    • 目的を達成するために必要な指摘をしてあげる。
    • 個人の性格に対する批判

早い段階で失敗、学習、反復をする

• とある大きなミスをした状況の場合、、、、
  • 組織にとって大きな損失となるミスをした、失敗したね の状態で終わらせてはいけない。
    • かといって、失敗した人を責めるのもNG（何も生まずに、負の意識だけ芽生える）
      
  • この失敗を前向きに捉える組織であるべき。
    • その失敗は、早い遅いに関わらず、どこかのタイミングで必ず起きる。
    • このインシデントを文書化して、組織の経験値として蓄え、次この失敗を起こさないために対策を取る。（ポストモーテム）
      • 文書化して、過去にどういう意インシデントが発生したか共有して、対応策を練る。

学習に時間を費やす

• 所属する組織内において、特定の分野で専門家としての地位を確立
  • → この時、専門家として、組織に貢献（周囲への指導など）を行い、組織に対する貢献はできている状態。しかし、退屈に感じるようになる
    • なせ？
      • 貢献はできているが、新しいことを学んでいない状態であった
      • 組織内の局所最適化してしまって学ぶことをやめた状態であった。
        
• 自身のコンフォートゾーンの外側に身を置き、専門家として指導できる状態であり、新たしいことを学び続ける状態でなければいけない。
  • 新たしいことを学ばない（自身の知識の範囲内で思考を収める）状態は何事も退屈に感じる。
  • 理由
    • 脳の刺激不足
      • 新しい情報や課題がないと、脳が十分な刺激を受けない
      • 脳は新しい情報や挑戦を求める傾向がある

    • 成長実感の欠如:
      • 新しいスキルや知識を獲得する機会がないと、自己成長の実感が得られない
      • 成長感は人間の基本的な欲求の一つ

    • 好奇心の不満足
      • 人間は本質的に好奇心を持つ存在
      • 新しい発見や学びがないと、この好奇心が満たされない

文化

• 創設時、スタートダッシュが肝心で、チームの文化が構成される。
• 創生時に文化をとして重要視するものを明示して共通認識を作る。

なぜ上記を行う必要がある？

• 新メンバーが加入した時、以前所属していた文化をもとに動くことがある。 これらを許容してしまうと、チーム文化が崩れてしまう。

チーム文化とは、、、、

• コードを書くためのものではなく、エンジニアリングチームで経験・価値・目標を共有する場
• 文化を作るのは初期メンバー
• 文化は変化していくもの
• どの組織会社でも、異なるもの。
  • →上記が成功している組織は、チーム初期メンバーがルーツとなり、組織が成長、成熟していき、文化が変化しても、文化そのもののアイデンティティが失われることはなく、組織の各方面に浸透していく。
    

新しいチームに加入した時、文化を気にすること

• なぜ？
  • チーム文化が崩れると、これまで不要であった批判的議論、口論などが増えて、これまで作れていた作業時間が取れなくなり、チームとしてのパフォーマンスが発揮できなくなる。
• 対応
  • チームメンバーが文化の定義、維持、防御はするべき
  • レビュー時、普段の振る舞い、メンバーが意識していることを観察して、感覚を文化に寄せていく必要がある。

まとめ : エンジニアチームの成功の鍵 - Team Geekから学んだこと

Team Geekを読んで、エンジニアチームの成功には3つの重要な要素があることに気づきました。
1つ目は、全員が共感できる明確な「ミッション」が必要。形式的な文書ではなく、日々の活動の指針となるものが必要です。
2つ目は、分散型のリーダーシップ。マネージャーだけでなく、各エンジニアが得意分野でリーダーシップを発揮することが重要です。
3つ目は、謙虚・尊敬・信頼（HRT）の文化。これがあれば、完璧を求めすぎず早めにフィードバックを求められ、失敗も学びに変えられます。

結局、良いチーム文化とは、コードを書くためだけでなく、メンバーが共に成長するための土台なのだと感じました。