株式会社Codence代表の西野です。

4月になりました。エンジニアにとって、4月は特別な時期だと思います。プロジェクトの切り替わり、チームの再編、新しい現場への異動。年度の変わり目に合わせて、働く環境が一気に変わる人も少なくないはずです。

新年度の初日に、ひとつ書いておきたいことがあります。私がエンジニア時代に痛感した「技術力だけでは足りない」という話です。

いま振り返ると、この気づきが私のキャリアを大きく変えました。そしてこの4月に新しい環境へ踏み出す方にとっても、何かしら参考になるのではないかと思い、今日はこの話をします。

勉強すれば評価されると信じていた

2018年にエンジニアとしてキャリアをスタートしたとき、私はとにかく技術を身につけることに全力を注いでいました。

当時はRuby on Railsを使った開発が中心でした。業務中はコードを書き、業務後は技術書を読み、週末は個人開発を進める。そんな生活を続けていました。新しいフレームワークが出れば触ってみたし、AWSの資格も取りました。

「技術力さえ上げれば、キャリアは自然についてくる。」

本気でそう信じていました。

実際、スキルが伸びた実感はありました。1年前には理解できなかった設計パターンが読めるようになり、コードレビューで受ける指摘の数も減っていった。対応できる技術領域が広がるにつれて、声のかかる案件の幅も広がりました。

でも、あるとき壁にぶつかります。

技術力が上がっているはずなのに、現場での評価が思うように上がらない時期がありました。「もっと勉強しなければ」と思って、さらに技術に没頭しました。でも、状況はあまり変わらなかった。

現場で頼りにされていたのは、別の人だった

転機になったのは、あるプロジェクトに参画したときのことです。

そのプロジェクトは金融系システムのリプレイス案件で、チームは10人ほど。私はバックエンドの実装を担当していました。

チームの中に、私より経験年数が短いエンジニアがいました。技術的なスキルで言えば、正直、私のほうが上だという自信がありました。実際、複雑なロジックの実装やトラブルシューティングでは私が対応する場面が多かった。

ところが、プロジェクトリーダーが判断に迷ったとき、最初に相談するのはその人でした。クライアントとの定例ミーティングに同席を求められるのもその人。進捗報告の場で意見を聞かれるのもその人。

最初は純粋に疑問でした。技術力なら自分のほうが貢献しているはずなのに、なぜだろうと。

しばらくその人の仕事ぶりを観察して、ようやく理由がわかりました。

その人は、自分のタスクだけを見ていなかったんです。

毎朝、チーム全体の進捗をざっと把握してから自分の作業に入る。他のメンバーが詰まっていそうな気配を察知すると、声をかける。クライアントからの仕様変更があれば、影響範囲を自分から洗い出して共有する。

自分のタスクの完了報告だけでなく、「この先こういうリスクがありそうです」という予測も含めて報告していました。分からないことがあれば、曖昧なまま進めず、その場で確認を取る。

技術的には目立つ仕事をしていなかったかもしれません。でも、プロジェクト全体の安定感を支えていたのは間違いなくその人でした。

一方の私は、割り振られたタスクを正確にこなすことに全集中していました。コードの品質には自信があった。でも、チーム全体の中で自分がどういう役割を果たせるかという視点が、すっぽり抜けていたんです。

「できる」と「任せられる」の間にある溝

この経験で学んだことを一言で言えば、「技術的にできること」と「仕事を任せられること」は別物だということです。

技術力はもちろん必要です。コードが書けなければエンジニアの仕事は成り立ちません。新しい技術を学び続ける姿勢も欠かせない。これは大前提です。

ただ、チームリーダーやクライアントの立場になって考えると、本当に求めているのは「この人に任せておけば大丈夫だ」という安心感なんです。

そしてその安心感は、技術力の高さだけからは生まれません。

進捗を聞かれる前に共有してくれる。問題が発生したら自分で抱え込まず、早い段階で相談してくれる。仕様に曖昧な部分があれば確認を取ってから進めてくれる。自分の担当範囲だけでなく、前後の工程やチーム全体のスケジュールも把握してくれる。

こうした行動の一つひとつは、特別なスキルではありません。誰にでもできることです。でも、これを当たり前にやり続けられる人は意外と少ない。だからこそ、それができる人は「任せられる人」として信頼を勝ち取っていきます。

SESの現場では、この差がさらに大きくなる

その後、私はSESのエンジニアとして複数の現場を経験しました。

SESという働き方には、一つ特徴的な構造があります。新しい現場に入るたびに、信頼関係をゼロから構築しなければならないことです。

前の現場でどれだけ実績があっても、新しいチームにとっては「今日から来た人」でしかない。過去の経歴書に何が書いてあろうと、目の前のチームが見ているのは「いま、この人と一緒に仕事をして大丈夫か」です。

そのとき、技術力だけでアピールしようとすると限界がある。最初の数週間で「この人は信頼できる」と感じてもらえるかどうかは、コードの品質よりも仕事への向き合い方に左右される部分が大きいのです。

初日に自己紹介をして、チームメンバーの名前を覚える。開発環境のセットアップでわからないことがあれば、遠慮せず質問する。最初のタスクが終わったら、完了報告と合わせて次にやるべきことを確認する。チームのルールや慣習を、その背景も含めて理解しようとする。

どれも技術とは関係ないことばかりです。でも、この最初の振る舞いで「一緒にやっていけそうだ」という印象が決まる。逆に言えば、ここで距離を感じさせてしまうと、技術力を見せる機会すら回ってこないこともあります。

私自身、このことに気づいてからは、新しい現場に入るときの意識が変わりました。技術的な準備はもちろんしますが、それと同じくらい「チームにどう溶け込むか」を考えるようになった。結果として、現場での信頼を得るまでの時間が明らかに短くなりました。

経営者になって、改めて確信したこと

2025年にCodenceを設立して、今度は「エンジニアを送り出す側」の立場になりました。

クライアント企業と日常的に話をするようになって、エンジニア時代に感じていたことが確信に変わりました。

技術スキルの高さだけでエンジニアを選ぶ企業は、ほとんどありません。

もちろんスキルは見られます。要件に合った技術スタックの経験があるかどうかは前提条件です。でも、面談でスキルシートの内容を確認した後に出てくるのは、こんな質問です。

「チームでの仕事の進め方について教えてください。」

「困ったとき、どうやって解決しましたか。」

「前の現場では周囲とどんなコミュニケーションを取っていましたか。」

技術的な質問よりも、こうした「人となり」を確認する質問のほうが多いことも珍しくありません。クライアントもわかっているんです。技術力は後から伸ばせるけど、仕事への姿勢やコミュニケーションの取り方は、すぐには変わらないと。

だから私は、Codenceのエンジニアと話すときに必ず伝えることがあります。

技術は磨き続けてほしい。それは前提だ。でも、技術と同じくらい「この人に任せたい」と思ってもらえる存在になることを意識してほしい、と。

スキルアップの勉強に費やす時間を削れという意味ではありません。技術力が土台であることは変わらない。ただ、その土台の上に何を積み上げるかで、エンジニアとしてのキャリアの幅はまったく変わってくる。

私がこの差に気づけたのは、あのプロジェクトでの経験があったからです。もしあのまま「技術力さえあれば」と思い込んでいたら、ずっと同じ壁にぶつかり続けていたかもしれません。

この4月、新しい環境に入る方へ

今日は4月1日。新年度の始まりです。

新しいプロジェクトに配属される人。転職して新しい会社に入る人。異動で別のチームに合流する人。いろいろな方がいると思います。

もし「技術力を上げなければ」というプレッシャーを強く感じているなら、一つだけ提案があります。

技術の勉強と並行して、目の前のチームにどう貢献できるかを意識してみてください。

難しいことをする必要はありません。進捗を聞かれる前に共有する。不明点を曖昧なまま残さない。隣の人が困っていたら声をかけてみる。

こうした小さな行動の積み重ねが、「この人は信頼できる」という評価につながり、やがてより面白い仕事や責任ある役割を任されるきっかけになります。

技術力は、努力すれば着実に伸びます。一方で「任せられる人」になるためには、技術とは別の意識が必要です。

私がこのことに気づくまでには数年かかりました。もっと早くわかっていれば、と思うこともあります。だから、いまエンジニアとして走り出している方に、この話を伝えたかった。私たちも、技術力を磨きながら、「一緒に働きたい」と言ってもらえるチームを目指して進んでいきます。