今の自分がWebエンジニア1年目に戻って伝えたい7つの教訓

最近新人育成に興味を持ち始めたので、4月に入社するであろう新人向けに伝えたいことを書く

フロントエンドだけを軸にしない（ほんの一部天才は除く）

フロントエンドはユーザーに最も近く、目に見える形で成果が現れるため分かりやすく、初心者でも花形の分野のように感じられることが多い。しかし、Webエンジニアとしてキャリアを積むうえでフロントエンドだけに軸を置くことはおすすめできない。

なぜなら、フロントエンドの技術は変化のスピードが非常に速く、ほんの一部の天才的なエンジニアしかその全貌を正しく理解し使いこなすことができないからだ。実際の開発現場においても、フロントエンドの重要な部分（ユーザービリティー）の多くはデザインに依存しており、エンジニアにしか提供できない価値というのは主にパフォーマンス改善などの技術的側面に限られている。そのため、フロントエンドの領域で真に価値を発揮するには、極めて深い理解が必要となり、大きな労力と時間を要する。

また、フロントエンドの学習においては自力で多くのことを調査・勉強しなくてはならない。世の中にあるソフトウェア設計に関する多くの書籍や理論は、主にデータを中心に構成されている。一方で、フロントエンド開発の中心はデータではなく「状態（ステート）」であり、この状態を軸とした設計について深く掘り下げた書籍や資料は非常に少ないのが現状だ。そのため、体系的な学習方法が存在せず、フロントエンドエンジニアは手探りで知識を身につけていく必要がある。

こうした理由から、フロントエンドだけに集中してキャリアを築くと、技術的にもキャリア設計的にも苦労する可能性が高まる。Webエンジニアとして長期的に成長し続けるためには、バックエンドやインフラといった他の技術領域にも広く視野を持ち、バランス良く技術力を伸ばすことが重要となる。

もしほんの一部の天才に該当する場合、とても貴重な人材なのでフロントエンドに集中してフロントエンドの発展貢献してほしい

評価はされるものではなく、してもらうもの

新卒のエンジニアにとって、「評価」とは何かを改めて考えてみる必要がある。評価の基本的な構造は、作業者が成果を出し、それを評価者が評価するというシンプルな仕組みだ。しかし、SNSなどを見ていると「成果を出しているのに評価されない」といった不満をよく目にする。この原因は、作業者が自分の成果を出すことだけに集中しすぎている点にある。

評価者が認知できていない成果をいくら出しても、それが評価に繋がらないのは当然だ。上司や評価者には部下を適切に評価するという役割があるが、それは彼らの仕事の一部でしかない。作業者側にも、「評価をしてもらう」という意識が必要になる。これは単に評価者の機嫌をとったり、仲良くなったりすることではなく、評価者が認識できる場所や形式で成果を明確に示す努力を意味する。

もちろん、見えない成果も数多く存在する。それらは短期間で評価されるものではなく、継続的な積み重ねによって徐々に明らかになるものだ。だからこそ、すぐに評価されなくても成果を出し続ける姿勢が重要である。自ら成果を評価者に届けるための工夫や努力を重ねていくことが、正しく評価される近道となる。

打席に立つことはすごいことではない

新卒エンジニアが入社した段階では、全員が同じスタートラインに立っているわけではない。学生時代にインターン経験がある人や社内に知り合いの先輩がいる人は、すでにある程度の社内認知を得ている場合がある。一方で、まったく認知されていないままスタートを切る人もいるだろう。

社内での認知度が高い人は、そうでない人に比べて仕事の機会（打席）に多く立てる傾向がある。つまり、入社初期の段階で多く打席に立てる人が必ずしも優秀であり、立てない人が優秀ではないというわけではない。打席に立てるかどうかは、実力の有無よりも「認知」の問題であることが多い。実際、仕事を振る立場からすれば、能力が未知数な人よりも、ある程度能力や性格を把握している人の方が安心して仕事を任せやすいのは当然だろう。

重要なのは、打席に立ったという事実ではなく、その打席でどれだけ結果を残せるかということだ。入社後しばらくは打席が少なくても焦る必要はないが、1〜2年経過しても状況が変わらない場合は、自分自身の実力や周囲とのコミュニケーションに何らかの課題がある可能性が高い。そのような場合には、自ら積極的にアクションを起こし、状況を改善していくことが大切だ。

人脈は大切

大きな成果を出すためには、一人の力だけでは限界がある。必ず誰かの助けや、部署を超えた協力が必要になる。そのときに重要になるのが人脈だ。

仕事で関わった人との縁をその場限りの関係として終わらせていると、なかなか人脈は広がらない。人脈と呼べるような信頼関係を築くためには、さまざまな方法がある。

例えば、飲み会や雑談など業務外でのコミュニケーションを積極的にとることも一つの方法だし、中期的に安定した成果を出し続けることで信頼を獲得することも可能だ。また、短期的に目に見える成果をあげたり、障害対応のような緊急で難易度の高い課題を一緒に乗り越えることも信頼構築に非常に有効だ。

もちろん、業務外でのコミュニケーションを必ずしも行う必要はない。ただし、そうした場を避ける場合には、それを補えるほどの高い能力や成果を示さなければ信頼関係を築くのは難しい。そのため、自分の能力やコミュニケーションスタイルを考えた上で、人脈をどう築いていくかの戦略を立てる覚悟が必要だ。

色々なコード読め

実際に動いているコードには、さまざまな歴史が詰まっている。よく言われる言葉に「愚者は経験に学び、賢者は歴史に学ぶ」というものがあるが、これはコードを読む際にも当てはまる。

コードを読むにはコツがある。単にコードが「どのように（How）」動作しているかを追うだけでなく、そのコードが「なぜ（Why）」書かれたのかを想像しながら読むことが大切だ。例えば、一見すると「クソコード」と思われるようなコードであっても、実は合理的な理由があったりすることもある。セキュリティインシデントなど緊急性の高い案件でスピードが優先されたり、リファクタリングの途中段階であったり、あるいは仕様そのものに問題があり、やむを得ず強引な実装をしたケースもあるかもしれない。実際に当時を知る人に話を聞いてみると、その背景を知ることができ、思わぬ学びにつながることもあるだろう。

もちろん、本当に質の低いコードも存在するが、それもまた重要な教材になる。なぜそのコードが悪いのか、どこに問題があるのかを深掘りすることで、自分自身が同じ過ちを犯さないための歴史的教訓になる。

自ら苦い経験を積まなくても、コードを通じて多くの教訓を得ることができる。色々なコードを読む習慣は、新卒エンジニアにとって貴重な学びの機会だ。

長期的に自分の書いたコードを保守することは重要な経験

自分の書いたコードの品質や設計を評価する最も簡単で確実な方法は、自分自身がそのコードを長期間保守してみることである。

特に3年以上といった長期間にわたって保守する経験は非常に有益だ。1年未満の短期間では大規模な改修が発生せず、自分の設計が本当に良かったのかどうかを判断するのは難しい。コードの真価が問われるのは、仕様変更や大きな改修、緊急で迅速な対応が求められるような場面である。そのような局面で、自分の設計が保守性や拡張性をどれほど担保できていたのかが初めて明らかになる。

他人のコードを読んだり、書籍から設計知識を得たりすることで理論や知識を蓄えることはできるが、自ら設計を行い、その結果を数年にわたって体感するという経験は、エンジニアとしての成長において極めて貴重だ。短期間で転職や異動を繰り返している場合、このような価値ある経験を得る機会を逃していることは理解しておくべきだろう。

ただし、エンジニアとしてではなく、「技術を理解しているビジネスパーソン」としてキャリアを築いていきたい場合には、必ずしもこの経験が必要というわけではない。自分の目指すキャリアによって、この経験の重要性を適切に判断すればよい。

成長を認知できることは稀

同じ部署で一定期間仕事を続けていると、次第に似たような業務ばかりに感じてしまい、自分が本当に成長しているのかどうか分からなくなることがある。このような「停滞感」は緩やかな死にも例えられるほど危険な状態であり、同期や周囲の活躍を見て危機感を抱くこともあるだろう。

しかし、そもそも自分自身の成長をリアルタイムで認知することは非常に稀だ。焦りを感じる必要はない。実際は同じように見える業務でも、毎回少しずつ新しい要素が含まれている。小さな工夫を加えて実装を変えてみたり、仕事の進め方を見直したりといった変化が起きているはずだ。ただ、その変化や積み重ねを日々の仕事の中で自覚することは難しい。

自分が成長したことを明確に認知できるのは、転職や異動などで環境が大きく変わったときである。新しい環境に移った際、それまで身につけてきたスキルや考え方の変化を初めて実感できることが多い。

重要なのは、常に改善しようという意識を持ち続けることであって、成長を実感できるような環境にわざわざ身を置くことではない。日々の小さな改善や学びの積み重ねこそが、長期的に本当の成長につながっている。