すみませんまた偉そうなこと言いました。
前回は採用側に向けた内容ですが、今回は転職する側に向けた内容です。
転職ってとてもエネルギーのいる行動ですよね。
「現在の状況に特に不満はないけど転職する」
「現在の状況に不満があるから転職する」
動機はいろいろあると思います。
今回話をするのは後者のタイプが本当に転職で幸せになれるのか。
前者の人はこれからもがんばってください。
技術力のある人＝評価される人 ではない
エンジニアは技術が好きな人種です。それ自体はいいことなのですが、技術力のある人は無条件で評価されるべきと思っている人が少なからずいるようです。
また、技術的に優秀な人が「この会社はテクニカルスキルを評価しないでマネージメントができる人ばかり評価する」といって辞めることもあります。
はっきり言います。
ちゃんと技術を評価できる会社はあまり多くありません。
外から見て技術を評価しているように見える会社でも、いざ転職すると今までとあまり変わらなかった…となる可能性は決して低くありません。
なぜでしょうか。
評価者が技術のことをわからない
よくあるやつです。評価者（≒上司）が非エンジニアの場合はもちろんですが、エンジニアでもテクニカルスキルは高くないけどマネージメントスキルの高さや社内政治のうまさで上に立っている場合もあります。
たとえば、不具合も障害もダウンタイムもなくサービスを1年間可動させることがどれだけ大変なことかわからない非エンジニアは少なくないでしょうし、エンジニアでもコンピューターサイエンスという基礎知識の重要さを理解できない人も少なくありません。
逆に、バリバリの技術者はあまり評価側に回りたがらないので、技術のことがわかるエンジニアは大勢いる会社でも、評価者が技術をわかっているという場合が意外と少ないのです。
技術は定量的に評価できない
上の「技術を評価できる人がいない」に関連しますが、技術力というのは労働時間のように定量的に（≒数値的に）測れるものではありません。そして定量的に評価できないものは評価者の裁量に任されることが多く、非エンジニアやテクニカルスキルの高くない評価者はどのように評価すればいいのかわからない、という場合が多々あります。
利用者からすれば不具合も障害もダウンタイムもないのは「当たり前」の状態なので、言ってみれば定量的な評価値が0の状態になっているのかもしれません。
コンピューターサイエンスという基礎知識も新しい技術の理解や未知の問題に対する対応力等に役立つのですが、定量的に評価できるものではないので、そんな知識より言語を1つでも多く覚えていたほうが指標としてはわかりやすいので評価されてしまうかもしれません。
会社のビジネスモデル的に、その技術力を活かせない
当たり前ですが、営利企業では利益を上げなければいけません。きちんと技術を評価する会社で、あなたがいくらすごい技術を持っていたとしても、会社がその技術を活かせるビジネスモデルでなければあなたの評価もそれほど上がらないでしょう。
もうすこし具体的に言うなら、会社としてもあなたによって会社にもたらされた利益以上の待遇は与えられないのです。
直接的にせよ間接的にせよ、あなたの技術で今の会社にどれだけの利益をもたらすことができるのでしょうか。
極端な話、言語やコンパイラを作れるような技術力を持った人がそのへんのちょっとしたウェブサービスを開発している会社で評価されるかと言われるとおそらくNOです。
自分の技術力と相性のいい会社を選ばなければ、転職先でも同じような評価をされるでしょう。
あなた自身に問題はないですか？
次に、「会社が悪い」「上司が悪い」だけでなく、あなた自身に問題がないか見てみましょう。自分を客観的に見ていない
あなたは同僚と比べてどんなスキルが優れていますか？周りのエンジニアと比べて「ここは負けない」と自信を持って言えるものがありますか？
「外国と比べて日本はエンジニアの待遇が低い！」
外国とひとくくりにしていますが具体的にどこですか？
その国で高待遇のエンジニアとあなたのスキルをと比べたことはありますか？
その国の事情をどの程度知っていますか？物価は？解雇規制は？
言われたことしかやらない
前回は企業というか評価者へのメッセージとして「指示待ちタイプだけど技術力が高くてきちんと指示通りに動いてくれる人を採用してもいいんじゃないの」的なことを書きましたが、だからといってあなたの上司が今現在そういうタイプに対して高い評価をしてくれる前提で動くと間違いなく期待はずれの結果になります。せっかく能力があっても、指示されたことしかやらないのでは、「誰に任せても大差ない」と判断されます。
見た目は簡単そうでも技術的にはとても高度だという案件はいくらでもありますが、それはエンジニア以外にはわかりません。
ネット界隈では「言われたことしかやらなくて何が悪い」「的確な指示を出すのがマネージャーの仕事だ」という意見もときどき見かけますが、人事評価は相対評価ですから「言われたことしかやらない人」と「言われなくてもどんどん先に進む人」ではよほどスキルに明確な差がない限り後者のほうが評価されるのは仕方がないでしょう。
アピールが下手
せっかくいい仕事をしていて、エンジニア仲間にはなくてはならない人と認識されているのに、「上」へのアピールが下手で評価されない人。「きちんと見て評価するのは上司の仕事だろ！」という意見もありますが、上司もあなただけを評価しているわけではありませんし、給与査定の場での上司の責任は「あなたがやっていることを報告すること」であって、「あなたがうまくやっていることを報告すること」ではありません。
「いやいや、それでもきちんと部下を見ていることがいい上司の条件であって…」と言っても、先程も書きましたが人事評価は相対評価です。アピール材料がある人とない人では前者のほうが評価されるのは当然です。
アピールといっても「ほらほら、これやったよ！すごいでしょ！」と子供が大人に褒めてもらうときのようなアピールするのではなく、「いつ」「何をやり」「その結果どうなったか（←これ大事！）」を関係者が見る場所に簡潔に、客観的に残しましょう。
上司の目にも留まりますし、記録として残しておけば考課面談のときにあらためて上司にアピールできます。
リファクタリングが好き
いや、リファクタリングはとても大事です。そこは否定しません。ただ、得てしてリファクタリングは評価の対象になりにくいものです。
機能向上するわけでもなく構造をわかりやすくするだけの作業は、よほど理解のある上司でないとまず評価されません。
運良く理解のある上司にめぐり合ったとしても、はたして上司は考課会議の場で（非エンジニアの役職者相手に）きちんとあなたの成果を伝えられるでしょうか。
リファクタリングが大事な作業だということは否定しませんが、「今期のあなたの成果は？」に対する答えが「ずっとリファクタリングをやっていました」だと、最悪「成果なし」と評価されることがあります。
ソースコードが汚いままだとモチベーションが上がらないでしょうが、かといってリファクタリングばかりしていて評価されずにモチベーションが0になってしまっては意味がありません。
きちんとした「成果」を出せるように、リファクタリングに使うリソース配分をしっかり決めておきましょう。
ちなみにエンジニア以外に評価されやすいのは「チーム内の困っている状況を（短期間で）解決したとき」です。
例えばみんなが1週間悩んでいたバグを、症状を聞いただけで「ソースコードのあのへんが怪しいんじゃない？」とアドバイスして実際そのとおりだったり、みんながどうやって実装するか困っている案件の設計方針を「こうすればいいんじゃない？」と提案したり、チームの課題をみんなが知らなかった技術で解決したり。
その積み重ねで「こいつ…できる！」と思われ、定量的な評価が難しい場合でも（適切にアピールすれば）「あなたがいなければこの問題は解決しなかった」という事実だけであなたの評価は上がるはずです。
えっと何の話だっけ。
そうそう転職の話だった。
まず会社選びの際は、カジュアル面談や面接の場で事前に評価制度を確認しておきましょう。
その際、上っ面の「弊社は技術も評価していますよ」という言葉を鵜呑みにするのではなく、具体的にどのように評価しているのかを納得行くまで根掘り葉掘り聞きましょう。
そして、あなた自身が高評価を受けるに足らなければ、仮に技術をしっかり評価している会社に転職できたとしても結局今までと変わらない評価しか受けないかもしれません。
「上司がダメだ」「会社がダメだ」「国がダメだ」と考える前に、まず自分自身を見直してみましょう。
0 件のコメント:
コメントを投稿