会社の「評価」に繋がりやすい活動

嫌われる勇気では、承認欲求の否定が説かれていて、確かに「人に好かれたい」を追求しすぎると疲れてしまうので５年くらい前に辞めた記憶がある。それはそれで楽で、嫌われようともなんだろうと自分の思ったことが言えることがやはり落ち着く。職場でも結構思ったことは言っている。

とはいえ「承認欲求」と「評価」は別物。「評価」はされるされないではされたほうが良いし、それは「評価」の先に会社の利益という承認欲求とは別次元の指標があるからこその話。上司に好かれたいが一心で評価を上げる行動にはあまり惹かれないけれども、会社という組織において「評価される」行動について解像度高く言語化しているこちらのスライドに学びがあったので、自分の言葉にしたい思いでアウトプット。

読書は果たして貢献しているのか？

「本を読む」だけでは、知見を得ているのは自分だけ。たとえばAWSの本を読んでWebサービスをデプロイするスキルを得たとしても、組織としてのメリットはゼロ。読んだ人の頭の中にある状態では、まだ見えない資産価値。「書籍購入制度」はよく会社にあるけれども、書籍を社員に読んでもらうだけでは貢献度はゼロで、社員に共有するための勉強会を開いたりしたほうが本当は良いはず。

本を読んで知見を得て、機能としてあるサービスに実装したとする。ここでようやく組織への貢献が形になる。そのサービスを外注した場合に10万円かかるとしたら、10万円の価値が生まれる。ここで初めて会社にとって単発の価値が生まれる。

リスクとしては、社員が辞めてしまった場合にそのスキルは会社から失われてしまうというのがある。社員が辞めてしまった場合は、そのWebサービスが作れないだけではなく、採用費や人員を補充するための費用、引き継ぎにかかる時間などマイナス面が大きく響く。

本を読んで、社内に知見を共有した場合はどうか。1人しか知らなかった情報が、複数人に共有されることによって、継続的にそのスキルが会社に根付くことになる。万が一その社員が離職してしまったり、離職までいかなくても別のプロジェクトにアサインされてしまった場合でも、複数人いるので安定して

経営面から見たエンジニアは、サービスを迅速かつ安定して開発するためのリソースとして期待されているので、「特定の誰かしか知らない」スキルに頼るのは少々リスク。「開発はできるがドキュメントは残さない」エンジニアにも結構出会しているけれども、引き継ぎの際に余計な時間がかかってしまったり、最悪の場合技術自体が埋もれてしまったりするリスクもある。

評価する側の人と評価される側の人

上の資料は、「評価される側」として大変良い心がけであるけれども、実際に「評価する」側の人間がこれらの情報を考慮しているかどうかは職場によりけり。「今日から読書したことを勉強会という形で共有します！」だったり「交流会で知り合った人を紹介します！」と行動したとして、「評価する側」に響かないケースだって存在する。「評価する側」の人間の考え方を知るとか変えるとかは労力も使うしそもそも難しい話なので、諦めるしかない。

ちゃんとした上司であれば、部下が再現性ある形で知見を共有しているかどうかも考慮に入れて欲しいと切に願うけれども、それだけが評価ではないし、上司によって重みは違う。部下の取り組みについて解像度が高い状態で理解はされていて欲しいけれども、上司によって把握している量やメモリの空き状況は異なる。良い行動・悪い行動に都度適切なフィードバックを本人に与えるべきだと思うけれども、上司によってフィードバックの有無はかなり異なる。「評価は半年に一回の面談でいいよね」みたいなあっさりスタイルでの上司もいる。

結局評価は上司の運

と思うのだけれども、100人の上司がいたとして、評価されやすい行動は何かと言われれば、やはりこの原則は外さないように思う。モチベーションが高いだけでは評価には繋がらないし、100冊読んだって評価には直結しない。仕事で成果を上げているかどうか。与えられた任務ができているかどうか。それ以外にも継続的にチームの知見を高めるための貢献ができているか。

まとめ

• 本を読んだりイベントに参加するのは好きだけれども、チームに共有しているかどうかという視点であまり考えたことがなかったので、良いきっかけになった。

• 有用な情報は、勉強会なり資料なりで共有して行きたい

• 継続的な形で共有できれば、なお良い