読者です 読者をやめる 読者になる 読者になる

レビューの壁をなくさないと若手エンジニアが育たない

老害というべきなんだろうけれど、所謂、リーダや年齢的に(技術とは言っていない)シニア層が尤もらしくレビューをするとき、

レビューア(シニアエンジニア)→レビューイ(若手エンジニア)

の関係性が出来上がります。これは気をつけないとレビューアもレビューイもストレスが溜まるだけで本来期待している機能の検証や実装すべき設計仕様の要件の充足性まで手が回らないことになってしまうのです。

レビューイのストレス

レビューアから一方的に指摘をされると、受け手となるレビューイはそのときの心理状態は、心理的な安全が確保できず、ストレスを感じるものです。

これはレビューのスタイル、場のデザインにも影響を受けますが、一番大きいのはレビューアとレビューイの関係性です。

本来は対等である必要があるのですが、勘違いをするレビューアは、内容が伴わなくても高圧的な物言いをされると、レビューイも人ですし、いなす技術も持ち合わせていないとなると、オフセットできず、レビューコメントと正面衝突の形をとることになります。

ただ、レビューイ側に何もないのかといえば、そうもいかなくて、「てにをは」やコードのお作法を自分のアウトプットを作り上げるときに織り込むことの必要性を気づけず進めてしまうために、結果的に自分自身で低レベルのレビューのツッコミどころというトラップを仕込んでしまっているのですけど。

レビューア側のストレス

レビューア側のストレスは、毎回同じ指摘をすることでしょう。何度言っても直らない、指摘が反映されないのであれば、レビューをすることでプロジェクトの品質目標の確保に貢献していると思えないですから。

何度かコメントをつけて、その結果が取り込まれいないとき、やはりレビューアも人ですから声のボリュームも物言いも制御できない人も出てくるかもしれません。

そのような態度はレビューアとして容認できることではありませんが。

関係性の壁を排除する

無意識に作り上げる関係、

レビューア(シニアエンジニア)→レビューイ(若手エンジニア)

 

がレビューアとレビューイの双方のストレスを作るのであれば、それをやめればいいのです。

とても単純な話で、

レビューア(シニアエンジニア)→レビューイ(若手エンジニア)

こんな風に、取り消し線を引いて、エンジニアならどっちの役割を担えるようにすればいいのです。

実際問題、

レビューア(シニアエンジニア)→レビューイ(若手エンジニア)

 

この関係性の拙さはどこにあるかというと、

・役割が固定されている
・レビューイ側から発言がない

 状態になることです。一方的な関係とはそう言った意味合いです。

本来のレビューの目的を鑑みれば、アウトプットするドキュメントやコードのお作法的なものは可能な限り機械で除去し、構造やスコープや技法だけをレビュー対象としたいところです。

では、そうしたときに若手がレビューアになれるのかといえば、質問することでそのデザインが適切なのかという検証ができるのです。そのためにはレビューアの役割となったときに、レビュー前にインプット情報をどれだけ飲み込んで準備できるかがカギとなりますけど。

 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 

  

ピアレビュー

ピアレビュー