何を評価するか
僕も人を評価する立場になって、いつも頭を悩ませてる。
けど、人生の経験も少し得たからか以前よりも「はっきりとした形がないもの」を重視するようになった。
自分が評価される側であったとき、どんな資格を取ったとか、いいコードを書けるとか、業務知識があるとかが
評価の基準になるとか思ってたけど、とんでもないな。
それらは手段でしかない。必要でないと言ってるわけじゃないよ。目的を伴っているか？ということ。
少なくとも企業であるならば、評価の高低は会社に提供する「価値」の高低だ。
会社がイメージしづらいなら、プロジェクトでもチームでもいい。
プロジェクトやチームにどれだけ貢献するか。
もっと簡単に言ってしまえば開発するシステムの価値を高めるかってこと。
若い僕は手段自体を価値だと勘違いしていた。
貢献が基準だ
どんなに技術力があろうと資格を持っていようと業務知識があろうとも、
それ自体は評価と直接関係がない。
いいコードによって、豊富な知識によって開発するシステムの価値を高めるから、
それが評価につながる。
勘違いしちゃいけないんだ。
個人として優秀だからといって、真の意味で優秀かには直結しない。
貢献をしない優秀さなんて、何も意味がないんだ。
手段自体を価値だと勘違いして、「正当に評価されていない」なんて思い込んじゃいけない。
貢献の形もいろいろだ。
コードでも、雰囲気作りでも、ファシリテートでも、マネジメントでも、システムの価値(コスト、納期、品質)を高められる。
それは貢献しているってことであり、その人は評価されるべきってことだ。
人の心を動かす
そして、1人だけでできる貢献なんて小さいもんだ。
周りを巻き込んでこそ貢献は大きくなる。
個人でシステムを作ろうとしたら、何年もかかるし、たいした機能もないだろう。
「個人」として優秀かなんて、世界の頂点まで突き抜けないと評価の対象にならないよ。
技術や知識が多少あろうが、自分のことしか考えない人ほど自分が正当に評価されないなんて思い込む。
人の心をポジティブに動かして、大きく価値を高められる人が評価される人だ。
どう実践するか
僕自身今年に入ってそう感じるようになった。
開発では、とにかくメンバーがポジティブに仕事をできるように、理不尽さから守ることだけを考えてる。
まずは残業とか休日出勤。これをさせないために早くからマネージャ側と議論してる。
理不尽な出勤はいいシステムにつながらない。その場しのぎになるだけだ。
会社では、とにかくメンバーにエンジニアを楽しんでもらいたいと思ってる。
好きこそものの上手なれ。
まずは技術を楽しんで、その流れでシステム開発の成功に必要なことを各自考えていって、行動を起こしてもらいたい。
そのために、エンジニアイベントを社内で開催してみた。
思った以上に好評だった。
定期的に開催する流れになっていきそうだ。
業界では、システム開発が硬直化しないように、「選択肢」を提案していきたい。
銀の弾丸はない、と言いながらも結局慣れた「いつもの方法」でシステム開発をするのは失敗につながるから。
プロセスも、アーキテクチャも、各プロジェクトで適切なものを考えて「選択」しなくちゃいけない。
今は技術の選択肢しか提案できないけど、だからまずテスティングフレームワークの「選択肢」としてTestNGを提案してみた。
テスティングフレームワーク = JUnitみたいな硬直はマズいから。
# Javaは選択肢が多すぎるとも思うけど、それ自体がJavaの魅力でもある気がする
書いていて思ったけど、やっぱり僕は実践がショボイな。
口(blog)ばっかりだ。
もっとできそうな気がしてきた。
