春になって暖かくなると、ついつい意識が高ぶってしまいますね。

今回はあくまで個人的な、エンジニアの評価基準とキャリアパスについての私見を、どちらかというと新人の方向けに垂れ流してみたいと思います。

はじめに

新人の方々は今頃は、研修に追われていたり、それが終わっても配属先で揉みくちゃにされる日々が待っているでしょう。中には既に後ろ向きな思考になっている人もいるかもしれませんが、そういう人には今回どうでもよい話で、前向きな人がそのエネルギーをエンジニアとしての成長に無駄なくつぎ込むために、若いうちにあまり考えないけど、考えておいた方がよい話をします。

ITエンジニアとして始動すると、目の前に与えられた仕事だけでも楽しいのに（その過程で苦しむのは別として）、さらにその先にIT知識が広く深く待ち受けていて、こんなことをやりたいんだ、全部マスターしてやるんだと意気込むかもしれません。そして、目の前の物事に集中し、給料もそれなりにもらえているなら、そのまま突っ走ることでしょう。

それはそれで大切なことなのですが、そういう時期には、突っ走った先の3年後・5年後・10年後の自分が何をしていて、どのくらい給料をもらっているのかといったことを想像することは難しいと思います。また、想像もできないと思います。これは10年後にどんな技術が流行っているかわからないし、という具体的な技術の話ではなく、組織的にどのようなポジションを目指すかという話です。目の前のことに躍起になっている時期は、組織の全体像や、上から下までどのような人材が必要とされているか、という話題には興味を持てませんし、また、自分から遠すぎるポジションの役割について理解することも難しいからです。

先を見据える「先」とは大体この辺のことです。アプリケーションなりインフラなり分析なり、職種ごとに一通り浅く、そして1つ2つ深堀りしてきて、エンジニアとして美味しく煮詰まってくる頃、必ず壁と分岐点がやってきます。ここでいう壁とは金、分岐とはキャリアパスのことです。それを早くから意識しておくことで、日々の目標や学びに芯が通りますし、なにより将来の社会人としての仕上がり度合いに影響してきます。

ということで、金と道についての小賢しい話を始めます。

エンジニアの評価制度

まずはエンジニアがどのように評価されるかという話です。評価とは、まんまカネです、金。高ければ次からお給金が高くなりますし、低ければ据置き以下になります。ただし、個人要素以外に企業の業績連動という、儲かっている時は上がりやすく赤字駄々漏れの時は下がりやすい仕組みもありますが、その話は今回は抜きにします。

さて、IT企業の評価制度の主軸は、年功序列ではなく成果主義であるところがほとんどでしょう。半年など一定期間ごとに目標を設定し、目標のズレを微調整しつつ、最終的に何をどの程度に仕上げて何に影響できたかを、評価という数値に落とし込み、それがお給金の増減として反映されます。

ただこの仕組みって、多数の従業員を抱える企業が、できるだけ公平に評価するためにあるので、スタートアップ期はそんなまどろっこしいことせずに限界にチャレンジするだけでしょうし、ひとつふたつ頭が抜けたエンジニアの場合はただの足枷となることもあります。ですので、ここではそういう特殊なエンジニアではなく、ごく一般的な社畜エンジニアの立場における話とします。

まず、評価するには目標が必要です。目標は、その人が今できること、そして少し難易度高くチャレンジすることを設定し、組織として堅実な成果を得ることと、個人に昇格機会を与えることを両立します。半年間の間、プロジェクトは色々動くので、マネージャと相談しつつ目標を調整し、半年後に最終面談をしてお互いが納得するよう評価を決定の上、さらなる上層部が最終決定を下し、良くも悪くも覆すことができない結果が返ってきて、また目標を立てる繰り返しになります。

ここで何気に大事なのは、エンジニア個人が調整したりアピールできるタイミングでボーッとしていないことです。目標は自分に適した内容になっているのか、自己評価に他の人が知らないプラスポイントのアピールを含めるのを忘れていないか、自分で考え、納得するまで相談しなくてはいけません。マネージャも人間ですので、部下の全てを感知できるわけもなく、はてブに出てくる『アタシが言わなくても察してよ』みたいなゴシップノリが通じるはずもありません。エンジニアは口下手でお金に執着が少ない傾向が強いですが、俺凄ぇアピールはしないと損なだけなので、グイグイ押して押しまくるようにしましょう。

エンジニアの評価基準

目標を立て、評価をし、を繰り返すとすぐに立派な中堅エンジニアになっています。ペーペーだった頃から中堅になるまで、技術力はこんなイメージで、得意分野が確立されつつも、離れた技術も多少なりとも広く浅く伸びてくることでしょう。



この、技術力の得意分野磨きと、全体の底上げがされるにつれて、当然、成果もグイグイ出せるようになってくるわけです。



ここで大事なのは、評価基準が技術力の面積ではなく、成果の面積というところです。なので、総合力が低くとも得意分野を活かして成果を上げる人もいれば、器用貧乏で大成できない人もいます。最初のうちは目の前のことをやり切ることや、ひたすら勉強することは重要ではありますが、それが果たして本当に成果に結びつくのかを一歩引いて考えると、そのまま突っ走るべきかもしれないし、組織の人材事情や自身の適性から、少し職種を横にズラしたほうが成果の大きさや効果を得られることに気づくかもしれません。

最も好きな分野を手がけて、最も成果を得られることが最高の幸せですが、多少、嗜好とズレた役割になったとしても、組織内でブルー・オーシャンな人材になれるとしたら、多少の辛抱と引き換えに大きな成果を得られるかもしれません。逆に、好きなことを貫いてグッと突き抜けるにせよ、伸び悩むにせよ、新人から中堅にかけては、とにかく１つないし２つの分野をやり切る力をもつことが大切です。

エンジニアの壁

中堅になってくると、エンジニアとしてはだいぶサマになってくるのですが、だんだんと伸び悩む時期が近づいてきます。技術力的にはこんな感じで面積は広がっていくのですが、



成果としては少しずつ上がっていっても、劇的な変化は難しくなります。



これはあらゆる努力に共通する話ですが、IT技術力の向上においても、時間の経過に対して修得度の上昇はどんどん鈍くなっていきます。もっと言うと、精度ばかりが向上していきます。さらに成果面で言えば、いかにIT技術が多種に渡って深い、と言っても、仕事の成果に結びつく技術力なんてアホみたいに深堀りする必要なんてなく、それなりの深さと広さ、そして精度があれば十分なので、成果が伸び悩むのは必然となります。

これについては私自身、考えた時期があり、だいたい半年おきに次々と違うことをやってきて、インフラシステムとして残したものはほぼ全てを余計な運用の手間なく放置できるように仕上げ、知識量としても相当な量を積み上げてきたと自負しています。なので、評価面談の時には心情的に、それまで積み上げてきたモノと技術力、知識を総合的に評価してもらいたく面談に臨んでいました。

しかし、評価軸が”成果”であるので、漫然とした総合技術力などではなく、あくまでその”半年間の成果”しか見てもらえないのです。一人の人間が、わずか半年の間に挙げられる成果など、格別なイノベーションや社会影響を起こす特別な状況を除くと、ある程度上限があるに決まっています。プログラミング言語でいえば、いかに5言語10言語とマスターしても、半年の間に使用する言語はせいぜい多くて2つか3つです。インフラ技術を幅広く深く知っていても、半年の間にBigData基盤しか作らなければ、成果はその基盤だけなのです。

これは実に健全な仕組みであると理解しつつも、技術力を売りにしているエンジニアとしては納得がいかない、いきたくないもどかしい面でもあります。しかし、短い期間で必要とされる技術がコロコロ変わっていくエンジニア業界にとっては、古い技術の価値がどんどん低くなっていくという現実もあり、納得せざるを得ない部分もあります。

そのまま伸び難くとも確実な成果を残せるポジションを続けてもよいのですが、このシステムでより上を目指すとなると、次のキャリアパスの話に行かざるを得なくなるのです。

エンジニアの分岐点

では、どのように成果を大きくし、評価を上げるかと前向きに考えていくことになります。単体の技術力、総合的な技術力、単体の成果では物足りないというのであれば、どうしたらいいのかと。

答えは、”対複数” です。
１つの仕事で、複数の人間や複数のサービスに影響を与えればよいのです。

例えばマネージャ。これは複数の人間のタスク管理や、別部署や外部の会社との外交などで広範囲を管理します。ただ、最近だとごく普通の管理職の必要性が薄れてきていて、技術現場上がりのプレイングマネージャが求められるようになってきています。

次に育成担当。初めは１人のメンターとして新人の成長を促すかもしれませんが、適性があるとわかり、より多数の人間の成長を促すようになれれば、講師という広範囲の社内影響です。

そしてエヴァンジェリスト系。とは言わなくても、会社の魅力を外部に伝えるような活動を行えば、採用面・営業面などが有利に働くので、立派な広範囲影響です。

システム面でいえば、１つのシステムで全サービスの運用が楽になるような、１つの分析で全サービスの利益になるような、自動化によって人的リソースを軽減できるような、そういう仕組みづくりが大きな成果になるといえます。

こういったRPGでいう上級職的な道は、大企業なら既に先人が道を切り開いているでしょうし、小さい企業なら自分で開拓することになるかもしれません。それまでに培った自分のいくつかの武器を元に、自分にとって組織にとってお互いが有益な道を模索し、自信を持って突き進んでいきましょう。

さいごに

若く、エンジニアリングが楽しい盛りの頃は、そのまま技術だけやって、そのまま給料が上がればいいなと考えますし、エンジニア同士としても、１つの技術をアホみたいに極めるエンジニアには尊敬の念を抱きます。しかし、そういった考えと社会的な評価は全く異なり非常に現実的です。また、分岐の道を選択し進むことは”逃げ”や”出世”とも違い、自分にできる最大の影響力を発揮する道の開拓といえます。

・・・とはいえ、実情としては、さらなる技術力に自信がないから管理系へ。管理が苦手なコミュ障だから技術系で。という消去法的選択が存在することも否定はできません。ただ、それが逃げとなるか向上心に変換できるかは本人の心持ち次第です。そして、よく言われるエンジニアにもコミュ力を、という話は、日々の業務にもそうではあるのですが、それよりもこういった分岐点における選択肢の広さにおいて、書ける・話せる・仲良く出来る、といった能力が役立つということを理解できていれば、根暗なままでいようなどと思えないはずです。

また、どの方向にも伸び切れず停滞する場合も少なくありません。そのため、こういった仕組みや考え方を早い段階で認識できれば、無駄に悩みヒネくれヤサぐれた時期を過ごさずに、スムーズに自身の成長と評価を向上させるための勉強や態度をとっていける……はずです。この会社は技術力を正しく評価してくれない……とか、技術単発でももっと評価されるべきだ……といった不平不満を抱える時期もあるかもしれませんが、漠然と怒ったり悩むのではなく、まずは基本となっている評価やキャリアパスの仕組みを正しく理解し、その上で声を上げたり自身で手がけていけるようになるべきです。

あと、どのような分岐を選ぶにせよ、１つ確実に言えるのは、エンジニアがシステムと関わらなくなったらただのクソになるということです。片手間、でもなく、両立できる道を模索するべきです（と、私もまだ若めなので思っている）。それを可能にするのが、エンジニアとしての実績と信頼です。そのためにも、エンジニアとしての前半戦、特に最初の１～２年はしっかりと確実な地力をつけるように頑張りきってしまうべきです。

……ということを、若いうちは多分考えるの無理なんだけど、それでも考え、積極的に周囲の先人たちに話を聞いてみて、そしてまた考えてほしいと思います。

生きるだけならまだしも、真の向上を目指すならば、どんなエンジニアも定年まで技術一本で押し通すことなど、ほぼあり得ないのですから。