エンジニアを減点主義で評価するのがなんかやな理由

評価はいくつになっても難しい。それでもうまくやれるように試行錯誤してますが、減点主義はいかんなと思うに至ったのでその経緯をメモ。

完璧が存在しない

バグゼロ運動を維持していたとしても、ユーザ環境によっては（特にモバイル）問題が起きてしまったり、大規模なデータやトラフィックだとテスト環境で拾えず本番環境で見つかってしまったり。

いいわけではなく「防ぎようがない」部分があるのは事実です。

なのに、完璧な理想の状態から減点していくのは、100点取れないテストみたいで、そのテストを受けるほうもモチベーションが下がります。

自分もパーフェクトではない

自分が完璧だったらいいんですが、全然ダメなので、そんな僕がする減点ってなんかやだなと。特に、新しい部署に入ってやる場合は、信頼の貯金もないのでさらにつらい。

たとえば、「じゃあ、お前は？」って聞かれたら答えられない。さらにここで、「俺の若い頃は…」とか言いだしたらもうね。

減点主義は、あらかじめ完璧が決まってる仕事ならいいかもしれません。必ず手順通りにやれているかとか、そういう確認なら使えそう。

でも、サービス開発のエンジニアリングは、そう簡単にはいかないもの。多分、サービス開発にかかわらずソフトウェア開発はそんな単純なものではない気がします。

考えた代替案

シンプルに考えました。

• いいところを伸ばせる方法を一緒に考える。
• 本人がやりたいこともあわせて考える。「いいところ（やれることともいう）」と「やりたいこと」がマッチすればとてもいいけど、マッチしない場合はどういう方向性で行くかをまず考える。考えてもらう
• 欠点もきちんと伝える。そのときに、こうしたほうがいいとか、具体的にイメージを持てるようにフォローする。なぜ欠点と僕が考えたのかをわかってもらうのが重要。

しばらくはこの考え方でやってみます。

きっと答えはないけど、考え続けるのが重要な気がする。