『アイのムチ よくないレビューの例とレビューで折れないメンタルづくり』読書メモ

攻撃的なレビュー

• コードを攻撃的に批判する

• 気持ちの良いフィードバック

  • Must/Wantを使って簡潔に説明する

• NG, OK等, 良いか悪いかを伝えるだけ

  • レビュアーを満足させるのが目的になってしまう

• レビュアー1は追々高度な実装を学んでくれると良いなと思ってokしたが、レビュアー2は突き放すレビューをした

  • 成長を促すようなレビュー

• 一貫性のないレビューはレビュアーが複数いる時に起こりがち

• 一方通行のレビュー

  • レビュアーのコードを誰もレビューしない
  • 若手が先輩のコードをレビューしない

良いレビューとは

• 自分の考えを明確にしつつ, 自分が正しいとは主張しない

• 客観的な着地点を探す

• レビュアーがレビュイーに共感している

• すべての人が対等

• 心理的安全性を作る

• 成長のためのムチとの妥協点

  • 開発フロー自体を見直す取り組みがされて欲しい

• 自分はむしろボコボコに言われてほしい, その方がやる気が出る

• 心理的安全性が低いと

  • ネガティブだと思われる不安
    • マイナスも言えないとチームの改善機械が失われたり本来の能力を発揮できない

• 柔らかい言葉を使う, 明言を避ける, 賛成するで心理的安全性が高まるわけではない

  • お互いがマイナスしても大丈夫と思いあえている状態

• 完璧主義で意見も出来るが一言多くて

• 謙虚な自信家だが意見食い違った時自分の意見を引っ込めちゃう

  • bestではなくbetterでよいと考えてしまう

• こういうところも含めて, 全員のパフォーマンスが最大化出来るならすごい

• バランスが大事, トレードオフスライダーを設定

  • 全てが両立することは無いので

技術⾯での融通は だいぶ効く環境になりましたし、エンジニアの興味やモチベーションを尊重してもらっています。

当時の開発チームで、電⼦レビューだと誤解やタイムラグが発⽣するからと、対⾯式の集合レ ビューを⾏なっていました。Qiita の記事は、その環境をもっとよくしたい、レビューのモヤモヤ に寄り添いたい

見習うべき良い方が多い