何らか開発をやっている人なら、開発物が一定のレベルに達した段階でレビューを受けることになります。ソフト開発ならコードレビュー、僕のようなハードウェア設計開発だとデザインレビュー(以下、DR)です。
前の会社でも今の会社でもレビューイ(レビューされる側)として幾度となくDRを経験しました。どの会社、どのプロジェクトでもDRは例外なくキツく、精神に堪えます。
なぜかというと、DRはムチでひたすら打たれるだけでアメが貰えないんですよね。
DRは欠点探しの場
DRの目的は不味い箇所を探して改善項目を挙げることです。ちょっとでも目に付く形状があると「ん？」とレビュアー(レビューする側)の皆様が首を傾け、追及が始まります。
レビューイとして、ツッコミ入りそうな箇所にはそれなりの理屈は用意しておくわけですが、数多のレビュアーから時には論理的に、時には感覚(経験)的に、これはダメだという結論に収束させられていきます。
NG結論が出た後に、具体的な改善方法や別案の構想などが貰えると設計的にも前進できてありがたいです。しかし現実は残酷なもので、ダメだという結論に達した時点で話が次に移るわけです。振り出しの荒野に戻ってしまうのです。
これはこれで有用な事には間違いありません。ダメなものはダメと捨て置き、一から考え直すことができるのは設計段階だけで、金型を作ってからでは遅すぎます。NG判定が後ろの工程に移るほど傷口は大きくなるものです。
良くできてる点にもスポットライトを
それはそうと、やはりDRで大量のダメ出しをされるとレビューイ側はツライのです。ひたすら突っ込まれて説明に明け暮れ、自身の成果物を否定された果てに待っているのはゼロスタート。
だから少しくらいはアメが欲しいわけです。攻めたクリアランスをきっちり公差計算で理屈付けして成り立たせていたり、危ういところを実地検証してクリアしてたりとか、新しいことしてても納得できるだけの材料集められているところだってあります。
そういうところを「じゃあ大丈夫か」と流すだけでなく、「良くできてるな」と一言お褒め頂きたいものです。
ダメ出し一辺倒になると減点方式になってしまいます。「出来ているのが当然」という雰囲気が出来上がり、後には無力感だけが残ります。これがDRの辛さの元です。
ここは出来ていて、ここは出来ていない。減点も加点もあれば、DR終了後も軽やかな気持ちで改善箇所の検討に移れるというものです。
良い点の指摘は難しい
しかし自分がレビュアーの時の振る舞いを思い出してみると、良い点を指摘した覚えがないことに気が付きました。
ダメな点や懸念点って、挙げるのが簡単なんですよね。それに意見を出すと仕事した気になれます。
対して良い点を挙げるのは難しいです。基本的にDRでやり玉に挙がるのは誰も経験にないような内容ばかりで「実際に作ってみなければ分からない」類のものばかりです。良い点を挙げるというのは、そういった得体のしれないものにお墨付きを与えるわけで、自分の責任だったりプライドだったりを運命共同体に組み込む行為にもなります。
いやー難しい。難しいんですが、自分より上の熟練の方々には、それでも良い点を指摘してお墨付きを与えることをガンガンやっていってほしいですね。
